The 2011 New MCU Bounty, coders please read

[Sokkan]

guest: How about adding a feature to the bootloader? I have myself been thinking of modifying the existing one so that it can take a firmware update via the MIDI ports also. The reason for this is that most people I know will never make a firmware update themselves because they fail to install the USB drivers on their computers(mostly mac). A big selling point for the new CPU project could be that it supports a sysex firmware update and thus eliminating the need for the USB port. Of course, sysex patch dumping should be implemented in the firmware too then.

[antto]

uhm, well, the bootloader must be small, so it might be technically difficult to implement midi sysex in the bootloader

[guest]

thats a good idea
although it would require a great deal more work
and some of that work i wouldnt know how to do
like parsing a .hex file and converting it into midi

the arduino bootloader is actually quite painless to install
its one thing to download and run
not like the current bootloader

[Sokkan]

thats a good idea
although it would require a great deal more work
and some of that work i wouldnt know how to do
like parsing a .hex file and converting it into midi

Actually, I see no point in that. The few people that develop firmware will most likely also have managed to install the com port drivers. Just upload via the com port and do a dump from the bootloader(which then also needs this functionality). The only thing to remember when sending stuff via MIDI is that you can not use the top bit in each byte. In the Sokkos code I just chop each byte in halves and send two nibbles. Then you only need a way to dump the contents and a way to decode the headers coming on the MIDI in port and piece the bytes together. It will not take up much code space.

(But a small utility that builds the header and chomps the .hex file into nibbles would also be quite easy to write.)

Just a thought, I would do it myself if I knew how to set up and access the MIDI port in assembler.

[Luap]

thats a good idea
although it would require a great deal more work
and some of that work i wouldnt know how to do
like parsing a .hex file and converting it into midi

Im just thinking out loud here.. My electronics knowledge is so so, but my coding knowledge is mostly non existent! However.. Shruthi synthesisers can take firmware updates via midi and also happen to use Bootloaders and arduino'esque MCU's.
Being another open source project, I expect there must be more than a few clues on how to do this over there.. (Or are these things really chalk & cheese!?) Olivier from MI certainly seems to know how to handle that side of things anyway (hex to midi etc etc), so may be worth contacting if you chaps can't fathom it out here..

[Altitude]

Yeah, OS update via midi would be nice so c0ntrol can finally be retired.

[antto]

to send .hex over midi this means you have to send the raw hex file (which is double the size of the actual binary data)
you also gotta convert it from hex to binary in the bootloader (thus, bootloader size jumps a bit)
and as sokkan said, if you can only use 7 bits with midi sysex, then the size increases even more

using just 4 bits out of each byte is probably the easiest thing, but i suggest using all 7 bits
i can write the peice of code for the convertion (in C tho, not asm)
my position is: i don't mind if the bootloader can accept firmware via midi sysex - that would be great i guess
but i won't rely on it myself, i rely on the usb/serial connection

btw, whoever makes the new bootloader - i suggest using a different device id string thing
the current x0xb0x bootloader returns the string "x0xb0x1" to the 'S' request
i suggest changing that to "x0xb0x2" or something, so that if (for example) c0ntr0l hooks to it, it won't try to do stuff, which *might* be potentially dangerous

and *please* put lots of readible comments around the bootloader code

[guest]

i ported the arduino bootloader for another chip yesterday
and it worked really well
i loaded the hex file with ardup
which is another free piece of software
and you can also just command line it with avrdude

im no good with computers
and this was really painless for me
so i think its a good solution

[antto]

guest: great then

[Brassteacher]

im no good with computers
and this was really painless for me
so i think its a good solution

Methinks thou may be understating abilities a bit, compared to mere mortals...

[guest]

ok
ive got a first rev of it running
i need to spend a day with it testing it out in various ways
but the bootloader seems to work

[guest]

i just got the first port of the x0x code for it
pretty much everything seems to work
except for the tempo function

the old tempo used external interrupts
and the new cpu doenst pin the rotary encoder
to any external interrupts

one more rev of the board might be in order
or they could be polled at some periodic rate

[Altitude]

I say poll it. I just ran into a similar thing with encoders with another project and going to a scanned approach worked well. Anything that can be done without a board revision

[guest]

ive got the tempo knob working again
polling is probably the better way of doing it anyways
as a noisey knob would interrupt all the time
and there is already a regular interrupt
so its minimal incremental overhead to the program

i will be putting all the docs up here
http://wiki.openmusiclabs.com/wiki/x0xb0x
probably up in the next hour

i will try to document them well
but i dont really intend to do much upkeep
or add features and such

also im having trouble getting my x0x to close
with the new chip in place
i think i will have to run new wires to the ioboard

[antto]

guest: THANK you, it's excelent
oh, i can't wait to get this thing ;]