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