board: arduino-mega2560: use uart_stdio by kaspar030 · Pull Request #3426 · RIOT-OS/RIOT

kaspar030 · 2015-07-16T07:38:06Z

This removes uart0 support and makes the port use shared uart_stdio code instead.

I don't remember where, but someone reported this patch doesn't work correctly. I don't have the board, so I can't debug. Volunteers?

~~(I marked it "waiting for other PR" as this breaks all tests that use uart0 without #3402)~~

kaspar030 · 2015-07-16T07:43:21Z

rebased
merged in "simplify_shell" (sys: simplify shell #3402). Will remove when that is merged.

PeterKietzmann · 2015-07-16T07:46:13Z

@ReneHerthel can you test this? I can give it a try tomorrow if Rene is not on it then.

kaspar030 · 2015-07-16T07:50:31Z

Someone said there was a problem with strings longer than "help". ;)

PeterKietzmann · 2015-07-16T07:57:18Z

Really :-) ?

PeterKietzmann · 2015-07-20T07:49:51Z

Still no success on mega2560. Seems to be the same problem like described in #3187. From tests/shell I get:

2015-07-20 09:46:53,567 - INFO # kernel_init(): This is RIOT! (Version: 2014.12-2372-g06c18-kaspar_mega2560_uart)
2015-07-20 09:46:53,579 - INFO # kernel_init(): jumping into first task...
2015-07-20 09:46:53,583 - INFO # test_shell.
help
2015-07-20 09:46:58,331 - INFO # > help
2015-07-20 09:46:58,339 - INFO # Command              Description
2015-07-20 09:46:58,351 - INFO # ---------------------------------------
2015-07-20 09:46:58,359 - INFO # start_test           starts a test
2015-07-20 09:46:58,367 - INFO # end_test             ends a test
2015-07-20 09:46:58,380 - INFO # echo                 prints the input command
2015-07-20 09:46:58,392 - INFO # reboot               Reboot the node
2015-07-20 09:46:58,408 - INFO # ps                   Prints information about running threads.
start_test hello



2015-07-20 09:47:20,450 - INFO # > star> E> > > > hY> > K> sW> > }> > > > > hello> sta.> E> > > > hello
2015-07-20 09:47:20,458 - INFO # shell: command not found:
2015-07-20 09:47:20,459 - INFO # hello

PeterKietzmann · 2015-07-20T07:53:50Z

tests/periph_gpio/main.c

shell_commands

PeterKietzmann · 2015-07-20T08:04:32Z

PR looks reasonable as far as I can evaluate this. The Atmega has the same problems than before. On the stm32f4discovery everything seems to be fine

kaspar030 · 2015-07-30T15:47:49Z

@PeterKietzmann could you try not using pyterm? Maybe pyterm sends the characters too fast...

edit or try a very low baudrate, e.g. 9600?

PeterKietzmann · 2015-07-31T13:29:15Z

@kaspar030 with minicom @38400 baud it looks fine. With pyterm @9600 baud it looks also fine. Pyterm @38400 baud is still "buggy"

kaspar030 · 2015-07-31T13:31:29Z

Well, our current design issues one interrupt per character, which might be too much for the little AVR. I'll change to 9600 for now, until we come up with a more efficient solution.

kaspar030 · 2015-07-31T13:37:54Z

@PeterKietzmann Could you try one thing:

Add while (!UART0_DTREG_EMPTY) before line 279 in cpu/atmega2560/periph/uart.c, so the callback gets called as long as there's data available?

Maybe the UART has a buffer, so reading in a loop might fix the issue.

kaspar030 · 2015-07-31T13:45:33Z

The datasheet states the Atmel has a two-byte buffer, so this might actually help.

kaspar030 · 2015-07-31T13:50:21Z

@PeterKietzmann Sorry, wrong flag, correct is
while (!UART0_RECEIVED_DATA).

9600 · 2015-07-31T13:54:54Z

@PeterKietzmann hey, thanks for letting me know!

kaspar030 · 2015-07-31T13:57:05Z

:)

PeterKietzmann · 2015-07-31T14:02:22Z

@kaspar030 sorry, I don't want to get into the datasheet right now. When exactly is this flag set? Calling the callback until the flag is unset brings no inputs to pyterm anymore. Again, with minicom 38400 baud worked. In general I'd be also fine with a default of 9600 baud on that platform.
@9600 thanks for letting you know what exactly :-) ?

9600 · 2015-07-31T14:04:00Z

@PeterKietzmann about this discussion. You AT'ed me.

kaspar030 · 2015-07-31T14:04:44Z

