Request for feedback: high-priority bugs/features

LeafLabs Garden » Community » Help Us Help You

Request for feedback: high-priority bugs/features

(41 posts) (14 voices)

Started 4 years ago by mbolivar
Latest reply from dipspb

« Previous 123 Next »

gbulmer
Moderator

mbolivar - I agree LeafLabs need to fix issues which are easiest for customers to implement.

I also agree re-flashing the bootloader is hassle, but maybe we should do a 'straw poll' to discover how hard it might be?
The wonderful feature of the STM32F103 is it has a built-in loader which works over USART1, so re-flashing is not as awkward as other processors.

I own more than one Maple, so I could use one as a USB to Serial adapter to re-flash another.
That would need some code to make it act as a USB to serial cable, but I assume it might be straightforward.
This is a "good thing" as it encourages people to buy extra Maples :-)

I own an FTDI USB-to-3.3V-Serial cable, so I can re-flash using that (and have made my boards using it)
This doesn't need any new software or hardware.

I own Arduino's, so I could lever the ATmega from the socket and use the USB to serial on that.
Or I could use a soft-serial interface (if we wrote some code). I think I'd need a tiny bit of electronics to make that work (but maybe the STM32F USART1 is 5V tolerant, I thought it wasn't but I should go check.)

There is a cheap (under £3 GBP) USB to serial adapter for Nokia phones, though we'd need to test and document that to make it viable.

With code, the Maple could update its own bootloader. I am a bit nervous about this as failure would require one of the USART1 based update mechanisms, but it might be a useful tool anyway.

Of course, with less common hardware, like JTAG, anything is possible.

I'd be happy to help people re-flash Maples at our hackspace meetings. We are re-launching fizzPop in Birmingham (UK) as of next Wednesday, so I could help anyone in the area at a meeting.

Using those sorts of mechanisms and support, could we move a majority of existing Maple owners across to a new bootloader?

Posted 4 years ago #
robodude666
Member

Well, we can take DMA Interrupts off of the todo list now. After spending the past 6 hours trying out dozens of previous versions of libmaple, and every combination of NVIC/DMA code, I stumbled upon the problem. Take a guess what's wrong:

dma.c defines: void __irq_dma_channel1(void)
The vector table expects to run: __irq_dma1_channel1

Any guesses? =]

-robodude666

Posted 4 years ago #
crenn
Moderator

I think I could also potentially help users from Australia to reload their bootloaders when the time came providing they were happy enough to mail it to a stranger. But if this were to happen, they'd need to lodge it with me before they sent.

@mbolivar, I might make a new thread about the problem, I can't get a visual/audio representation until Monday (it's Saturday now), however I can do a slightly better description. I also didn't get to run a test that perry recommended yesterday with an oscilloscope attached to the I2C bus, however, I remember an arduino sketch being used to sniff out packets on the I2C bus, so I might be able to rig something up during the weekend.

Posted 4 years ago #
nully
Member

mbolivar,

There is nothing specific I like about arduino's string object, I would just like an easy to use string object so I don't need to use char[]. std::string would be fine.

I am currently playing around with a gps module and would like to be able to easily deal with some of the strings the gps sends, instead of having to deal with allocating char arrays myself. C++ isn't a strong point of mine so a string class would hasten my prototyping.

Sorry if this isn't clear I am suffering a sever case of Mondayitis and we are all out of coffee.

Posted 4 years ago #
mbolivar
LeafLabs

robodude666,

ugh, embarrassing. thanks so much for tracking this down. fixed:

https://github.com/leaflabs/libmaple/commit/f99e0310faf34ab37f7fb31ff2592fa6d6c3213d

also updated the USART/DMA example code:

https://github.com/leaflabs/libmaple/commit/c1a7fa7aadb73c26ddac76a5eb3ffad4d6526d92

Posted 4 years ago #
mbolivar
LeafLabs

nully,

thanks for the response. dealing with char arrays is a pain. we'll see what can be done about that; unfortunately, it'll have to wait until after dynamic memory support goes in.

Posted 4 years ago #
mbolivar
LeafLabs

gbulmer,

The wonderful feature of the STM32F103 is it has a built-in loader which works over USART1, so re-flashing is not as awkward as other processors.

I agree. I didn't mean to imply that changes to the bootloader itself were unimportant. I simply meant that, given that perpetual bootloader mode seems to work reliably, the greatest benefit for the least cost seems to lie in fixing the libmaple autoreset code, potentially in concert with changes to Maple IDE's upload routines.

