you just can't get flash a led easyly.
An operator issue?
Just think of GPIO on AVR/PIC and in STR32F4 series.. Look at the number of pages you have to read to work on..
you have to deal with a lot to just blink a led
Not really sure what you meant here. To blink an led, a few things are involved, regradless of which chips you are on
#include <hal>
int main()
{
core.init();
Pin led(P1_0, OUTPUT); // depending on MCU, for ST PA_0 for intance
while (1)
{
led = !led;
wait(500);
}
}
#include <hal.h>
Pin led1;
Pin led2;
Task<128> task1; // task with 128 byte stack
void handleLed1Task()
{
while (1)
{
led1 = !led1;
wait(250);
}
}
int main()
{
core.init();
led1.init(P1_0, OUTPUT);
led2.init(P1_1, OUTPUT);
task1.start(handleLed1Task);
while (1)
{
led2 = !led2;
wait(500);
}
}
The code above is not C, but CPP btw. I also don't understant why embedded community does not use C++.. Using virtual methods, templates it openned a lot of oportunities..
Wouldn't a beginner just grab a code sample and go from there?
Some C++ features add overhead
In documentation it says FIO0SET, however in CMSIS there is no FIO0SET definition. You have to use LPC_GPIO0->FIOSET.. This is another headache..
Yeah I know what you mean, when I got bit banding in my course I was laughing my ass off, using 1MB codespace so with writing directly one word you can toggle 1 bit. Then ofcourse with a memoryspace of 4GB you have some room to spare, but what a waste if you look at it from an 8 bit POV.
Wouldn't a beginner just grab a code sample and go from there? Last time I checked NXP provided example projects, at least for their LPCXpresso devboards, that included a blinky program. From this you can easily modify the program to change the frequency / duty cycle, blink multiple LEDs, wait for a button, etc. All the complex stuff like GPIO setup is handled by the provided project, although eventually one has to figure out what those mysterious lines that you copy-pasted mean.The code above is not C, but CPP btw. I also don't understant why embedded community does not use C++.. Using virtual methods, templates it openned a lot of oportunities..Some C++ features add overhead. Virtual methods add an extra layer of indirection to every method call, for example. Many embedded applications are sensitive to overhead, although I'll admit that a blinky program on an ARM Cortex is not one of those. Historically compiler support for C++ has also been weak for embedded targets. The free version of the Code Red IDE does not support C++.
using bit-banding each could be represented by a single bit in memory without having to do a lot of masking and shifting.
At a quick glance bit-banding seems as useful as an ashtray on a motorbike
QuoteAt a quick glance bit-banding seems as useful as an ashtray on a motorbike
It is for speed as well as atomicity.
Quoteusing bit-banding each could be represented by a single bit in memory without having to do a lot of masking and shifting.Bit-banding is the opposite: by writing to a memory location (could be a byte / half-word / word, depending on the setup) you could change a bit.
QuoteIn documentation it says FIO0SET, however in CMSIS there is no FIO0SET definition. You have to use LPC_GPIO0->FIOSET.. This is another headache..
I am not sure which chips you are specifically talking but it is not unique to CMx chips that you need to read the compiler manual + header files in addition to the datasheet. Those structs are well documented in there. In my view, they are far better than the Luminary / TI / typical 8-bit approach of using discrete memory addresses for such names.
BTW, the CMx chips have fairly standard naming convention (of using FIOSET/DIR/CLR...). Where did NXP use the FIOxSET/DIR/CLR convention?
QuoteIn documentation it says FIO0SET, however in CMSIS there is no FIO0SET definition. You have to use LPC_GPIO0->FIOSET.. This is another headache..
I am not sure which chips you are specifically talking but it is not unique to CMx chips that you need to read the compiler manual + header files in addition to the datasheet. Those structs are well documented in there. In my view, they are far better than the Luminary / TI / typical 8-bit approach of using discrete memory addresses for such names.
BTW, the CMx chips have fairly standard naming convention (of using FIOSET/DIR/CLR...). Where did NXP use the FIOxSET/DIR/CLR convention?
You still talk like experienced developer.. I am sure you just grab a MCU, and start using it in a few hours.. Was the discussion about why ARM was a little tougher than 8 bit-ters?
I was talking about NXP's LPC17 series..
On ARM shifting is nearly free of charge..
No actually the discussion was originally about me possibly making the move to ARM or PIC32 (I do have some background on PIC 8 bit chips) because I am starting to get into interests revolving around audio and video processing with embedded chips. Somehow it got derailed a bit along the way with discussions about ARM chip setup and peripheral access...