AVR Freaks

Ive got question regarding scanf

Thats when i want to read 2 strings seperated by spaces ' ' , and want to read the 2 strings like this:

The fist string is read propperly but the 2nd string is disregared when I type this in a terminal window:
"ABC DEF"[CR]

string1 = ABC
string2 waits fir user input!

Other C compilers use DEF for the 2nd string automaticly I think.
Im using this scanf programming style for commands such as
CD [path]
OPENFILE [filename]
etc

I think the problem depends on how the input buffering works. scanf()
consumes a single char at a time from the input stream, and tries a
conversion. If the char cannot be converted, it is pushed back onto
the stream (by means of unputc(), which will make it be held in a
special area inside the FILE* structure). So if no more formats are
available, it will simply cease reading input data. If you've been
able to enter a full line before anyway, somehow you application must
have buffered it somewhere. Of course, the next call to scanf should
then start reading the old input buffer at the same spot where the
previous scanf stopped.

Actually, I always found it more practical to read full lines into a
local buffer, and then sscanf it.

Uhm it doesnt matter that I declare different character arrays inside each function for scanf does it?

actual shell code:

function example:

:oops:

Im not buffering anything regarding the UART/RS232.... That must be the problem right?

I have a plain RX routine that checks if theres data or not,, if not it just returns nothing.

So make a buffered UART routine to solve my problems with scanf?

the speed of which rs232 is send to the device isn't faster then my hand typing.. thats troughly maximum of 22 bytes/sec at tops :P

The avr must be getting really bored when processing 22 bytes/sec @ 16MHz

8)

Writing interrupt driven loop-buffered uart thingy now,, or ill rob someones else,, , there's no point in re-inventing the wheel.

(Better use new threads for unrelated items.)

That's because you probably don't know what you're doing. You request
a 16-bit wide unsigned conversion, but only supply storage for 8 bits
(uint8_t). Obviously, another 8 bits of possibly important to you
data might be overwritten that way.

While C99 offers the `hh' modifier for that purpose, the current stdio
implementation only implements the C89 (ISO-C 1990) feature set, so
you stand no chance to convert directly into an 8-bit variable, sorry.
While it would certainly be possible to extend the functionality to
cover all the interesting C99 items (as we don't implement wchar_t's
in the library it would e. g. make no sense to implement conversions
for it in stdio), I somewhat hesitate to do this in order to not bloat
the already huge stdio code even more. What do people think? (It
would probably be easy enough to add those modifiers for intmax_t,
ptrdiff_t, and size_t without much bloat, as they are merely aliases
for already existing conversions. Anything else, in particular `ll'
and `hh' modifiers would cause much bloat though.)