#qi-hardware IRC log for Wednesday, 2015-06-24

DocScrutinizer05is PTC5/LLWU_P9 some A/D input capable pin?00:53
DocScrutinizer05lemme rephrase: is there any A/D input capable GPIO pin on MKL26Z128VFM4?00:55
wpwrak1) no. 2) yes, see http://downloads.qi-hardware.com/people/werner/anelok/tmp/kl-32-cheat.pdf00:56
DocScrutinizer05if yes then you probably should use that pin for connecting D200:56
wpwrakADV in are the little green ones, S... (and D...)00:56
wpwrakadC even00:56
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:00
DocScrutinizer05how about PTB1 pin21?01:01
DocScrutinizer05aah ok, you already solved that01:01
DocScrutinizer05and *seems* red LEDs are best for photodiode01:03
DocScrutinizer05(not verified)01:03
wpwrakby the way, this one is a potential DNP LED. D1 is guaranteed to say.01:06
DocScrutinizer05couldn't find my way for D101:07
DocScrutinizer05ooh, con401:08
DocScrutinizer05still lost01:09
DocScrutinizer05ugh, secure MCU01:09
DocScrutinizer05B0 you said? looks good01:10
wpwrakthe other LEDs are just for debugging, not designed to be visible from the outside01:10
DocScrutinizer05just wondering about clock/speed of secure MCU01:11
DocScrutinizer05o.O01:11
DocScrutinizer05will it be fast enough to do more than 4 ADC / s?01:11
DocScrutinizer05or what's the rationale for 32kHz clock?01:12
DocScrutinizer05maybe it has a PLL that can create a real clock even from 32kHz?01:15
DocScrutinizer05or it has an internal oscillator?01:17
DocScrutinizer05TLV61220 running as long as battery provides power?01:24
wpwrakit has many clock options. normal operating speed would be 48 MHz core, 24 MHz bus01:25
wpwrak32 kHz is for the RTC. only draws a few nA01:25
wpwrakyes, 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
DocScrutinizer05aah ok. I just been worried about cpu grunt01:26
wpwrak(do better) i.e., low-voltage switches contain their own little boosters and are actually quite power-hungry01:27
DocScrutinizer05well, as long as boost doesn't eat power...01:27
wpwrakit does, of course :) but switches aren't much better.01:27
DocScrutinizer05the FB is already very high impedance01:27
DocScrutinizer05so how much quescent does it eat?01:28
wpwraktypical quiescent current is 5 uA01:28
DocScrutinizer05meh01:28
DocScrutinizer05:-)01:28
DocScrutinizer05nice01:29
wpwrakpoor battery. never a moment of rest :)01:29
DocScrutinizer05ohmy01:29
DocScrutinizer05self dicharge will be higher01:29
wpwrakbut yes, i think this is the sort of boost converter they also use in mice01:29
DocScrutinizer05ok, for the tresor code you possibly might change that to sort of gesture recognition on capacitive sensor01:36
DocScrutinizer05tap left, tap right, tap left, slide up, slide down, doubletap right01:37
DocScrutinizer05this sort of thing01:38
wpwrakright now it's sort of a pin01:38
DocScrutinizer05yeah, where you need to look closely and navigate carefully to the digit you need next01:38
wpwraksee also http://downloads.qi-hardware.com/people/werner/anelok/tmp/walkthrough.png01:38
wpwrak(need to update this for the new logo :)01:39
wpwrak(navigate) no .. it's totally different from that 2013 video01:39
DocScrutinizer05no idea how that works01:40
DocScrutinizer05the walkthrough is a cheat sheet only01:40
DocScrutinizer05doesn'01:42
DocScrutinizer05tt really give away any of the UI01:42
wpwrakyou can get a more detailed impression with the simulator: https://gitlab.com/anelok/anelok/blob/master/sim/README  (see "quick start")01:42
DocScrutinizer05it still doesn't tell how to enter text or digits/pin01:48
DocScrutinizer05anyway, 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:52
Action: DocScrutinizer05 drums a funny rhythm on table with three fingers01:53
DocScrutinizer05ditap dutup dutap ditip01:54
wpwraktouch 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.html01:57
DocScrutinizer05your current system lacks the time component02:02
DocScrutinizer05the "pen" idea is basically exactly what I suggested02:03
DocScrutinizer05just that the pen in my concept only writes as long as touch02:03
DocScrutinizer05the resulting pattern could get matched against a stored pattern02:04
DocScrutinizer05scaling in both X and Y direction02:04
DocScrutinizer05in 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/noise02:06
DocScrutinizer05the patter would look like . _ . -- ` / .   \/02:07
DocScrutinizer05/ and \ are full range slides02:08
DocScrutinizer05stuff like ^ and v and V may also appear02:08
wpwrak(time component) that thing would move continuously. so time = y position02:09
DocScrutinizer05err yes02:09
DocScrutinizer05that's what I said02:09
DocScrutinizer05nope, I swapped X and Y02:09
DocScrutinizer05in your tap thing there's no time component. In the pen thing aiui there is no tap component, only slides02:10
DocScrutinizer05the "new quick idea" pen thing02:11
DocScrutinizer05I suggest to combine the two02:11
wpwrakyes, you could add "no touch" as additional information. but it may have other uses. e.g., to signal the end of the pattern.02:12
DocScrutinizer05end of pattern is "no touch event for >1s"02:13
DocScrutinizer05or N02:13
DocScrutinizer05fractions of a second02:13
wpwrakyes, there are many possibilities for the details. it's a matter of implementing it, trying to see how it works, refining it, etc.02:14
DocScrutinizer05:-) my approach is different. implementation is negligible since feasible. It's the usability aka UI design that counts02:16
DocScrutinizer05with a slide-only_one-touch-event input you need way longer to gather sufficient number if significant bits02:17
DocScrutinizer05or let me put it this way: the UI bandwidth is inconveniently low02:18
wpwraki tend to discover lots of things about the usability of my designs when actually using them :)02:20
DocScrutinizer05yeah, and probably you won't implement an alternative concept unless the current one is comletely useless :-)02:21
DocScrutinizer05well, 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 subset02:24
DocScrutinizer05triggering*02:24
wpwrakthe tricky bit is the pattern matching. capturing some doodle is easy, matching it is hard.02:25
wpwrakand the better the algorithm, the more "secret bits" it can extract02:25
DocScrutinizer05sure. but that doesn't differ between your and my concept either02:25
DocScrutinizer05no, since you can't enter with such precision02:26
wpwrakyes, you have to compensate for the "noise". basically like a human recognizes signatures.02:27
DocScrutinizer05I think simple X and Y shifting and zooming to adjust for best match will go a long way02:28
DocScrutinizer05then define match as "to points are less than distance Delta from each other"02:29
DocScrutinizer05two*02:29
DocScrutinizer05or think of drawing the reference pattern with a thick brush02:30
DocScrutinizer05the 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 enough02:31
DocScrutinizer05zoom up and down a bit in X and Y and see if matching factor gets better (search maximum)02:32
DocScrutinizer05or you do some nifty math like FFT and compare wavelets02:33
DocScrutinizer05actually zooming on time axis is pretty simple02:41
DocScrutinizer05just adjust-zoom length of test pattern to reference pattern - as long as that doesn't mean more than 50% scaling02:42
DocScrutinizer05if you'd beed more than 50% it's a fail 02:43
DocScrutinizer05need*02:43
DocScrutinizer05maybe even just 20 or 30%02:44
DocScrutinizer05oh, 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-touch02:51
DocScrutinizer05no-touch points have no (or a fixed 'out-of-band') position02:52
wpwrakwell, i hope someone will pick up the idea and contribute something02:52
DocScrutinizer05probably a proof of concept could get done with those image magick tools and a script02:53
DocScrutinizer05the 'canvas' wouldn't need to be larger than 4x40 bit for a 2s pattern02:58
wpwrakwhy not in the simulator ?02:58
DocScrutinizer05because it's way simpler to have the whole thin on a high level of abstraction first02:59
DocScrutinizer05thing02:59
wpwrakyou get input and canvas in the simulator ...03:00
DocScrutinizer05only 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 MCU03:01
wpwrakprobably more work this way. the sim runs on linux, so it has access to anything you want to add03:03
DocScrutinizer05just 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 found03:03
wpwrakwell, just telling you that the simulator can do more than one may think03:04
paul_boddieNo progress on the jz4740 interrupt quest. :-/11:19
larsconly one of the cpu irqs is used11:27
larsc#311:27
larsceverything else is on a second level irq chip11:27
pcercuei#211:28
pcercueiI think11:29
paul_boddieWhat 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
paul_boddieThe cleanest code I've seen is actually in Rockbox. Linux is a bunch of #ifdefs.11:31
paul_boddieI'm probably making lots of beginner mistakes, especially with GNU as and MIPS, although I'm figuring them out as I go along.11:33
paul_boddieIt's all rather frustrating, as I actually have booting working over USB and from SD, with the framebuffer functional.11:39
paul_boddieThe timer is working, I'm unmasking the timer IRQ, leaving only the actual IRQ dispatch a mystery.11:58
DocScrutinizer05timer most likely does no IRQ servicing (reset IRQ cause in peripheral), is probably edge triggered, and thus simpler than "normal" IRQs12:00
paul_boddieYes, the timer stuff can be read straight out of a register. But actual interrupt stuff is desirable for more advanced purposes.12:01
DocScrutinizer05sure, it's just more involved 12:02
paul_boddieIt's difficult to know if things are actually doing something sensible without serious debugging gear, though.12:03
paul_boddieLike whether the CPU is just ignoring the bit combination I set on its register because I didn't set something else first.12:04
DocScrutinizer05IRQ (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:06
DocScrutinizer05to debug that stuff you basically only can write a byte to a meaningful location at checkpoints. Ideally a GPIO that makes an LED shine up12:08
paul_boddieAll that the handler really needs to do is to change a single memory location and I'd see it working.12:09
DocScrutinizer05yes12:09
paul_boddieWhich 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:10
larsclow level bootstrapping is always the hardest12:11
paul_boddieI wish someone had written a recipe for this stuff. That would be worth having for just about every new device.12:11
DocScrutinizer05start with a IRQ handler consisting of max 20 assembler instructions, to blink a LED in an endless loop13:09
DocScrutinizer05start: XOR LED,0x01; REG a=0; REG b=0; loop: DJNZ a,loop; DJNZ b,loop; JUMP start;13:12
paul_boddieThe NanoNote doesn't have any LEDs, but I guess I can think of an alternative.13:23
pcercueithe backlight13:23
DocScrutinizer05speaker/beeper. display backlight13:23
DocScrutinizer05oh, 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 iteration13:27
larscthe beeper13:28
DocScrutinizer05what's NN ops/s?13:33
DocScrutinizer05ballpark13:33
DocScrutinizer05after reset13:34
paul_boddieWell, it's 336 MHz, but that's just the CPU.13:34
DocScrutinizer05good enough13:34
DocScrutinizer05prolly in the range 10 to 100 ops/s then13:35
DocScrutinizer05Mops/s13:35
DocScrutinizer05;-P13:35
DocScrutinizer05Mips13:36
paul_boddie335.05 BogoMIPS according to the Qi-Hardware site.13:37
DocScrutinizer05then for beeper a single 16bit register for a single DJNZ is sufficient to get sth audible13:38
DocScrutinizer05start: XOR beeper,0x01; REG a=0; loop: DJNZ a,loop; JUMP start;13:39
DocScrutinizer05~336e6 / 2**1613:41
DocScrutinizer05grr13:41
DocScrutinizer05~336*10**6 / 2**1613:41
infobot5126.95312513:41
DocScrutinizer05/213:44
DocScrutinizer052500Hz13:44
DocScrutinizer05b=250; start: XOR beeper,0x01; REG a=0; loop: DJNZ a,loop; DJNZ b,start; RETI;13:46
DocScrutinizer05for a 0.1s beep each time you call the IRQ handler13:47
DocScrutinizer05where 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 subroutine13:49
DocScrutinizer05often 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 pending13:51
paul_boddieIt's ERET on MIPS, as far as I can tell.13:51
DocScrutinizer05good, then it has atomic return from subroutine with IRQ enable :-)13:51
paul_boddieWell, to start my sanity checking, I got the screen to show the bit patterns from memory locations where the handlers should be.13:54
paul_boddieThey seem to match up with the instructions from my disassembled program.13:55
paul_boddieThink of it being a bit like the Pioneer probe's artwork but without the naked people. :-)13:55
pcercuei< DocScrutinizer05> good, then it has atomic return from subroutine with IRQ enable :-)13:59
pcercueinope13:59
DocScrutinizer05hmm14:00
paul_boddieI was worried about caching, but it seems like what I put in 0x8000.... is actually what the CPU can read.14:00
Action: paul_boddie almost misses writing ARM assembly language from back in the day.14:01
DocScrutinizer05so what's the method of choice for leaving IRQ handler on this ISA?14:01
pcercueiI'd have to verify this, but I'm pretty sure that ERET doesn't change the program counter14:01
DocScrutinizer05so what does it do?14:02
DocScrutinizer05Enable @ next RETurn?14:02
DocScrutinizer05those RISC assembler codes sometimes drive me nuts14:03
pcercueisorry, got confused with the RFE opcode14:04
pcercuei(Return From Exception)14:04
DocScrutinizer05hmm, sounds almost similar14:04
pcercueiRFE is a CP0 opcode on mips114:04
DocScrutinizer05just it changes the status bits14:04
DocScrutinizer05but also should change PC14:05
paul_boddieIt's all a nasty mess of real opcodes, pseudo-opcodes and several generations of cruft.14:05
DocScrutinizer05yeah14:05
paul_boddieOn 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
DocScrutinizer05ARM is a mess too14:06
pcercueiI think mips v6 cleans that up14:06
pcercueimips32r614:06
paul_boddieModern ARM probably is. The instruction format is awkward, so I'm told.14:07
paul_boddieHere we are: http://blog.imgtec.com/mips-processors/mipsfpga-opens-up-the-mips-architecture-to-universities-worldwide14:07
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
paul_boddieThe 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:08
paul_boddie(I guess some people here or on #m-labs would have something to say about that article, anyway.)14:09
DocScrutinizer05what happened to all the really good CPU technical manuals) like e.g. the original Zilog Z80 manual14:11
DocScrutinizer05?14:11
paul_boddieI know. I also dabble in retro stuff and some of those early manuals are quite good.14:12
paul_boddieEven 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
DocScrutinizer05yeah, they *really* explained such stuff like IRQ (handlers) - with example code and all14:13
paul_boddieExample code? These days people have forgotten that the CPU actually does something so dirty as to run code!14:15
DocScrutinizer05indeed14:15
paul_boddieI think that there's a technical gap in most companies now where the doc writers don't actually know anything else.14:15
paul_boddieI sometimes wonder whether some of the engineers actually understand their area, either.14:17
paul_boddieOK, on to a more practical test: incrementing a counter and trying to show that.14:24
DocScrutinizer05that's what your timer IRQ already does ;-)14:42
paul_boddieIf only!14:47
larscfake it until you make it!14:50
paul_boddieStill faking it, I'm afraid.14:51
paul_boddieStupid question: can the jz4740 actually be interrupted in kernel mode?15:37
paul_boddieAll 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:37
paul_boddieThe R4000 manual mentions this.15:39
larscsure15:39
paul_boddie"Interrupt Enable: Interrupts are enabled when all of the following conditions are true: IE = 1; EXL = 0; ERL = 0"15:41
paul_boddieIf I clear ERL, which is set at reset time, the device hangs. I imagine that clearing ERL causes some mode transition.15:51
pcercueior youa get an interrupt maybe15:53
pcercueiyou*15:53
DocScrutinizer05exactly :-)15:56
paul_boddieI did think that, together with my handlers not working, of course.15:57
DocScrutinizer05that's the "usual" scenario ;D15:57
DocScrutinizer05that's why you want a "LED blinker" IRQ handler routine, to start with15:58
DocScrutinizer05even better: a beeper-yell IRQ handler like sketched above15:59
DocScrutinizer05which would allow the device to continue "normal" operation even when IRQ handler gets invoked16:00
paul_boddieBut what is strange is that as soon as I clear ERL, even if the interrupt enable flag is clear, I get the hang.16:01
paul_boddieWhich 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:02
paul_boddieHmm: http://www.dingux.com/2010/11/hwinit-modified.html16:12
pcercueiI remember that16:19
paul_boddieThe fix: https://code.google.com/p/dingoo-linux/source/detail?r=17616:51
paul_boddieNothing says "condescending" more than Comic Sans: http://homepage.cs.uiowa.edu/~ghosh/2-16-10.pdf16:57
paul_boddieWell, I was clearing the cause register and setting IV, anyway. So that doesn't really explain very much, sadly.17:06
paul_boddieAnyway, will look at this later. Sigh!17:10
--- Thu Jun 25 201500:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!