How do you structure a large C project for embedded applications.

[Mechatrommer]

yeah +1 if you are not in dipsheet hurry up profit based organization. its been discussed here one example, the largest company that is as large as all-tee-uhmmm.

[miguelvp]

yeah +1 if you are not in dipsheet hurry up profit based organization. its been discussed here one example, the largest company that is as large as all-tee-uhmmm.

all-tee-uhmmm is way smaller than the company I work for, heck, it's bigger than Mickey D's

Still +1 on unit testing, saves a lot of mula!

Unless I misinterpreted what you where saying!

[neslekkim]

+1 on unit testing at least.

How do you unittest mcu code?

[neslekkim]

Seems like Adafruit is starting on some guide also:
https://learn.adafruit.com/ktowns-guide-to-readable-c-code

[dannyf]

Seems like Adafruit is starting on some guide also:

Nicely done.

I like the sublime 2 styled background,

[nctnico]

+1 on unit testing at least.

How do you unittest mcu code?

Compile it on a PC and run it there.

[neslekkim]

+1 on unit testing at least.

How do you unittest mcu code?

Compile it on a PC and run it there.

?
Emulator?, haven't seen much of emulators for small mcu's, and running mcu code on an your pc seems kinda strange.

[Mechatrommer]

Seems like Adafruit is starting on some guide also:

Nicely done.

if you browse carefully... there is no such thing as the word "embedded" in there. its all "history" lesson that the "people who have died" are already knew from looking of it, it still short of many things like modularization/reusability and encapsulation technique. and oh i should project the history lesson back to the assembly age, since everybody talking about hardware access. you should know in which layer you are, being in c# is being in the topmost layer of today. btw.... i've made emulator for my arduino c/c++ color LCD code for debugging in more capable ide. as someone said, a good code is independent of the languange and hardware running the code. fwiw. ymmv.

[HackedFridgeMagnet]

In C# you probably use permeative multi threading

Sorry couldn't ignore it. Should be Preemptive. 

[Mechatrommer]

and to avoid being accused of not helping, i believe this is the right site for the topic...
things like... https://www.google.com/search?q=c+coding+style&rls=com.microsoft:en-us&ie=UTF-8&oe=UTF-8&startIndex=&startPage=1
one example is... http://users.ece.cmu.edu/~eno/coding/CCodingStandard.html

[nctnico]

+1 on unit testing at least.

How do you unittest mcu code?

Compile it on a PC and run it there.

?
Emulator?, haven't seen much of emulators for small mcu's, and running mcu code on an your pc seems kinda strange.

I develop code for embedded projects on a PC all the time. In most cases 99% of the code running on an MCU is not hardware specific. It doesn't make much sense to debug such code on a microcontroller with limited debugging capabilities. On a PC you can read files with stimuli and write files with all kinds of output data. Actually you could fire interrupts from a second thread. On a PC with multiple processors you'd give the mutexes/semaphores a thourough test.

[dannyf]

I just looked at a project I worked on last year. 350 source/header files + CMSIS + about 10 user files specific to the particular project. It takes 90 seconds to compile on an I7.

All the 350 files are canned modules accumulated over time and reused for this project. Maybe 1/3 of that code base is specific to this particular target. The rest are generic (not target specific).

Most of the coding for the project was done over a 2 months period. If I had to write the whole thing from scratch, it would have easily taken me a year, and a lot more time to debug it.

[MacAttak]

It should be pointed out that code style guidelines aren't really the same thing as project structure guidelines.

Many really large codebases will use automated formatting tools anyways that apply consistency policies upon check-in.

[dannyf]

code style guidelines
...
automated formatting tools

Coding styles are probably more than formatting guidelines.

[kile]

Code: [Select]

uint8_t temp_rtc_minutes;
cli(); // disable interrupts
temp_rtc_minutes = RTC_minutes_AT;
sei(); // restart interrupts
... use temp_rtc_minutes for something ...


I don't want to be a nitpicker here, but I think that in this particular case (assuming RTC_minutes_AT is also uint8_t) it is not necessary to disable the interrupts. If you just want to read the state of an 8 bit value that is changed inside an ISR, you can just read it and carry on. Nothing bad can happen.

Now, if RTC_minutes_AT were uint16_t, or if you actually changed the value of RTC_minutes_AT that would be a different thing.

[HackedFridgeMagnet]

idk about you but I can change a uint32_t atomically 

[MacAttak]

Doesn't a shared var (one used in ISR's) also need to be flagged with volatile to prevent caching?

Also, unless you are absolutely certain that your particular processor supports reading/writing a particular integer type atomically, then it's best to not assume it. Different hardware will behave differently. For example, I wouldn't expect an 8-bit MCU to do 32-bit operations atomically. And technically the C and C++ languages don't make any guarantees of atomicity - not even for simple assignment statements on 32-bit hardware. If your data is naturally aligned then 32-bit ops will happen to be atomic - but not if you have packed structs that don't follow natural byte alignment.

[dannyf]

I don't want to be a nitpicker here,

You are correct, obviously.

Another case is reading / writing of multi-byte types on 8-bit mcus. Sometimes there is hardware support for atomicity. Otherwise, it requires a little bit more work.