Change only a part of an application

[anakin]

Hi to all

I'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

[TK.]

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 Studio

Method 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 .hex

Example: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fexamples%2Fasm%2Fbs_xfer%2F

Disadvantage of these methods: the core will be reset after upload. But this might be acceptable

Alternatively 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 programming

Program data into EEPROM from your application: just use MIOS_EEPROM_Write

Best Regards, Thorsten.

[anakin]

Hi Tk and thank you for your reply

I'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

[TK.]

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 Studio

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

[anakin]

Hi and thank you for your help

It'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?

Bye

Anakin

[TK.]

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 it

Code is located here:

http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fexamples%2Fsyx_dump%2F

The 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 options

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

[stryd_one]

However, since I was planning to write a SysEx handler example anyhow, I started with it

SWEET!!  :D

[TK.]

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%2F

Additional enhancements are not planned from my side.

Best Regards, Thorsten.

[anakin]

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

Hi

Maybe 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 ;D

The 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 regards

Anakin

[TK.]

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 methods

If so, what do you mean with "parse the sysex stream"?

See detailed description in README.txt

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

Yes

Are 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 this

Best Regards, Thorsten.

[anakin]

Hi Tk

Another 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

[wackazong]

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.

[TK.]

You should also mention the advantages/disadvantages:

advantage: less bytes have to be sent - but you won't notice a big difference on streams < 1k

disadvantage: you have to implement an encoder/decoder to descramble the stream

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