MCU C programs architecture patterns

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good day!

I'm curious about MCU C programs architecture patterns. One (common?) pattern I use is:

- interrupt routine set some flags in C bitfield marked 'volatile'
- flags are processed inside loop in main()

Are there any other proven techniques?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Isn't this a bit like saying "What's the best route to take when driving from London, UK to Auckland, NZ?"

[also what relevance does this have to GCC in particular? If none, I'll move it to the AVR Forum]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry for posting in the wrong forum. It seems I can't move the topic by myself, do you have rights to do this?

Thanks!

About my question -- that's not a question about what is best, I just want to find options I can choose\mix from :)

I want to establish in my mind something like famous GoF patterns (http://en.wikipedia.org/wiki/Des...) or Martin Fowler architecture patterns, but for low-level C code :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Buy yourself a packet of cigarettes and a pencil.
Discard cigarettes if you do not smoke.

Draw your flowchart on the back of the packet.

Scratch your head / testicles.

Draw another flowchart on another packet.

Rinse and repeat.

You will find that most times you have a setup() and loop() structure. You might poll things in your loop(), or you might just let interrupts do everything in the background. Or most likely, a combination of the two.

David.

p.s. smoking is bad for your health.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another "pattern" is polled operation. It has some strengths and some weaknesses compared to interrupts. In a few, fairly rare, cases when timing is critical, polling MAY have an advantage. Whether or not this is a solution rather than just a personal preference comes from a timing analysis and a familiarity with the structure of interrupt service routines in c.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Scratch your head / testicles.

LOL :) To limit damage to various parts of the body, I'm looking for some proven techniques :)

I've found some tutorials (in Russian) on different patterns and approaches, in case anybody interested:
http://easyelectronics.ru/avr-uc...
http://easyelectronics.ru/avr-uc...
http://easyelectronics.ru/avr-uc...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you need to perform long tasks in your firmware, state machines would be a good choice. Basically, they let you break up your long task in multiple small states and you would process one state on each iteration of your main loop. This is especially useful if your app needs to run multiple things, such as running your long state machine and monitor and ADC and serial port.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, state machines seems to be good and proven option...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Which then leads to RTOS as another possibility (but only on large/complex designs).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I hold myself away from RTOS for AVR (but they are really very interesting! :)) before I get more familar with writting programs without any 'framework'.

I assume for RTOS I should have at least something like ATmega168?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I assume for RTOS I should have at least something like ATmega168?

I always reckon that the coplexity boundary that justifies the use of an RTOS occurs somewhere between 32K and 64K in fact. Your mileage may vary.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, thanks!

So this shifts my need for RTOS a little :) For now I'll stay with something smaller.

By the way, which open-source RTOSes you can recommend?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

By the way, which open-source RTOSes you can recommend?

One of these:

RTOS for AVR

(personally I'd probaby go for "FreeRTOS")