A proposal to improve Maple Firmware (Bootloader)

LeafLabs Garden » Community » Help Us Help You

A proposal to improve Maple Firmware (Bootloader)

(67 posts) (13 voices)

Started 5 years ago by gbulmer
Latest reply from feurig

12…5 Next »

gbulmer
Moderator

I assume folks have noticed the new Arduino UNO: http://arduino.cc/en/Main/ArduinoBoardUno
The on board silk screen seems to be much clearer. (I like the '~" for PWM!)

The FTDI USB-to-USART has been replaced by an Atmel ATmega8U2, which has on-board USB.
IMHO, this is the most significant improvement, it removes the need to install any drivers on a host PC.

IMHO this is where I believe Maple, Maple Native, Mini, Oak, needs to get to.

Some schools, and universities, I work with either can't, or won't install new device drivers onto their networks of PC's.

The Arduino UNO uses Dean Camera's LUFA on an ATmega8U2 for the USB interface.
Arduino UNO interprets DTR to 'auto-reset' the main ATmega328 Arduino processor into the Arduino bootloader.

I've communicated with Dean in the past, and he believes DTR is available on the key platforms (Windows, Mac OS X and Linux). Though he has not done detailed testing himself, some of the LUFA users have tried different platforms and report success.

So, may I ask LeafLabs to consider this?
Let's modify the Maple bootloader to remove the DFU USB device, and only use the USB serial device.
This removes the need to install a DFU driver on the host.
It also removes the need to re-enumerate USB devices to switch between upload and operation.
We can ponder on the bootloader load protocol, but I believe the DFU upload protocol should be okay as the Python program doesn't seem to care.
In this model, Maple-ets (Maple, Native, Mini, ...) would look like a USB serial device all the time (unless the user wrote their own USB device implementation), and DTR would be used to trigger the bootloader.

Possible benefits:
a. print/println will work in setup() because their is no USB re-enumeration
b. slightly smaller bootloader
c. easier to write dumb host programs to talk to programs running on Maple as their is no need for anything to 'escape' or interpret bytes coming over the connection, and the host program has a simple way to reset the Maple to a known state (wiggle DTR).
d. might be easier to connect to other USB hosts, and even USB On-The-Go devices and they act as a USB host for Maple-ets (i.e. no need to port DFU driver to Google phones, iPad, Blackberry, XBox, PlayStation, Wii, ... :-)
e. users may have fewer issues with their OS interfacing to the USB serial, rather than two USB devices.

I realise LeafLabs have put significant effort into the bootloader, but I feel the UNO has changed the ground rules, and IMHO, for the better.

EDIT: Added word 'Bootloader' to title as another thread has started, and it might be nice to keep similar ideas in a thread.

Posted 5 years ago #
leaflabsandy
Member

Your concept does have merit with no drivers needed!

Posted 5 years ago #
gbulmer
Moderator

I started the conversation with Dean about cross-platform, driverless, USB-serial-only for a different project, which is on the back burner for now, so I haven't worked out every detail, but we were pretty certain it was doable.
Maybe now I know why Dean was so certain :-)

In any case, it is wonderful that the Arduino folks have taken the 'no drivers please' feedback to heart, and fixed it.

We might not yet be able to program an Arduino from a phone, but IMHO it is only a matter of weeks before folks use, maybe, the USB OTG iPhone frameworks, or Android, or RIM, or ... to try to talk directly to their Arduino UNOs with a USB cable.

(I should add, that I had a horrible experience two weeks ago running an Arduino workshop for the British Science Festival mostly because of the FTDI drivers. I have been against custom drivers when they can be avoided, but that experience caused me to swear-off hardware that need custom USB drivers. It's just to fragile in any environment that I can't fully control).

Posted 5 years ago #
mbolivar
LeafLabs

Gbulmer: without tipping our hand too much at this point, as not everything is decided, we are very sympathetic to what you're saying. There are definitely some bootloader changes in the pipe for Maple rev6.

Posted 5 years ago #
crenn
Moderator

Will those changes be able to be back ported to previous maple versions?

Posted 5 years ago #
gbulmer
Moderator

mbolivar - it's good to know that bootloader improvements are coming.
Can you suggest when?

After my horrible experience during Science Festival, it has become much more urgent, so I am very willing to put effort into making it happen.

I assume USB improvements will port to rev3 boards.

Posted 5 years ago #
StephenFromNYC
Moderator

Hello-

I wanted to give this topic a bump to learn if there is any more current info about the bootloader.

mbolivar, you said earlier (above six months ago):

definitely some bootloader changes in the pipe for Maple rev6

I realize a lot can happen in a few months (and I would not be surprised if you forgot you made the statement). Is "rev6" the next version of the IDE (0.1.0) or will the bootloader changes be released after the Maple mini?

Thanks!

Stephen from NYC (full disclosure: I am not a member of the LeafLabs staff)

Posted 4 years ago #
CidVilas
Member

Will bootloader changes in Rev6 be compatible with Rev5? I have a Rev5 and I keep having problems with my Maple. I am trying to create a Reprap brain board, but the serial locks up. Even with a simply 'Sketch' that reads Serial input and echoes back to the Serial Terminal locks up if the text is too long. I would have expected this board to be comfortable with text no matter how long it was. Is there something im missing?

Thank you!

Posted 4 years ago #
StephenFromNYC
Moderator

Hello-

CidVilas, I am glad you are trying to use a LeafLabs product to drive a Reprap board. If things work (or even if they do not) you might consider creating a section on the "Projects" page.

