I did not program AVR for years now and just think if it is possible to pass PORTx to the function and use it directly like in the ARM micros?
foo(GPIO_TypeDef *gpio, uint8_t pin, ....)
First hit when Googling "AVR pass port as parameter to function": http://www.atmel.com/webdoc/avrl... .
As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.
No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.
"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]
Thank you - yes I did not do my home work.
Edit - late edit but I tried to find the excuse for my laziness but I have not found any :(
Aaah -- another new fan of "generic I/O" on an AVR8.
Many threads on this. A few months ago, there was at least once a week.
I'll drag out my tired old questions:
-- What makes this attractive to you? Does the wiring of your app magically change during run time, so you need to make an elaborate setup to handle such morphing?
-- AVR8 instruction set doesn't lend itself well. So instead of "direct" access taking a couple cycles with no RMW effects and no temporary registers needed, your favoured mechanism takes many cycles, needs intermediate registers, and can introduce RMW possibilities.
"You make the call."
You can put lipstick on a pig, but it is still a pig.
I've never met a pig I didn't like, as long as you have some salt and pepper.
Not the new fan - porting one of my libraries to avr8 (I did not program them for a very long time, now use only Cortex ones). I know the downsides but do not want to rewrite the rest of the code.
Next you'll decry how slow your library code is on AVR8. And then we'll here about "non-working ports" which will be traced back to subtle RMW effects.
All that said -- go for it. How hard could it be? In the end you only set/clear a bit in an I/O register. You should find examples here. Did you follow all the links I gave to prior discussions?
Meanwhile I have finished porting and started testing. It works as expected. I know the downsides and I am not going to complain about avr-s. Forced to use atmega as the controller is built in the device.
as the side effect of this project - any pattern LED blinking library with callbacks.
©2015 Atmel Corporation