ESP8266 Community Forum

- Thu Jan 10, 2019 4:48 pm #80002 My start with programming was punch cards high school, maybe Fortran? Can't remember. Then Pascal in college, I hated it. The microprocessor course was assembly language with the Z80. I ended up using the Z80 in the earlier microprocessor based products I designed. I used the Intel 8031/8051 along with early Microchip parts. All code was assembly language. I liked the clarity of the instruction set. I liked building my tool chest of routines. Then I got a job as a hardware designer and only did minor programming for test purposes.

Working at that low level certainly give a useful perspective. Its too bad that there isn't time for that anymore when teaching new people.

- Fri Jan 11, 2019 10:12 am #80011

Well I am glad you have moved forward in solving the whole problem. It is always worthwhile trying to isolate code/functions in order to find the fault, but of course depends on the code whether you can do that or not.

In answer to yor question:

The main code (in the assignment) can be iunterrupted, you are correct. However, perhaps it might be considered a 'trick' but because it becomes a rollover counter the value will always be valid and consistent because it is an atomic 32 bit operation, so if the main code was interrupted between the load and store then the counter would be one less than it should be after the isr runs, but that would be the case even when the isr ran just after the main code too. Because the main code took a copy (which will be one less than the isr sets it to) the next iteration of the main code will find it to be an updated value and thus process the new count. I might not have explained it very well, but it does work and is a common technique. It is important that the main code 'polls' this count frequently enough for your purposes: This would depend whether you must process each interrupt after it has happened or you can handle multiple at one time. You might be tempted to also set a 'flag' in the isr after the increment and clear it in the main code but you would just introduce another 'window' for inconsistent data since you now have two variables that may be interrupted part way through one or both.

If I think of a better explanation I will write it here later

Great! Many thanks for the explanations !!
I learned a lot!

I just found another topic that might solve the other part of the problem. My ESP restarts indefinitely if I connect the esp with the frequency already connected to the pin.

Look at this topic.
Interesting it.
Does adding this to the function name solve it?
That simple?

- Fri Jan 11, 2019 10:25 am #80012

My start with programming was punch cards high school, maybe Fortran? Can't remember. Then Pascal in college, I hated it. The microprocessor course was assembly language with the Z80. I ended up using the Z80 in the earlier microprocessor based products I designed. I used the Intel 8031/8051 along with early Microchip parts. All code was assembly language. I liked the clarity of the instruction set. I liked building my tool chest of routines. Then I got a job as a hardware designer and only did minor programming for test purposes.

Working at that low level certainly give a useful perspective. Its too bad that there isn't time for that anymore when teaching new people.

WOW!
How cool! I'm not from that time.
I started by learning Pascal and then C.
I never picked up a punched card.
You are very knowledgeable.

- Fri Jan 11, 2019 11:13 am #80016

...

I just found another topic that might solve the other part of the problem. My ESP restarts indefinitely if I connect the esp with the frequency already connected to the pin.

Look at this topic.
Interesting it.
Does adding this to the function name solve it?
That simple?

Which topic? Sorry, I don't understand.