The mode bit field is the wheel pattern number. The number 15 is not valid because that's the number used for serial communication and 31 is for when the user wants to use the DIP switches to control the wheel pattern (but this has to be done after powering up the JimStim and going to the serial comm mode). Numbers 47 and 63 are also invalid (ending in 0xF).mtx_man wrote:Committed/pushed, basic support for JimStim. *I need docs from jean about the "mode" bitfield and what it actually describes.
Docs on the wheel pattern loader would be nice too as that code doesn't make sense, and the file formats for the patterns aren't well defined/described. I can make sense of the dynamic rpm control stuff, which i plan on sticking into MTX's jimstim support once fred tests the basics..
.
The names in the ini are for the patterns from the default wheel pattern file and what is loaded with the firmware. If a user uploads new patterns then the pattern names in the ini may no longer be correct as each pattern in the uploaded file is numbered sequentially (with the exception of 15, 31, 47 and 63 which are skipped). The numbering in the comments is not used by the code.
I'll see what I can do about documenting the wheel pattern loader. Let me just say that the wheel pattern file format defines one trigger transition per line (defined on one byte) where the first part is the state of the 2nd trigger and the first trigger as 2 bits and the second part is the number of degrees up to the next transition defined on 6 bits. If the actual pattern transition is more than 63 degrees then the transition is defined as many transitions of less than 63 degrees with the same 2 higher bit values for the trigger states. And the end of the pattern is done by using the terminating string 0xff (so using a 63 degree transition with both triggers set to on needs to be avoided as that would define the end of the pattern).
And the transfer is done in 2 steps. First, the wheel patterns are transmitted by parsing the wheel pattern file. The code is very simple and assumes the format is correct. The second part is the transmission of the relative position of each of the patterns in the first block (pointers to the wheel patterns). The first block is 3.5K and the second block is 512 bytes which means there could be up to 256 patterns.
As mentioned, the code is really simple and does not perform much validation of the inputs. And it does output a binary file which is the exact representation of the memory blocks. For most (all) users this output has not real use but it was useful during development and could be used for validation of MTX implementation.
Let me know if you need more details and what is actually problematic. I'll have to spend some time on this because it has been a while and I don't actually remember most of it except for the high level explanation above.
Jean