Guys, I've freaked yous lately about my battle to port the SAM5DXX bare metal framework over to C++.
Well... Sad, but I'm nearly there...
The only two issues I have now is that when I build environment using g++ instead of gcc, printf does not work.
And exceptions freeze the system.
Everything else seems fine.
Hi clawson, thanks for the suggestion. I'll have a look tomorrow.
PS: I'm using the arm-none-eabi, would my librry be "libgcc.a"?????
It may also be worth looking at picolibc. There are some ideas for doing the uart so it can work with the newlib FILE objects.
https://github.com/keith-packard/picolibc/blob/master/doc/os.md
It is my understanding that printf writes to stdout, so that needs to be set up (e.g., initialize a FILE structure.... it's in the link above). Back in the AVR universe, it is sort of the same. This links to my uart0_putchar.
https://github.com/epccs/Gravimetric/blob/master/Applications/lib/uart0.c#L175
and this to the avr-libc version of the FILE object setup
https://github.com/epccs/Gravimetric/blob/master/Applications/lib/uart0.c#L131
WARNING: my code is not well tested so don't trust it.
Update: I am a few years out from starting my C++ ten year plan, but I think "-Wl,-lstdc++" is an implicit library, so you don't need to ask for it when compiling with g++.
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dynamic_or_shared.html
and this to the avr-libc version of the FILE object setup
guys, I'm trying to add .a archives to the linker, could someone for example show me how to do this.
I've included the two make files to this post.
say I want to add "libc.a" located at "D:\arm dependencies\gcc-arm\arm-none-eabi\lib\"
Thanks guys.
Have you noticed that most .a files are actually called libXXX.a?
When you give the command -lfoo to the linker it prefixes the given "foo" with "lib" and suffixes it with ".a" so the command -lfoo means "link with libfoo.a".
By the same token then if you want to link with libc.a yous use -lc, if you want to link with libm.a you use -lm, if you want libgcc.a you -lgcc and so on.
By default it's likely to use an implied "-lc -lm -lgcc" as a minimum.
The GCC will have been built to have prior knowledge of the (relative) path to where it might expect to find libxxx.a files so normally you don't need to tell it but if you really had a d:\some\place\libfoobar.a then you might use commands such as "-Wl,-Ld:\some\place" -Wl,-l,foobar to tell it where to look (-L sets lib search paths) and the name of the lib (with the usual "lib" and ".a" additions).
Clawson: you may want to look at that picolibc link in #4, I may be wrong, but it seems to be a modified newlib, specifically the stdio was done somewhat like avr-libc so the avr-libc way of handling printf() does seem to apply.
Compiling C++ programs with the non-primary libc.
http://tldp.org/HOWTO/Glibc2-HOWTO-7.html
How to Statically Link C and C++ Programs on Linux with gcc
https://www.systutorials.com/5217/how-to-statically-link-c-and-c-programs-on-linux-with-gcc/
These options look promising from the above link
gcc -static -static-libstdc++ -static-libgcc
https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Invoking-GCC.html
use option summary to hunt for the option
https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Option-Summary.html
they are link options (e.g., -static-libstdc++)
https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Link-Options.html
Update: I don't have an Arduino IDE installed, maybe it is doing some of these options or some others.
Adding -lc to the linker sorted printf out, now lists are not working!
# linker flags
LDFLAGS = -Wl,-lc -specs=nosys.specs -Wl,--cref -Wl,--check-sections -Wl,--gc-sections
LDFLAGS += -Wl,--unresolved-symbols=report-all -Wl,--warn-common
LDFLAGS += -Wl,--sort-section=alignment
Any suggests guys?
I tried adding c++ libs no joy...
not working
Go on - you can do better than that!
Fianawarrior wrote:not workingGo on - you can do better than that!
it freezes execution. lol
Current linker flag settings are as follows:
# linker flags
LDFLAGS = -Wl,-lc -specs=nosys.specs -Wl,--cref -Wl,--check-sections -Wl,--gc-sections
LDFLAGS += -Wl,--unresolved-symbols=report-all -Wl,--warn-common
LDFLAGS += -Wl,--sort-section=alignment
some C++ functions work but link lists and exceptions don't work..
Any suggestions lads?
The problem is definitely a link flag option missing, the linker is using g++ by the way...
Without -Wl,-lc the C++ list functions work, with they do not...
I've tried that, feck it, I'll re-check.
giving that we are now a couple of hours later.......
did Fianawarrior freeze to execute too now? so can we conclude that up on re-checking the suggested sollution did not work????
On that bombshell we start the day and wait for the fog to clear.......
giving that we are now a couple of hours later.......
did Fianawarrior freeze to execute too now? so can we conclude that up on re-checking the suggested sollution did not work????
On that bombshell we start the day and wait for the fog to clear.......
lol.
Nah, never worked. Printf works when I include -lc or -lg in the linker flags but lists in c++ don't work. There are probably other things that also do not work.
When I remove -lg or -lc then the C++ works but printf does not works.
I just missing a number flags tht I'm unware of.
Nearly there, one last error. C++ works, so does printf. But when I try to boot my kernel it fails? No idea why or what the exact error is but I'm close. very close..
I'm close. very close..
He missed it by that much...... Maxwell Smart
SAM5DXX bare metal framework over to C++.
He was talking ARM not AVR so the avr-libc way of handling printf() does not apply here.
Are we, yet again for this poster, doing ARM discussion on the AVR8 forum set?
Are we, yet again for this poster, doing ARM discussion on the AVR8 forum set?
All the time.
And not the first time it's caused confusion.
Sorry guys but I like to annoy yous. Anyway, more freaks here in this forum. I think someone died of boredom in the ARK forum.
Tíocfaidh ár lá!
Sorry guys but I like to annoy yous.
You began to do that quite a while ago.
Latest complaint from me, and moving to the appropriate forum: https://www.avrfreaks.net/commen...
And another, the same day: https://www.avrfreaks.net/commen...
My reply referred to January 19 ---
Curiously in the intervening couple weeks the OP did indeed post several things in ARM-World...
Anyway, more freaks here in this forum. I think someone died of boredom in the ARK forum.
What did I tell you?
[yeah, I know, "when I post on these Forums I get answers". Still, there should be a vigorous ARM community somewhere...]
Cut it out. Go play with your ARM or fingers or socks or whatever somewhere else. Just my opinion...you seem to have the knowledgeable regulars under your spell.
https://www.avrfreaks.net/forum/... And there you SAID it wasn't the right place for SAM stuff.
Same comments there, from me and others.
clawson wrote:I think you'll find it's simply because he's got some "good answers" in the past when posting to AVR (actually AVR32 in fact) whereas "ARM" may be a bit of a desolate wasteland for this kind of question.Well, yeah -- agree [nearly] 100%. 'Freaks is a great resource. It isn't my problem that that forum is a wasteland. I'd speculate without digging that this is not the first instance from this poster. Poster should put into off-topic, or perhaps a link there to the posting in the proper wasteland and then anyone that might be interested can follow up.
Next we'll hear about PIC 99V99 COMP operation in COBOL on Burroughs Medium Systems, perhaps. "General Programming", right? And a vast wasteland elsewhere. CC RM ///
But perhaps Cliff hit it in the next post. Hmmm--better not quote that here.
Perhaps what started me off is the attitude about Microsoft LFN patent(s) a year ago:
https://www.avrfreaks.net/forum/...
https://www.avrfreaks.net/forum/...
holy shite! really!
lol, I'm from Ireland, we don't do licenses.
Slán
So complete disregard for intellectual property rights, and then repeated disregard for this site's posting guidelines. Is it me that is way off base?
The only Fiona I can think of: Fiona Glenanne from Burn Notice
theusch wrote:
Are we, yet again for this poster, doing ARM discussion on the AVR8 forum set?
All the time.
And not the first time it's caused confusion.
I agree with both of you that this is indeed an ARM (not a leg) related question. BUT, sadly there is no General Programming forum in teh ARM community, and the OP originally posted in teh Off-Topic forum. I moved it the the general programming as its the most appropriate forum overall.
Jim
BUT, sadly there is no General Programming forum in teh ARM community,
Not true.
And some of OP's previously reported posts were moved there. The existence of that forum has been made known to OP, and indeed a few threads were started there by him/her. You can find this direction in the threads I linked to.
BUT, sadly there is no General Programming forum in teh ARM community,
LOL -- you recently posted there:
Begone!
Right guys, have c++ working, completely!!! lol, so I won the SAM-ICE!!!
One last error though, is that when I call a c++ routine that has a exception in it then the under lying c code (kernel) freezes. after the call to the function that is throwing the exception.
I'm guessing I require a flag in the linker or compiler.
Any suggestions?
So... What was wrong with lists?
when I call a c++ routine that has a exception in it then the under lying c code (kernel) freezes.
Is the compiler generating an actual exception to handle C++-level exceptions? Perhaps an exception that there is no handler installed for? That seems to be a common source of "freezing" ARM code.
The only Fiona I can think of
Ah, but it's "Finana", presumably related to:
Fianna (singular fiann; Scottish Gaelic: Fèinne) were small, semi-independent warrior bands in Irish mythology.
jgmdesign wrote:BUT, sadly there is no General Programming forum in teh ARM community,LOL -- you recently posted there:
OOPS!! Goes to show I am not paying attention....not the first time. Thanks for the mental kick in the head Lee.
JIm
So... What was wrong with lists?
when I call a c++ routine that has a exception in it then the under lying c code (kernel) freezes.
Is the compiler generating an actual exception to handle C++-level exceptions? Perhaps an exception that there is no handler installed for? That seems to be a common source of "freezing" ARM code.
The only Fiona I can think of
Ah, but it's "Finana", presumably related to:
Fianna (singular fiann; Scottish Gaelic: Fèinne) were small, semi-independent warrior bands in Irish mythology.
Yup, that's me. An independent warrior fighting c++……………………...
Guys, gassed here, think I'll call it a night.
Stoned too, "much".
Guys, I've freaked yous lately about my battle to port the SAM5DXX bare metal framework over to C++.
Well... Sad, but I'm nearly there...
The only two issues I have now is that when I build environment using g++ instead of gcc, printf does not work.
And exceptions freeze the system.
Everything else seems fine.
Do you have a link to a git repo somewhere to follow your progress? Maybe this is a dumb question and Im missing it
Still no joy in getting the system functioning perfectly with c++. Going to look at the kernel code.
In particular this:
// Setup Status registers
if (((unsigned int)task & 0x01u) == 0x01u) { /* See if task runs in Thumb or ARM mode */
*cpu_core_stack-- = (OS_CPU_ARM_BIT_CPSR_MODE_SUPERVISOR /* Set supervisor mode. */
| OS_CPU_ARM_BIT_CPSR_T); /* Set Thumb mode. */
} else {
*cpu_core_stack-- = (0x00000100 | OS_CPU_ARM_BIT_CPSR_MODE_SUPERVISOR);
}And crack out the debugger...
yeah, me thinks its the kernel code...
Find out more tomorrow when I test it.
C++ is working, my kernel is failing in IRQ mode when making a context switch...
Bored looking for the error...…….
checked the context switch. It works! I'll explain a little.
When I call a c++ function, namely temeplates, lists, and exceptions cause the system to hang when an irq occur afterwards, in this case TC0.
Theres another thread on this subject:
https://community.atmel.com/foru...
This is getting out of hand.
JIm