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