[En-Nut-Discussion] USART0 problem...
Harald Kipp
harald.kipp at egnite.de
Tue Mar 11 19:24:19 CET 2003
Same occured here a few times, too seldom to track it.
One reason might be the initialization stack problem with
GCC and Nut/OS 3.0, which I reported previously.
Try to increase the sleep following the baudrate ioctl.
_ioctl(_fileno(uart), UART_SETSPEED, &baud);
NutSleep(500);
In order to fix the stack problem, add
#define main NutAppMain
immediately before
#endif /* GCC */
In NutInit add:
#ifdef __GNUC__
/*
* Some special declarations for AVRGCC. The runtime library
* executes section .init8 before finally jumping to main().
* We never let it do that jump, but start main() as a
* separate thread. This introduces new problems:
* 1. The compiler reinitializes the stack pointer when
* entering main, at least version 3.3 does it.
* 2. The compiler doesn't allow to redeclare main to make
* it fit for NutThreadCreate().
* 3. The runtime library requires, that main is defined
* somewhere.
* Solutions:
* 1. We do not use main at all, but let the preprocessor
* redefine it to NutAppMain() in the application code.
* See compiler.h. Note, that the declaration of NutAppMain
* in this module differs from the one in the application
* code. Fortunately the linker doesn't detect this hack.
* 2. We use a linker option to set the symbol main to zero.
*
* Thanks to Joerg Wunsch, who helped to solve this.
*/
void NutInit(void) __attribute__ ((naked)) __attribute__ ((section(".init8")));
extern void NutAppMain(void *arg) __attribute__ ((noreturn));
#endif
The NutInitLine is already part of the release.
Then you need to run "make install" in the installation directory
and also "make clean" and "make" your application samples.
Please let me know, if this helps.
Harald
More information about the En-Nut-Discussion
mailing list