@PeterKietzmann Sorry again, my logic was wrong. Please try again with
while (UART0_RECEIVED_DATA) (without the !).
That flag should be set as long as there's a byte available.

PeterKietzmann · 2015-07-31T14:11:56Z

@9600 sorry. I didn't realize what I did at first :-), sorry for the interruption.

PeterKietzmann · 2015-07-31T14:13:18Z

@kaspar030 the your idea seems reasonable to me but still if have the problem, that longer strings don't work. E.g. ps works but the other commands don't

kaspar030 · 2015-07-31T14:21:51Z

@PeterKietzmann Ok, thanks for trying! Let's set to 9600baud for now.

kaspar030 · 2015-09-03T13:54:30Z

rebased, all dependencies merged

kaspar030 · 2015-09-03T13:57:56Z

@PeterKietzmann Could you take another look?

OlegHahm · 2015-09-03T13:58:45Z

With master on default on arduino-mega2560 I get output, but input (shell) isn't working. With the current state of this PR, I get neither input nor output.

kaspar030 · 2015-09-03T14:36:07Z

Hm, too bad. I remember this was working in @PeterKietzmann's tests. We had to lower the baudrate to 9600 baud, but still.... Unfortunately I don't have a board to test.

OlegHahm · 2015-09-03T14:38:05Z

Ah, didn't read about the baudrate.

OlegHahm · 2015-09-03T14:39:05Z

With 9600 baud it's working indeed.

PeterKietzmann · 2015-09-03T14:41:51Z

But the baudrate should be changed within the third commit?!

With the current state of this PR, I get neither input nor output.

@OlegHahm is this still current?

OlegHahm · 2015-09-03T14:42:41Z

As I said, with 9600 baud it's working, yes.

kaspar030 · 2015-09-03T14:48:15Z

Nice. Question would be, why is there no output at higher baudrate with this PR? Anyways, would you guys ACK this?

OlegHahm · 2015-09-03T14:49:26Z

Question would be, why is there no output at higher baudrate with this PR?

No, sorry, I was imprecise. This has been a case of PEBCAK: I called pyterm manually with the wrong baudrate.

Anyways, would you guys ACK this?

ACK - slow shell is better than no shell.

PeterKietzmann · 2015-09-03T14:57:43Z

:-) @OlegHahm I agree. IIRC with other terminal programs (e.g. minicom) the higher baud rate worked, but not in pyterm. Anyway, I didn't re-test this PR but ACK for the state from some weeks ago

OlegHahm · 2015-09-03T15:00:15Z

Wait! Now you made me curious and I reverted the last commit. Still working. With 115200 baud and pyterm.

Edit: Just realized that the baudrate is 38400 then.

kaspar030 · 2015-09-03T15:05:34Z

@PeterKietzmann Do you think you could quickly test with 38400 and 115200 baud? fast shell is better than slow shell. :)

OlegHahm · 2015-09-03T15:08:52Z

115200 is not working.

OlegHahm · 2015-09-03T15:09:23Z

I still get the output, but shell isn't working.

kaspar030 · 2015-09-03T15:12:45Z

So I revert the 9600 baud commit? Whatever you're more likely to ACK.

PeterKietzmann · 2015-09-03T15:13:34Z

Will do, moment

PeterKietzmann · 2015-09-03T15:18:43Z

I see the same problems with 38400 baud as before. IMO you should not revert that commit

PeterKietzmann · 2015-09-03T15:19:47Z

@OlegHahm pleas try tests/shell and use the commands start_test or echo hello oleg

OlegHahm · 2015-09-03T15:25:47Z

Works like charm:

