Particle Matter: Updates from Sprint 40

Here’s some updates from our latest sprint.

tl;dr Photon improvements, and working on the Electron!

Hardware Team

  • The Electron hardware design was open-sourced! Egads! Check it out at www.github.com/spark/electron – we’d love your feedback and thoughts about the current direction of the design.
  • We’ve completed purchasing for all of the materials needed for the beta run of Electrons that we’ll be doing in mid-August, and things are running on schedule.
  • We’ve learned a lot from the frustrating sourcing process for the Photon, and have purchased all long-lead-time components for mass production well ahead of schedule.
  • We manufactured and shipped a bunch more Photons and Shields out of China, and we will be wrapping up all pre-orders within the next sprint.

Software Team

  • We started the dashboard private beta! Organizations and products are getting created in our systems, and beta testers are giving us all kinds of great feedback. This is clearly a super useful tool for product creators!
  • The whole team spent a great deal of time testing a new firmware system module updater in preparation for release this week along with a firmware release. UPDATE: This will be released sometime next week due to some major infrastructure changes that we need in place before we can distribute the firmware update to everyone.
  • We upgraded arm-none-eabi-gcc of the cloud compiler from 4.8.4 to 4.9.3 to prepare for new firmware which requires >= 4.9.3.
  • The Electron firmware team achieved their first cloud connection!
  • Many people on the team did research and work toward a broad spectrum of Electron user experience and cloud infrastructure goals, with the primary sprint objective of driving out uncertainty. For the Electron beta test in August, we will use the existing TCP device service, but we’re building a new UDP-based device service for deployment in October. The goal is to stay as close to the CoAP spec as we can. We’re designing systems to support sleepy devices as a primary use case. We also have started some of the back-end carrier integration work, and we made some billing and metering system architecture decisions.
  • We made some DevOps infrastructure changes to prime the cloud for more granular version upgrades.
  • We added some more team member management endpoints for the dashboard.
  • In mobile, we hit a big milestone—both SDKs (iOS and Android) are released and fully documented!
  • We also added analytics to the open source Tinker iOS app and device setup library. This will allow us to understand some hard to diagnose bug reports, and since it’s open source, it gives clear guidance to everyone who creates their own mobile apps on Particle on how to integrate analytics.
  • One more common request in mobile has been to separate the ability to perform Wi-Fi setup from the authentication and claiming process. We got this done in the iOS SDKs, and Android will follow soon.

Business Team

  • Got new documentation ready to ship, build it locally here if you like. These updates will go live this week. We’d love your thoughts and pull requests when they do.
  • Continued to move forward with the Electron. If you’re a backer, you saw our most recent update
  • We took steps forward to improve both our e-commerce and order fulfillment experiences-- stay tuned!
  • Continued to fulfill Photons
  • Ran our first Particle Interactions interview with CEO Zach Supalla. This has finally been transcribed and will be put on the forums or blog presently. Watch out for another interview next week.
  • Sent @christine to FAB11 in Boston, an amazing conference where we joined forces with Alroy Almeida of Voltera to give a talk on prototyping to production
11 Likes

I just grabbed the most recent LATEST build from Github, hoping that some pesky bugs would be fixed. OUCH--an empty binary compiles to 87,880 bytes! Are you kidding me???? As though 78KB of firmware in the Core was bad enough. Or is the firmware yet a work in progress, with lots of space consumed with debug? I submit that effort should be made to reduce the size of the firmware, especially when we already have only 40K of user code space available:

d:/particlebuild/arm embedded 4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld.exe: region `APP_FLASH' overflowed by 1680 bytes
```
:cold_sweat: :cry: :sob:

EDIT: Takes my binary from 99,060 bytes to beyond the 110,592 byte maximum.  Back to the month-old LATEST version...I can at least compile my project then.  @zachary As head of firmware development, do you have any comment about the firmware size?

Hi @WebDust21,

Good question! I completely understand why you’d be surprised that the new core firmware with the hardware-abstraction-layer might be bigger, especially with the debug flag in place!

The newer HAL firmware has been mostly focused on supporting the photon, and unlocking the features it offers, while speeding up the time it takes to OTA an app to the device. We haven’t made a size optimizing pass for the Core yet, and this firmware is still rather experimental for the Core, which is also why it’s not generally available via the build farm yet.

We also noticed that the 4.9.3 version of the arm-none-eabi-gcc compiler has a size optimizing regression, which causes the compiler to not optimize in the same way as it did before. Here are some bugs on the compiler bug tracker that people have reported as fixed in the 5.0 (unstable) version ( Here , and here ).

I’m sorry that the current unreleased experimental debug firmware build for the core uses an extra 10KB, I’ll ping the firmware team and ask if they can take a size optimizing pass before it’s released.

Thanks!
David

1 Like

I’ve been using ARM Embedded 4.9 2015q2 as the compiler (arm-none-eabi-gcc). Same compiler, same project…just different firmware. Digging into the 1,182 page reference datasheet to see if I can figure out how to get the A/D converter to read full scale…

