| kyak | wpwrak: 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 |
|---|---|---|
| wpwrak | for this, you'll have to put the driver into the kernel | 13:34 |
| wpwrak | an intermediate solution would be to write a kernel driver that just sees the interrupt and then schedules the process by some means | 13:35 |
| wpwrak | (of course, the latter may have considerable latency) | 13:35 |
| kyak | ok, no userland processes can see interrupts - lesson learned :) | 13:35 |
| wpwrak | similarly, if you want to halt the CPU until an interrupt happens, you need to go into the kernel | 13:36 |
| kyak | i see. .thanks.. while (!timer_full()) it is then | 13: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/3b0c8c6 | 13: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/376aa54 | 13:38 |
| larsc | wpwrak: there is. UIO | 13:45 |
| larsc | http://www.kernel.org/doc/htmldocs/uio-howto.html#wait_for_interrupts | 13:46 |
| kyak | larsc: seems like UIO still requires a driver | 14:01 |
| kyak | and even that, it's still poll() or select() | 14:03 |
| kyak | so it's not asynchronous, like a fully-fledged interrupt | 14:04 |
| larsc | well spwa | 14:05 |
| larsc | well spawn a second thread which polls on the descriptor | 14:05 |
| larsc | but yes, you still need a dummy driver which exports the irq | 14:06 |
| kyak | ok, 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 easier | 14:08 |
| larsc | yes | 14:10 |
| larsc | although you'll burn a quite a few cpu cycles | 14:10 |
| kyak | indeed.. | 14:10 |
| kyak | how bad would it be to sleep() in the while loop for the time, just a little bit less than the timer duration? | 14:11 |
| kyak | and then wake up before the timer is expected to trigger? | 14:11 |
| larsc | why do you need the timer anyway? | 14:12 |
| kyak | well, i want my function to run periodically | 14:12 |
| larsc | but why do you need to use the hwtimer directly | 14:13 |
| kyak | for example, it could be a function that reads temperature sensor data | 14:13 |
| larsc | can't you just use sleep | 14:13 |
| larsc | or hrtimer | 14:13 |
| larsc | or alarm | 14:13 |
| kyak | hm, i think i could.. but i want it to be as precise as possible in non-real time linux | 14:14 |
| larsc | I think using hrtimers will be more preceise | 14:14 |
| kyak | why werner doesn't use hrtimers in swuart? :) | 14:14 |
| larsc | I don't know | 14:15 |
| kyak | k, thanks for suggestion, i'll have a look | 14:15 |
| larsc | it might be more precise if he also disables interrupts globally | 14:17 |
| larsc | so the kernel can reschedule the process | 14:17 |
| larsc | but that only works for short time periods | 14:17 |
| larsc | if you want to capture a sample say every 10 seconds or so, hrtimers is probably the best solution | 14:17 |
| kyak | i'm thinking about sample times between 1ms and 1s | 14:19 |
| kyak | https://rt.wiki.kernel.org/index.php/Cyclictest | 14:27 |
| kyak | interesting find :) | 14:27 |
| wpwrak | kyak: 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 microseconds | 14:27 |
| wpwrak | bit at 1-1000 ms, you have more options | 14:28 |
| wpwrak | also, 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 |
| kyak | a precise sampling is preferable | 14:31 |
| kyak | it'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 |
| wpwrak | hmm. 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 |
| kyak | the temperature is just an example. I'm thinking if it is possible to run low-speed control loop with Ben :) | 14:37 |
| wpwrak | and 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 loop | 14:38 |
| wpwrak | hw timers are much easier to control, particularly if you have cumulative timing, even though they're less precise than a good timing loop | 14:38 |
| kyak | what is a calibrated timing loop? | 14:38 |
| wpwrak | (of course, making that perfect timing loop will cost you :) | 14:38 |
| wpwrak | a timing loop where you verify the exact duration | 14:39 |
| wpwrak | as 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 |
| kyak | ok, 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 |
| wpwrak | for < 10 us i'd turn off interrupts. for < 1 or 2 us, i'd enlist the MMC controller | 14:42 |
| kyak | but since Ben is no real-time anyway, maybe i'll just stick to sleep. This way there won't be too much expectations | 14:43 |
| wpwrak | that 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 accuracy | 14:44 |
| wpwrak | (i.e., tens of nanoseconds) | 14:44 |
| kyak | yeah, probably something could be done on algorithmic side.. | 14:44 |
| wpwrak | btw,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 |
| kyak | but in terms on control systems, it generally means that you would have to tune your system (the parameters of your controller) in each step | 14:46 |
| wpwrak | also, 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 |
| kyak | why didn't you just drop an MCU on UBB-VGA board? | 14:49 |
| larsc | that would have been to easy ;) | 14:49 |
| wpwrak | indeed. besides, it's not so easy to find MCUs that even run at such a speed (well, small and cheap ones) | 14:51 |
| larsc | next time just build an asic | 15:04 |
| wpwrak | how boring. better a quantum computer. then a can calculate a frame at a time, at a leisurely 50 Hz or so :) | 15:08 |
| sagex | hey | 16:23 |
| whitequark | wpwrak: (cache latency) I'm also wondering about virtual memory performance in MIPS | 21:32 |
| whitequark | with its less than stellar TLB refilling mechanism | 21:32 |
| wpwrak | yeah, if you're unlucky you get some TLB misses as well | 21:33 |
| wpwrak | DMA conveniently solves that, too :) | 21:34 |
| whitequark | but DMA competes for the bus access cycles | 21:37 |
| whitequark | iirc it's a) round-robin b) 1/3 of the CPU freq on Ben | 21:37 |
| whitequark | so the maximal precision of your timings is substantially decreased | 21:37 |
| wpwrak | that's DMA to GPIO. yes, that's bumpy. but the MMC controller has a FIFO, which absorbs all those small problems. | 21:39 |
| whitequark | oh, FIFO fixes that indeed | 21:45 |
| whitequark | wpwrak: how do you think, is HDMI bitbanging possible or viable? | 21:49 |
| whitequark | say at small resolutions. I'll be quite happy to start with 640x480 | 21:49 |
| whitequark | it's already hard to find new devices with VGA ports... | 21:50 |
| whitequark | aha, it requires pixel rate of at least 25 MHz. that sounds quite reasonable. | 21:51 |
| wpwrak | hmm, but i think you have a lot of bits per pixel, don't you ? | 21:53 |
| whitequark | hm. basically it uses 24-bit color, where components are 8b/10b encoded and transmitted via TMDS | 21:58 |
| whitequark | (plus some control signals with 2b/10b encoding) | 21:58 |
| whitequark | it seems that this is the absolute minimum required to spin up an image | 21:58 |
| wpwrak | ubb-vga pushes out four bits per cycle at 56 MHz, so that's 224 Mbps | 21:59 |
| wpwrak | for 25 MHz, 24 bits 8/10 = 25*30 you'd need about thrice that | 22:00 |
| wpwrak | of course, you could add a CPLD that maps, say, 4-bit pixels into 24 bit pixels | 22:01 |
| whitequark | yeah, it requires quite a lot of speed | 22:05 |
| whitequark | stm32 can drive I/Os at 50MHz @CL=30pF | 22:07 |
| wpwrak | that's even slower :) | 22:11 |
| whitequark | ... and it seems that bus limitations actually cap that at 18 MHz :) | 22:13 |
| wpwrak | heh :) | 22:14 |
| viric | wpwrak: i got that video capture card to work | 22:51 |
| viric | damn thing. I had to play with printk and dump_stack :) | 22:51 |
| viric | at the end, that only helped me finaly understand what to do from userland. | 22:52 |
| wpwrak | the bttv ? or the usb critter ? | 22:55 |
| viric | wpwrak: the usb :) | 23:01 |
| viric | I'll throw away the bttv | 23:01 |
| wpwrak | so that's how you treat the elderly | 23:01 |
| viric | those elderly had enough time to learn to talk pci properly | 23:02 |
| wpwrak | well, i still have one sitting in a box somewhere. no idea if it would still work :) | 23:02 |
| viric | do you still have analog tv ground broadcast? | 23:02 |
| viric | here stations switched all to digital two or three years ago | 23:03 |
| wpwrak | they're moving towards digital here, too. but i don't pay much attention to TV anyway :) | 23:03 |
| viric | neither do I | 23:04 |
| viric | I had the bttv thing only for recording some VHS tapes. But it didn't serve the purpose. | 23:04 |
| viric | well, enough for today. Bona nit! | 23:04 |
| wpwrak | ah, the work begins :) | 23:06 |
| --- Thu Jan 3 2013 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!