`--> BOARD=arduino-mega2560 make term
/home/oleg/git/RIOT/dist/tools/pyterm/pyterm -b 38400 -p /dev/ttyACM0
2015-09-03 17:24:55,740 - INFO # Connect to serial port /dev/ttyACM0
Welcome to pyterm!
Type '/exit' to exit.
start_test
2015-09-03 17:25:01,035 - INFO # > start_test
2015-09-03 17:25:01,039 - INFO # [TEST_START]
echo hello oleg
2015-09-03 17:25:06,307 - INFO # > echo hello oleg
2015-09-03 17:25:06,315 - INFO # “echo” “hello” “oleg” 
echo 123456789012345678901234567890
2015-09-03 17:25:21,066 - INFO # > echo 123456789012345678901234567890
2015-09-03 17:25:21,078 - INFO # “echo” “123456789012345678901234567890”

PeterKietzmann · 2015-09-03T15:29:09Z

Hm. Do you have an original arduino board or is yours also from Funduino?

OlegHahm · 2015-09-03T15:30:22Z

How do I figuret that out? Mine has printed SainSmart on the PCB.

PeterKietzmann · 2015-09-03T15:35:45Z

Well, seems to be just an other supplier. Anyway, @ReneHerthel and me both have the Mega2560 by Funduino and both of us experienced problems with shell examples when initialized at 38400 baud. Is this reason enough to merge it with 9600 baud per default? Maybe one could add a comment in the peripheral configuration or elsewhere

OlegHahm · 2015-09-03T15:37:34Z

I'm fine with 9600 baud. ACK

PeterKietzmann · 2015-09-03T16:04:16Z

And go

…t_stdio board: arduino-mega2560: use uart_stdio

kaspar030 assigned haukepetersen Jul 16, 2015

kaspar030 force-pushed the make_arduino-mega2560_use_uart_stdio branch from 7c44626 to b715d95 Compare July 16, 2015 07:42

PeterKietzmann reviewed Jul 20, 2015
View reviewed changes

tests/periph_gpio/main.c Outdated

Copy link
Copy Markdown

Member

PeterKietzmann Jul 20, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shell_commands

OlegHahm added the Platform: AVR Platform: This PR/issue effects AVR-based platforms label Jul 20, 2015

PeterKietzmann mentioned this pull request Jul 31, 2015

Arduino-mega2560 GPIO implementation #2799

Merged

kaspar030 removed the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Jul 31, 2015

PeterKietzmann mentioned this pull request Aug 27, 2015

sys: remove uart0 #3164

Merged

10 tasks

kaspar030 removed the State: waiting for other PR State: The PR requires another PR to be merged first label Sep 3, 2015

board: arduino-mega2560: set default baudrate to 9600

fa0202e

PeterKietzmann added a commit that referenced this pull request Sep 3, 2015

Merge pull request #3426 from kaspar030/make_arduino-mega2560_use_uar…

ef000d4

…t_stdio board: arduino-mega2560: use uart_stdio

PeterKietzmann merged commit ef000d4 into RIOT-OS:master Sep 3, 2015

kaspar030 deleted the make_arduino-mega2560_use_uart_stdio branch February 7, 2017 22:11

Conversation

kaspar030 commented Jul 16, 2015

Uh oh!

kaspar030 commented Jul 16, 2015

Uh oh!

PeterKietzmann commented Jul 16, 2015

Uh oh!

kaspar030 commented Jul 16, 2015

Uh oh!

PeterKietzmann commented Jul 16, 2015

Uh oh!

PeterKietzmann commented Jul 20, 2015

Uh oh!

PeterKietzmann Jul 20, 2015

Choose a reason for hiding this comment

Uh oh!

PeterKietzmann commented Jul 20, 2015

Uh oh!

kaspar030 commented Jul 30, 2015

Uh oh!

PeterKietzmann commented Jul 31, 2015

Uh oh!

kaspar030 commented Jul 31, 2015

Uh oh!

kaspar030 commented Jul 31, 2015

Uh oh!

kaspar030 commented Jul 31, 2015

Uh oh!

kaspar030 commented Jul 31, 2015

Uh oh!

9600 commented Jul 31, 2015

Uh oh!

kaspar030 commented Jul 31, 2015

Uh oh!

PeterKietzmann commented Jul 31, 2015

Uh oh!

9600 commented Jul 31, 2015

Uh oh!

kaspar030 commented Jul 31, 2015

Uh oh!

PeterKietzmann commented Jul 31, 2015

Uh oh!

PeterKietzmann commented Jul 31, 2015

Uh oh!

kaspar030 commented Jul 31, 2015

Uh oh!

kaspar030 commented Sep 3, 2015

Uh oh!

kaspar030 commented Sep 3, 2015

Uh oh!

OlegHahm commented Sep 3, 2015

Uh oh!

kaspar030 commented Sep 3, 2015

Uh oh!

OlegHahm commented Sep 3, 2015

Uh oh!

OlegHahm commented Sep 3, 2015

Uh oh!

PeterKietzmann commented Sep 3, 2015

Uh oh!

OlegHahm commented Sep 3, 2015

Uh oh!

kaspar030 commented Sep 3, 2015

Uh oh!

OlegHahm commented Sep 3, 2015

Uh oh!

PeterKietzmann commented Sep 3, 2015

Uh oh!

OlegHahm commented Sep 3, 2015

Uh oh!

kaspar030 commented Sep 3, 2015

Uh oh!

OlegHahm commented Sep 3, 2015

Uh oh!

OlegHahm commented Sep 3, 2015

Uh oh!

kaspar030 commented Sep 3, 2015

Uh oh!

PeterKietzmann commented Sep 3, 2015

Uh oh!