AVR Freaks

Full instructions here: https://www.avrfreaks.net/comment...

You have not given us much to go on.  No picture or diagram or ASCII-art of what you want to do.  And the mystery function write_lcd_one_step().

You might be interested in https://www.avrfreaks.net/comment... where I linked to https://www.avrfreaks.net/comment...

I give up.

If you want me to pay further attention, show a picture or diagram of what you want to end up with.  And for now, eliminate the "for loop" and use some constant test data.

Without that, I still think you are dealing with the 8-character maximum.  Tell more about what "fading" means.

For the benefit of future readers, describe how, exactly, you "solved the problem".

If one (or more) of the replies gave the answer to your question, use the 'Mark Solution' button to identify it/them.

EDIT (update & generalisation - for future reference)

It seems that you can only select the 'Mark Solution' button for one post:

So, if you feel multiple posts have all contributes to the solution, you can write a summary post and select the 'Mark Solution' button for that one.

EDIT 2

Note that marking the solution does also flag it in the topic lists;  so there is no need to also edit the thread title with "Solved", or suchlike.

For example:

EDIT 3

Added illustration of the "solved" marker.

(image courtesy of clawson: https://www.avrfreaks.net/commen... )

EDIT 4

Once a solution has been marked, the button changes to 'Unmark Solution':

So, if you later decide the the issue is not actually solved, you can change your mind.

Note also that marking a solution does not prevent further posts to the topic.

EDIT 5

In a December 2020 update, it became possible for Moderators to Mark a Solution. Even after that has happened, the OP can still un-mark it - and then has the option to mark again.

See: https://www.avrfreaks.net/commen...

EDIT 6

As well as flagging the title in the forum listings, marking a solution also adds a link to the solution in the opening post of the thread - like this:

So, when choosing which post to mark, think: "which post would someone looking for the solution want to jump to?"

#MarkSolution #MarkAsSolution

Why bother? He already solved his problem. ;D

variables shared between main() and ISR() must be declared volatile.

int newcnt;

should be

volatile int newcnt;

and if larger then 8 bit, then read atomically as well.

Jim  edit: added atomic

And the code presented above is not complete, and will not build clean...

PLEASE, when you have a problem with actual code do not post code that you just typed in. Copy the malfunctioning code from your editor into a forum post. It is essential that we see the actual code that you have, not some inexact replication of it. Your computer has copy/paste-functionality. Use it.

There is a missing semicolon at the definition of volt_array.

main() has a declared return type of int, yet no return statement is present.

Also, there is no actual loop in your main() so execution will just rush though it once.

The optimal situation is that

you post a minimal but complete program that we can copy into Studio, build and run,

you describe as accurately and to the point as possible the symptoms of malfunction that you see at your end,

we can repeat your symptoms by using the code you posted without any alterations at all.

Honestly, I cant make heads or tails of " this does not put my data into the array "volt_array" 100 times and overwrites the values each time it counts up again".

Tell us exactly what you want your program to do.

Tell us exactly what you observe your program doing.

You mean "8 bits", not "8 octets" right?

Atomicity issues is not only about accessing larger-tha-byte values. Even for byte-sized values there might be problems if two independent "threads of execution" accesses such a value.

Example:

the variable x has the value 42.

Thread A does

x += 7;

Thread B does

x = x * 2;

Suppose thread A is bout to start it's operation on x:

1. It reads from the location x into a register, that now holds the value 42.
2. It adds 7 to that register, so that it now holds the value 49.
3. By some mechanism (e.g. an interrupt) now thread B starts its operation on x.
4. It reads from location x into some register, that now holds the value 42.
5. It multiplies it by 2, so that it holds 84.
6. It stores that value back to the location x.
7. Thread B now relinquishes control.
8. Thread A commences Remember, it has the value 49 in "its" register.
9. Thread A stores the value 49 at position x.

We end up with the update from thread B being overwritten/lost.

Making both accesses atomic means forcing them to execute in sequence rather than interleaved. The common technique is to disable interrupts while accessing data. In ISRs interrupts are disabled automagically, so unless you've enabled interrupts explicitly in the ISR there's nothing special to do there. In other code you could use CLI/SEI explicitly, or (better, if avr-gcc/avrlibc is used) the macros from atomic.h .