And did they work as expected?
Sorry, I was still testing them.
I had a small bit of weirdness. I activated a preset, pixels went about 12" out and it immediately retracted. Then I could activate it again. Can’t get it to happen consistently, but it did twice going thru 14 presets 2 times.
wrong
Also, almost every time a clash happens, it starts lockup. It is a one button with fetts prop, so It shouldn’t do that. I still need to go back and see if it still does it with 3.6.
scratch that last part, it does it on 3.6 too, so it must be me or my setup.
Quick update @profezzorn I added a sound font folder via the board itself as opposed to the SD card directly, resulting in a “There’s a problem with the drive, scan to fix” error.
This has occurred for the same reason before, so I don’t think it’s 4.7 beta specific. It led me to a general tech question though:
Does the soundboard arrange and recall memory in a cascade format the way a HDD does? i.e. data arranged in “ABC” format, so if you delete B and add Q, the drive looks for the first empty spot to fill in, making the order “AQC”, causing latency for retrieval and performance. This would make sense to me and add context as to why flashing the board completely each time new data is added to the board itself is the best practice.
I think I’m going to take the extra 2 seconds to grab the SD card moving forward either way - it’s WAY less error-prone.
Follow-up on last post:
Trying to flash the board again prompted this error:
c:/users/owner/appdata/local/arduino15/packages/proffieboard/tools/arm-none-eabi-gcc/9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld.exe:C:\Users\Owner\AppData\Local\Arduino15\packages\proffieboard\hardware\stm32l4\3.6\variants\STM32L452RE-ProffieboardV3/linker_scripts/STM32L452RE_FLASH.ld:224: warning: memory region `SRAM2' not declared
C:\Users\Owner\AppData\Local\Temp\ccgILRKq.s: Assembler messages:
C:\Users\Owner\AppData\Local\Temp\ccgILRKq.s: Internal error (Segmentation fault).
Please report this bug.
lto-wrapper.exe: fatal error: C:\Users\Owner\AppData\Local\Arduino15\packages\proffieboard\tools\arm-none-eabi-gcc\9-2020-q2-update/bin/arm-none-eabi-gcc returned 1 exit status
compilation terminated.
c:/users/owner/appdata/local/arduino15/packages/proffieboard/tools/arm-none-eabi-gcc/9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld.exe: error: lto-wrapper failed
collect2.exe: error: ld returned 1 exit status
exit status 1
Compilation error: exit status 1
Compiling the sketch beforehand was successful
This could be a result of switching between compilers.
Gcc does have problems with using intermediate files generated by other versions of gcc, and I think arduino is not always great at cleaning up the temporary files…
The SD card is an hard drive for all intents and purposes.
When you’re accessing the SD card from the computer, it’s not up to the sound board where the information ends up, your operating system decides, the proffeboard only reads and writes blocks of data.
The effect you’re describing generally describes how FAT32 works in most operating systems though. Formatting isn’t the only way to fix it, you can also use the venerable “defrag” to do it.
As for the internal memory of the board itself, it doesn’t behave like this. It is just a list of bytes, which are always written from the beginning.
Well, I think I’m going to call it.
We’re probably not getting any more tests, and I assume that some people on the board have been using 4.6 for a while with no major problems now, so I’m probably going to make 4.6 the new “live” version in a few days unless new weird problems show up before then.
I’ll chime in that my latest upload is 4488 bytes less with 4.6.0 than 3.6.0.
Does this self-resolve with subsequent flashes? If not, is there a way to flush out temp files like an app reset or cache clear?
I suspect that simply closing Arduino fixes it, but I’m not really sure.
i am getting the following error , only happens with my sabertrio , the other 3 sabers has no porblems at all :
C:/Users/edgar/AppData/Local/Arduino15/packages/proffieboard/tools/arm-none-eabi-gcc/14-2-rel1-xpack/bin/…/lib/gcc/arm-none-eabi/14.2.1/…/…/…/…/arm-none-eabi/bin/ld.exe:C:\Users\edgar\AppData\Local\Arduino15\packages\proffieboard\hardware\stm32l4\4.6\variants\STM32L452RE-ProffieboardV3/linker_scripts/STM32L452RE_FLASH.ld:224: warning: memory region `SRAM2’ not declared
lto-wrapper.exe: warning: using serial compilation of 18 LTRANS jobs
lto-wrapper.exe: note: see the ‘-flto’ option documentation for more information
Sketch uses 523520 bytes (103%) of program storage space. Maximum is 507904 bytes.
Sketch too big; see https://support.arduino.cc/hc/en-us/articles/360013825179 for tips on reducing it.
text section exceeds available space in board
Compilation error: text section exceeds available space in board
“I reinstalled 3.6 Arduino 2.3.4 on Windows 11. My Sabertrio Proffie 3.9 now works well with 90% memory usage. The issue only happens when I use version 4.6.”
update : I had to delete 8 blade-styles from the config . now it works its at 93% . so it not so efficient as 3.6 ?
What’s weird is that we have lots of reports of 4.6 using a little more or a little less memory.
We have two reports of 4.6 using a lot more memory, both of which seems to be using configurations that nearly fill up all the memory on a V3 board.
So maybe 4.6 uses more memory if you use more memory?
Ok, that’s confusing, let me rephrase:
Maybe 4.6 is less efficient if you use more memory?
It could be the ltrans thing, 4.6 seems to use more ltrans jobs, which may potentially reduce the number of optimizations it can do. I wonder if changing -flto to -flto=1 would fix it?
Btw, if you can post your config, I can do some experimentation with it to see if various flto options help…
I agree with you , cause my other 3 sabers working weel , and i saw they used a bit less memory.
this is my sabertrio config , now its 93% // ProffieOS7 Config File Reaver Sabertrio#ifdef CONFIG_TOP#include "proffie - Pastebin.com
Can confirm more flash memory used with 4.6.
I have a config that’s 92% (243160 bytes) on 3.6, and overflows by 8200 bytes on 4.6. Even disabling like four bladestyles means still at 5 kbytes