V0.5.x Release Candidate: Execution Scheduler Redesigned

WOW! this sounds like something that will open many new possibilities!!! cant wait to see what’s boiling :slight_smile:

Sorry if this is dumb question, but does this mean we will need a new cpu or hardware to move on to 1.0 ?

I feel like 99.99999% certain Brian would not do that to his customers. I’m sure it means something awesome for us, whatever it is.


I hope it allows us to have a neat dev environment for third party modules custom-units(I bet @Joe dreams of this!)


Sure, always looking forward to advances on the development enablement front. Right now I think the biggest pain point is swapping the SD card from computer to 301 to test/debug. Sometimes I get lucky. For other units I’ve probably moved the SD back and forth hundreds of times to get it right! :slight_smile:


Substantial changes in my build/development environment masquerading as a minor bug fix release. :grin:

v0.5.02 CHANGES

  • SYSTEM: Moved build environment from Code Composer Studio on Windows to GNU make on Linux.
  • FIXED: Oscilloscope > Reduced the appearance of gaps in traces of waves with discontinuities (e.g. square, saw, and so on).
  • FIXED: Teletype Integration > Jitter in message timing grew over time.
  • MAYBE FIXED?: Teletype Integration > Need to wait for ER-301 to finish booting before booting other I2C devices. Feedback needed.
  • FIXED: Sample-and-Hold, Track-and-Hold units > Held values were not being restored properly from presets/quicksaves.
  • FIXED: HOLD mode > When adding an empty PinSet, the new (empty) PinSet rendered with zero width.

Ooooh I can’t wait to test this one out! Thanks Brian!


(from the other thread)

Very happy to report I have been running continuously for over 7 hours with solid timing, same script that used to fail everytime between 30-60 minutes. Great Job Brian!

Also, I noticed that with the same quicksave my CPU usage went from %51 to %60 percent from 0.5.01 to 0.5.02. Is this expected?

Scope improvement looks solid too! (pun, har har)

1 Like

Not expected. I’ll take a look.

1 Like

Is there a performance increase when using “standard latency” firmware vs “low latency” firmware? If so, how much of a performance gain is it to use “standard latency”?

1 Like

Thanks so much!

Which scenarios should we test and provide feedback on? IOW: what’s this fix addressing?

I can also confirm that a quicksave that uses 26% when loaded in v0.5.01 uses 32% when loaded in v0.5.02

Have you enables i2c? If so is it being used when comparing those two numbers? Is the cpu also going up with no i2c?

I had I2C enabled for both previously quoted CPU loads. When I disable I2C in v0.5.02 the CPU load goes down by 1%

Change of development environment probably also means change of compiler which probably also means a change in compiler optimizations. From past experience, I know this can have substantial influence. Of course, I know nothing about this particular case. Just guessing…

First report back. I’ve had a semi buzy teletype scene running all day (some of the time while doing other things). Almost all things were happening on the 301

Good news: all SC.TR seems to align when ever I checked back. So the rhythmic relationship between the triggers over i2c seems to be in sync with each other! Don’t think that would have happened before.

Bad news: I wanted to add a timed modulation of an external module and found that all i2c triggers to the 301 were delayed one M cycle. Super tight, but all delayed the exact same amount. Rebooting the 301 made everything align perfectly again…

I don’t know when this happened (was I doing something or did it happen while I was away?), will make sure to incorporate triggers both over i2c and regular triggers from now on, hopefully I’ll notice exactly when the shift occurs and be able to give a more meaningful report…

EDIT: @odevices is it OK to report findings here, or should I use the “strange experience” thread?

1 Like

Just chiming in to say I tried this new firmware with my 16n and it works! I don’t need to plug my 16n in after boot up. It’s the best! I just left everything plugged in and turned on my system and it just connects. Thanks so much!!!


Whoa that’s really good to hear. I have a euro 16n, so delaying power up has been an issue.


It’s normal that if you bypass a unit on top of a xBand container, the next units will be bypassed too?
Seems strange that I don’t remember to have never noticed this on 0.4.x, now that I’m on 0.5.1, but who knows…

Searching in the forum, I found a similar fixed issue in the 0.2.x firmware post, but related to Custom Units.