You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Large static arrays need to be stored in RAM, at least temporarily, before being passed to sendSysEx.
Those could be declared as PROGMEM to be saved in Program Space, and it would be fairly easy to have another sendSysEx implementation that reads one byte at a time from Program Space instead of RAM, effectively saving lots of memory, at the cost of extra program size and execution time.
Let me make a different suggestion. The fundamental problem with the Sysex subsystem at the moment is that it requires transferring the entire data stream as one buffer. Which means you have to have that buffer allocated, sometimes twice. For example, if I want to read Sysex into a memory space I've allocated, The library at present allocates its own memory space, loads it, then sends it to me where I copy it into my space. If you have a memory constrained space (as I do) this is essentially impossible.
I suggest instead that that the Sysex library be written as:
STATE is one of: (0) start of sysex message (1) continuing a sysex message (2) end of a sysex message (3) start and end of a sysex message
-- output --
void MidiInterface<SerialPort, Settings>::setHandleSystemExclusive (void()(byte *array, unsigned size, int state) fptr, byte sysexArray, int sysexArraylength)
STATE is one of: (0) start of sysex message (1) continuing a sysex message (2) end of a sysex message (3) start and end of a sysex message
SYSEXARRAY provides the sysex array to the system to use as its own internal buffer, and SYSEXARRAYLENGTH is its length. This way the library doesn't have to have a large static buffer allocated like it presently does (which is a serious memory issue). Instead it has exactly the size one we specified because we provided it.
That's a very interesting approach indeed. It also works like the USB MIDI approach (where you receive data by packs of up to 3 bytes, and the SysEx has special status codes to indicate how much data is received), therefore I'll be giving this a look when I'm working on the next version of the lib, which will focus on USB compatibility.
Large static arrays need to be stored in RAM, at least temporarily, before being passed to
sendSysEx
.Those could be declared as
PROGMEM
to be saved in Program Space, and it would be fairly easy to have anothersendSysEx
implementation that reads one byte at a time from Program Space instead of RAM, effectively saving lots of memory, at the cost of extra program size and execution time.http://www.nongnu.org/avr-libc/user-manual/pgmspace.html
The text was updated successfully, but these errors were encountered: