| 00:53.14 | DocScrutinizer05 | is PTC5/LLWU_P9 some A/D input capable pin? |
| 00:55.16 | DocScrutinizer05 | lemme rephrase: is there any A/D input capable GPIO pin on MKL26Z128VFM4? |
| 00:56.01 | wpwrak | 1) no. 2) yes, see http://downloads.qi-hardware.com/people/werner/anelok/tmp/kl-32-cheat.pdf |
| 00:56.13 | DocScrutinizer05 | if yes then you probably should use that pin for connecting D2 |
| 00:56.35 | wpwrak | ADV in are the little green ones, S... (and D...) |
| 00:56.51 | wpwrak | adC even |
| 01:00.54 | wpwrak | (led on adc) if i was to do this, B0, B1, or D6 would be best. they all have high drive strength and ADC in. not that high drive strength really matters that much, but hey, since we have it :) |
| 01:01.22 | DocScrutinizer05 | how about PTB1 pin21? |
| 01:01.49 | DocScrutinizer05 | aah ok, you already solved that |
| 01:03.18 | DocScrutinizer05 | and *seems* red LEDs are best for photodiode |
| 01:03.46 | DocScrutinizer05 | (not verified) |
| 01:06.58 | wpwrak | by the way, this one is a potential DNP LED. D1 is guaranteed to say. |
| 01:07.41 | *** join/#qi-hardware fengling (~fengling@2002:6fc6:1d35:0:a5be:9039:2d15:5ec7) |
| 01:07.46 | DocScrutinizer05 | couldn't find my way for D1 |
| 01:08.10 | DocScrutinizer05 | ooh, con4 |
| 01:09.31 | DocScrutinizer05 | still lost |
| 01:09.52 | DocScrutinizer05 | ugh, secure MCU |
| 01:10.35 | DocScrutinizer05 | B0 you said? looks good |
| 01:10.57 | wpwrak | the other LEDs are just for debugging, not designed to be visible from the outside |
| 01:11.16 | DocScrutinizer05 | just wondering about clock/speed of secure MCU |
| 01:11.19 | DocScrutinizer05 | o.O |
| 01:11.52 | DocScrutinizer05 | will it be fast enough to do more than 4 ADC / s? |
| 01:12.29 | DocScrutinizer05 | or what's the rationale for 32kHz clock? |
| 01:15.22 | DocScrutinizer05 | maybe it has a PLL that can create a real clock even from 32kHz? |
| 01:17.57 | DocScrutinizer05 | or it has an internal oscillator? |
| 01:24.00 | DocScrutinizer05 | TLV61220 running as long as battery provides power? |
| 01:25.24 | wpwrak | it has many clock options. normal operating speed would be 48 MHz core, 24 MHz bus |
| 01:25.39 | wpwrak | 32 kHz is for the RTC. only draws a few nA |
| 01:26.30 | wpwrak | yes, boost is "always on", even if we have USB power. not entirely happy with the arrangement, but it seems difficult to do better. |
| 01:26.41 | DocScrutinizer05 | aah ok. I just been worried about cpu grunt |
| 01:27.09 | wpwrak | (do better) i.e., low-voltage switches contain their own little boosters and are actually quite power-hungry |
| 01:27.13 | DocScrutinizer05 | well, as long as boost doesn't eat power... |
| 01:27.35 | wpwrak | it does, of course :) but switches aren't much better. |
| 01:27.40 | DocScrutinizer05 | the FB is already very high impedance |
| 01:28.35 | DocScrutinizer05 | so how much quescent does it eat? |
| 01:28.38 | wpwrak | typical quiescent current is 5 uA |
| 01:28.43 | DocScrutinizer05 | meh |
| 01:28.53 | DocScrutinizer05 | :-) |
| 01:29.17 | DocScrutinizer05 | nice |
| 01:29.33 | wpwrak | poor battery. never a moment of rest :) |
| 01:29.38 | DocScrutinizer05 | ohmy |
| 01:29.50 | DocScrutinizer05 | self dicharge will be higher |
| 01:29.54 | wpwrak | but yes, i think this is the sort of boost converter they also use in mice |
| 01:36.46 | DocScrutinizer05 | ok, for the tresor code you possibly might change that to sort of gesture recognition on capacitive sensor |
| 01:37.56 | DocScrutinizer05 | tap left, tap right, tap left, slide up, slide down, doubletap right |
| 01:38.02 | DocScrutinizer05 | this sort of thing |
| 01:38.03 | wpwrak | right now it's sort of a pin |
| 01:38.29 | DocScrutinizer05 | yeah, where you need to look closely and navigate carefully to the digit you need next |
| 01:38.45 | wpwrak | see also http://downloads.qi-hardware.com/people/werner/anelok/tmp/walkthrough.png |
| 01:39.00 | wpwrak | (need to update this for the new logo :) |
| 01:39.32 | wpwrak | (navigate) no .. it's totally different from that 2013 video |
| 01:40.22 | DocScrutinizer05 | no idea how that works |
| 01:40.45 | DocScrutinizer05 | the walkthrough is a cheat sheet only |
| 01:42.20 | DocScrutinizer05 | doesn' |
| 01:42.32 | DocScrutinizer05 | tt really give away any of the UI |
| 01:42.42 | wpwrak | you can get a more detailed impression with the simulator: https://gitlab.com/anelok/anelok/blob/master/sim/README (see "quick start") |
| 01:48.46 | DocScrutinizer05 | it still doesn't tell how to enter text or digits/pin |
| 01:52.41 | DocScrutinizer05 | anyway, seems you have a UI concept consisting of the elements "touch left, touch middle, touch right" for activation at least. probably those 3 digits together with pace/speed of enering them could make a convenient "gesture" to enter some "pin" |
| 01:53.19 | DocScrutinizer05 | drums a funny rhythm on table with three fingers |
| 01:54.27 | DocScrutinizer05 | ditap dutup dutap ditip |
| 01:57.37 | wpwrak | touch up / middle down, yes (for the "PIN"). but i'm not very happy with this system. for an idea for a more advanced approach, see "A quick idea" in http://lists.en.qi-hardware.com/pipermail/discussion/2015-March/010836.html |
| 02:02.40 | *** join/#qi-hardware wej (j@gateway/vpn/mullvad/x-zyvdriejqaowsunm) |
| 02:02.47 | DocScrutinizer05 | your current system lacks the time component |
| 02:03.09 | DocScrutinizer05 | the "pen" idea is basically exactly what I suggested |
| 02:03.37 | DocScrutinizer05 | just that the pen in my concept only writes as long as touch |
| 02:04.03 | DocScrutinizer05 | the resulting pattern could get matched against a stored pattern |
| 02:04.28 | DocScrutinizer05 | scaling in both X and Y direction |
| 02:06.23 | DocScrutinizer05 | in X (time axis) only a 20% of scaling and even less of nonlinearity (distortion) allowed, in Y (slider pos) axis I'd allow even a 50% of zoom and nonlinearity/noise |
| 02:07.41 | DocScrutinizer05 | the patter would look like . _ . -- ` / . \/ |
| 02:08.04 | DocScrutinizer05 | / and \ are full range slides |
| 02:08.25 | DocScrutinizer05 | stuff like ^ and v and V may also appear |
| 02:09.17 | wpwrak | (time component) that thing would move continuously. so time = y position |
| 02:09.27 | DocScrutinizer05 | err yes |
| 02:09.40 | DocScrutinizer05 | that's what I said |
| 02:09.53 | DocScrutinizer05 | nope, I swapped X and Y |
| 02:10.52 | DocScrutinizer05 | in your tap thing there's no time component. In the pen thing aiui there is no tap component, only slides |
| 02:11.12 | DocScrutinizer05 | the "new quick idea" pen thing |
| 02:11.37 | DocScrutinizer05 | I suggest to combine the two |
| 02:12.25 | wpwrak | yes, you could add "no touch" as additional information. but it may have other uses. e.g., to signal the end of the pattern. |
| 02:13.20 | DocScrutinizer05 | end of pattern is "no touch event for >1s" |
| 02:13.41 | DocScrutinizer05 | or N |
| 02:13.51 | DocScrutinizer05 | fractions of a second |
| 02:14.42 | wpwrak | yes, there are many possibilities for the details. it's a matter of implementing it, trying to see how it works, refining it, etc. |
| 02:16.14 | DocScrutinizer05 | :-) my approach is different. implementation is negligible since feasible. It's the usability aka UI design that counts |
| 02:17.34 | *** join/#qi-hardware atommann (~atommann@58.251.2.94) |
| 02:17.58 | DocScrutinizer05 | with a slide-only_one-touch-event input you need way longer to gather sufficient number if significant bits |
| 02:18.41 | DocScrutinizer05 | or let me put it this way: the UI bandwidth is inconveniently low |
| 02:20.09 | wpwrak | i tend to discover lots of things about the usability of my designs when actually using them :) |
| 02:21.20 | DocScrutinizer05 | yeah, and probably you won't implement an alternative concept unless the current one is comletely useless :-) |
| 02:24.20 | DocScrutinizer05 | well, when you add pen-down / pen-up to your concept, and add a timer to detect end-of-input pen-up (which you'll need anyway to avoid trihhering on glitches) then you're already with my concept while still yours is a perfectly working subset |
| 02:24.46 | DocScrutinizer05 | triggering* |
| 02:25.18 | wpwrak | the tricky bit is the pattern matching. capturing some doodle is easy, matching it is hard. |
| 02:25.41 | wpwrak | and the better the algorithm, the more "secret bits" it can extract |
| 02:25.45 | DocScrutinizer05 | sure. but that doesn't differ between your and my concept either |
| 02:26.06 | DocScrutinizer05 | no, since you can't enter with such precision |
| 02:27.30 | wpwrak | yes, you have to compensate for the "noise". basically like a human recognizes signatures. |
| 02:27.43 | *** join/#qi-hardware wej (j@gateway/vpn/mullvad/x-mpgwxifpfgygvgvb) |
| 02:28.31 | DocScrutinizer05 | I think simple X and Y shifting and zooming to adjust for best match will go a long way |
| 02:29.21 | DocScrutinizer05 | then define match as "to points are less than distance Delta from each other" |
| 02:29.28 | DocScrutinizer05 | two* |
| 02:30.02 | DocScrutinizer05 | or think of drawing the reference pattern with a thick brush |
| 02:31.34 | DocScrutinizer05 | the ratio of points of test pattern overlaying the "thick" reference pattern to those that don't is your matching factor which needs to be high enough |
| 02:32.23 | DocScrutinizer05 | zoom up and down a bit in X and Y and see if matching factor gets better (search maximum) |
| 02:33.38 | DocScrutinizer05 | or you do some nifty math like FFT and compare wavelets |
| 02:41.52 | DocScrutinizer05 | actually zooming on time axis is pretty simple |
| 02:42.47 | DocScrutinizer05 | just adjust-zoom length of test pattern to reference pattern - as long as that doesn't mean more than 50% scaling |
| 02:43.18 | DocScrutinizer05 | if you'd beed more than 50% it's a fail |
| 02:43.23 | DocScrutinizer05 | need* |
| 02:44.04 | DocScrutinizer05 | maybe even just 20 or 30% |
| 02:44.44 | *** join/#qi-hardware wej (j@gateway/vpn/mullvad/x-svtegbwnabkswwmd) |
| 02:51.33 | DocScrutinizer05 | oh, it needs a special sort of "points" that match when in both reference and test pattern the same special sort of point at this time is present: no-touch |
| 02:52.22 | DocScrutinizer05 | no-touch points have no (or a fixed 'out-of-band') position |
| 02:52.22 | wpwrak | well, i hope someone will pick up the idea and contribute something |
| 02:53.55 | DocScrutinizer05 | probably a proof of concept could get done with those image magick tools and a script |
| 02:58.31 | DocScrutinizer05 | the 'canvas' wouldn't need to be larger than 4x40 bit for a 2s pattern |
| 02:58.35 | wpwrak | why not in the simulator ? |
| 02:59.33 | DocScrutinizer05 | because it's way simpler to have the whole thin on a high level of abstraction first |
| 02:59.39 | DocScrutinizer05 | thing |
| 03:00.30 | wpwrak | you get input and canvas in the simulator ... |
| 03:01.06 | DocScrutinizer05 | only when it works and you seen what happens on a 40x4000 canvas, using imagemagick tools, you slim the concept down to fit into this tiny MCU |
| 03:03.08 | wpwrak | probably more work this way. the sim runs on linux, so it has access to anything you want to add |
| 03:03.28 | DocScrutinizer05 | just like you possibly design a PID controller in spreadsheet first, before you implement a tailored-to-purpose assembler program with the algo and parameters you found |
| 03:04.08 | wpwrak | well, just telling you that the simulator can do more than one may think |
| 03:17.21 | *** join/#qi-hardware atommann (~atommann@58.251.2.94) |
| 04:21.17 | *** join/#qi-hardware rjeffries (~rjeffries@pool-108-40-199-126.snloca.fios.verizon.net) |
| 07:50.44 | *** join/#qi-hardware atommann (~atommann@58.251.2.94) |
| 08:10.48 | *** join/#qi-hardware pcercuei (~paul@137.71.226.54) |
| 09:38.13 | *** join/#qi-hardware paul_boddie (~paul_bodd@cm-84.215.150.4.getinternet.no) |
| 09:47.28 | *** join/#qi-hardware nicksydney (~quassel@18.097.dsl.syd.iprimus.net.au) |
| 09:51.24 | *** join/#qi-hardware nicksydney (~quassel@18.097.dsl.syd.iprimus.net.au) |
| 09:59.11 | *** join/#qi-hardware jwhitmore (~jwhitmore@88.151.80.134) |
| 10:37.50 | *** join/#qi-hardware newcup (newcup@peruna.fi) |
| 10:43.34 | *** join/#qi-hardware sb0 (~lekernel@194-144-39-174.du.xdsl.is) |
| 11:19.57 | paul_boddie | No progress on the jz4740 interrupt quest. :-/ |
| 11:27.32 | larsc | only one of the cpu irqs is used |
| 11:27.36 | larsc | #3 |
| 11:27.53 | larsc | everything else is on a second level irq chip |
| 11:28.58 | pcercuei | #2 |
| 11:29.06 | pcercuei | I think |
| 11:31.09 | paul_boddie | What puzzles me is the actual bare-metal initialisation. Everyone seems to set BEV to 1, but the PM indicates that a bunch of 0xbfc0.... addresses would be used then. |
| 11:31.37 | paul_boddie | The cleanest code I've seen is actually in Rockbox. Linux is a bunch of #ifdefs. |
| 11:33.37 | paul_boddie | I'm probably making lots of beginner mistakes, especially with GNU as and MIPS, although I'm figuring them out as I go along. |
| 11:39.40 | paul_boddie | It's all rather frustrating, as I actually have booting working over USB and from SD, with the framebuffer functional. |
| 11:58.07 | paul_boddie | The timer is working, I'm unmasking the timer IRQ, leaving only the actual IRQ dispatch a mystery. |
| 11:58.48 | *** join/#qi-hardware jwhitmore (~jwhitmore@88.151.80.134) |
| 12:00.15 | DocScrutinizer05 | timer most likely does no IRQ servicing (reset IRQ cause in peripheral), is probably edge triggered, and thus simpler than "normal" IRQs |
| 12:01.49 | paul_boddie | Yes, the timer stuff can be read straight out of a register. But actual interrupt stuff is desirable for more advanced purposes. |
| 12:02.07 | DocScrutinizer05 | sure, it's just more involved |
| 12:03.14 | paul_boddie | It's difficult to know if things are actually doing something sensible without serious debugging gear, though. |
| 12:04.08 | paul_boddie | Like whether the CPU is just ignoring the bit combination I set on its register because I didn't set something else first. |
| 12:06.09 | DocScrutinizer05 | IRQ (auto-locks) -> jump to IRQ handler which does: {fetch data from peripheral; reset peripheral IRQ-enable (when not done implicitly by reading data); hand over data to an IRQ deferred handler (often called worker thread) and schedule that worker thread for eventual execution; atomic local IRQ enable and return-from-IRQ} |
| 12:08.06 | DocScrutinizer05 | to debug that stuff you basically only can write a byte to a meaningful location at checkpoints. Ideally a GPIO that makes an LED shine up |
| 12:09.07 | paul_boddie | All that the handler really needs to do is to change a single memory location and I'd see it working. |
| 12:09.26 | DocScrutinizer05 | yes |
| 12:10.49 | *** join/#qi-hardware unclouded (~neil@2001:4428:200:80fc:7e05:7ff:fe0d:d421) |
| 12:10.58 | paul_boddie | Which makes me think that whatever I set the damned register to, it either changes the memory map (obvious hang) or does nothing (and my program runs uninterrupted). |
| 12:11.20 | larsc | low level bootstrapping is always the hardest |
| 12:11.45 | paul_boddie | I wish someone had written a recipe for this stuff. That would be worth having for just about every new device. |
| 12:25.37 | *** join/#qi-hardware Jay7 (jay@128-73-158-207.broadband.corbina.ru) |
| 13:08.22 | *** join/#qi-hardware newcup (newcup@2a04:3540:1000:310:a8aa:aaff:feaa:396c) |
| 13:09.24 | DocScrutinizer05 | start with a IRQ handler consisting of max 20 assembler instructions, to blink a LED in an endless loop |
| 13:12.49 | DocScrutinizer05 | start: XOR LED,0x01; REG a=0; REG b=0; loop: DJNZ a,loop; DJNZ b,loop; JUMP start; |
| 13:23.03 | paul_boddie | The NanoNote doesn't have any LEDs, but I guess I can think of an alternative. |
| 13:23.42 | pcercuei | the backlight |
| 13:23.45 | DocScrutinizer05 | speaker/beeper. display backlight |
| 13:27.36 | DocScrutinizer05 | oh, and I shouldn't say that, but: test the LED blinker code first, by jumping directly to "start". Only then use it as IRQ handler in next iteration |
| 13:28.55 | larsc | the beeper |
| 13:33.15 | DocScrutinizer05 | what's NN ops/s? |
| 13:33.50 | *** join/#qi-hardware paulburton (paulburton@gateway/shell/firrre/x-vdymoxsompgyrhmh) |
| 13:33.50 | DocScrutinizer05 | ballpark |
| 13:34.26 | DocScrutinizer05 | after reset |
| 13:34.34 | paul_boddie | Well, it's 336 MHz, but that's just the CPU. |
| 13:34.43 | DocScrutinizer05 | good enough |
| 13:35.07 | DocScrutinizer05 | prolly in the range 10 to 100 ops/s then |
| 13:35.19 | DocScrutinizer05 | Mops/s |
| 13:35.23 | DocScrutinizer05 | ;-P |
| 13:36.04 | DocScrutinizer05 | Mips |
| 13:37.34 | paul_boddie | 335.05 BogoMIPS according to the Qi-Hardware site. |
| 13:38.50 | DocScrutinizer05 | then for beeper a single 16bit register for a single DJNZ is sufficient to get sth audible |
| 13:39.51 | DocScrutinizer05 | start: XOR beeper,0x01; REG a=0; loop: DJNZ a,loop; JUMP start; |
| 13:41.35 | DocScrutinizer05 | ~336e6 / 2**16 |
| 13:41.40 | DocScrutinizer05 | grr |
| 13:41.48 | DocScrutinizer05 | ~336*10**6 / 2**16 |
| 13:41.48 | infobot | 5126.953125 |
| 13:44.13 | DocScrutinizer05 | /2 |
| 13:44.26 | DocScrutinizer05 | 2500Hz |
| 13:46.38 | DocScrutinizer05 | b=250; start: XOR beeper,0x01; REG a=0; loop: DJNZ a,loop; DJNZ b,start; RETI; |
| 13:47.49 | DocScrutinizer05 | for a 0.1s beep each time you call the IRQ handler |
| 13:49.04 | DocScrutinizer05 | where RETI maybe doesn't exist on this ISA and needs to get implemented in the correct way by re-enabling the IRQ and atomically returning from subroutine |
| 13:51.01 | DocScrutinizer05 | often the enable-irq command has a one instruction delay until it takes effect, so the return-from-sub instruction gets always executed even when a new IRQ is already pending |
| 13:51.21 | paul_boddie | It's ERET on MIPS, as far as I can tell. |
| 13:51.45 | DocScrutinizer05 | good, then it has atomic return from subroutine with IRQ enable :-) |
| 13:54.30 | paul_boddie | Well, to start my sanity checking, I got the screen to show the bit patterns from memory locations where the handlers should be. |
| 13:55.06 | paul_boddie | They seem to match up with the instructions from my disassembled program. |
| 13:55.54 | paul_boddie | Think of it being a bit like the Pioneer probe's artwork but without the naked people. :-) |
| 13:59.41 | pcercuei | < DocScrutinizer05> good, then it has atomic return from subroutine with IRQ enable :-) |
| 13:59.44 | pcercuei | nope |
| 14:00.24 | DocScrutinizer05 | hmm |
| 14:00.47 | paul_boddie | I was worried about caching, but it seems like what I put in 0x8000.... is actually what the CPU can read. |
| 14:01.03 | paul_boddie | almost misses writing ARM assembly language from back in the day. |
| 14:01.04 | DocScrutinizer05 | so what's the method of choice for leaving IRQ handler on this ISA? |
| 14:01.05 | pcercuei | I'd have to verify this, but I'm pretty sure that ERET doesn't change the program counter |
| 14:02.12 | DocScrutinizer05 | so what does it do? |
| 14:02.34 | DocScrutinizer05 | Enable @ next RETurn? |
| 14:03.44 | DocScrutinizer05 | those RISC assembler codes sometimes drive me nuts |
| 14:04.07 | pcercuei | sorry, got confused with the RFE opcode |
| 14:04.24 | pcercuei | (Return From Exception) |
| 14:04.38 | DocScrutinizer05 | hmm, sounds almost similar |
| 14:04.53 | pcercuei | RFE is a CP0 opcode on mips1 |
| 14:04.54 | DocScrutinizer05 | just it changes the status bits |
| 14:05.08 | DocScrutinizer05 | but also should change PC |
| 14:05.10 | paul_boddie | It's all a nasty mess of real opcodes, pseudo-opcodes and several generations of cruft. |
| 14:05.19 | DocScrutinizer05 | yeah |
| 14:06.13 | paul_boddie | On the imgtec blog a while back there were some catty remarks about "other RISC architectures", which I interpreted as being aimed at ARM. |
| 14:06.35 | DocScrutinizer05 | ARM is a mess too |
| 14:06.47 | pcercuei | I think mips v6 cleans that up |
| 14:06.53 | pcercuei | mips32r6 |
| 14:07.19 | paul_boddie | Modern ARM probably is. The instruction format is awkward, so I'm told. |
| 14:07.24 | paul_boddie | Here we are: http://blog.imgtec.com/mips-processors/mipsfpga-opens-up-the-mips-architecture-to-universities-worldwide |
| 14:08.00 | paul_boddie | "you could pick ARM, but that's also become increasingly complex, and was arguably never true RISC in the first place" |
| 14:08.33 | paul_boddie | The only non-RISC thing I can think of with the original ARM are the multiple load/store instructions, which are actually a good idea. |
| 14:09.08 | paul_boddie | (I guess some people here or on #m-labs would have something to say about that article, anyway.) |
| 14:11.37 | DocScrutinizer05 | what happened to all the really good CPU technical manuals) like e.g. the original Zilog Z80 manual |
| 14:11.58 | DocScrutinizer05 | ? |
| 14:12.10 | paul_boddie | I know. I also dabble in retro stuff and some of those early manuals are quite good. |
| 14:13.09 | paul_boddie | Even the outsiders like MOS and their licencees put out reasonable manuals. Nothing like the stuff I see here with missing chapters and "don't ask me I only work here" explanations. |
| 14:13.21 | DocScrutinizer05 | yeah, they *really* explained such stuff like IRQ (handlers) - with example code and all |
| 14:15.09 | paul_boddie | Example code? These days people have forgotten that the CPU actually does something so dirty as to run code! |
| 14:15.21 | DocScrutinizer05 | indeed |
| 14:15.54 | paul_boddie | I think that there's a technical gap in most companies now where the doc writers don't actually know anything else. |
| 14:17.23 | paul_boddie | I sometimes wonder whether some of the engineers actually understand their area, either. |
| 14:24.50 | paul_boddie | OK, on to a more practical test: incrementing a counter and trying to show that. |
| 14:42.56 | DocScrutinizer05 | that's what your timer IRQ already does ;-) |
| 14:47.14 | paul_boddie | If only! |
| 14:50.38 | larsc | fake it until you make it! |
| 14:51.18 | paul_boddie | Still faking it, I'm afraid. |
| 15:10.54 | *** join/#qi-hardware jwhitmore (~jwhitmore@109.79.117.235) |
| 15:25.05 | *** join/#qi-hardware zrafa (~rafa@170.210.83.36) |
| 15:37.00 | paul_boddie | Stupid question: can the jz4740 actually be interrupted in kernel mode? |
| 15:37.59 | paul_boddie | All the docs talk about combinations of KSU (or UM) and ERL and EXL, and some mention interrupts being enabled or disabled for some combinations. |
| 15:39.44 | paul_boddie | The R4000 manual mentions this. |
| 15:39.58 | larsc | sure |
| 15:41.43 | paul_boddie | "Interrupt Enable: Interrupts are enabled when all of the following conditions are true: IE = 1; EXL = 0; ERL = 0" |
| 15:51.52 | paul_boddie | If I clear ERL, which is set at reset time, the device hangs. I imagine that clearing ERL causes some mode transition. |
| 15:53.24 | pcercuei | or youa get an interrupt maybe |
| 15:53.29 | pcercuei | you* |
| 15:56.40 | DocScrutinizer05 | exactly :-) |
| 15:56.53 | *** join/#qi-hardware sb0 (~lekernel@194-144-39-174.du.xdsl.is) |
| 15:57.25 | paul_boddie | I did think that, together with my handlers not working, of course. |
| 15:57.47 | DocScrutinizer05 | that's the "usual" scenario ;D |
| 15:58.50 | DocScrutinizer05 | that's why you want a "LED blinker" IRQ handler routine, to start with |
| 15:59.36 | DocScrutinizer05 | even better: a beeper-yell IRQ handler like sketched above |
| 16:00.07 | DocScrutinizer05 | which would allow the device to continue "normal" operation even when IRQ handler gets invoked |
| 16:01.39 | paul_boddie | But what is strange is that as soon as I clear ERL, even if the interrupt enable flag is clear, I get the hang. |
| 16:02.32 | paul_boddie | Which suggests that some other mechanism is involved. The initial reset condition is like an exception condition, which is why I wondered about special magic when you clear the ERL bit. |
| 16:12.19 | paul_boddie | Hmm: http://www.dingux.com/2010/11/hwinit-modified.html |
| 16:19.46 | pcercuei | I remember that |
| 16:51.22 | paul_boddie | The fix: https://code.google.com/p/dingoo-linux/source/detail?r=176 |
| 16:57.42 | paul_boddie | Nothing says "condescending" more than Comic Sans: http://homepage.cs.uiowa.edu/~ghosh/2-16-10.pdf |
| 16:58.04 | *** join/#qi-hardware Ornotermes (~ornoterme@78-69-244-120-no180.tbcn.telia.com) |
| 17:06.18 | paul_boddie | Well, I was clearing the cause register and setting IV, anyway. So that doesn't really explain very much, sadly. |
| 17:10.20 | paul_boddie | Anyway, will look at this later. Sigh! |
| 17:21.00 | *** join/#qi-hardware sb0 (~lekernel@194-144-39-174.du.xdsl.is) |
| 17:21.43 | *** join/#qi-hardware FDCX_ (~fdcx@ceata/consiliu/FDCX) |
| 17:53.08 | *** join/#qi-hardware jwhitmore (~jwhitmore@109.79.117.235) |
| 18:07.58 | *** join/#qi-hardware pcercuei (~pcercuei@95.90.198.207) |
| 18:17.22 | *** join/#qi-hardware FDCX_ (~fdcx@ceata/consiliu/FDCX) |
| 18:42.38 | *** join/#qi-hardware pcercuei (~pcercuei@95.90.198.207) |
| 19:27.54 | *** join/#qi-hardware pcercuei (~pcercuei@95.90.198.207) |
| 19:54.39 | *** join/#qi-hardware sb0 (~lekernel@194-144-39-174.du.xdsl.is) |
| 19:56.14 | *** join/#qi-hardware pcercuei (~pcercuei@95.90.198.207) |
| 20:50.12 | *** join/#qi-hardware wej (j@gateway/vpn/mullvad/x-cqadstunoultocpr) |
