mbolivar
LeafLabs
Hey all,
I thought I'd open up a thread where you can post/vent about the bugs that are making you the craziest. Right now, here's my top three; feel free to add your own:
- Bootloader/auto-reset isn't reliable enough, especially on Windows
- SerialUSB isn't reliable enough
- IDE source code parsing/compiler error checking isn't reliable enough
edit: added a third item
robodude666
Member
Three things I'd love to see improved, in relatively no particular order:
- DMA Interrupts
- Timer Interrupt Overhead (all timers in general have overhead)
- Bootloader
I'm not worrying about the IDE because I gave up on the Arduino / Processing IDE years ago. I love TextMate/XCode and a Terminal window.
I've also found very little issue with SerialUSB, and plan to minimize the amount I have to use it as it wouldn't be available to me either way if I use GPIOA as a 16-bit parallel interface on the Mini in the future.
I've looked at the DMA Interrupts a little bit as well, and find it strange that it's not working. I'm probably more curious about why they aren't working than having them working. I'm experiencing the same documented issues: once the DMA interrupt is enabled and triggers the board jus "freezes" execution.
While it's not massively important, the current interrupt system (jumping between a couple functions/logic checks) has some overhead associated with it. It's something that is understandable on a 8-bit 16MHz Arduino, but on a 72MHz ARM board that's meant for more serious processing it's rather disappointing to see. As I, and others, have described in a related thread there are some things that could be done to allow advanced users to handle the interrupts themselves rather than letting libmaple handle them.
The bootloader works, but I've seen some people bring up ways of making it better, and a better bootloader certainly never hurt anyone. I'd also like to see improvements with auto-reset for programming as that's probably the most annoying thing right now. I love my Arduino because it would automatically reset every time you wanted to program it, and that's very frequently if you're developing features or debugging an issue.
mbolivar
LeafLabs
robodude666,
thanks for the feedback.
I've looked at the DMA Interrupts a little bit as well, and find it strange that it's not working. I'm probably more curious about why they aren't working than having them working. I'm experiencing the same documented issues: once the DMA interrupt is enabled and triggers the board jus "freezes" execution.
yeah, that's a weird one. didn't have enough time to debug it before the code went out the door, and haven't looked at it much since then. a previous incarnation of the same code had working interrupts (but was worse in every other way), so my plan is to go in and check registers to try to figure out what happened.
edit: upped the priority on the DMA bug to "high", given the feedback:
I2C reliability is important. I'm having issues when I don't use a delay between sending messages, it will quickly stop sending messages without a delay. It's also what is blocking the release of the Wire library currently since I've narrowed it down to the I2C implementation, I'm just not sure where the issue lies. I'll be active on IRC in about 7-8 hours if you want to talk to me.
poslathian
LeafLabs
a fast interrupt mode - reducing overhead is an interesting idea, there may be a way to fold the table-jump style operation into wirish, and leave libmaple with function overloading. The problem there is that you would be forced to name all your interrupts by their proper names, and you would not be able to change interrupt handlers on the fly. This is obviously OK if you know what you are doing.
poslathian
LeafLabs
alternatively, and perhaps a better solution, is to let users overload the interrupt handlers in libmaple. So by default its the table lookup thing, but if you name something with the magic "proper" name, the function can be overloaded and the user can own the interrupt directly.
gbulmer
Moderator
poslathian - there is a discussion on thread http://forums.leaflabs.com/topic.php?id=720
about interrupt handlers.
I like the ultra-simple approach:
1. Every interrupt handler has a well-defined (function) name.
2. A user can take over handling an interrupt by providing a function with that name, and setting up the link stage so that user interrupt handlers replace system defaults.
The implementation arranges it so that there is no overhead, the interrupt vector table is built at link time to point straight at the users code. The Cortex-M3 hardware works this way; it retrieves the address of the interrupt handler from the vector table.
In the 'olden days' this was trivial because link-editors worked this way, building a topological-sorted list of 'needed symbols'. The other thread has two articles explaining how to achieve the effect on Cortex-M3 using gcc.
I think it is relatively straightforward to build a layer which supports run-time changes on top of a link time mechanism. Even better, a user could implement their own trivial system without any more than the link time interrupt vector table using well-defined names.
gbulmer
Moderator
mbolivar - I'd like to put all my votes onto a better bootloader.
The very first experience a new user has colours their views, and can be very off-putting, or stimulate interest.
I'd like to introduce people (e.g. school children of 12 up to people in their 80's) to Maple systems rather than Arduino systems because the 'head-room' on a Maple is so huge; it will get even more enormous when STM's Cortex-M4 arrives.
Even if they start with Arduino, I don't want to make the excuse 'this is much more flexible than an Arduino, and so you should forgive it being unreliable or cranky'.
I'd much prefer to say 'this is much more flexible than an Arduino, it can be used for all the same tasks, but many more as well, and it's just as easy to use'.
LarryP
Member
I'd like to add my agreement with:
Bootloader/auto-reset isn't reliable enough, especially on Windows
Reading the above is the first indication I've seen that others are having problems with bootloading from a Windows PC (FYI, mine is WinXP.) Eternal bootloader mode works for me (on a Maple mini), but is a real pain to use.
mbolivar
LeafLabs
Thanks to everyone for the continuing comments! This sort of thing really helps us prioritize.
Your call is important to us... <annoying elevator music>...
Ok, so bootloader and autoreset are the clear winners so far. Here's our plan for getting this fixed; comments/help welcome/solicited.
In terms of source code patches, this is really two problems:
(1) Fixing the known issues in libmaple/usb/, and doing more testing (test feedback from you is a big help; more on this later).
(2) Reworking the bootloader itself (this is the code in the maple-bootloader repo).
Problem (1) is important because that's where the autoreset code lives. If it's not working, you need perpetual bootloader mode, and that's very annoying. Problem (2) is important too, and we've hashed out new bootloader schemes on the forum in the past. However, any improvement we can get from it requires existing users to flash a new bootloader, which requires external hardware. Thus, solving (2) helps fewer people, and doesn't help as much. For these reasons, solving (1) seems like the bigger win.
We figured there'd be widespread agreement on bootloader/autoreset being by far the most painful part of the Maple experience, so work on (1) began this week. More on that:
The libmaple/usb/ directory is essentially borrowed wholesale from the bootloader code, so there's lots of stuff in there that has nothing to do with USB. My first priority is to remove duplicated functionality and get it written in terms of existing libmaple code (this has the ancillary benefit of exercising the rest of libmaple).
Progress on that has been OK so far. I got sidetracked for most of yesterday by confusing/contradictory ST/ARM documentation, but among other things, I've removed the files usb_hardware.h and usb_hardware.c entirely. There's no shortage of low-hanging fruit for chopping out code that doesn't really belong in usb/, which will make hunting for bugs much simpler.
It's badly named (the bugs lie in libmaple proper, not SerialUSB), but Issue 10 on the bugtracker ("Generally buggy SerialUSB", http://code.google.com/p/leaflabs/issues/detail?id=10 ) is where we track updates to solving (1). You can keep an eye on that as time goes on.
As the bugfixes occur, we'll put together some "snapshot" IDE releases you can download and try out. I'll make a note on the bugtracker and post in the forum whenever an Issue 10-related snapshot gets released.
As I said earlier, any feedback ("improved behavior on XP", "breaks on OS X when my iPod is plugged in") is extremely valuable, so if this issue is important to you, please help us help you by downloading and testing these snapshots as they come out.
Besides getting the existing scheme working better, here are some other improvements I'm planning. gbulmer, on a thread a while ago, you mentioned a need for a user-visible means for attaching a function for use in the USB interrupt, so that users can make up their own autoreset schemes. That's a good idea, and will happen. x893 (and anyone else who wants CAN) also needs something like this so they can handle CAN interrupts; it seems likely to me that we can kill two birds with one stone here. And luckily enough, we've even got a proposed solution that kills a third bird: using linker scripts to make it easy to override IRQ handlers. That means that these IDE snapshots will also be fertile ground for hashing out and testing a solid mechanism for this as well.
Again, thanks for the feedback! We feel your pain, and are working on getting this done.
mbolivar
LeafLabs
crenn,
I2C reliability is important. I'm having issues when I don't use a delay between sending messages, it will quickly stop sending messages without a delay.
Hm, weird. Got a test case illustrating the unexpected behavior (ideally a small, self-contained one)?
mbolivar
LeafLabs
nully,
Would love to see String working.
To be honest, I don't like String.
On the Arduino developers' list, there have been long threads where they try to figure out the myriad issues you get when trying to do the sorts of dynamic memory games it has to play. Figuring out an error handling scheme that's palatable to users has apparently been a real issue; this is crucial given that running out of memory during string concatenation is a real possibility, and we don't have the luxury of exceptions. I seem to recall some emails to it that, between the lines, made it look like they regretted adding it.
It's also a classic case of reinventing the wheel; we've got C++ already, so I'd rather try to get std::string working than port the String class (although that's a possible non-starter due to code size and other issues).
What about String appeals to you in particular? I'm especially curious on benefits it provides over std::string.
edit: clarified my rationale
You must log in to post.
