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.
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)
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.