| 00:36.09 | *** join/#qi-hardware viric_ (~viric@unaffiliated/viric) |
| 01:30.33 | *** join/#qi-hardware atommann (~atommann@58.251.2.94) |
| 02:17.04 | *** join/#qi-hardware arhuaco (~arhuaco__@186.80.243.165) |
| 02:19.10 | *** join/#qi-hardware xiangfu (~xiangfu@60.191.125.138) |
| 02:31.09 | *** join/#qi-hardware rjeffries (~rjeffries@pool-108-40-199-126.snloca.fios.verizon.net) |
| 04:33.20 | *** join/#qi-hardware wildlander (~wild@unaffiliated/wildlander) |
| 06:09.23 | *** join/#qi-hardware arhuaco (~arhuaco__@186.80.243.165) |
| 06:28.43 | *** join/#qi-hardware archang (~archang@111.198.29.54) |
| 06:52.42 | *** join/#qi-hardware sb0 (~lekernel@173-160-41-85-colorado.hfc.comcastbusiness.net) |
| 07:24.46 | *** join/#qi-hardware marcus (~marcus@unaffiliated/hex0r) |
| 07:36.18 | eintopf | is searching for an alloy expert - http://alloy.mit.edu/alloy/ |
| 07:36.54 | eintopf | is somebody here which knows this language PROMELA and did this stuff - I have no idea and need to write ~1 month an exam about that |
| 07:36.58 | eintopf | :-) |
| 08:12.13 | *** join/#qi-hardware pcercuei (~paul@137.71.226.54) |
| 11:03.32 | wpwrak | how does alloy relate to promela ? |
| 11:04.13 | wpwrak | i use(d) promela. not recently, though. very nice tool. |
| 11:04.34 | wpwrak | lets you find protocol bugs you never even dreamed could exist ;-) |
| 11:57.19 | eintopf | ah, no |
| 11:57.24 | eintopf | promela was to other tool |
| 11:57.25 | eintopf | spin |
| 11:58.34 | eintopf | I think promela will be at the end of the course as well |
| 12:00.10 | eintopf | http://spinroot.com/spin/whatispin.html |
| 12:00.12 | eintopf | this stuff |
| 12:01.23 | 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 |
| 12:01.40 | eintopf | so somehow atomic, like in avr mcu it would be one byte |
| 12:01.45 | eintopf | (I suppose) |
| 12:03.58 | whitequark | all loads/stores on avr are atomic |
| 12:03.59 | whitequark | even two-byte |
| 12:04.08 | whitequark | they'll never be interrupted |
| 12:04.26 | whitequark | this actually screwed up timings on my VGA waveform generator |
| 12:04.50 | larsc | even on a multicore AVR? ;) |
| 12:05.40 | whitequark | larsc: since no multicore AVRs exist, yes |
| 12:06.35 | eintopf | whitequark: it's also one cycle? |
| 12:06.42 | whitequark | eintopf: no, multiple cyclse |
| 12:06.45 | eintopf | for a one byte integer tyype? |
| 12:06.50 | eintopf | ah |
| 12:06.55 | whitequark | hm |
| 12:07.03 | eintopf | but the datasheet says, some ops are really one cycle |
| 12:07.19 | whitequark | sure, the datasheet is right |
| 12:07.24 | eintopf | :D |
| 12:07.27 | eintopf | don't know which ops |
| 12:07.28 | whitequark | the two-byte load/stores are multiple cycles |
| 12:07.33 | whitequark | for one byte, I dont' remember |
| 12:08.16 | eintopf | ah and two-bytes is also not interuptable |
| 12:08.19 | eintopf | interesting |
| 12:08.45 | eintopf | and >4 bytes? That's some linking big number library then |
| 12:08.53 | eintopf | ehm >2 bytes |
| 12:09.10 | whitequark | there are no >2 byte stores in avr |
| 12:09.20 | whitequark | it doesn't have any >2 byte registers |
| 12:09.34 | eintopf | yea, okay then avrlibc to some bignum lib |
| 12:09.42 | eintopf | s/to/do |
| 12:09.42 | qi-bot | eintopf meant: "yea, okay then avrlibc do some bignum lib" |
| 12:09.47 | whitequark | huh? |
| 12:09.57 | eintopf | I can use a uint32_t |
| 12:10.02 | whitequark | multiple instructions |
| 12:10.02 | eintopf | even uint64_t |
| 12:10.14 | whitequark | unless you cli/sei around the load/store, it is not atomic |
| 12:11.27 | eintopf | yes, that's why I do always when I will have something atomic in avr |
| 12:11.35 | eintopf | whitequark: do I need to do this in a isr? |
| 12:11.41 | eintopf | an* |
| 12:11.48 | whitequark | no |
| 12:12.09 | whitequark | don't forget volatile too |
| 12:12.33 | eintopf | ah, yes |
| 12:20.54 | *** join/#qi-hardware valhalla (~valhalla@78-134-117-130.v4.ngi.it) |
| 13:02.42 | *** join/#qi-hardware wolfspraul (~wolfsprau@x4d0c8f45.dyn.telefonica.de) |
| 13:38.59 | *** join/#qi-hardware valhalla (~valhalla@78-134-117-130.v4.ngi.it) |
| 14:06.10 | *** join/#qi-hardware valhalla (~valhalla@78-134-117-130.v4.ngi.it) |
| 14:49.49 | *** join/#qi-hardware ysionneau (~fallen@ks3002254.kimsufi.com) |
| 17:06.28 | *** join/#qi-hardware pcercuei (~pcercuei@95.91.238.39) |
| 17:36.05 | 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 |
| 17:36.21 | eintopf | or are there also spi devices outside which have register access even in sleep state |
| 17:36.45 | eintopf | need to know to make this configurable by a flag or not |
| 17:54.31 | eintopf | grml, I found now another spi device which have the possibility to access the register while sleep |
| 20:01.00 | *** join/#qi-hardware Ornotermes (~ornoterme@78-69-244-120-no180.tbcn.telia.com) |
| 21:53.00 | *** join/#qi-hardware jwhitmore (~jwhitmore@86-44-189-100-dynamic.agg2.cty.lmk-pgs.eircom.net) |
| 21:55.56 | *** join/#qi-hardware nicksydney_ (~quassel@159.102-50-210.dynamic.dsl.syd.iprimus.net.au) |
| 23:26.34 | *** join/#qi-hardware mth (atuxqmnp@88.159.34.112) |
| 23:51.05 | *** join/#qi-hardware wildlander (~wild@unaffiliated/wildlander) |