Page 1 of 8

Succ-U-Bus

PostPosted: Fri Jun 26, 2009 6:43 pm
by Ken Forgettable
Succ-U-Bus is a robust bootloader for the ATmega324p and ATmega644p.
It was developed for the MegaDrum BSS design which required the following:

+ Auto' bauding.
Calc's it's xtal speed

+ Auto' firmware selection.
Uses the above and device ID (Number of inputs not important)

+ Auto' time out and recovery.
Interrupt driven.

+ Everything else is automatic...

Dmitri - the final requirement actually needs your help. As far as I
can tell it's not a deal breaker and is backward compatible. Obviously to
approve the change you're going to want to see what's going on, but in
the mean time - do you see a problem with your firmware implementing
a WDT reset on receipt of an Erase syx?

Other requirements for BSS Stage 1 are handled in cooperation with the MCT.

Re: Succ-U-Bus

PostPosted: Fri Jun 26, 2009 7:13 pm
by dmitri
Ken Forgettable wrote:Succ-U-Bus is a robust bootloader for the ATmega324p and ATmega644p.
It was developed for the MegaDrum BSS design which required the following:

+ Auto' bauding.
Calc's it's xtal speed

+ Auto' firmware selection.
Uses the above and device ID (Number of inputs not important)

+ Auto' time out and recovery.
Interrupt driven.

+ Everything else is automatic...

Dmitri - the final requirement actually needs your help. As far as I
can tell it's not a deal breaker and is backward compatible. Obviously to
approve the change you're going to want to see what's going on, but in
the mean time - do you see a problem with your firmware implementing
a WDT reset on receipt of an Erase syx?

I don't see a problem.

IMHO, I don't think most of MegaDrum users do firmware upgrades often, so the bootloader "userfriendliness" is of very low importance.

Re: Succ-U-Bus

PostPosted: Sat Jun 27, 2009 12:20 am
by Ken Forgettable
dmitri wrote:bootloader "userfriendliness" is of very low importance.
I'd expect the cost to your code space is around 20 words.

Re: Succ-U-Bus

PostPosted: Sat Jun 27, 2009 9:35 am
by dmitri
Ken Forgettable wrote:
dmitri wrote:bootloader "userfriendliness" is of very low importance.
I'd expect the cost to your code space is around 20 words.

???

Re: Succ-U-Bus

PostPosted: Sat Jun 27, 2009 1:11 pm
by Ken Forgettable
dmitri wrote:
Ken Forgettable wrote:
dmitri wrote:bootloader "userfriendliness" is of very low importance.
I'd expect the cost to your code space is around 20 words.
???

Code: Select all
void dmitri_recieved_erase_syx_msg(void) {
  //Clear current/pending wdt resets
  __asm__ __volatile__ ("wdr");

  //Enable update
  WDTCSR |=   (1<<WDCE) | (1<<WDE);
                                                   
  //Reset after 32ms
  WDTCSR =   (1<<WDIF) | (0<<WDIE) | (1<<WDE) |
                        (0<<WDP3) | (0<<WDP2) | (0<<WDP1) | (1<<WDP1);

  //no nothing until reset (Succ-U-Bus will catch this)
  for (;;);
}

Re: Succ-U-Bus

PostPosted: Sat Jun 27, 2009 2:09 pm
by dmitri
You're missing the point or in fact the first part of my IMHO.
dmitri wrote:IMHO, I don't think most of MegaDrum users do firmware upgrades often, so the bootloader "userfriendliness" is of very low importance.


Let's do it like this. MegaDrum users get MCT supporting firmware updates for "secure" and "secure+midi" bootloaders and I will add WDT reset to the MegaDrum firmware the same or next day.

Re: Succ-U-Bus

PostPosted: Sat Jun 27, 2009 2:20 pm
by Ken Forgettable
dmitri wrote:I will add WDT reset to the MegaDrum firmware the same or next day.
Yup ok.

Re: Succ-U-Bus

PostPosted: Wed Jul 01, 2009 11:09 am
by Ken Forgettable
dmitri wrote:get MCT supporting firmware updates for "secure" and "secure+midi" bootloaders
Dmitri (and elrules) here is a test fix for the above.
Only tested with virtual ports so far.
Code: Select all
    public static boolean sendBigSysex(byte data[], String outputDeviceName) { //the device is supposed to be opened yet
        try {
            Vector v = MidiPort.enumerateDevices(MidiPort.MIDIPORT_OUTPUT);
            int i = 0;
            for (; i < v.size(); i++) {
                if (v.elementAt(i) != null && v.elementAt(i).equals(outputDeviceName)) {
                    break;
                }
            }
            if (i == v.size()) {
                return false;
            }

            MegadrumConfigTool.log.info("Opening MIDI port (" + i +") to send firmware...");
            MidiPort mp = new MidiPort(i, i);
            mp.open();

            MegadrumConfigTool.log.info("Sending firmware...");


    MegadrumConfigTool.log.info("sendBigSysex: data len: " + (data.length/2));
    try {
        mp.writeLongMessage(data, (data.length/2), Common.SYSEX_SEND_TIMEOUT);

    } catch (MidiPortException e) {
        MegadrumConfigTool.log.error("sendBigSysex: data: " + e.getMessage());
    }

    try {
        Thread.sleep(20000);
    } catch (Exception e) {
    }

    byte part2[] = Converter.subByteArray(data, (data.length/2), data.length);

    MegadrumConfigTool.log.info("sendBigSysex: part2 len: " + part2.length);
   
    try {
        mp.writeLongMessage(part2, part2.length, Common.SYSEX_SEND_TIMEOUT);

    } catch (MidiPortException e) {
        MegadrumConfigTool.log.error("sendBigSysex: part2: " + e.getMessage());
    }

            MegadrumConfigTool.log.info("Firmware was sent. Now closing...");
            mp.close();

            return true;
        } catch (Exception e) {
            MegadrumConfigTool.log.error("Trying to send BIG SYSEX message<br>The error was: " + e.getMessage());
            return false;
        }
    }

Re: Succ-U-Bus

PostPosted: Wed Jul 01, 2009 12:55 pm
by elrules
What you mean is avoiding buffer overflows sending firmware in parts.

I don't know if MidiPort will allow sending big sysex data if it does not start with byte 0xF0 but I could try.

Re: Succ-U-Bus

PostPosted: Wed Jul 01, 2009 2:14 pm
by Ken Forgettable
elrules wrote:What you mean is avoiding buffer overflows sending firmware in parts.

I don't know if MidiPort will allow sending big sysex data if it does not start with byte 0xF0 but I could try.
MidiPort stuffs the data into a (circular ?) buffer and attaches the Microsoft callback handler to it. No checks are done on the data by MidiPort as far as I can see. MidiOX correctly interprets the split data and the old bootloaders shouldn't complain either.

I am looking into the optimum syx buffer size for Succ-U-Bus.
The choices are from:
+ MidiPort size
+ Microsfot size
+ USB packet size
+ ATmega pagesize

Tuning this bit will speed transfers up considerably :P