Post by apluscwWell, for AVR the XMEGA line is well positioned and should be around for quite awhile. Atmel's XMEGA Xplain board are relatively cheap and fairly full featured. I bought an XMEGA board from Boston Android for a Halloween custom and general playing around but they stopped producing them. :(
I'll continue to keep my eyes open.
Post by apluscwFor hobbyist, the Holy Grail is the ATMEGA328, which is available in 28-pin DIP and is programmable using a $50 AVR Dragon board and Atmel Studio is 100% free. Of course, you then get into the question of whether or not OpenOCD supports the tools. :(
The ATMega328 is, indeed, a popular embedded MCU. But at 32KB FLASH and 2KB of RAM, it is not going to be hosting any significant multi-threaded applications. So it is not too interesting from my point of view as an RTOS guy.
Post by apluscwATMEGA328 -> XMEGA -> SAM4
For the money, the XMEGA's are pretty impressive. I would argue the Atmel tools are not as mature for the SAMs as for the AVRs (the tools was AVR Studio until fairly recently, not Atmel Studio.) However, if you are running NuttX, that may not be much of an issue.
BTW, Atmel has their own "Atmel Software Framework" which might be useful to set up any given microcontroller or just take advantage of things already written. How would that work with NuttX? Would the ASF code need to be pulled in? If it was modified, can it exist as part of the NuttX project? The ASF has it's own "ASF License", which I won't quote here.
Because of license uncertainties, I make an effort not to use any chip vendor software in NuttX. I might look at it as guidelines for writing my own, but every vendor software package has hidden licensing gotchas (besides tending to be awful code. Well, not awful, just wrongly purposed. Most vendor code is obviously intended to support testing, not sane application development).
<parody>
typedef enum ERROCODE_ENUM ERRORCODE_TYPE;
enum TRUE_FALSE_ENUM
{
FALSE_VALUE = 0,
TRUE_VALUE = 1,
NUMBER_OF_TRUE_FALSE_VALUES
};
typedef enum TRUE_FALSE_ENUM TRUE_FALSE_TYPE;
ERRCODE_TYPE BONHD_SetTrueFalseValue(TRUE_FALSE_TYPE TrueFalseValue)
{
CHECK_INPUT_PARAMETER(TRUE_FALSE_TYPE, TrueFalseValue, FALSE_VALUE, TRUE_VALUE);
if (TrueFalseValue == FALSE_VALUE)
{
BONHD_SetFalseValue();
return ERROCODE_SUCCESS;
}
else if (TrueFalseValue == TRUE_VALUE)
{
BONHD_SetTrueValue();
return ERROCODE_SUCCESS;
}
else
{
return ERROCDE_BAD_TRUE_FALSE_VALUE;
}
}
</parody>
I am sure that some people reading this probably think that is great code.
Post by apluscwPost by Gregory N8KB actually works pretty well because the AVRs don't require enormous stacks like the 32-bit ARMs do (but 4KB is a bit pinched). I would like to have more SRAM for significant, modern C/C++ applications.
I noticed when I glanced through the POSIX calls a reference to loading an app and running it in RAM, which made we wonder if that would be a problem for AVR both from a RAM standpoint and from a Harvard architecture standpoint.
Well, 8KB would be a problem in any case. But even so, yes, it would not work. The FLASH is connected to the instruction bus and supports only 16-bit addressing. That is why 128KB with a 16-bit address is such a popular AVR FLASH size (higher FLASH sizes require extended addressing).
So you can fetch instructions from FLASH, but you cannot access data in FLASH without some asm magic. Here is that asm magic for the AVR: http://sourceforge.net/p/nuttx/git/ci/master/tree/nuttx/arch/avr/src/avr/up_romgetc.c#l63 (Notice that despite my sarcasm above, this actually is using a AVR Studio function to read from FLASH -- pgm_read_byte_near()).
Conversely, the RAM is connected to the data bus (supporting a maximum of 64KB of RAM with 16-bit addressing). You can access data in RAM, but you cannot fetch instructions (and I don't think that there is any asm magic available in this case).
Post by apluscwPost by Gregory NBut the only real SRAM limitation that I run into with these parts has to do with the AVR's Harvard architecture: All .rodata has to lie in SRAM (or else be accessed from the instruction bus through special asm functions). Most of the NuttX example software is very console oriented, using serial output to interact with the software and for debug output. Tests like the NuttX OS test will use a lot of space for constant printf() strings and this all ends up in SRAM. Even 8KB is not enough memory for any significant .rodata storage.
You would like to keep the .rodata in FLASH as you would for ARMs. I do have some logic that will take printf() strings from the instruction space, but it is not foolproof. There is no way to make a standard, generic printf() function that works with strings in either SRAM or FLASH. Most AVR code uses special, non-portable versions for printf or else special printf formats to access strings in FLASH.
You may have more detailed knowledge than I do but having worked with both the AVRS and the XMEGA AVRs they do have some special means of insuring data gets into Flash rather than instantiated in RAM.
Yes, with the linker script, you can force .rodata to lie in FLASH or in RAM. But even if you position it in FLASH, there is no transparent way to access it. How could printf() know whether the address lies in FLASH or RAM? This is the real heart of the issue.
Post by apluscwI am more interested in making NuttX usable in a moderate, single chip embedded systems so Cortex-M4(F) platforms are more interesting to me right now, but I do have an interest in seeing how far down we can push NuttX into things like the AVR and I have lots of AVR goodies to work with. (I bought an STK500 back when having a development system for less than $100 was practically unheard of.)
Post by Gregory NPost by talkingtokenPost by apluscwAlso, I am having a hard time picturing how one actually develops using NuttX. I saw a reference to downloading using OpenOCD and some debugger. What I am not clear on is can you do traditional things like set breakpoints, single step through source code, etc? Is that all done with gdb? If yes, is it strictly text based? There is a LOT I really like about NuttX, but I can't wrap my head around how one develops and debugs with it.
I am using OpenOCD with my STM32F4 development boards and can comment on this.
... [snip] ...
I have never used OpenOCD with the 8-bit AVRs. I don't know if that is possible or not; I would have to investigate that. I don't know if there is open source AVR JTAG hardware that would work with OpenOCD. I used the NuttX buildroot toolchain with either an AVRISP mkII or an AVRICE mkII and AVRStudio (just to control the debugger). There may be some discussion in the configs/<board>/README.txt file for any particular board.
For me, support for the SAM-ICE is probably more critical, though Atmel has the SAM4S Xplained board which has it's own built in debugger. I am thinking about making that a future project. They are only $29 and a bit more direct from DigiKey.
I have a port for the SAM3U which should be a good start for the SAM4S family. It was at the point of maturing when a student bricked my SAM3U-EK. But the port is still in pretty good shape -- I believe.
I toyed with buying an Arduino Due but decided against it because I was not comfortable with the Arduino debug interface. I don't think there is really a place for NuttX in the Arduino ecosystem.
Greg