this issue might also be one of others than myself
my main development environment is based on linux ... firmware, QT, android and whatever comes along ... i used to write firmware starting with the 8085, z80, 68k and for the last 10 years on arm from mostly nxp, so i'm pretty familiar with eclipse (lpcxpresso flavor) as well as keil and iar while working at nxp a while back ... i see no reason to try the keil light ide and later overrunning the 32k boundary and facing to cough up 5 grand for the real license
my current project is to eliminate code written for 2 different (m4 and m0) mcus which communicate via ble serially to a ble based nrf5x module ... why use one arm on the main board and another one on the ble module if the code of the on-board arm can run on the ble module wired to an mcu less main board
setup :
installed eclipse oxygen with cdt, installed eclipse gnu mcu plug-ins, installed toolchain "gcc-arm-none-eabi-6-2017-q2-update", fetched and installed all nrf packages, installed nrf SDK 10.x for my 51822 based 1st test proj
did the toolchain test "arm-none-eabi-gcc --version"
ran the make test "/examples/peripheral//blank/armgcc/" on the blinky example
so far so good ;)
now the real issues showed up, maybe being part of my lack in real computer science
tried the makefile flavor of the blinky example in my eclipse setup ... don't remember the errs and didn't like a makefile only proj ... no makefile only for me
went back to my bare metal days with some of my eclipse arm projects ... start simple and build on it
oh, before i forget, i use almost exclusively my own modular style C++ in all my firmware projects in this 21st century we're living now ... no more time for legacy "C" only based stuff ... i agree there is some stuff which tends to lead to "C" implementation which is ok
so i created a new C++ "hello" cortex-m arm proj and it compiled without errs, but there is a lot of system fuzz attached to it ... for now i can live with it
started to strip the main part of the project down to main.cpp ... the arm timer code goes and a couple others
replace the main.cpp portion with the blinky main content and add an extern "C" { ... } around the main funct in case there are some issues with the C++ name mangling
in "C/C++ Build -> settings -> assembler and compilers -> includes" i satisfy the new #includes to point to the nfr SDK locations ... add NRF51 and BOARD_PCA10028 to the preprocessor sections and it all almost compiles
i do not expect anything to load and run at this point, but it's a step forward
i have a few issues open i would like to bring up at this point in the game
-
" nrf_delay_ms (500) ; " throws an undefined reference ... what am i or the sdk missing at this point ... nrf_delay.h contains the prototype for the funct, but why am i or eclipse not finding the implementation
-
i realize that all the "system" stuff i inherited with the creation of a new empty "hello" project is not gonna run on an nrf51 mcu, but where can i find the replacement startup and other inits for a bare metal simple blinky to flip one gpio pin ... at the early nxp based projects with lpc-open, before the new mcuxpresso SDK became fashionable, there was a cr_startup_lpc82x.cpp or similar file containing the startup and intr vectors and whatever was necessary to later jump to "main"
it doesn't need to be contained in one file, but where is this stuff with respect to nrf bare metal (no softdevice) projects just for the purpose to flip a bit
i'm reading now for a few days whatever i can find nordic related, but didn't hit the mother lode yet
- i was spoiled by nxp with their ...xpresso support providing tailored memory maps for ever chip and could live without it, but i'm a bit stuck with the linker scripts ... the fetched and installed nrf packages provide a very simple memory map under the "settings -> devices" tap but it has a "Memory map (Warning: Not yet used to generate the linker scripts!" and is greyed out, so no use ... i know, not nordics problem
can i now freely edit the mem.ld linker script or is this auto generated and i have to set the boundaries by other means
- that's it for now and i don't want to explore the world with a softdevice yet, even i will need it eventually ... the same is for how to i get the code into the device ... simply later
one word to get this questionnaire wrapped up ... almost every chip mfg supports in one way or another the open source society of linux and others with eclipse (TI seems to be the exception, but with their windows only based CCS and the ti-rtos for the CC264x parts is definitely not a choice for me ... not for the windows only based CCS only, but for the ti-rtos being forced upon their users complicating otherwise simple things)
i like the nordic chips so far but why are the 5k $ keil and iar ide as a dessert the only sweets if i choose nordic for the main meal ;)
any fruit bearing answers are highly appreciated
am i the only one asking for more linux and eclipse support, other than the cryptic makefile only way
is my approach of simple steps the right one to achieve at least one simple eclipse managed project from which it might be easier to derive others
cheers efiLabs