I own more than one Maple, so I could use one as a USB to Serial adapter to re-flash another. [...] I own an FTDI USB-to-3.3V-Serial cable, so I can re-flash using that. [...] I own Arduino's, so I could lever the ATmega from the socket and use the USB to serial on that. [...] There is a cheap (under £3 GBP) USB to serial adapter for Nokia phones [...] With code, the Maple could update its own bootloader [...]

Using those sorts of mechanisms and support, could we move a majority of existing Maple owners across to a new bootloader?

I agree with what I think you're implying: the wide variety of options means we could get wide adoption of a new bootloader relatively easily. I personally would rather avoid getting stuck in one of those famous traps where a young software project gets stuck with bad decisions because they were too afraid to trust their users to cope with change, so I'm happy to put effort into this.

While the current bootloader docs provide a "blessed" way to update your bootloader over serial, such a one-size-fits-all solution seems suboptimal here. It seems to me that leveraging the wiki would be a good way to get community contributions on this; some sort of "List of ways to update your Maple bootloader" page may be useful.

Posted 4 years ago #
mbolivar
LeafLabs

Update: the current state of the shrink-the-USB-code front.

I've rebased my local usb-related commits into something resembling order, and pushed them into a topic branch in my personal libmaple tree on GitHub.

You can get a summary of what's happened so far in USB land here:

https://github.com/mbolivar/libmaple/compare/usb-touchups

Some unfortunately compatibility-breaking changes to scb.h happen on this branch. Here are the details:

https://github.com/mbolivar/libmaple/commit/27506206f2feca91fc340f55213a120a067d8f63

To be clear, there are no bugfixes yet. This is purely the initial process of making the libmaple/usb/ directory contents smaller (and thus easier to debug).

The game plan is to continue making incremental changes like these until the entire libmaple/usb/usb_lib/ directory is dead code, which we'll delete en masse before proceeding with the debugging process. These initial cleanups are expected to take place over the next couple of days, after which they'll be merged into the official LeafLabs libmaple repo.

Once that's done, it's open season on autoreset bugs, with a particular focus on Windows environments.

Posted 4 years ago #
gbulmer
Moderator

mbolivar - if the bootloader changes so that Maple is only one device (no dfu <-> USB Serial changes) then I had assumed the Windows autoreset bug would change or disappear completely. Is that not the case?

If it is the case that the autorest bug changes or disappears, and you intend to build and release a new single-USB-device bootloader soon, then is it a waste of effort to fix autoreset before releasing a new bootloader?

Posted 4 years ago #
mbolivar
LeafLabs

gbulmer,

Fixing the autoreset code is important for a couple of reasons:

1) depending on ST's code is not a great idea
2) the autoreset code has some important bugs which prevent it from working in situations where it really should. if we don't fix it, then we never get into bootloader mode. it doesn't matter how fantastic a new bootloader would be if we don't reset into it reliably.
3) the USB stack is bloated, not general enough, and is written entirely differently than the rest of the library

of these, (3) is perhaps the most important, since it blocks the creation of a new bootloader. the original bootloader was written before libmaple existed, so it uses its own internal conventions etc., many of which were copied into the contents of libmaple/usb/. a new bootloader will be written against libmaple, so it would definitely be a waste of effort to start work on that before the libmaple USB interfaces are better done.

Posted 4 years ago #
gbulmer
Moderator

mbolivar - thanks for the feedback.

I still believe Voltaire was right, "best is the enemy of the good"
http://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good

IMHO, only 2 matters in the near term.

IMHO 1) is not a defect. It only matters if ST are going to prevent convenient distribution. Right now, Maple is the best (only viable) card in the Arduino game for STM32F. After talking to them, I believe ARM understands that Maple is important.

IMHO 3) is a 'nice to have'. It should be driven by real needs. The existing code mostly works, and has worked for more than a year. Where does the money come from to pay to change a working piece of software? It's okay to change it to fix defects or when there are end user Use Cases for it, but change it as little as practical to make diffs useful.
If it is conventions, can you do an automated and reversible change? If you can't, are there enough automated tests to ensure no new defects creep in?

There are real problems using Maple on MS Windows and MS Windows thin clients because of the current dfu-USB-device bootloader. It appears MS Windows thin-client will only be fixable by using a USB HID or USB serial device. These seem to me to be problems worth fixing. I agree work on 2 helps. I don't understand how work on 3 and 1 improves any existing defects *directly*.

