<eintopf>
"Peterson's solution to the mutual exclusion problem (1981)" -> this works indeed, when the variables for shared memory fits into one data bit width of memory
<eintopf>
so somehow atomic, like in avr mcu it would be one byte
<eintopf>
(I suppose)
<whitequark>
all loads/stores on avr are atomic
<whitequark>
even two-byte
<whitequark>
they'll never be interrupted
<whitequark>
this actually screwed up timings on my VGA waveform generator
<larsc>
even on a multicore AVR? ;)
<whitequark>
larsc: since no multicore AVRs exist, yes
<eintopf>
whitequark: it's also one cycle?
<whitequark>
eintopf: no, multiple cyclse
<eintopf>
for a one byte integer tyype?
<eintopf>
ah
<whitequark>
hm
<eintopf>
but the datasheet says, some ops are really one cycle
<whitequark>
sure, the datasheet is right
<eintopf>
:D
<eintopf>
don't know which ops
<whitequark>
the two-byte load/stores are multiple cycles
<whitequark>
for one byte, I dont' remember
<eintopf>
ah and two-bytes is also not interuptable
<eintopf>
interesting
<eintopf>
and >4 bytes? That's some linking big number library then
<eintopf>
ehm >2 bytes
<whitequark>
there are no >2 byte stores in avr
<whitequark>
it doesn't have any >2 byte registers
<eintopf>
yea, okay then avrlibc to some bignum lib
<eintopf>
s/to/do
<qi-bot>
eintopf meant: "yea, okay then avrlibc do some bignum lib"
<whitequark>
huh?
<eintopf>
I can use a uint32_t
<whitequark>
multiple instructions
<eintopf>
even uint64_t
<whitequark>
unless you cli/sei around the load/store, it is not atomic
<eintopf>
yes, that's why I do always when I will have something atomic in avr
<eintopf>
whitequark: do I need to do this in a isr?
<eintopf>
an*
<whitequark>
no
<whitequark>
don't forget volatile too
<eintopf>
ah, yes
valhalla has quit [Ping timeout: 256 seconds]
valhalla has joined #qi-hardware
wolfspraul has joined #qi-hardware
valhalla has quit [Remote host closed the connection]
valhalla has joined #qi-hardware
valhalla has quit [Ping timeout: 252 seconds]
valhalla has joined #qi-hardware
ysionneau has quit [Ping timeout: 255 seconds]
ysionneau has joined #qi-hardware
sb0 has quit [Quit: Leaving]
pcercuei has quit [Ping timeout: 276 seconds]
pcercuei has joined #qi-hardware
<eintopf>
if an spi device has something like a sleep state, if it's a normal behaviour that the sleep state has no register access
<eintopf>
or are there also spi devices outside which have register access even in sleep state
* eintopf
need to know to make this configurable by a flag or not
<eintopf>
grml, I found now another spi device which have the possibility to access the register while sleep
pcercuei has quit [Ping timeout: 245 seconds]
wolfspraul has quit [Quit: leaving]
Ornoterm1s has quit [Quit: leaving]
Ornotermes has joined #qi-hardware
jwhitmore has joined #qi-hardware
nicksydney_ has joined #qi-hardware
nicksydney has quit [Ping timeout: 272 seconds]
jwhitmore has quit [Ping timeout: 276 seconds]
apelete has quit [Ping timeout: 252 seconds]
mth has quit [Read error: Connection reset by peer]