2015-06-24 00:53 is PTC5/LLWU_P9 some A/D input capable pin? 2015-06-24 00:55 lemme rephrase: is there any A/D input capable GPIO pin on MKL26Z128VFM4? 2015-06-24 00:56 1) no. 2) yes, see http://downloads.qi-hardware.com/people/werner/anelok/tmp/kl-32-cheat.pdf 2015-06-24 00:56 if yes then you probably should use that pin for connecting D2 2015-06-24 00:56 ADV in are the little green ones, S... (and D...) 2015-06-24 00:56 adC even 2015-06-24 01:00 (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 :) 2015-06-24 01:01 how about PTB1 pin21? 2015-06-24 01:01 aah ok, you already solved that 2015-06-24 01:03 and *seems* red LEDs are best for photodiode 2015-06-24 01:03 (not verified) 2015-06-24 01:06 by the way, this one is a potential DNP LED. D1 is guaranteed to say. 2015-06-24 01:07 fengling has joined #qi-hardware 2015-06-24 01:07 couldn't find my way for D1 2015-06-24 01:08 ooh, con4 2015-06-24 01:09 still lost 2015-06-24 01:09 ugh, secure MCU 2015-06-24 01:10 B0 you said? looks good 2015-06-24 01:10 the other LEDs are just for debugging, not designed to be visible from the outside 2015-06-24 01:11 just wondering about clock/speed of secure MCU 2015-06-24 01:11 o.O 2015-06-24 01:11 will it be fast enough to do more than 4 ADC / s? 2015-06-24 01:12 or what's the rationale for 32kHz clock? 2015-06-24 01:15 maybe it has a PLL that can create a real clock even from 32kHz? 2015-06-24 01:17 or it has an internal oscillator? 2015-06-24 01:24 TLV61220 running as long as battery provides power? 2015-06-24 01:25 it has many clock options. normal operating speed would be 48 MHz core, 24 MHz bus 2015-06-24 01:25 32 kHz is for the RTC. only draws a few nA 2015-06-24 01:26 yes, boost is "always on", even if we have USB power. not entirely happy with the arrangement, but it seems difficult to do better. 2015-06-24 01:26 aah ok. I just been worried about cpu grunt 2015-06-24 01:27 (do better) i.e., low-voltage switches contain their own little boosters and are actually quite power-hungry 2015-06-24 01:27 well, as long as boost doesn't eat power... 2015-06-24 01:27 it does, of course :) but switches aren't much better. 2015-06-24 01:27 the FB is already very high impedance 2015-06-24 01:28 so how much quescent does it eat? 2015-06-24 01:28 typical quiescent current is 5 uA 2015-06-24 01:28 meh 2015-06-24 01:28 :-) 2015-06-24 01:29 nice 2015-06-24 01:29 poor battery. never a moment of rest :) 2015-06-24 01:29 ohmy 2015-06-24 01:29 self dicharge will be higher 2015-06-24 01:29 but yes, i think this is the sort of boost converter they also use in mice 2015-06-24 01:36 ok, for the tresor code you possibly might change that to sort of gesture recognition on capacitive sensor 2015-06-24 01:37 tap left, tap right, tap left, slide up, slide down, doubletap right 2015-06-24 01:38 this sort of thing 2015-06-24 01:38 right now it's sort of a pin 2015-06-24 01:38 yeah, where you need to look closely and navigate carefully to the digit you need next 2015-06-24 01:38 see also http://downloads.qi-hardware.com/people/werner/anelok/tmp/walkthrough.png 2015-06-24 01:39 (need to update this for the new logo :) 2015-06-24 01:39 (navigate) no .. it's totally different from that 2013 video 2015-06-24 01:40 no idea how that works 2015-06-24 01:40 the walkthrough is a cheat sheet only 2015-06-24 01:42 doesn' 2015-06-24 01:42 tt really give away any of the UI 2015-06-24 01:42 you can get a more detailed impression with the simulator: https://gitlab.com/anelok/anelok/blob/master/sim/README (see "quick start") 2015-06-24 01:48 it still doesn't tell how to enter text or digits/pin 2015-06-24 01:51 wej has quit [Ping timeout: 248 seconds] 2015-06-24 01:52 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" 2015-06-24 01:53 * DocScrutinizer05 drums a funny rhythm on table with three fingers 2015-06-24 01:54 ditap dutup dutap ditip 2015-06-24 01:57 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 2015-06-24 02:02 wej has joined #qi-hardware 2015-06-24 02:02 your current system lacks the time component 2015-06-24 02:03 the "pen" idea is basically exactly what I suggested 2015-06-24 02:03 just that the pen in my concept only writes as long as touch 2015-06-24 02:04 the resulting pattern could get matched against a stored pattern 2015-06-24 02:04 scaling in both X and Y direction 2015-06-24 02:06 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 2015-06-24 02:07 the patter would look like . _ . -- ` / . \/ 2015-06-24 02:08 / and \ are full range slides 2015-06-24 02:08 stuff like ^ and v and V may also appear 2015-06-24 02:09 (time component) that thing would move continuously. so time = y position 2015-06-24 02:09 err yes 2015-06-24 02:09 that's what I said 2015-06-24 02:09 nope, I swapped X and Y 2015-06-24 02:10 in your tap thing there's no time component. In the pen thing aiui there is no tap component, only slides 2015-06-24 02:11 the "new quick idea" pen thing 2015-06-24 02:11 I suggest to combine the two 2015-06-24 02:12 yes, you could add "no touch" as additional information. but it may have other uses. e.g., to signal the end of the pattern. 2015-06-24 02:13 end of pattern is "no touch event for >1s" 2015-06-24 02:13 or N 2015-06-24 02:13 fractions of a second 2015-06-24 02:14 yes, there are many possibilities for the details. it's a matter of implementing it, trying to see how it works, refining it, etc. 2015-06-24 02:14 FDCX_ has quit [Ping timeout: 252 seconds] 2015-06-24 02:16 :-) my approach is different. implementation is negligible since feasible. It's the usability aka UI design that counts 2015-06-24 02:17 atommann has joined #qi-hardware 2015-06-24 02:17 with a slide-only_one-touch-event input you need way longer to gather sufficient number if significant bits 2015-06-24 02:18 or let me put it this way: the UI bandwidth is inconveniently low 2015-06-24 02:20 i tend to discover lots of things about the usability of my designs when actually using them :) 2015-06-24 02:21 yeah, and probably you won't implement an alternative concept unless the current one is comletely useless :-) 2015-06-24 02:24 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 2015-06-24 02:24 triggering* 2015-06-24 02:25 the tricky bit is the pattern matching. capturing some doodle is easy, matching it is hard. 2015-06-24 02:25 and the better the algorithm, the more "secret bits" it can extract 2015-06-24 02:25 sure. but that doesn't differ between your and my concept either 2015-06-24 02:26 no, since you can't enter with such precision 2015-06-24 02:26 wej has quit [Ping timeout: 248 seconds] 2015-06-24 02:27 yes, you have to compensate for the "noise". basically like a human recognizes signatures. 2015-06-24 02:27 wej has joined #qi-hardware 2015-06-24 02:28 I think simple X and Y shifting and zooming to adjust for best match will go a long way 2015-06-24 02:29 then define match as "to points are less than distance Delta from each other" 2015-06-24 02:29 two* 2015-06-24 02:30 or think of drawing the reference pattern with a thick brush 2015-06-24 02:31 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 2015-06-24 02:32 wej has quit [Ping timeout: 246 seconds] 2015-06-24 02:32 zoom up and down a bit in X and Y and see if matching factor gets better (search maximum) 2015-06-24 02:33 or you do some nifty math like FFT and compare wavelets 2015-06-24 02:41 actually zooming on time axis is pretty simple 2015-06-24 02:42 just adjust-zoom length of test pattern to reference pattern - as long as that doesn't mean more than 50% scaling 2015-06-24 02:43 if you'd beed more than 50% it's a fail 2015-06-24 02:43 need* 2015-06-24 02:44 maybe even just 20 or 30% 2015-06-24 02:44 wej has joined #qi-hardware 2015-06-24 02:51 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 2015-06-24 02:52 no-touch points have no (or a fixed 'out-of-band') position 2015-06-24 02:52 well, i hope someone will pick up the idea and contribute something 2015-06-24 02:53 probably a proof of concept could get done with those image magick tools and a script 2015-06-24 02:58 the 'canvas' wouldn't need to be larger than 4x40 bit for a 2s pattern 2015-06-24 02:58 why not in the simulator ? 2015-06-24 02:59 because it's way simpler to have the whole thin on a high level of abstraction first 2015-06-24 02:59 thing 2015-06-24 03:00 you get input and canvas in the simulator ... 2015-06-24 03:01 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 2015-06-24 03:03 probably more work this way. the sim runs on linux, so it has access to anything you want to add 2015-06-24 03:03 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 2015-06-24 03:04 well, just telling you that the simulator can do more than one may think 2015-06-24 03:16 atommann has quit [Read error: Connection timed out] 2015-06-24 03:17 atommann has joined #qi-hardware 2015-06-24 04:21 rjeffries has joined #qi-hardware 2015-06-24 04:45 rjeffries has quit [Ping timeout: 264 seconds] 2015-06-24 05:15 wildlander has quit [Quit: Saliendo] 2015-06-24 07:30 newcup has quit [Remote host closed the connection] 2015-06-24 07:40 atommann has quit [Ping timeout: 276 seconds] 2015-06-24 07:50 atommann has joined #qi-hardware 2015-06-24 07:51 sb0 has quit [Ping timeout: 264 seconds] 2015-06-24 08:10 pcercuei has joined #qi-hardware 2015-06-24 09:05 valhalla_ is now known as valhalla 2015-06-24 09:07 atommann has quit [Ping timeout: 246 seconds] 2015-06-24 09:38 paul_boddie has joined #qi-hardware 2015-06-24 09:46 nicksydney has quit [Quit: No Ping reply in 180 seconds.] 2015-06-24 09:47 nicksydney has joined #qi-hardware 2015-06-24 09:50 nicksydney has quit [Client Quit] 2015-06-24 09:51 nicksydney has joined #qi-hardware 2015-06-24 09:59 jwhitmore has joined #qi-hardware 2015-06-24 10:13 archang has quit [Ping timeout: 256 seconds] 2015-06-24 10:37 newcup has joined #qi-hardware 2015-06-24 10:43 sb0 has joined #qi-hardware 2015-06-24 10:50 jwhitmore has quit [Ping timeout: 252 seconds] 2015-06-24 10:52 newcup has quit [Ping timeout: 246 seconds] 2015-06-24 10:58 sb0 has quit [Quit: Leaving] 2015-06-24 11:04 unclouded has quit [Ping timeout: 246 seconds] 2015-06-24 11:19 No progress on the jz4740 interrupt quest. :-/ 2015-06-24 11:27 only one of the cpu irqs is used 2015-06-24 11:27 #3 2015-06-24 11:27 everything else is on a second level irq chip 2015-06-24 11:28 #2 2015-06-24 11:29 I think 2015-06-24 11:31 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. 2015-06-24 11:31 The cleanest code I've seen is actually in Rockbox. Linux is a bunch of #ifdefs. 2015-06-24 11:33 I'm probably making lots of beginner mistakes, especially with GNU as and MIPS, although I'm figuring them out as I go along. 2015-06-24 11:39 It's all rather frustrating, as I actually have booting working over USB and from SD, with the framebuffer functional. 2015-06-24 11:58 The timer is working, I'm unmasking the timer IRQ, leaving only the actual IRQ dispatch a mystery. 2015-06-24 11:58 jwhitmore has joined #qi-hardware 2015-06-24 12:00 timer most likely does no IRQ servicing (reset IRQ cause in peripheral), is probably edge triggered, and thus simpler than "normal" IRQs 2015-06-24 12:01 Yes, the timer stuff can be read straight out of a register. But actual interrupt stuff is desirable for more advanced purposes. 2015-06-24 12:02 sure, it's just more involved 2015-06-24 12:03 It's difficult to know if things are actually doing something sensible without serious debugging gear, though. 2015-06-24 12:04 Like whether the CPU is just ignoring the bit combination I set on its register because I didn't set something else first. 2015-06-24 12:06 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} 2015-06-24 12:08 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 2015-06-24 12:08 jwhitmore has quit [Ping timeout: 252 seconds] 2015-06-24 12:09 All that the handler really needs to do is to change a single memory location and I'd see it working. 2015-06-24 12:09 yes 2015-06-24 12:10 unclouded has joined #qi-hardware 2015-06-24 12:10 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). 2015-06-24 12:11 low level bootstrapping is always the hardest 2015-06-24 12:11 I wish someone had written a recipe for this stuff. That would be worth having for just about every new device. 2015-06-24 12:25 Jay7 has joined #qi-hardware 2015-06-24 13:06 paulburton has quit [Ping timeout: 272 seconds] 2015-06-24 13:08 newcup has joined #qi-hardware 2015-06-24 13:09 start with a IRQ handler consisting of max 20 assembler instructions, to blink a LED in an endless loop 2015-06-24 13:12 start: XOR LED,0x01; REG a=0; REG b=0; loop: DJNZ a,loop; DJNZ b,loop; JUMP start; 2015-06-24 13:23 The NanoNote doesn't have any LEDs, but I guess I can think of an alternative. 2015-06-24 13:23 the backlight 2015-06-24 13:23 speaker/beeper. display backlight 2015-06-24 13:27 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 2015-06-24 13:28 the beeper 2015-06-24 13:33 what's NN ops/s? 2015-06-24 13:33 paulburton has joined #qi-hardware 2015-06-24 13:33 ballpark 2015-06-24 13:34 after reset 2015-06-24 13:34 Well, it's 336 MHz, but that's just the CPU. 2015-06-24 13:34 good enough 2015-06-24 13:35 prolly in the range 10 to 100 ops/s then 2015-06-24 13:35 Mops/s 2015-06-24 13:35 ;-P 2015-06-24 13:36 Mips 2015-06-24 13:37 335.05 BogoMIPS according to the Qi-Hardware site. 2015-06-24 13:38 then for beeper a single 16bit register for a single DJNZ is sufficient to get sth audible 2015-06-24 13:39 start: XOR beeper,0x01; REG a=0; loop: DJNZ a,loop; JUMP start; 2015-06-24 13:41 ~336e6 / 2**16 2015-06-24 13:41 grr 2015-06-24 13:41 ~336*10**6 / 2**16 2015-06-24 13:41 5126.953125 2015-06-24 13:44 /2 2015-06-24 13:44 2500Hz 2015-06-24 13:46 b=250; start: XOR beeper,0x01; REG a=0; loop: DJNZ a,loop; DJNZ b,start; RETI; 2015-06-24 13:47 for a 0.1s beep each time you call the IRQ handler 2015-06-24 13:49 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 2015-06-24 13:51 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 2015-06-24 13:51 It's ERET on MIPS, as far as I can tell. 2015-06-24 13:51 good, then it has atomic return from subroutine with IRQ enable :-) 2015-06-24 13:54 Well, to start my sanity checking, I got the screen to show the bit patterns from memory locations where the handlers should be. 2015-06-24 13:55 They seem to match up with the instructions from my disassembled program. 2015-06-24 13:55 Think of it being a bit like the Pioneer probe's artwork but without the naked people. :-) 2015-06-24 13:59 < DocScrutinizer05> good, then it has atomic return from subroutine with IRQ enable :-) 2015-06-24 13:59 nope 2015-06-24 14:00 hmm 2015-06-24 14:00 I was worried about caching, but it seems like what I put in 0x8000.... is actually what the CPU can read. 2015-06-24 14:01 * paul_boddie almost misses writing ARM assembly language from back in the day. 2015-06-24 14:01 so what's the method of choice for leaving IRQ handler on this ISA? 2015-06-24 14:01 I'd have to verify this, but I'm pretty sure that ERET doesn't change the program counter 2015-06-24 14:02 so what does it do? 2015-06-24 14:02 Enable @ next RETurn? 2015-06-24 14:03 those RISC assembler codes sometimes drive me nuts 2015-06-24 14:04 sorry, got confused with the RFE opcode 2015-06-24 14:04 (Return From Exception) 2015-06-24 14:04 hmm, sounds almost similar 2015-06-24 14:04 RFE is a CP0 opcode on mips1 2015-06-24 14:04 just it changes the status bits 2015-06-24 14:05 but also should change PC 2015-06-24 14:05 It's all a nasty mess of real opcodes, pseudo-opcodes and several generations of cruft. 2015-06-24 14:05 yeah 2015-06-24 14:06 On the imgtec blog a while back there were some catty remarks about "other RISC architectures", which I interpreted as being aimed at ARM. 2015-06-24 14:06 ARM is a mess too 2015-06-24 14:06 I think mips v6 cleans that up 2015-06-24 14:06 mips32r6 2015-06-24 14:07 Modern ARM probably is. The instruction format is awkward, so I'm told. 2015-06-24 14:07 Here we are: http://blog.imgtec.com/mips-processors/mipsfpga-opens-up-the-mips-architecture-to-universities-worldwide 2015-06-24 14:07 "you could pick ARM, but that's also become increasingly complex, and was arguably never true RISC in the first place" 2015-06-24 14:08 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. 2015-06-24 14:09 (I guess some people here or on #m-labs would have something to say about that article, anyway.) 2015-06-24 14:11 what happened to all the really good CPU technical manuals) like e.g. the original Zilog Z80 manual 2015-06-24 14:11 ? 2015-06-24 14:12 I know. I also dabble in retro stuff and some of those early manuals are quite good. 2015-06-24 14:13 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. 2015-06-24 14:13 yeah, they *really* explained such stuff like IRQ (handlers) - with example code and all 2015-06-24 14:15 Example code? These days people have forgotten that the CPU actually does something so dirty as to run code! 2015-06-24 14:15 indeed 2015-06-24 14:15 I think that there's a technical gap in most companies now where the doc writers don't actually know anything else. 2015-06-24 14:17 I sometimes wonder whether some of the engineers actually understand their area, either. 2015-06-24 14:24 OK, on to a more practical test: incrementing a counter and trying to show that. 2015-06-24 14:42 that's what your timer IRQ already does ;-) 2015-06-24 14:47 If only! 2015-06-24 14:50 fake it until you make it! 2015-06-24 14:51 Still faking it, I'm afraid. 2015-06-24 15:10 jwhitmore has joined #qi-hardware 2015-06-24 15:25 zrafa has joined #qi-hardware 2015-06-24 15:37 Stupid question: can the jz4740 actually be interrupted in kernel mode? 2015-06-24 15:37 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. 2015-06-24 15:39 The R4000 manual mentions this. 2015-06-24 15:39 sure 2015-06-24 15:41 "Interrupt Enable: Interrupts are enabled when all of the following conditions are true: IE = 1; EXL = 0; ERL = 0" 2015-06-24 15:51 If I clear ERL, which is set at reset time, the device hangs. I imagine that clearing ERL causes some mode transition. 2015-06-24 15:53 or youa get an interrupt maybe 2015-06-24 15:53 you* 2015-06-24 15:56 exactly :-) 2015-06-24 15:56 sb0 has joined #qi-hardware 2015-06-24 15:57 I did think that, together with my handlers not working, of course. 2015-06-24 15:57 that's the "usual" scenario ;D 2015-06-24 15:58 that's why you want a "LED blinker" IRQ handler routine, to start with 2015-06-24 15:59 even better: a beeper-yell IRQ handler like sketched above 2015-06-24 16:00 which would allow the device to continue "normal" operation even when IRQ handler gets invoked 2015-06-24 16:01 But what is strange is that as soon as I clear ERL, even if the interrupt enable flag is clear, I get the hang. 2015-06-24 16:02 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. 2015-06-24 16:12 Hmm: http://www.dingux.com/2010/11/hwinit-modified.html 2015-06-24 16:19 I remember that 2015-06-24 16:23 Ornotermes has quit [Quit: leaving] 2015-06-24 16:51 The fix: https://code.google.com/p/dingoo-linux/source/detail?r=176 2015-06-24 16:57 Nothing says "condescending" more than Comic Sans: http://homepage.cs.uiowa.edu/~ghosh/2-16-10.pdf 2015-06-24 16:58 Ornotermes has joined #qi-hardware 2015-06-24 16:58 pcercuei has quit [Ping timeout: 246 seconds] 2015-06-24 17:05 sb0 has quit [Read error: Connection reset by peer] 2015-06-24 17:06 Well, I was clearing the cause register and setting IV, anyway. So that doesn't really explain very much, sadly. 2015-06-24 17:10 Anyway, will look at this later. Sigh! 2015-06-24 17:10 paul_boddie has quit [] 2015-06-24 17:16 jwhitmore has quit [Ping timeout: 255 seconds] 2015-06-24 17:21 sb0 has joined #qi-hardware 2015-06-24 17:21 FDCX_ has joined #qi-hardware 2015-06-24 17:45 sb0 has quit [Quit: Leaving] 2015-06-24 17:48 FDCX_ has quit [Ping timeout: 244 seconds] 2015-06-24 17:53 jwhitmore has joined #qi-hardware 2015-06-24 17:58 jwhitmore has quit [Ping timeout: 255 seconds] 2015-06-24 18:07 pcercuei has joined #qi-hardware 2015-06-24 18:17 FDCX_ has joined #qi-hardware 2015-06-24 18:40 pcercuei has quit [Quit: brb] 2015-06-24 18:42 pcercuei has joined #qi-hardware 2015-06-24 18:45 pcercuei has quit [Client Quit] 2015-06-24 19:27 pcercuei has joined #qi-hardware 2015-06-24 19:54 pcercuei has quit [Quit: brb] 2015-06-24 19:54 sb0 has joined #qi-hardware 2015-06-24 19:56 pcercuei has joined #qi-hardware 2015-06-24 20:41 wej has quit [Ping timeout: 248 seconds] 2015-06-24 20:50 wej has joined #qi-hardware 2015-06-24 20:56 sb0 has quit [Quit: Leaving] 2015-06-24 22:00 pcercuei has quit [Quit: dodo] 2015-06-24 23:54 FDCX_ has quit [Remote host closed the connection]