STM32F4 UART dropping chars (was New STM32 eLua platform / getting eLua binary working)
Locked
|
On Thu, Apr 5, 2012 at 8:06 PM, Ernie <[hidden email]> wrote:
> Not sure if it's related, but I ran up eLua on an STM32F4DISCOVERY board > yesterday, and it has massive character loss on the UART console port at > 115200 baud when talking via minicom on Ubuntu using a Pololu AVRisp serial > port on /dev/ACM1, I didn't have any flow control enabled, not sure if > software flow control is supported. It looks like we have interrupts and buffered UARTs on that platform so it shouldn't drop chars unless you send quite a few and the console or whatever isn't keeping up. Is this text that's just typed or are you pasting into the console and getting dropped chars? Also, are the chars that are dropped ones that are just sent by the MCU or the echo chars of things you've typed? One other thing to try: I haven't used minicom anytime recently, I usually just use "screen" on Linux & OS X which you should be able to invoke something like this: screen /dev/ACM1 115200 8n1 (I almost never include the 8n1, it seems to default to that on the platforms where I've tried it) Note if you're not familiar with screen, the following can be used to kill the session: Ctrl-a k > > >> >> On Thu, Apr 5, 2012 at 4:24 AM, Martin Guy <[hidden email]> wrote: >> > On 5 April 2012 02:21, Brent Picasso <[hidden email]> wrote: >> >> We're working on a new development board/platform using tere hhe STM32F103RE >> >> which will feature eLua as it's operating environment. >> >> when processor >> >> comes out of reset, we see the eLua prompt on USART1, but we cannot interact >> >> with it - it does not respond to keyboard input from the terminal. >> > >> > I haven't had this exact problem, but there are two ways that the >> > USART is driven. When BUF_ENABLE UART is undefined, it is polled, and >> > when BUF_ENABLE_UART is on and CON_BUF_SIZE > 0, it is >> > interrupt-driven. >> > Maybe trying the other of these options compared to what you're >> > using might help home in on the problem. >> >> I would suggest looking in this direction as well. >> >> Is a completely unmodified port? Does it ever work over that USART or >> is it only under certain conditions. One other thing could be related >> to pin configurations if you've perhaps modified which pins the USART >> is available on and/or perform some reconfiguration of pins during >> startup (perhaps one thing is overriding another?) >> >> As I recall, the console may use some timer related facilities, but at >> least the last time I had a platform where the timer wasn't configured >> or available the main problem was that our code to try and handle >> different platforms' newline handling (\r, \n or \r\n) wouldn't work >> correctly, but it was still usable. >> >> >> > >> > Good luck! >> > >> > M >> > _______________________________________________ >> > eLua-dev mailing list >> > [hidden email] >> > https://lists.berlios.de/mailman/listinfo/elua-dev >> >> >> >> -- >> James Snyder >> Biomedical Engineering >> Northwestern University >> http://fanplastic.org/key.txt >> ph: (847) 448-0386 >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> > > > -- > "I Ping therefore I am." > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev -- James Snyder Biomedical Engineering Northwestern University http://fanplastic.org/key.txt ph: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
_______________________________________________
eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Fri, Apr 6, 2012 at 6:25 AM, Ernie <[hidden email]> wrote:
> Ok, if they UART is buffered, then it must be my environment. > I am running Ubuntu on Virtualbox as my NuttX development environment > since I couldn't find a suitable toolchain to use for development on > MacOS X 10.6.8. I usually haven't had trouble with USB things running in VirtualBox lately, but I've never used the exact adapter you mention. If you experience the problem with some other configurations or adapters, let me know. Generally I use a fairly recent version of Mentor/Sourcery's G++ sources (and build myself) or their binaries as a build environment. > > I will try and compile the Sourcery arm-eabi-toolchain so I can ditch Virtualbox/Ubuntu. These instructions should work for building a toolchain on OS X: https://github.com/jsnyder/arm-eabi-toolchain (using Sourcery CodeBench Lite sources) > > > - Ernie. > > > >> >> On Thu, Apr 5, 2012 at 8:06 PM, Ernie <[hidden email]> wrote: >> > Not sure if it's related, but I ran up eLua on an STM32F4DISCOVERY board >> > yesterday, and it has massive character loss on the UART console port at >> > 115200 baud when talking via minicom on Ubuntu using a Pololu AVRisp serial >> > port on /dev/ACM1, I didn't have any flow control enabled, not sure if >> > software flow control is supported. >> >> It looks like we have interrupts and buffered UARTs on that platform >> so it shouldn't drop chars unless you send quite a few and the console >> or whatever isn't keeping up. Is this text that's just typed or are >> you pasting into the console and getting dropped chars? Also, are the >> chars that are dropped ones that are just sent by the MCU or the echo >> chars of things you've typed? >> >> One other thing to try: >> I haven't used minicom anytime recently, I usually just use "screen" >> on Linux & OS X which you should be able to invoke something like >> this: >> screen /dev/ACM1 115200 8n1 >> (I almost never include the 8n1, it seems to default to that on the >> platforms where I've tried it) >> >> Note if you're not familiar with screen, the following can be used to >> kill the session: Ctrl-a k >> >> > >> > >> >> >> >> On Thu, Apr 5, 2012 at 4:24 AM, Martin Guy <[hidden email]> wrote: >> >> > On 5 April 2012 02:21, Brent Picasso <[hidden email]> wrote: >> >> >> We're working on a new development board/platform using tere hhe STM32F103RE >> >> >> which will feature eLua as it's operating environment. >> >> >> when processor >> >> >> comes out of reset, we see the eLua prompt on USART1, but we cannot interact >> >> >> with it - it does not respond to keyboard input from the terminal. >> >> > >> >> > I haven't had this exact problem, but there are two ways that the >> >> > USART is driven. When BUF_ENABLE UART is undefined, it is polled, and >> >> > when BUF_ENABLE_UART is on and CON_BUF_SIZE > 0, it is >> >> > interrupt-driven. >> >> > Maybe trying the other of these options compared to what you're >> >> > using might help home in on the problem. >> >> >> >> I would suggest looking in this direction as well. >> >> >> >> Is a completely unmodified port? Does it ever work over that USART or >> >> is it only under certain conditions. One other thing could be related >> >> to pin configurations if you've perhaps modified which pins the USART >> >> is available on and/or perform some reconfiguration of pins during >> >> startup (perhaps one thing is overriding another?) >> >> >> >> As I recall, the console may use some timer related facilities, but at >> >> least the last time I had a platform where the timer wasn't configured >> >> or available the main problem was that our code to try and handle >> >> different platforms' newline handling (\r, \n or \r\n) wouldn't work >> >> correctly, but it was still usable. >> >> >> >> >> >> > >> >> > Good luck! >> >> > >> >> > M >> >> > _______________________________________________ >> >> > eLua-dev mailing list >> >> > [hidden email] >> >> > https://lists.berlios.de/mailman/listinfo/elua-dev >> >> >> >> >> >> >> >> -- >> >> James Snyder >> >> Biomedical Engineering >> >> Northwestern University >> >> http://fanplastic.org/key.txt >> >> ph: (847) 448-0386 >> >> _______________________________________________ >> >> eLua-dev mailing list >> >> [hidden email] >> >> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> >> >> >> > >> > >> > -- >> > "I Ping therefore I am." >> > >> > _______________________________________________ >> > eLua-dev mailing list >> > [hidden email] >> > https://lists.berlios.de/mailman/listinfo/elua-dev >> >> >> >> -- >> James Snyder >> Biomedical Engineering >> Northwestern University >> http://fanplastic.org/key.txt >> ph: (847) 448-0386 >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> > > > -- > "I Ping therefore I am." > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev -- James Snyder Biomedical Engineering Northwestern University http://fanplastic.org/key.txt ph: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |