Succ-U-Bus

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

[dmitri]

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.

[Ken Forgettable]

bootloader "userfriendliness" is of very low importance.

I'd expect the cost to your code space is around 20 words.

[dmitri]

bootloader "userfriendliness" is of very low importance.

I'd expect the cost to your code space is around 20 words.

???

[Ken Forgettable]

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 (;;);
}

[dmitri]

You're missing the point or in fact the first part of my IMHO.

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.

[Ken Forgettable]

I will add WDT reset to the MegaDrum firmware the same or next day.

Yup ok.

[Ken Forgettable]

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;
        }
    }

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

[Ken Forgettable]

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