Your question about the compatibility of the "Rev6" bootloader with Rev3/5 Maple boards is definitely pertinent to this topic. I hope the answer is yes, because I have a Rev 3 Maple board (from summer 2010).

It is not clear why you think your Serial problem is related to firmware/bootloader thread (this topic). It is more likely that other users will read your posts and offer help you if you create a new topic whose title accurately describes the problem. Also, if your test sketch, which displays the problem, is not too long include it with your future posts.

Are you using SerialN (eg. Serial2) or SerialUSB functions?

Looking forward to hearing more about your Reprap project.

Thanks!

Stephen from NYC (full disclosure: I am not a member of the LeafLabs staff)

Posted 4 years ago #
mbolivar
LeafLabs

CidVilas,

We don't have a firm time-line for Rev 6; however, we'll keep things backwards compatible firmware-wise (any incompatible bootloader changes will be invisible if you're using the IDE).

Regarding your problems with your current board, I'd like to repeat StephenFromNYC's question about whether you're using SerialN or SerialUSB. Also, can you please tell us which version of the IDE you're using? It's hard to diagnose bugs without this sort of information.

Posted 4 years ago #
dreamcat4
Member

Yeah its actually preferable to avoid using DTR because the feature is hard/impossible to switch off on certain OSes. The Arduino IDE does use DTR as a solution because the ATmega hasnt any proper soft reset. The situation may be different on STM32.

Posted 4 years ago #
mbolivar
LeafLabs

[post by cocochen deleted for spam]

Posted 4 years ago #
gbulmer
Moderator

dreamcat4 -

its actually preferable to avoid using DTR because the feature is hard/impossible to switch off on certain OSes.

Why do you say that?
Which OS's are you referring to? Are you talking about DTR over physical serial interfaces, or USB serial?

I found DTR over USB serial was reliable across Windows, Mac OS X, and Linux; I tested on a couple of Windows versions, as well as Mac OS X and Ubuntu, back in 2008. I also believe that is okay-ish because the Arduino uses it. When I was using the lower-levels of the USB serial interface, I was working with a guy who had written an embedded USB serial device (from scratch), and he had made it work with Solaris, Windows, OS X and Linux. He said DTR also worked on Solaris.

The Arduino IDE does use DTR as a solution because the ATmega hasnt any proper soft reset. The situation may be different on STM32.

The USB to serial interface on an Ardiuno has to interpret out-of-band signals (ioctls) sent over USB, and trigger ATmega reset. I agree, the ATmega has only one external pin that has (guaranteed) reset behaviour. There are a few pins that could be used to create a 'DIY' soft reset, but that might conflict with the users use of pins, and the ATmega on an Arduino hasn't got many I/O pins, so I'd prefer it not to consume another to get a soft reset.

The case is different for Maple because the USB is on-board. The Maple firmware/software can interpret in-band or out-of-band data over USB, and do whatever it wants. The current boot loader effectively does implement a sort of soft reset when it gets a specific in-band sequence (That is explained in a different thread)

Oddly enough I am reading the reset parts of RM0008 (which describes all of the STM32F peripherals and capabilities).

I assume a 'soft reset' would trigger the processor even if it has been put into a low-power mode; it would be less useful to have a second reset which only works if the software is behaving nicely :-)

It is possible to have an external signal on the reset pin (nRST) run different code.

It is also possible to use the 'Tamper' pin to run externally triggered code, so that might be a reasonable candidate if you want the soft reset triggered by a button.

full disclosure: I am not a member of the LeafLabs staff)

EDIT by crenn: Fixing blockquotes
EDIT: Thank you cren

Posted 4 years ago #
dreamcat4
Member

Specifically on Mac OS X the DTR signal is always sent during the opening any serial connection. The problem is that theres nothing in any of the corresponding header files on Mac OS platform for this DTR sending to be switched off. Hence the DTR behaviour isnt controllable across all platforms... hence not the best choice to use DTR if other special-purpose mechanisms exist for reseting on STM32... If you think that DTR can be switched off on Mac OS, then send me the code and I'll test it for you.

More to the point, there should be other special-purpose ways to send a reset instruction, and there are also various levels of what is known as 'reset' to consider. It makes sense to make the 'hard' reset controllable by a physical switch. And all the kinds of soft reset to be controllable by remote USB command / USB function or in-program function call. Sorry that I dont know any more about that interesting area of STM32 programming. You comments seem promising however.

Posted 4 years ago #
gbulmer
Moderator

dreamcat4

Specifically on Mac OS X the DTR signal is always sent during the opening any serial connection.

Are you certain?

I think todbots port opening program:
http://todbot.com/blog/2006/12/06/arduino-serial-c-code-to-talk-to-arduino/
would talk to an Arduino without resetting it (on Mac OS X).
To do that it must not send DTR.

Are you saying you DO NOT want DTR to do a 'hard reset' on STM32F? Or are you saying you want several types of reset?

I believe the first requirements is an out-of-band signal (not in the data stream) which will get to the Maple over all major OS-supplied USB virtual serial drivers. The out-of-band signal could be different on each platform, but it must be unambiguous across all of the platforms. It is preferable that it is the same on every platform to make code easier to write and test, but that is not necessary.

The interpretation of DTR is in the firmware on the Maple, not in any hardware, so I assume the ability to change to some 'softer' reset could be achieved by rewriting the bootloader.

What would a soft reset do differently from a hard reset?

Posted 4 years ago #

RSS feed for this topic

12…5 Next »

Reply »

You must log in to post.