AVR metaprogramming (C++, article)

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

Embedded

C++ template metaprogramming for AVR microcontrollers

by

October 19, 2016

http://www.embedded.com/design/programming-languages-and-tools/4442876/C---template-metaprogramming-for-AVR-microcontrollers

If you're like me and are weak on C++ consider reading the last page first.

 

"Dare to be naïve." - Buckminster Fuller

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

gchapman wrote:
... consider reading the last page first.

 

Direct link to save scrolling-through to the last page

 

http://www.embedded.com/design/p...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use C++.  If I had to use C, I'd take up stamp collecting instead.  smiley   My code is portable in the sense that I can run it on a PC and test a lot of it, but not all of it, before I install it on my AVR.

 

I don't use templates although I can see where it could make I/O register access more efficient, at the expense of a bigger program.  

 

I damn sure use inheritance.  Inheritance can make some things simpler to code and I don't think there is a performance penalty, at least for what I use it for.

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

steve17 wrote:
My code is portable in the sense that I can run it on a PC and test a lot of it, but not all of it, before I install it on my AVR.
How is C different in that sense. I've been doing C projects for the last 15..20 years and I think almost all of them have been part developed in PC simulation.

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

clawson wrote:

steve17 wrote:
My code is portable in the sense that I can run it on a PC and test a lot of it, but not all of it, before I install it on my AVR.
How is C different in that sense. I've been doing C projects for the last 15..20 years and I think almost all of them have been part developed in PC simulation.

It's not that sexy. By far.

 

JW

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

Well I dunno.  Can you test the drivers for the peripherals in the simulators?  I looked at Atmel's simulator but it didn't seem very promising.  Maybe I didn't look at it hard enough.

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

On the projects I work on (much larger than AVR) we simulate all the hardware components that are not easily attachable to the PC. But the key thing is the replacement of the user input and output with keyboard/mouse in and Windows/Linux client window output. You can then exercise most of the components of the code in the PC build.

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

We got off on a simulator tangent.   I was replying to the link.

http://www.embedded.com/design/programming-languages-and-tools/4442876/C---template-metaprogramming-for-AVR-microcontrollers

 

They used simulators and templates and they didn't use inheritance because they were inefficient.

 

I replied that I C++.   I use simulators.  I don't use templates, but there may be a use for them.  I do use inheritance and I believe they are not inefficient.

 

No matter how you slice it, I think C++ is a better language because the modularity makes for code that is easier to understand.

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

steve17 wrote:
I think C++ is a better language because the modularity makes for code that is easier to understand.
I don't disagree with that. (though we were writing "modular C" long before C++ was a real possibility). What I was questioning is how C++ makes simulation any easier. If you are writing C not C++ in a modular way then you just replace your I/O modules with simulations.

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

Like I said, C++ makes all programming easier.  I don't replace I/O modules.  They run in the simulator the same way as they run in the AVR.  

 

For example, if the AVR code sets the "start conversion" bit in the ADC registers, the simulator thread notices that.  It then fakes a conversion.  It flips the appropriate bits and sets a value in the conversion results register.  If the ADC interrupt is enabled, it then runs the ISR.  The clueless AVR code thinks it did a real conversion.

 

I like the idea of the simulator simulating the peripherals. Lets face it, the reason we use microcontrollers isn't to use the diddly squat CPU, it's the peripherals.

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

steve17 wrote:
They run in the simulator the same way as they run in the AVR.
OK so you have a 3x4 keypad as your input device on the AVR. How does the identical I/O code work on the PC then? If it were me I would be replacing "class Keypad {}" (or just module keypad.c) with something that shows some buttons on a Windows hDC and then reads mouse clicks as the 4x3 "input" and feeds that back to the modules that instantiate the Keypad class object(s). The clients of the KeyPad class don't care how the "press at (2,3)" info is being generated - they just consume it the same whether it's on the AVR and real PORTs/PINs connected to a real 4x3 matrix or this Windows based simulation.
steve17 wrote:
For example, if the AVR code sets the "start conversion" bit in the ADC registers, the simulator thread notices that. It then fakes a conversion.
Yeah, sure, things like the simulator in AS7 show that it is fairly easy to simulate the action of the internal AVR peripherals (ADC, SPI, timers, etc) but how do you get on with an HD44780 or my 4x3 keypad or whatever? For an HD44780 I assume the exposed interface from the "class LCD44780{}" or whatever it is called is things like lcd.home(), lcd.puts("hello") and stuff like that? So in Windows simulation I'd google myself up an HD44780 font. I'd paint the client area of a wide, squat child window client area in a dirty light green and I'd draw things on it in black ink.

 

or I'd just spend £300 on a copy of Proteus VSM which does:

http://3.bp.blogspot.com/_WyqB9Ls02ZM/TT3Jk8rQ57I/AAAAAAAAAD8/u0uxa4onLCU/s1600/LCD32a.JPG

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

Simulating a keypad seems easy.  When I was programming the Butterfly, I simulated the joystick and the LCD.  When I get back home, I'll show it to you, if I can find it.

 

The point is, I use the real AVR code driving the LCD controller and reading the ports connected to the joystick. 

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

steve17 wrote:
I use the real AVR code driving the LCD controller
Yes but that is just wiggling PORT pins isn't it? Are you putting in a virtual simulation of HD44780 on the other end of those simulated outputs that polices the same timing requirements as a real HD44780 (Proteus does have this).

 

If you are old enough to remember this back in the AS4 days there was a "plugin" to the Atmel simulator called "HapSim" that offered the same there. However it (and it's UART simulation) failed to impose strict timing limits so you could wiggle the wires at any virtual speed you liked and the thing would still work. Again Proteuse VSM is not like this - you have to drive your HD44780 or your UART at exactly the right rate or it simulates failure just as the real hardware will. I guess this is what makes Proteus worth those £300.

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

"Dare to be naïve." - Buckminster Fuller

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

clawson wrote:

 

steve17 wrote:I use the real AVR code driving the LCD controller

 

Yes but that is just wiggling PORT pins isn't it? Are you putting in a virtual simulation of HD44780 on the other end of those simulated outputs that polices the same timing requirements as a real HD44780 (Proteus does have this).

I don't know anything about a HD44780.  The AVR code puts data into the registers of the LCD controller that is built in to the megaxx9 chip.  The LCD controller wiggles pins that connect to the LCD glass.  My LCD controller simulator notices what data is put into the registers and draws the appropriate segments on the simulated display. 

 

I have menus to control various peripherals etc.  In the USART menu I can set the baud rate.  The LCD menu just has 3 choices.  Enable, Disable, and the all segment test.  I can control the menu with the joystick simulator.

 

I found the Butterfly simulator.