WOW! this sounds like something that will open many new possibilities!!! cant wait to see what’s boiling
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!
Substantial changes in my build/development environment masquerading as a minor bug fix release.
- 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)
Not expected. I’ll take a look.
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”?
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?
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.