Hi!
Yes, thanks, memory is fine, the data logger is up and running, storing 2048
values at 24 bit resolution, great! :-)
I have a program, but it uses a watch crystal and counts external pulses. And,
for saving time... I've now seen the error three times within ten days.
Thinking again about the issue, I'm not really sure if "volatile" is the right
term to describe the problem. "volatile" specifies, that for every read/write
in the source code, exactly one read/write in the machine code is done.
Perhaps it is up to the program author to ensure the correct reading outside of
the interrupt if a variable is modified inside the interrupt and vice versa.
Then it would be a subject of documentation. Which, by the way, I didn't read
:-D
But, while disgressing already, a bit to make JAL popular and usable...Where is
the official documentation? I lately had to place byte variables over dword
variables and couldn't find the syntax in any document, only placing bits. I
kind of tried luckily with var byte name1 at name2+byte_offset.
(Ok, found the website and the language reference. But no byte offsets :-) )
Greets,Kiste
Am Freitag, 27. November 2020, 11:39:06 MEZ hat Rob CJ <[email protected]>
Folgendes geschrieben:
Hi Kiste,
Hmm, my next puzzle for the weekend. Can you send a complete sample program
that I can use? It will save me time.
BTW. Did you already test the new build compiler that solves the memory issue?
Thanks.
Kind regards,
Rob
Van: 'Oliver Seitz' via jallib <[email protected]>
Verzonden: vrijdag 27 november 2020 07:44
Aan: Jallib <[email protected]>
Onderwerp: [jallib] Compiler doesn't honour "volatile" Sorry... This isn't in
fact the proper list for compiler issues, is it?
This one is probably more severe. I'll start with the example. This is the data
I've received:
?2807 2808 1?2807 2809 2?2807 2810 2?2807 2811 4?2807
2812 4?2807 2813 6?2807 2814 7?2807 2815 8?2807 2816 264
It's generated from this part of code, running on an PIC18F27K42. extra_time is
increased in an interrupt every 16 seconds. It is declared as var volatile
word, so the compiler should make sure that the bytes of the variable are in a
consistent state:
diff=word(extra_time-last_pulse_time_uw)
if print_debug then
print_debug=false
serial="?"
print_word_dec(serial,last_pulse_time_uw)
serial=" "
print_word_dec(serial,extra_time)
serial=" "
print_dword_dec(serial,diff)
print_crlf(serial)
end if
Let me repeat some of the results above in hex:
AFE-AF7 =7AFF-AF7 =8B00-AF7 =108
So, what has happened? The last line is clearly wrong. The subtraction was done
just as extra_time was in the process of increasing. The low byte was processed
before, the high byte was processed after the interrupt fired. So the actual
subtraction done was BFF-AF7, with the result of 108.
I've had a look at the asm file. Both bytes of the variable are just handled
one after the other, both in the main program and in the interrupt service
routine. The "volatile" declaration does not seem to do anything.
Greets,Kiste
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email
[email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/1713803051.2007385.1606459457507%40mail.yahoo.com.
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/AM0PR07MB6241378E01DF90BC2AFE3E46E6F80%40AM0PR07MB6241.eurprd07.prod.outlook.com.
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/136924260.2056558.1606476509299%40mail.yahoo.com.