Further 1 and 3 might be made irrelevant by porting LUFA. Even if LUFA suffered from bloat (which I do not believe is the case) it barely matters as Maple would gain a pile of USB devices, which are much more significant to me.

LUFA may introduce a new set of different conventions. I would not care if LUFA uses different conventions from libmaple unless they clash e.g. different typedefs with the same name or overlapping file names with different contents.

Are LeafLabs going to avoid adopting other code because it doesn't follow libmaple conventions?
I'd certainly like to know that sooner rather than later.

Posted 4 years ago #
mbolivar
LeafLabs

regarding (1), i agree that it's not a show-stopper. i also agree that (2) is the most relevant in terms of easing user pain. however, i think you're underestimating the value of (3) as a prerequisite for fixing the problems in (2).

i don't know if you've had a look at the contents of libmaple/usb/usb_lib/. frankly, it's a mess. many important things are accomplished by side-effecting global variables that are scattered about the source code. the documentation looks like it was written in order to fulfill a requirement, rather than educate the users about how things work.

as you might imagine, using such a thing correctly is not the easiest thing in the world.

it will be easier, and get results faster, to rip out all of that extra complexity before proceeding further. the fact that doing so is a good investment in the future of the library is just a secondary benefit.

to be perfectly clear: i am explicitly not trying to make an end-all-be-all USB library. i _am_ trying to do the stupidest thing that could possibly work. saying "not general enough" in my previous post was a mistake on my part. i meant that the public usb.h interface wasn't too general; ST's code is of course general-purpose, but using it has all the problems described above.

as you know, we really want a serial-only bootloader. i truly believe that it will be faster to first put together a better USB interface, then write such a bootloader on top of that, rather than try to put something together using the code we have now.

when i talk about moving over to libmaple's conventions, i'm not trying to start a bikeshed argument. we write libmaple because it makes it easier to develop for the STM32, not out of NIH or tabs vs. spaces.

we're an open source company; of course we are happy to build upon work shared by others. we'd be happy to use LUFA or whatever other open source library, if it gets the job done. however, porting LUFA would take way more time than the path we're taking now.

Posted 4 years ago #
gbulmer
Moderator

mbolivar - Thank you. I think you've given is a helpful explanation because I think I understand your view a bit better.

Posted 4 years ago #
mbolivar
LeafLabs

hey all,

just a bump to let you know we haven't forgotten about this; i've been chipping away at this periodically, and here's the status.

usb-touchups now has a pair of files, usb_cdcacm.h/usb_cdcacm.c which control all the VCOM functionality; usb.h and usb.c are now just pretty thin skins on top of ST's usb_lib/.

for the near future, i've decided against replicating all the code in usb_lib/; there's too many other things on my plate to make this worthwhile at the moment. i managed to get rid of the things i hated most (the biggest win was replacing usb_regs.h with a new usb_reg_map.h), so i'm satisfied for now.

anyway, in terms of user-visible changes, i was thinking about the autoreset scheme, and wanted to try a new way to go about it. the basic idea is to interpret DTR/RTS changes as a sequence of bits. at compile time, we decide a particular sequence to use as a "password". to reset the board, just "send" this password over DTR/RTS.

the idea is still preliminary, and i'd like to take this time to solicit some feedback from any interested parties. more details on my idea and its current implementation are available in this commit:

https://github.com/mbolivar/libmaple/commit/6c5bc6eb40868f997d67ca3aadd707dc3844b6c0

edit: the reason why i want to do it this way is because it seems likely that it will be very reliable, and also for the improved separation of concerns between autoreset and data transmission. this should let us avoid certain classes of bugs entirely, e.g. the current (libmaple 0.0.11) situation, where you can't autoreset the board if SerialUSB has any unread bytes, since the RX endpoint will just NAK attempts to send the '0x1eaf' sequence.

as long as the DTR/RTS password is long enough and implausible enough, it should be unlikely to occur in common use, and besides which, we can always revise the docs to make it clear that libmaple claims DTR and RTS for its own purposes.

Posted 4 years ago #
gbulmer
Moderator

I'd still prefer a way to for my code to intervene before your 'autoreset-password-checker' and catch the DTR in my code.

Rather than you guys come up with some ingenious way to make it highly unlikely that a false DTR-driven-reset happens, I'd like to get the DTR and decide for myself what to do.

I think we agree, DTR is the only cross-platform out-of-band signal USB serial signal.
IMHO, that makes it far to useful to waste by tying it irrevocably into the USB reset mechanism.

Posted 4 years ago #

RSS feed for this topic

« Previous 123 Next »

Reply »

You must log in to post.