anakin Posted August 4, 2008 Report Share Posted August 4, 2008 Hi to allI'm using and application (part wrote down in C and part in Assembler) and in particular it has the "classic" MAIN.C, MAIN.H (for managing with pots and buttons ecc ecc) and I have also a file called Preset.asm that work in this way: It write some values in the eeprom of the PIC when I flashed it with the .sys file and in the "Main.c" there a shortcut for those values: so when I press one din it read the values in the eeprom and some Control Change will assume those values (pots related to those CC will not work)... it work like a normal "preset" bank.The "preset.asm" is like this: list p=18f452 radix dec org 0xf00000 ; eeprom base address db 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 db 0x00, 0x00, 0x00, 0x50, 0x30, 0x20, 0x00, 0x00 db 0x00, 0x00, 0x00, 0x00, 0x40, 0x40, 0x30, 0x20 db 0x00, 0x00, 0x00, 0x00, 0x00, 0x7F, 0x70, 0x40 db 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x50 db 0x00, 0x30, 0x20, 0x70, 0x60, 0x40, 0x50, 0x20 db 0x20, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 db 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x50, 0x40 db 0x50, 0x40, 0x40, 0x00, 0x00, 0x00, 0x40, 0x40 END this is my questions.The only way to change the value of the preset is to make a new .sys file and put it into the core... is there a way to compile a new .sys file without include on it the Main.c , Main.h ecc ecc ,but only the preset.asm so doesn't matter if the main.c is different... after the flashing of the PIC nothing will change in Main.c ecc ecc, the only thing the will change is the preset.asm file.... any idea?In your opinion there's a way to change the values of the eeprom without re-flashing the pic? E.G. make a "dedicated" din that if you press it together with another din, the system will "read" some pots value and report it to the eeprom...some kind of "user preset" that I can change without sending a new .sys file.Thank you for your help!Anakin Quote Link to comment Share on other sites More sharing options...
TK. Posted August 4, 2008 Report Share Posted August 4, 2008 You can use the common MIOS mechanisms to upload code (or EEPROM) data.It doesn't matter, if data is located in code memory, EEPROM or a BankStick, it's only important that the tables are located at an absolute address (so that pointers compiled into the code never change)Method 1 (quick&dirty): recompile the application, and modify the .hex file, so that it only contains the data section which should be updated. Upload the .hex via MIOS StudioMethod 2 (modification of #1): you could use the "mksyx.pl" script to convert the modified .hex file into .syx if you don't want to use MIOS Studio (not recommented, as MIOS Studio provides the much faster (and secure) "smart" mode)Method 3: create a Makefile which only compiles the .asm file to .hexExample: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fexamples%2Fasm%2Fbs_xfer%2FDisadvantage of these methods: the core will be reset after upload. But this might be acceptableAlternatively you would have to program an own SysEx handler like I did in most of my "main" applications (mostly located in *_sysex.inc) - but it's some work and requires more knowledge about side effects, like collecting data into a buffer before storing into EEPROM, since the CPU won't be able to handle MIDI data during programmingProgram data into EEPROM from your application: just use MIOS_EEPROM_WriteBest Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
anakin Posted August 10, 2008 Author Report Share Posted August 10, 2008 Hi Tk and thank you for your replyI'm not 100% sure that you understand the first part of my question... I try to explain in other way, with examples.1) I have a a code and it is made by some "subcodes" like main.C , main.H ( some in C some in ASM) when the compiler do the job it brings all and create the .hex file; I have a feature that is wrote in preset.asm and I want to change it, I do and I would like to upload a new code ( I know quite well the method for do it ) so when I compile, the compiler brings ALL the codes (main.asm, main.C, preset.asm ecc ecc) and create the .hex. Just for asking and understanding, I want not to touch the application wrote in the pic ( 99% made by the main.c and other files) but I would like ONLY to re-write the files stored in the eeprom with the file preset.asm, but how to do it?2) I think you understand well my question regarding other ways to change the values stored in the eeprom , but maybe I don't understand... Is it possible to change the files stored in the eeprom without using the .hex and mios studio ecc ecc but with the application running and use special feature for doing it ( I'm thinking about a "special state" where the application go to some kind of "listen state" where it doesn't work but only work for doing the thing I need)?Is it difficult to do? some kind of help?Thank you very much!Anakin Quote Link to comment Share on other sites More sharing options...
TK. Posted August 10, 2008 Report Share Posted August 10, 2008 I'm sure that I understood your question, I'm not sure how I can explain the methods better. You are asking:1) I have a a code and it is made by some "subcodes" like main.C , main.H ( some in C some in ASM) when the compiler do the job it brings all and create the .hex file; I have a feature that is wrote in preset.asm and I want to change it, I do and I would like to upload a new code ( I know quite well the method for do it ) so when I compile, the compiler brings ALL the codes (main.asm, main.C, preset.asm ecc ecc) and create the .hex. Just for asking and understanding, I want not to touch the application wrote in the pic ( 99% made by the main.c and other files) but I would like ONLY to re-write the files stored in the eeprom with the file preset.asm, but how to do it?My answer was:Method 1 (quick&dirty): recompile the application, and modify the .hex file, so that it only contains the data section which should be updated. Upload the .hex via MIOS StudioYou can modify the .hex file with a common text editor. You could also write a text processing script (if you know how to do this) to extract the data section and to write it into a new .hex file before loading the new file into MIOS Studio.2) I think you understand well my question regarding other ways to change the values stored in the eeprom , but maybe I don't understand... Is it possible to change the files stored in the eeprom without using the .hex and mios studio ecc ecc but with the application running and use special feature for doing it ( I'm thinking about a "special state" where the application go to some kind of "listen state" where it doesn't work but only work for doing the thing I need)?Is it difficult to do? some kind of help?It isn't difficult to do, there are many programming examples for SysEx handling and EEPROM store/load operations in the repository, but it seems that you haven't looked into the files... this makes it really difficult to help you.As mentioned before, most of the MIDIbox applications are supporting exactly these SysEx functions, and they are mostly programmed on different ways to cover special application requirements. They are not using MIOS Studio to exchange data. However, so long the incoming data is buffered (or directly written into existing data structures for the informations you want to exchange), you can read and write back with a selfwritten SysEx handler. Your SysEx handler has to store the received (and temporary stored) informations into the EEPROM after the transfer has been finished. But as mentioned before, you have to take care that during the EEPROM write operation no additional MIDI data will be received to prevent data loss.Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
anakin Posted August 12, 2008 Author Report Share Posted August 12, 2008 Hi and thank you for your helpIt's OK, I will try to code something using the EEPROM write function.Just another question: You tell me that it's better to suspend the midi data when we are writing on eeprom... maybe you are think about a "special state", a "programming state" in which midi messages are not recognize or are you thinking about something else?ByeAnakin Quote Link to comment Share on other sites More sharing options...
TK. Posted August 12, 2008 Report Share Posted August 12, 2008 Just another question: You tell me that it's better to suspend the midi data when we are writing on eeprom... maybe you are think about a "special state", a "programming state" in which midi messages are not recognize or are you thinking about something else?No, I'm thinking about a special requirement for the program you are using to send the dump.EEPROM writes are blocking operations, it has to be ensured that at the time the EEPROM is programmed no additional MIDI data is received. MIOS Studio (and other tools which are interacting with MIDIbox applications, like the MBSID V2 Editor) are waiting for an acknowledge string sent by the core after the EEPROM has been programmed before sending a new SysEx command. You probably already noticed this ("Smart Mode")Alternatively the tool has to wait for a specific time before sending anything else to prevent the MIDI in buffer overrun (e.g. see hints about SysEx transfers with MIDI-Ox at various ucapps pages)You are refering to a state machine handler for SysEx transfers. It is required as well to parse the SysEx stream...However, since I was planning to write a SysEx handler example anyhow, I started with itCode is located here:http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fexamples%2Fsyx_dump%2FThe code is a bit more complex than somebody could program a simple handler... the reason is, that I take many error cases into account to improve the robustness. I also consider different use cases (e.g. SysEx handling when MIDI merger is enabled - a different topic, but covered by the example)Normaly you should never receive an error acknowledge, but if somebody owns a bad, unstable MIDI interface, some diagnose messages are always very helpful.It also provides an optional checksum protection (disadvantage: checksum has to be re-calculated when patch is modified manually), and optional BankStick support in patch.c (therefore the abstraction layer)What is missing yet in this example, and what I'm planning to add later:a README.txt which explains the programming model and the different optionsand a new option which allows to send the EEPROM content nibble-wise, so that all 8 instead only the last 7 bits are transfered.If this code looks too complicated, then just consider again the usage of the generic MIOS download feature ;)(Still don't know, why exactly you are not using it, I especially don't know, what your application is doing exactly)Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
stryd_one Posted August 13, 2008 Report Share Posted August 13, 2008 However, since I was planning to write a SysEx handler example anyhow, I started with itSWEET!! :D Quote Link to comment Share on other sites More sharing options...
TK. Posted August 13, 2008 Report Share Posted August 13, 2008 Now with an alternative format (2 nibble format) and a documentation (-> see README.txt)http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fexamples%2Fsyx_dump%2FAdditional enhancements are not planned from my side.Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
anakin Posted August 15, 2008 Author Report Share Posted August 15, 2008 No, I'm thinking about a special requirement for the program you are using to send the dump.EEPROM writes are blocking operations, it has to be ensured that at the time the EEPROM is programmed no additional MIDI data is received.MIOS Studio (and other tools which are interacting with MIDIbox applications, like the MBSID V2 Editor) are waiting for an acknowledge string sent by the core after the EEPROM has been programmed before sending a new SysEx command. You probably already noticed this ("Smart Mode")Alternatively the tool has to wait for a specific time before sending anything else to prevent the MIDI in buffer overrun (e.g. see hints about SysEx transfers with MIDI-Ox at various ucapps pages)You are refering to a state machine handler for SysEx transfers. It is required as well to parse the SysEx stream...HiMaybe for the reason that english is not my default language :) i'm not sure I understand the stuff...We have 2 method for write the eeprom of the core: 1 using mios studio or other software and send a .syx file and this a thing that I already can do...2 using the application by itself for doing it... is this what we are talking about?If so, what do you mean with "parse the sysex stream"?If this code looks too complicated, then just consider again the usage of the generic MIOS download feature Wink(Still don't know, why exactly you are not using it, I especially don't know, what your application is doing exactly)So, if I understand well (just before trying to understand code you wrote) this is a "template" for doing what we are talking about, also if it is complicated, it is C, so it's better for me ;DThe main reason why I don't use the "generic MIOS download feature" (case 1 the two method), is that this is not so fast... and I'm using my hardware based Midibox for live situation, it is difficult to explain but I have to change some "presets" 2-3 times every night and the first method is not so easy, the other reason is that writing down everytime the value of the pots (in hexadecimal) and write them in the file "preset.asm", recompile and then put is into the core it's not a simple thing...Best and optimal thing: decided a "pot situation", do like a snapshots and store them into the eeprom, so then I can resume them when I want.Are you agree?I'm mistaken in something?Best regardsAnakin Quote Link to comment Share on other sites More sharing options...
TK. Posted August 15, 2008 Report Share Posted August 15, 2008 We have 2 method for write the eeprom of the core: 1 using mios studio or other software and send a .syx file and this a thing that I already can do...2 using the application by itself for doing it... is this what we are talking about?Yes, we were talking about both methodsIf so, what do you mean with "parse the sysex stream"?See detailed description in README.txtSo, if I understand well (just before trying to understand code you wrote) this is a "template" for doing what we are talking about, also if it is complicated, it is C, so it's better for meYesAre you agree?I'm mistaken in something?You could use an external IIC EEPROM ("BankStick") to store and restore your presets. Up to 128 presets can be stored in a single device. No PC required to replace data.The example shows, how to handle thisBest Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
anakin Posted August 16, 2008 Author Report Share Posted August 16, 2008 Hi TkAnother time I want to thank you very much for your help!Today I will try to do something, write down some code and try it in my hardware.Best regards :)Anakin Quote Link to comment Share on other sites More sharing options...
wackazong Posted September 15, 2008 Report Share Posted September 15, 2008 Wow, I just discovered that the syx_dump is brandnew. Thanks TK for that, that is really just in time :)@Anakin, I successfully implemented the sysex transfer in my project. If you need it I did some encoding to send 8bit values over sysex (which can only use 7bit). You find it at http://www.midibox.org/forum/index.php/topic,10598.15.html. You can also ask me if you need the algorithm explained.Best, ALEXander. Quote Link to comment Share on other sites More sharing options...
TK. Posted September 15, 2008 Report Share Posted September 15, 2008 You should also mention the advantages/disadvantages:advantage: less bytes have to be sent - but you won't notice a big difference on streams < 1kdisadvantage: you have to implement an encoder/decoder to descramble the streamThe nibble format increases the length of the stream, but it's easier to edit with already available MIDI SysEx tools (e.g. MIDI-Ox or Sounddiver). So, even people without programming knowledge can edit it.Therefore I provided this format as an example to transfer 8bit values instead of re-using the scrambling algorithm which I implemented into MIOS. Btw.: if you would take the MIOS scrambling format, you would be able to re-use already existing perl scripts ($MIOS_PATH/bin), and/or java code (see source code of MIOS Studio)Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.