C / C++ / MFC
|No I am in Australia .. ancestors are Dutch, South African
Anyhow you have many and varied problems ... Now all GCC have a name format called ABC
Quote:GCC A-B-C name convention
A indicates the target (arm for AArch32 little-endian, aarch64 for AArch64 little-endian).
B indicates the vendor (none or unknown for generic) . Note that this is optional (Eg: not present in arm-linux-gnueabihf)
C indicates the ABI in use (linux-gnu* for Linux, linux-android* for Android, elf or eabi for ELF based bare-metal).
C has values which seem odd until you understand the history behind it (basically AArch32 used to have a linux-gnu ABI which got changed so needed a new name so we have linux-gnueabi). For AArch32 we have linux-gnueabi and linux-gnueabihf which indicate soft float, and hard float respectively.
The bare-metal ABI will assume a different C library (newlib for example, or even no C library) to the Linux ABI (which assumes glibc). Therefore, the compiler may make different function calls depending on what it believes is available above and beyond the Standard C library.
So you have A-C your compiler is linux gnu and the output is hard floats.
What it doesn't tell me is if you are compiling on Raspbian Pi or some other linux version because that isn't inbuilt into the name. What I do know is you are putting out the right thing if you are trying to do baremetal.
Now the big problem there are big differences between where peripherals are and what they do between a Pi1, Pi2, Pi3.
So first the peripheral base address is different on a Pi1 all peripherals are at 0x20000000 on a Pi2/Pi3 they are at 0x3F000000
So that means if you ever see a peripheral with 0x20xxxxxx you know it is for a Pi1 and if you are on a Pi3 you need to change it
to 0x3Fxxxxxx. There are no exceptions every peripheral is physically moved to allow for more memory. The converse is also true
any address with 0x3Fxxxxxx is for a Pi3 and wont work on a Pi1 and you change the first two to 0x20xxxxxx
Generally we #define a variable called PI_IO_BASE or such and we just change that one number the alternative is you can autodetect it
by looking for USB hub vendor string which is on every model. The logic goes look at the Pi location if it isnt there its at the other.
volatile uint32_t* vendorid = (uint32_t*)0x20980040;
if (*vendorid == 0x4F54280A) PI_IO_BASE = 0x20000000;
else PI_IO_BASE = 0x3F000000;
So you deal with that first thing in your code and then you have the different model peripheral address covered.
There is one final snark, the UART change between models if you use it as a terminal and it is covered here
The Raspberry Pi UARTs - Raspberry Pi Documentation[^]
Quote:By default, on Raspberry Pis equipped with the wireless/Bluetooth module (Raspberry Pi 3 and Raspberry Pi Zero W), the PL011 UART is connected to the BT module, while the mini UART is used for Linux console output. On all other models the PL011 is used for the Linux console output.
So they are the programming differences between all the PI models and it is what it is.
I suspect your code is running into one or multiple problems related to those because you can't just write code for one Pi and have it work on another unless you strictly write only using the linux drivers. The moment you start poking anything with hardware you need to be aware of model differences.
If you get stuck just ask, we bash the thing around baremetal I never use linux at all ... so we know it pretty well.
In vino veritas
modified 21-Nov-18 11:34am.
General News Suggestion Question Bug Answer Joke Praise Rant Admin
Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.