Understanding an embedded C language variable declaration

I'm trying to understand some embedded C code that declares a variable.

uint8_t *p=(uint8_t *)&NOCAN_REGS;

The NOCAN_REGS is a structure defined in a different file (see link below)

My understanding is that the variable "p" is a pointer to an unsigned 8 bit integer, but everything from the typecast after the equals sign is a mystery to me.

I would appreciate a step by step explanation, or a link to a learning resource that can help me master this syntax.

• https://github.com/fastbike/canzero-driver-firmware/blob/master/driver/nocan.h

Okay, here is everything after the = sign:

(uint8_t *)&NOCAN_REGS;

Taken from right to left (because it's easier to explain in that order):

NOCAN_REGS;

... this is the name of a global struct-object, as you mentioned.

&

The & sign indicates you want a pointer-to-whatever-is-after-it, so

&NOCAN_REGS

... means "pointer to the NOCAN_REGS struct".

(uint8_t *)

The cast is here to forcibly change the type of the expression from nocan_registers_t * to uint8_t *. That is, you are telling the compiler that you want the expression's type to be pointer-to-unsigned-bytes, rather than a pointer-to-a-nocan_registers_t.

Typically a programmer would do a cast like this when he wants to treat a struct's memory as if it were a raw byte-buffer. It's a tricky thing to do, since when you throw away the type-information like that, issues that the compiler normally takes care of for you (like the endian-ness of member-variables, their alignment to appropriate boundaries, padding bytes, etc) now become things the programmer has to think about... but it can be useful in cases where you want to e.g. dump the raw memory to disk or similar.

NOTE: The code you link to is very flawed and amateurishly-written with many bugs and bad practices.

Since it mentions SPI, it would appear that the purpose is to control an old external CAN controller like MCP2515 etc using SPI. (Please note that most engineers stopped using these external CAN controllers long before Cortex M and STM32 were even invented.)

To explain what the code does and the problems I could spot only at a glance:

• NOCAN_REGS is apparently a struct corresponding to the memory map of the registers in an external CAN controller accessed over SPI. This struct has two oddities: packing was disabled and one member is volatile qualified.

  If this had been an on-chip CAN controller then the whole of it would have to be volatile. In this case volatile only serves as protection against compiler optimizations when the variable is shared with an ISR. So it's correct but should perhaps be documented better.

  What's worse is the disabled packing, which means that the uint32_t members are likely allocated at misaligned addresses. So accessing them as uint32_t might cause hard faults. Not sexy. These should have been uint8_t [4] arrays. (Or alternatively padding should not have been disabled and the struct should be serialized/deseriazlied on member-by-member basis.)

• NOCAN_REGS is declared as global variable and exposed to the entirely program, which is very bad practice. It should have been declared static. It should not be in the header. No other part of the program but the driver should access it, if the program design was sound.

• The uint8_t *p=(uint8_t *)&NOCAN_REGS; etc casts are used for the purpose of serialization - turning a larger type into a byte stream. Most SPI communication and external CAN controllers work with bytes. By taking the address of the struct &NOCAN_REGS and converting it to a pointer to uint8_t, we can access the struct byte by byte. So it's handy for passing on a struct to the SPI hardware.

  Normally casts like this would be deeply problematic in C, but there is a special rule (ISO C 6.3.2.3) which allows us to inspect any type in C using a pointer to a character type. On all sound mainstream systems, uint8_t is just a typedef for unsigned char so it is a character type. Meaning that the cast is valid and de-referencing the struct byte by byte is also valid. (The opposite - going from an array of character types to a struct, by using a struct pointer, is not allowed/undefined behavior.)

• Examples of such undefined behavior are the casts (uint16_t*)CHIP_UDID, (uint16_t*)NOCAN_REGS.UDID. Anything can happen here, it could lead to misaligned access and strict aliasing violation bugs. Never write dirty casts like these.

• The macros NOCAN_STATUS_SET should set off all alarms and blinking red lights during code review. You do not write drivers for a specific hardware peripheral that handle re-entancy to an ISR by disabling the global IRQ mask. This will trash all timing and behavior of any other unrelated interrupt present on the MCU. I've lost count over how many times such rotten driver code have caused problems. These should only disable the specific interrupt for the CAN and/or SPI peripheral, not shoot the whole MCU timing to pieces each time the struct variable is accessed.

• Please note that CPU endianess (STM32 is little endian) vs CAN controller endianess may be an issue here. I don't know which controller that's used, but one has to have this in mind during serialization. CAN overall has a tendency to favour big endian and the CAN data link layer uses big endian (identifier, CRC).

• ~D etc on a 16 bit type while executing on a 32 bit MCU isn't correct. Hello integer promotion: the result of ~0x5476 will not become 0xAB89 but 0xFFFFAB89. Which is then treated as a negative number dec -21623. The whole pseudo_hash is plain sloppily written by someone who seemingly didn't grasp integer promotions in C - if it works at all it is because of luck.

Overall I would strongly recommend not to use this code. It needs to be reviewed more in-depth than my brief review above, and this needs to be done by someone with at least intermediate embedded C/microcontroller programming skills. After that, it might be possible to salvage the code, but at a bare minimum, the misalignment and global IRQ bugs must be fixed.