#qi-hardware IRC log for Wednesday, 2013-01-02

kyakwpwrak: is it possible to attach my function to an interrupt triggered by a timer (as opposite to while loop that you do waiting for the timer)?13:28
wpwrakfor this, you'll have to put the driver into the kernel13:34
wpwrakan intermediate solution would be to write a kernel driver that just sees the interrupt and then schedules the process by some means13:35
wpwrak(of course, the latter may have considerable latency)13:35
kyakok, no userland processes can see interrupts - lesson learned :)13:35
wpwraksimilarly, if you want to halt the CPU until an interrupt happens, you need to go into the kernel13:36
kyaki see. .thanks.. while (!timer_full()) it is then13:36
wpwrak(interrupts) as far as i know, there's no generic interrupt-to-user space interface in the kernel. certainly also for its ideological implications :)13:37
wpwrak(halting the CPU) that would be the most accurate means to synchronize with a timer. those poll looks still have a fair bit of jitter.13:38
qi-bot[commit] Werner Almesberger: lpc111x-isp/lpc111x.c: define IO pins via array, not #defines (master) http://qi-hw.com/p/ben-blinkenlights/3b0c8c613:38
qi-bot[commit] Werner Almesberger: lpc111x-isp/lpc111x.c: new option  -P function=signal  to reassign pins (master) http://qi-hw.com/p/ben-blinkenlights/376aa5413:38
larscwpwrak: there is. UIO13:45
larschttp://www.kernel.org/doc/htmldocs/uio-howto.html#wait_for_interrupts13:46
kyaklarsc: seems like UIO still requires a driver14:01
kyakand even that, it's still poll() or select()14:03
kyakso it's not asynchronous, like a fully-fledged interrupt14:04
larscwell spwa14:05
larscwell spawn a second thread which polls on the descriptor14:05
larscbut yes, you still need a dummy driver which exports the irq14:06
kyakok,  got your idea.. But then i have multithreaded application which requires the kernel module :) i guess waiting in a while loop with disabled interrupts is just much easier14:08
larscyes14:10
larscalthough you'll burn a quite a few cpu cycles14:10
kyakindeed..14:10
kyakhow bad would it be to sleep() in the while loop for the time, just a little bit less than the timer duration?14:11
kyakand then wake up before the timer is expected to trigger?14:11
larscwhy do you need the timer anyway?14:12
kyakwell, i want my function to run periodically14:12
larscbut why do you need to use the hwtimer directly14:13
kyakfor example, it could be a function that reads temperature sensor data14:13
larsccan't you just use sleep14:13
larscor hrtimer14:13
larscor alarm14:13
kyakhm, i think i could.. but i want it to be as precise as possible in non-real time linux14:14
larscI think using hrtimers will be more preceise14:14
kyakwhy werner doesn't use hrtimers in swuart? :)14:14
larscI don't know14:15
kyakk, thanks for suggestion, i'll have a look14:15
larscit might be more precise if he also disables interrupts globally14:17
larscso the kernel can reschedule the process14:17
larscbut that only works for short time periods14:17
larscif you want to capture a sample say every 10 seconds or so, hrtimers is probably the best solution14:17
kyaki'm thinking about sample times between 1ms and 1s14:19
kyakhttps://rt.wiki.kernel.org/index.php/Cyclictest14:27
kyakinteresting find :)14:27
wpwrakkyak: i'd expect the jitter of anything that leaves interrupts on to be unacceptably high, particularly at higher data rates where each bit it only a few microseconds14:27
wpwrakbit at 1-1000 ms, you have more options14:28
wpwrakalso, do you need precise sampling or would it be sufficient to sample at only roughly the desires interval and add a precise timestamp so that you can correct the time axis when evaluating the data ?14:29
kyaka precise sampling is preferable14:31
kyakit's hard to think about exact requirements, but do you think that it is possible to fit into one microsecond jitter when running at one millisecond sample time?14:34
wpwrakhmm. what kind of temperature are you measuring that changes perceptibly in just 1 us ? have you takes some inspirations from the DIY nuclear fusion talk at EHSM ? ;-)14:37
kyakthe temperature is just an example. I'm thinking if it is possible to run low-speed control loop with Ben :)14:37
wpwrakand for accuracy of 10 us or better i would expect to need to turn off interrupts and use a hardware timer or a calibrated timing loop14:38
wpwrakhw timers are much easier to control, particularly if you have cumulative timing, even though they're less precise than a good timing loop14:38
kyakwhat is a calibrated timing loop?14:38
wpwrak(of course, making that perfect timing loop will cost you :)14:38
wpwraka timing loop where you verify the exact duration14:39
wpwrakas a rule of thumb, for anything >= 0.1 s i'd use some variant of sleep without worrying about much else. for >= 100 us, i might try the fancier timers and real-time priority.14:41
kyakok, i got it.. it's just that when you a running a feedback control system, the information about the real timer duration won't help..14:42
wpwrakfor < 10 us i'd turn off interrupts. for < 1 or 2 us, i'd enlist the MMC controller14:42
kyakbut since Ben is no real-time anyway, maybe i'll just stick to sleep. This way there won't be too much expectations14:43
wpwrakthat leaves the interval 10-100 us. what you can get there depends a lot on how nice the kernel drivers are. if one spends time with interrupts off, it'll upset your timing.14:43
wpwrak(feedback control) you just need an algorithm that can handle jitter :) you can measure jitter with pretty good accuracy14:44
wpwrak(i.e., tens of nanoseconds)14:44
kyakyeah, probably something could be done on algorithmic side..14:44
wpwrakbtw,turning off interrupts not only prevents kernel code from interrupting your code but it also prevents it from trashing your cache. cache delays do become relevant at some point in time.14:45
kyakbut in terms on control systems, it generally means that you would have to tune your system (the parameters of your controller) in each step14:46
wpwrakalso, at some point you need to worry about DMA latency as well. e.g., ubb-vga also turns off the screen refresh to avoid competing for memory access.14:46
kyakwhy didn't you just drop an MCU on UBB-VGA board?14:49
larscthat would have been to easy ;)14:49
wpwrakindeed. besides, it's not so easy to find MCUs that even run at such a speed (well, small and cheap ones)14:51
larscnext time just build an asic15:04
wpwrakhow boring. better a quantum computer. then a can calculate a frame at a time, at a leisurely 50 Hz or so :)15:08
sagexhey16:23
whitequarkwpwrak: (cache latency) I'm also wondering about virtual memory performance in MIPS21:32
whitequarkwith its less than stellar TLB refilling mechanism21:32
wpwrakyeah, if you're unlucky you get some TLB misses as well21:33
wpwrakDMA conveniently solves that, too :)21:34
whitequarkbut DMA competes for the bus access cycles21:37
whitequarkiirc it's a) round-robin b) 1/3 of the CPU freq on Ben21:37
whitequarkso the maximal precision of your timings is substantially decreased21:37
wpwrakthat's DMA to GPIO. yes, that's bumpy. but the MMC controller has a FIFO, which absorbs all those small problems.21:39
whitequarkoh, FIFO fixes that indeed21:45
whitequarkwpwrak: how do you think, is HDMI bitbanging possible or viable?21:49
whitequarksay at small resolutions. I'll be quite happy to start with 640x48021:49
whitequarkit's already hard to find new devices with VGA ports...21:50
whitequarkaha, it requires pixel rate of at least 25 MHz. that sounds quite reasonable.21:51
wpwrakhmm, but i think you have a lot of bits per pixel, don't you ?21:53
whitequarkhm. basically it uses 24-bit color, where components are 8b/10b encoded and transmitted via TMDS21:58
whitequark(plus some control signals with 2b/10b encoding)21:58
whitequarkit seems that this is the absolute minimum required to spin up an image21:58
wpwrakubb-vga pushes out four bits per cycle at 56 MHz, so that's 224 Mbps21:59
wpwrakfor 25 MHz, 24 bits 8/10 = 25*30 you'd need about thrice that22:00
wpwrakof course, you could add a CPLD that maps, say, 4-bit pixels into 24 bit pixels22:01
whitequarkyeah, it requires quite a lot of speed22:05
whitequarkstm32 can drive I/Os at 50MHz @CL=30pF22:07
wpwrakthat's even slower :)22:11
whitequark... and it seems that bus limitations actually cap that at 18 MHz :)22:13
wpwrakheh :)22:14
viricwpwrak: i got that video capture card to work22:51
viricdamn thing. I had to play with printk and dump_stack :)22:51
viricat the end, that only helped me finaly understand what to do from userland.22:52
wpwrakthe bttv ? or the usb critter ?22:55
viricwpwrak: the usb :)23:01
viricI'll throw away the bttv23:01
wpwrakso that's how you treat the elderly23:01
viricthose elderly had enough time to learn to talk pci properly23:02
wpwrakwell, i still have one sitting in a box somewhere. no idea if it would still work :)23:02
viricdo you still have analog tv ground broadcast?23:02
virichere stations switched all to digital two or three years ago23:03
wpwrakthey're moving towards digital here, too. but i don't pay much attention to TV anyway :)23:03
viricneither do I23:04
viricI had the bttv thing only for recording some VHS tapes. But it didn't serve the purpose.23:04
viricwell, enough for today. Bona nit!23:04
wpwrakah, the work begins :)23:06
--- Thu Jan 3 201300:00

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