[En-Nut-Discussion] Help for a Newbie

[Harald Kipp]

Hello Joshua,

At 10:07 11.07.2005 -0700, you wrote:

>1) When going through the Net Configurator, what .conf file should I use
>since I am not using a specific Ethernut board?

You can load any conf file. Then change the settings
to fit your board and save them in a new conf file.


>2) How exactly do I code a program and then load it onto the chip?  From my
>understanding, I can use a program like Programmer's Notebad to code my
>program.  Then, using one of the premade Makefiles from Ethernut, I modify
>it for the chip I am using.   I then load the program and the modified
>makefile into a directory.  Using an AVR bootloader, I load that program and
>then load it onto the mcu via the serial interface.  Also, that program I
>load onto the mcu should be a .hex file if I understand correctly.

It may help to know, that Nut/OS is not a self
contained OS like Linux or Windows. Instead,
the parts your application is referring to
are linked to your application code. The final
hex file contains both, your application and
Nut/OS.


>To try to be clearer, I am having trouble understanding exactly how the real
>time os fits into this picture of programming the mcu.  For I have already
>with just WinAVR and Programmer's Notepad programmed a simple program to
>light up the LEDs on the board.  And I did not use any real time os.  I
>understand why we want to use a real time os, just not exactly how it fits
>into programming the mcu.

Have a look to app/threads.c. It calls NutThreadCreate()
twice to create two additional threads. The code to
provide this feature is included in libnutos.a, which
is linked to the application when running 'make'. The
final hex file contains code, which runs three "concurrent"
loops.

In addition Nut/OS provides a versatile I/O interface
including fopen(), printf() etc. which make your code
quite portable. In most cases, you can develop and test
an application on a desktop computer and then change
some system specific calls to get it running on the
AVR target hardware, e.g. change _beginthread() to
NutCreateThread(), sleep() or Sleep() to NutSleep() etc.

Harald