AVR Freaks

Using a port is extremely easy and straightforward...what is all this worthless crap for?

Partly my fault. I showed some example in another thread, and the pin struct was used. What is left resembles what I showed, but was made worse.

You can use that idea, but no need to create the extra info (only need &PINx, not DDR and PORT). Also, as soon as you start creating an array of them (which is nice), you have to remember as soon as you start using array indexes you will lose the atomic properties as cbi/sbi is no longer being produced. So it needs to be treated just as you would treat a macro if you want to maintain the use of sbi/cbi (no variables for array index).

If these are going to be used, then also use the pinFunctions so you do not have to do bit manipulations yourself (and you then don't have to look at a bunch of bit manipulations in your app code), and can easily take advantage of the PIN/DDR/PORT relationship. This idea works fine and is better than macros (imo), but you have to knows the 'rules' to maintain atomic pin manipulation (static inline always_inline also needed). Use an avr0/1 and the atomic restrictions go away since there are registers for atomic with no reliance on getting a specific instruction.

This would be a good start to the project, where you get a display working that depends on no other code, works in the background, can easily be tested/verified (also notice that any pin can be used for any segment/common)-

https://godbolt.org/z/aT1o5Txbr

and once this is done, move on to the next problem. You will have a display you can use at that point, which will not be tangled up in or depend on other code. Get smaller pieces of code doing specific things, work on them one at a time, eventually ending up in a completed app.

Also posted here...

These questions are getting posted to this forum, eevblog forum, and I guess possibly others. A shotgun approach. Makes one less interested in answering when its known you are missing 1/2 (or more) of the conversation.

I sniffed a little, to see how it can be done in C, for all my 7S and Temp projects were in ASM.

Only one remark on PWM for light level: Do it! If you can, do adjust display refresh to be 16ms, and add another timer for up to 1ms, which will produce either Overflow, or Compare match (I prefer Overflow) and which will stop the light and engage another digit. Choose light power in steps not less than 1:3, for example 1:4:16:64.

Thus, 16ms and 1ms, two timers... if you run out of them, you can use WDT 16ms.

Once in 16ms you can read all keys.

So, start with program-keeping, good luck.

What do you mean by this exactly? What is cbi/sbi?

When you change a pin you typically want to only change a single pin, preserving the state of the other pins on the same port. This is usually in the form of port |= bitmask or port &= ~bitmask, which means the code will read the port register, modify the value (set/clr 1 bit), then write the new value back to the register. Since this is several instructions, there is an opportunity for an interrupt to 'interrupt' that sequence, and if you also change a pin in the interrupt code its possible that you are setting/clearing a pin on the same port and now when you get back to the main code it will finish its sequence. The problem is the main code does not know about the changes that took place, and will write an 'old' value back to the register, 'undoing' the pin work the interrupt just did. Not an easy thing to figure out that once in a while the pins act strange, so avoidance is the answer. This is not a unique thing only to pins, its just pins are a high use item in both interrupt and non-interrupt code, and there are certainly many more things that should not be interrupted.

For an avr, these pin registers are in an address range where the sbi/cbi instruction can be used. This single instruction clears/sets a single bit in a register, and since it cannot be interrupted (its a single instruction) you can know your pin manipulation will always be valid (atomic). These instructions encode the address and bit position so can only be produced at compile time. If you start creating code where the compiler cannot know the address or bit position at compile time (like using a var for an index into an array of pin_t), it will revert to using the

'regular' instructions which are no longer atomic. There are other ways to deal with this, and if you look at arduino code they surround their pin code with disable/re-enable interrupts because of the way they deal with pins. Not a pleasant thing to do, surrounding all pin manipulation with interrupt protection, but if you never have to see it then probably not so bad.

Newer avr's like the avr0/1 series deal with atomic pin manipulation by having a special set of port registers that set/clr/tgl a pin. It no longer matters what instructions are produced by the compiler, you will always get atomic pin manipulation if you use these registers. So for example an array of pin_t can be used without any thought of atomic, assuming you are using the set/clr/tgl registers.

And this is what a similar translation would look like for a mega4809-

https://godbolt.org/z/vT1v119Ed

notice the use of OUTSET/OUTCLR, so atomic is taken care of, which also means accessing the arrays by index is fine, too. And a little nicer to use. The pin code for a avr0/1 would normally look a little different, but just kept it similar to the previous 328p example.