1 Like

@dave, after some bug frustrations, I decided to play around with the most recent DEVELOP branch. (Good luck trying to get me to do anything with GitHub–I can’t even get the Git GUI to download the DEVELOP branch–all it does is download one third of the released build. I’m about to save myself the 100MB of wasted disk space.)

Finally downloaded SwiftCompare from Oorja Software, and manually started merging the most recent DEVELOP with my month-old LATEST:

BOOTLOADER was no problem to merge
BUILD - merging this one wrecked the program! Now I get the following errors:

```d:/particlebuild/arm embedded 4.9 2015q2/bin/…/lib/gcc/arm-none-eabi/4.9.3/…/…/…/…/arm-none-eabi/bin/ld.exe: …/build/target/main/platform-0/main.elf section .text' will not fit in regionAPP_FLASH’
d:/particlebuild/arm embedded 4.9 2015q2/bin/…/lib/gcc/arm-none-eabi/4.9.3/…/…/…/…/arm-none-eabi/bin/ld.exe: region APP_FLASH' overflowed by 4176 bytes ../build/target/user/platform-0/applications/mproj/\libuser.a(application.o): In functionPOff()’:
d:\ParticleSrc\firmware-latest\user/applications/mproj/application.cpp:537: undefined reference to `SystemClass::sleep(unsigned short, unsigned short, long)’


It's nothing with the firmware fixes, etc.—it's the changes to the build configuration that make it too big!  "De-merging" back to the month-old "LATEST" build folder results in a successful compile.

Keep merging in other folders from today's "DEVELOP"...

WIRING - I had to keep some of my space-saving changes.
USER - had to keep my project folder
SYSTEM-DYNALIB - no changes
SERVICES-DYNALIB - no changes
SERVICES - no appreciable changes
SYSTEM - no serious changes.

<strong>At this point, my project compiles.</strong>  It is 103,488 bytes in size, as compared to month-old "LATEST" building the exact same project at 101,252 bytes.  No big deal.

Keep working...

PLATFORM - I'll gladly take those CC3000 fixes.  (Whoops: results in a build error.  Maybe it needs some other definitions...)
MODULES - that's for the Photon.  Hey, maybe it'll rub off on the Core :wink:
MISC - no changes
MAIN - no changes
HAL-DYNALIB - not sure what this does, but no changes.
HAL - better believe there's some changes in here!
DYNALIB - the readme got bigger.  No other changes.
DOCS - those don't compile anyway :stuck_out_tongue_winking_eye: 
COMMUNICATION-DYNALIB - new, don't think it'll be a problem

Still getting the "hw ticks" errors from above.  Hmm?

COMMUNICATION - expect only good changes here.
CI - nothing new.

Still getting the errors.  Nothing left to do but the BUILD folder.  Let's start with subfolders...
BUILD/ARM - some changes
BUILD/BIN - same'ol
BUILD/TEST - no changes
BUILD/TARGET - that's all output stuff.  Merge...

<b>Woohoo!</b>  Got a bunch of "Spark is now Particle" warnings...and it builds to 103,784 bytes.  ~400 bytes more than the first build, and 2,532 bytes more than the month-old LATEST.  I don't mind this for progress.  So far so good!

The ONLY thing left to merge are the files in the root of "firmware-develop\build."  That's the only thing left to add 10K to the firmware size.
- No changes to any of the files except for "module.mk" and "module-defaults.mk".  Output BIN is the same size.

<b>module.mk</b>:  It's smaller than the old one.  Code should do the same???  ""make": *** No rule to make target `../build/module-defaults.mk'.  Stop."  :cry:

<b>module-defaults.mk</b> Building...

d:/particlebuild/arm embedded 4.9 2015q2/bin/…/lib/gcc/arm-none-eabi/4.9.3/…/…/…/…/arm-none-eabi/bin/ld.exe: …/build/target/main/platform-0/main.elf section .text' will not fit in regionAPP_FLASH’
d:/particlebuild/arm embedded 4.9 2015q2/bin/…/lib/gcc/arm-none-eabi/4.9.3/…/…/…/…/arm-none-eabi/bin/ld.exe: region `APP_FLASH’ overflowed by 4312 bytes
collect2.exe: error: ld returned 1 exit status
"make": *** […/build/target/main/platform-0/main.elf] Error 1


That results in a calculated BIN size increase of 11,120 bytes.  All because of the new makefile rules!  Pppplllleeeeeeeeeeaasssssseeeee..........can this be fixed?

We've just reverted the cloud compiler used by the Web IDE, CLI, and IDE to 4.8.4 20140526 to make this issue go away. For Core users running into memory limitations, this should set things straight again.

3 Likes

so, this is why itoa() both came and went away?

is this the appropriate place to look for updates on cloud compiler?

Hi @BulldogLowell,

I wasn’t tracking itoa specifically, but that sounds right, sorry about that. We’ll post another thread when we release more cloud build farm updates, hopefully soon this week!

Thanks,
David

1 Like