#avr Logs

Oct 11 2020

12:59 PM vmt: --
01:08 PM cehteh: mhm guessimate: this SSR's here have 200V/µs dv/dt ... i only want to protect them with a varistor no snubber, adding a ferrite bread may should keep the rise in check or? :D
02:30 PM vmt: now which one of you people were doing fpgas?
02:30 PM vmt: was it you cehteh or was it twnqx
02:31 PM cehteh: not me
02:32 PM vmt: must be the other option then
02:33 PM vmt: i was wondering, on a scale of 1 to 10, how big of a pain in my arse would i have to go through if i was to use an fpga and some (possibly d)ram to buffer multiple 1080p mjpeg streams and save them to a card
02:35 PM vmt: i was thinking of a possibly sizeable buffer and then probably do some kind of arbitration which block of stream data in the buffer gets written to the card next
02:36 PM vmt: err, and i mean an sd card
02:37 PM vmt: and if there exists a solution for this already. talking about 2-6 streams
02:37 PM twnqx: depending on the source format/electrical parameters, some small computer will be easier
02:38 PM vmt: yeah but i am very limited in terms of space and weight
02:38 PM twnqx: how very?
02:39 PM vmt: sec
02:41 PM * cehteh rather wonders about sd card sustanined data rates when doing non continous writes (multiple files, filesystem operations) and all other crap that may happen, bus resets, garbage collection, varying latencies
02:41 PM twnqx: there's always SiP/SOM solutions of all kinds of sources
02:41 PM vmt: in terms of the board, around 40x80mm
02:41 PM twnqx: sizes*
02:42 PM vmt: cehteh: but that's why i'd arbitrate the stream which gets next written to the card
02:42 PM cehteh: besides the space you need for fpga cooling you can use for a better computer :D
02:42 PM vmt: write the buffer empty or to a some low water mark, and then hop to the next
02:42 PM cehteh: pri computer module or zero or something custom
02:42 PM twnqx: well, i'd personally say... don't use an FPGA
02:43 PM vmt: sure i mean i'm not horny for fpga to begin with
02:43 PM twnqx: how do the streams even come in, ethernet?
02:43 PM vmt: just that i'm wondering a suitable device as i have not meddled with arm socs, which are probably the next most reasonable thing
02:43 PM vmt: uvc
02:43 PM cehteh: you can also write to the raw device tag frames just sequentially no filesystem at all and later when you slurp the data in elsewhere divert it to files
02:43 PM twnqx: so, usb 2.0
02:44 PM vmt: yes
02:44 PM twnqx: or would you need 3.0?
02:44 PM vmt: 2.0 is fine
02:44 PM vmt: cehteh: yeah that was pretty much what i was planning
02:44 PM twnqx: go with some easy devel board to check if the cpu works for you, e.g. https://www.microchip.com/wwwproducts/en/ATSAMA5D27C-LD2G this SiP (would only need power supply & external QSPI flash for the OS)
02:45 PM twnqx: devel board for that is like 160€ if i remember though
02:46 PM cehteh: how about rpi zero?
02:46 PM twnqx: probably there are higher spec chips, too - just currently am working with something similar to that (my system is 30x84mm, a third of which is a GSM modem :P)
02:46 PM cehteh: well where does the data come from?
02:46 PM twnqx: uvc cameras, he said
02:46 PM cehteh: i mean bus
02:46 PM twnqx: uvc implies usb 2.0
02:46 PM cehteh: ah ok
02:46 PM twnqx: well, USB, but the resolution implies at least 2.0 ;)
02:47 PM vmt: yes
02:47 PM cehteh: bandwidth management over multiple usb2 's will be a tight call then
02:48 PM twnqx: so yeah, pi zero would be a decent starter to see what performance you need
02:48 PM vmt: cehteh: yeah that was why i initially thought of an fpga
02:48 PM twnqx: µSD card, usb micro OTG to A adapter cable, powered USB HUB, hook up the cams and check
02:48 PM cehteh: iirc that has only one usb2 ... may be good enough for very few cams, but not more, and the SD card interface isnt really stellar either
02:50 PM cehteh: i am not into fpga'S but doing multiple usb interfaces in fpgs and output them to some faster interface that your mcu supports (memory bus? dma even?) might be something ... when you have infinite time and resources to develop that :D
02:51 PM twnqx: yeah, there would be tons of state to track
02:51 PM cehteh: methinks there are no much soc's/mcus with *plenty* usb interfaces
02:51 PM twnqx: that's what hubs are four
02:51 PM twnqx: for* lol
02:51 PM vmt: don't see a reason for the mcu there. just have enough buffers to facilitate for the card's write speed
02:51 PM cehteh: still the upward port is the bottleneck
02:51 PM vmt: sure
02:51 PM cehteh: what bandwidth needs a single camera?
02:52 PM twnqx: mostly because usb enumeration requires state, UVC requires parameter finding/matching (usually tons of parameters for codec, resolution, whitebalance, ...)
02:52 PM twnqx: you'd probably want a file system on the SD card
02:52 PM twnqx: etc
02:52 PM vmt: i'm just doing back of the envelope here. i'm not locked in final numbers yet
02:53 PM vmt: no, i probably wouldn't want a file system
02:53 PM vmt: to keep it simple, i'd probably split the card into n sequential write areas and keep track of the top for n streams
02:53 PM cehteh: twnqx: thats why i was thinking about only implement the plenty usb interfaces on the fpgs, kinda lightweight, host assisted for all the higher protocols
02:54 PM cehteh: aynway nit my beer :D
02:54 PM vmt: and i could just write the card blank in-between recordings
02:54 PM twnqx: pointless, just stick a USB hub to a soc
02:54 PM twnqx: gets you buffering and parameter control out of the box, ready to use code
02:54 PM cehteh: if single bus is fast enuugh
02:54 PM twnqx: and you can still write to raw cards
02:54 PM twnqx: sure is
02:54 PM vmt: sure
02:54 PM twnqx: mjpeg doesn't need much
02:55 PM cehteh: ok
02:55 PM vmt: yeah
02:55 PM twnqx: raw RGB... would need more:P
02:55 PM vmt: a lot of cam modules can output already compressed mjpeg so it's not a biggie
02:56 PM cehteh: then ok ,, duno how much cameras you want to connect and what/res bandwidth
02:57 PM vmt: yeah, i'll probably start out with a zero and check out how far i can push it
02:57 PM twnqx: anyway, i'd really start with a raspi (normal one even) to benchmark bandwidth needs
02:57 PM twnqx: then you'll at least know how fast things have to be
02:57 PM cehteh: the acquisition system we're doing next will be 16k x 16k pixel uncompressed 10 bit .. but only black/white ahah
02:58 PM cehteh: that'll need shitloads of bandwidth
02:59 PM cehteh: ah no 64k x 64k ..
02:59 PM cehteh: line camera is 16k but needs 4 passes
03:00 PM twnqx: if you have a line camera it's 16k x 1 :P
03:00 PM twnqx: but super high framerates
03:00 PM cehteh: yeah
03:01 PM cehteh: over 100kHz not finally settled yet
03:01 PM vmt: what's the application?
03:02 PM twnqx: mh, 100k x 16k 1.6G?
03:03 PM twnqx: with 10bpp, 16gbit/s - sounds fun
03:04 PM cehteh: scanning microscope
03:04 PM twnqx: what protocol? multilane CSI?
03:06 PM cehteh: nothign settled yet .. just planning, beefy PC with some kind of framegrabber, depending on the camera we finally choose and other factors
03:08 PM * twnqx somehow hears "Basler" in the digital silence
03:08 PM cehteh: will see
03:09 PM twnqx: though only 12k
03:09 PM cehteh: https://www.teledynedalsa.com/en/products/imaging/cameras/linea-ml/
03:10 PM twnqx: need
03:10 PM twnqx: neat*
03:32 PM joakimk: I'm working on a hobby project, with an ATMEGA88 and a 3.6864MHz external crystal. I'm trying to set up the 16-bit timer 1 to blink some LEDs, at a variable rate.
03:32 PM joakimk: Please see the ISR setup at https://github.com/joakimgk/trafikklys/blob/atmega88/ATmega16_WIFI/ATmega16_WIFI/main.c#L402
03:33 PM joakimk: Then, in line 355, I receive a byte containing the "tempo" (from 0 to 255) and I want to use that to set the rate accordingly... Faster or slower... https://github.com/joakimgk/trafikklys/blob/atmega88/ATmega16_WIFI/ATmega16_WIFI/main.c#L355
03:35 PM cehteh_: atmega + wifi sounds wrong :D
03:35 PM joakimk: The idea is to set this up so that the min tempo (I guess that is tempo 255) is ~1 sec rate, while the max tempo might be whatever is preceivable by the eye (perhaps ~0.1 sec or something)
03:35 PM joakimk: cehteh_ hehe... It's very much a hobby project
03:36 PM joakimk: I'm using an ESP8266 for the wifi communications
03:36 PM cehteh_: seen that
03:37 PM joakimk: so, it's pretty much working... The TCP/IP link is established, and I see the AVR is receiving the payloads (i.e. the tempo bytes etc), but I can't get the rate into the desired interval I described
03:37 PM joakimk: max is too slow, and min is too fast ;)
03:37 PM cehteh_: yeah with very slow blinking you need to do some timer stunts
03:38 PM joakimk: but there are all those parameters to configure in the setup. Very overwhelming for an amateur.. Have I got this at all correct?
03:39 PM joakimk: I *guess* so, since it does work, but I need some fine-tuning
03:39 PM cehteh_: uhm dunno :) too much code for me to digest :D
03:39 PM joakimk: yeah... but could you please have a look at the ISR setup routine?
03:40 PM cehteh_: you only want blinking? on/off?
03:40 PM joakimk: yes
03:40 PM joakimk: like, I have 3 LEDs, and I want the to scroll, or blink in patterns
03:40 PM joakimk: like 00000100 - 00000010 - 00000001 etc
03:40 PM joakimk: think, Night Rider ;)
03:40 PM cehteh_: yep
03:40 PM joakimk: (I did mean Knight Rider yes, thank you google)
03:41 PM cehteh_: well that involves some dimming :D thats more complex
03:41 PM cehteh_: but ok
03:41 PM joakimk: dimmign?
03:41 PM joakimk: how so
03:41 PM cehteh_: knight rider
03:41 PM joakimk: aah
03:41 PM joakimk: yes
03:42 PM joakimk: never mind that :)
03:42 PM joakimk: this is way simpler
03:43 PM cehteh_: anyway there are plenty ways how you can approach it, i dont think you need CTC mode, just normal mode (fastpwm?) should be enouhg
03:43 PM cehteh_: ah moment thats the 16bit timer might beok
03:45 PM joakimk: so, what are you saying? You said I might be over complicating things with CTC over normal mode, but then since it's the 16bit timer you're saying CTC might be OK after all? Or is CTC *required* since it's the 16bit timer?
03:46 PM cehteh_: i am just thinking how you try to do it, because i doing things differently :)
03:46 PM joakimk: :) much appreciated that you take time for this
03:46 PM joakimk: Reading this: "If all you want to do is toggle an output pin, use CTC or PWM. If you want to do more, use normal mode (or CTC or PWM, depending on the timing requirements)."
03:47 PM cehteh_: so you setup CTC to overflow at the timesteps you want?
03:47 PM joakimk: that's my aim
03:47 PM joakimk: and it's working like 70% the way I want ;)
03:48 PM joakimk: if the setup looks OK, then I need some help converting the tempo byte (0-255) to the proper new interrupt timestep
03:48 PM joakimk: or compare value (or what it's called)
03:48 PM joakimk: does that make sense?
03:49 PM cehteh_: thats just some math, you have a minimum time and a maximum time and want 256 steps between that
03:49 PM joakimk: right
03:49 PM joakimk: so you see my attempt?
03:49 PM joakimk: https://github.com/joakimgk/trafikklys/blob/atmega88/ATmega16_WIFI/ATmega16_WIFI/main.c#L355
03:49 PM joakimk: first, I'm correct to set the value in the `OCR1A` register?
03:50 PM joakimk: (must be correct...)
03:50 PM cehteh_: iirc yes, depends on the WGM mode but in CTC its OCR1A when i remember correctly
03:51 PM cehteh_: you can jsut toggle a debug led in the ISR then you should be able to measure/scope half of your isr freq there
03:52 PM joakimk: ISR (TIMER1_COMPA_vect) ?
03:53 PM joakimk: yes
03:53 PM joakimk: so I have a "pattern" blinking already, and I am able to send tempo bytes which change the rate.
03:53 PM cehteh_: just use the overflow isr (but shouldnt matter except its a bit more universal and the prgram stays working even wehn you experiment with other modes)
03:53 PM joakimk: I'm running the ATMEGA88 in the STK500 programmer, using PORTB LEDs
03:54 PM joakimk: which is the overflow ISR?
03:55 PM joakimk: ISR(TIMER0_OVF_vect) ?
03:55 PM cehteh_: TIMER1 oblv
03:55 PM joakimk: oh yes
03:56 PM cehteh_: anyway that doesnt change anything else, just a recommendation (semantics are slightly different, but doesnt matter here)
03:56 PM joakimk: as for my calculations though, OCR1A is set from 32895 (byte 0) to 65663 (byte 255)
03:56 PM cehteh_: ah you modulate ORC1A depending on speed?
03:56 PM joakimk: maybe I should just shift down the "initial" constant, 32768, to something lower?
03:56 PM joakimk: yes
03:57 PM joakimk: `OCR1A = 32768 + (payload[0] + 1) * 128 -1;`
03:57 PM cehteh_: then you need the correct formula for that
03:57 PM joakimk: this is too ad hoc?
03:57 PM cehteh_: if you want it this way .. mkay
03:57 PM joakimk: :)
03:57 PM cehteh_: wastes a timer somewhat, because its exclusively used for that task
03:58 PM joakimk: sure
03:58 PM joakimk: I'm using the timer0 for the ESP/wifi comms
03:58 PM cehteh_: anyway you want 0.1s to 1sec
03:58 PM cehteh_: so span is 0.9sec
03:58 PM joakimk: something like that yes
03:58 PM cehteh_: 0.9/256 would be the time step
03:59 PM cehteh_: and you need to offset it by the minimum 0.1sec
03:59 PM cehteh_: thats should pretty much all
03:59 PM joakimk: now there's some xtal frequency / prescaler maths, isn't there?
04:00 PM joakimk: to get the offset?
04:00 PM cehteh_: yes
04:00 PM cehteh_: good old math :)
04:00 PM cehteh_: i have some macros around that
04:00 PM joakimk: but am I right to use prescaler 8, you think=
04:00 PM joakimk: I mean, why not 64
04:01 PM joakimk: or 1024 ;)
04:01 PM cehteh_: you can calculate that
04:01 PM cehteh_: make it as fast as possible where the longest time (1s) is still covered in the 64k steps
04:03 PM joakimk: can I use something like this https://eleccelerator.com/avr-timer-calculator/
04:04 PM cehteh_: https://git.pipapo.org/?p=muos;a=blob;f=lib/clock.h;h=e5173abb87c997a375919226ad38dbcfb59d3b40;hb=refs/heads/devel
04:04 PM cehteh_: i put that in some macros
04:08 PM joakimk: thanks for the help! I did look into this timer setup before, but I haven't played with this project for some months now and I need to look into all that once again ;)
04:09 PM joakimk: those web calculators are a bit confusing at first sight
04:09 PM cehteh_: never used them
04:14 PM cehteh_: https://paste.debian.net/1166761/ thats how i do it :D
04:15 PM joakimk: but, with a 3.6864MHz crystal, each timer step takes 3.686.400 / 8 / 2^16 = 7,03125 instructions?
04:15 PM joakimk: sorry, I can't figure out the macros just now ;)
04:16 PM joakimk: looks convenient tho!
04:16 PM cehteh_: well needs more than just that of course :)
04:17 PM joakimk: so... if I set OCR1A to 2^16 then the blink rate will be once every ... 7 secs?
04:17 PM joakimk: no that doesn't look right
04:17 PM joakimk: it's a bit late here for this ;)
04:18 PM cehteh_: heh ... just try step by step as i saied make it toggle a debug led on each interrupt
04:19 PM cehteh_: that then should be your precision (0.9s/256)
04:19 PM cehteh_: ah moment too late for me
04:19 PM cehteh_: i am confused because i do things differently ,, having one timer at constant speed :D
04:19 PM cehteh_: overflow at max
04:20 PM joakimk: but if so, then how do you change the rate/tempo?
04:20 PM joakimk: do you change the tempo?
04:20 PM cehteh_: no
04:21 PM cehteh_: but it does fairly more complex things :)
04:21 PM cehteh_: complete scheduling at any time
04:30 PM joakimk: cehteh_ you there?
04:30 PM joakimk: fell off the wifi here ;)
04:31 PM joakimk: so I changed the calculation
04:31 PM joakimk: to `OCR1A = 16384 + (payload[0] + 1) * 128 -1;` and this responds more like I want/like
04:32 PM joakimk: however, now min is too fast... ;) so I think I need to adjust the step width -- just like you suggested
04:33 PM joakimk: I need to re-visit the whole clock freq / prescaler stuff, and just do the maths properly.
04:33 PM joakimk: thanks again for your help!
04:36 PM cehteh_: i am out .. bbl
09:19 PM rue_shop1: :) got a DS1307 working as NV ram
09:19 PM rue_shop1: ok
09:19 PM rue_shop1: what you lot up to
11:35 PM day_ is now known as day