#avr Logs

Apr 09 2019

12:50 AM gsi__ is now known as gsi_
07:12 AM wondiws: is it possible to secure your flash against reading out? I read out the flash of this chinese device I bought, but I just get an ascending pattern.
08:10 AM paulo_ is now known as Guest23089
08:38 AM cehteh: wondiws: yes most (or all?) avr's have lockbits which prevent that
08:39 AM wondiws: cehteh, and it is set to 0, so it is locked :(
08:39 AM wondiws: just found that out
08:39 AM cehteh: dunno if you even can read that lockbits reliably
08:39 AM cehteh: but you can do a chip-erase and then reprogram it :D
08:39 AM wondiws: cehteh, that's not what I want
08:40 AM LeoNerd: Can we not have the same conversation twice in both here and #avrs please?
08:40 AM LeoNerd: It is getting confusing
08:40 AM cehteh: lol
08:40 AM cehteh: i go on with work anyway
08:41 AM LeoNerd: I'm mostly working on some of the newer AVR xtiny chips today
08:41 AM LeoNerd: Though I'm still unsure what we call them all. xtiny? ATtiny 1-series?
08:45 AM * cehteh wonders what microchips strategy is, beefing up the lower end and phase out the bigger ones?
08:45 AM cehteh: avr's i mean
08:45 AM LeoNerd: I dunno, they don't seem to be stopping the larger ones any time soon
08:46 AM cehteh: the 0- and 1- series got nice new features but otherwise they are really punny and small
08:46 AM LeoNerd: E.g. see the new flagship that is the ATmega4809
08:46 AM LeoNerd: Huuuuge thing
08:46 AM cehteh: ah not seen yet
08:46 AM cehteh: imagine atmegas in the 200mHz range, even with 8 bit that would be pretty competive in performance
08:47 AM LeoNerd: I expect you mean 200MHz
08:47 AM cehteh: yeah
08:47 AM LeoNerd: Any ATmega can already achieve 200mHz now ;)
08:47 AM cehteh: :)
08:48 AM LeoNerd: Though interestingly, PIC24s can't because they use a PLL to generate internal clocks and that has a minimum frequency limit too
08:48 AM LeoNerd: Whereas an AVR can clock right down to DC
08:48 AM cehteh: yep
08:48 AM cehteh: upper limits is set by the architecture "execute from flash" ... they would need to change a lot to overcome that
08:49 AM cehteh: i mean by magnitudes
08:49 AM cehteh: 32MHz is archiveable by xmegas
08:49 AM LeoNerd: Yeah, you'd probably need a shadow RAM to read the flash into at boot time
08:49 AM cehteh: but saying 150-200 would proll never be possible
08:49 AM LeoNerd: For that you're looking at an ARM chip definitely
08:49 AM cehteh: dunno or some parallel flash
08:50 AM LeoNerd: If you need that sort of clock speed it's likely you'll want the 32bit chips instead
08:50 AM cehteh: i would like to go risc-v
08:50 AM cehteh: arm is state of the art, but kindof ugly at architecture level
08:50 AM cehteh: avrs are in some sense very simple and clean
08:50 AM LeoNerd: And complex
08:51 AM LeoNerd: Yah; the AVRs are nice. I'm actually quite impressed how simple they are. Even the new 1-series aren't too bad
08:51 AM LeoNerd: There's a -bit- of added complexity e.g. around the clock system but it's still nothing as compared an STM32, say..
08:51 AM cehteh: thats the biggiest selling point on avr's and hands down, if there would be a 200mhz version i would prefer it over a 72mhz arm for its simplicity
08:52 AM LeoNerd: I'm on the fence on that, though. Most things I've done, I've never really been up against the CPU speed limit; that having a faster CPU wouldn't help
08:52 AM LeoNerd: If I was limited in CPU time I was probably limited in RAM or something else as well
08:54 AM cehteh: yeah of course such an imaginary 200MHz avr could/should max out other architecture limits as well, having up to 64K ram and 128k flash
08:54 AM cehteh: maybe only 32k ram (nuff io space)
08:55 AM LeoNerd: Ahh..
08:55 AM LeoNerd: Have you seen the xtiny chips? They have unified memory space now. No split RAM / flash
08:55 AM LeoNerd: No more need for LPM :)
08:56 AM LeoNerd: That's why the biggest chip only goes up to 48Ki, because the lowest 16Ki of address space is needed for IO/peripherals/stack/RAM
08:57 AM LeoNerd: Huh.. but even the giant that is the mega4809 only has a single SPI and a single I²C. So it's still no replacement for the 328PB
08:57 AM cehteh: oh flash becomes byte adressable by that?
08:57 AM LeoNerd: Yup :)
08:57 AM LeoNerd: I don't have to use fprintf_P or the %S hack or PSTR() or anything like that any more on the tiny814
08:57 AM cehteh: ok
08:57 AM LeoNerd: Just a regular fprintf(uart_out, "Format string here\n"); already comes from program flash, not RAM
08:58 AM cehteh: but that has some limits
08:59 AM cehteh: i almost sued the 32k on the 328pb and some features are still to add (but can remove other things to save space)
08:59 AM cehteh: used
08:59 AM twnqx: i had to add external ram to a at90can :P
09:00 AM twnqx: which wasn too bad as i used external memory I/O anyway, but still...
09:00 AM cehteh: well i now wish for a risc-v devel board which is price and performance competive with a cortex m0
09:00 AM cehteh: twnqx: i meant flash
09:00 AM LeoNerd: Heh.. I've never come close to flash limit
09:00 AM LeoNerd: I do have some stage kit that I made multicore though.. ;)
09:00 AM twnqx: ah. the at90can i use has 128kB... that's enough.
09:01 AM LeoNerd: A dedicated ATtiny841 doing DMX offload, a couple of tiny84s doing WS2812 buffering, and a big 328P doing the main core
09:01 AM twnqx: speaking of ws2812...
09:02 AM twnqx: if i want to drive 8 chains of these at once i kind of have to pre-transform the output, any idea about doing that efficiently? :P
09:02 AM LeoNerd: Ooh.. no .. :/
09:02 AM LeoNerd: I've thought lots about 2812s... what I really want is a dual-ported SPI RAM chip
09:02 AM LeoNerd: I'd use that as a display buffer; have the 328P core write values in there and have a second ATtiny just reading them out and squirting them over the 2812 lines
09:02 AM cehteh: when you can put them on one port you can bitbang byte wise
09:03 AM cehteh: should be doable, but not saying it should be done
09:03 AM LeoNerd: It could possibly do some transforms like HSV->RGB, or overall brightness mutiplier too
09:03 AM LeoNerd: The 2812 IO loop easily has lots of NOP slots to do nopthreading in
09:03 AM twnqx: well, i actually am building (with a 1.5 years pause now...) a 8x8x8x cube of PL<whatever> 5mm LEDs
09:03 AM LeoNerd: ... did I tell you about my nopthread?
09:03 AM twnqx: which have a similar protocol
09:04 AM cehteh: what is nopthreading?
09:04 AM LeoNerd: Yeah there's quite a few of those. I've also used the APA-102s which have an SPI-like two-line protocol of clock and data. They're much easier to drive
09:04 AM LeoNerd: Much faster PWM'ing too. good for moving props
09:04 AM cehteh: i mean 2812 protocol is PITA
09:05 AM LeoNerd: cehteh: Are you familar with the usual way to drive a 2812? The manual bitbanging with lots of 'NOP' instructions in it?
09:05 AM twnqx: so is the PL
09:05 AM twnqx: it's just a few ms difference
09:05 AM cehteh: yeah
09:05 AM cehteh: i just dont know that term
09:05 AM LeoNerd: cehteh: So.. the main IO routine per bit, uses 6 then 9 then 6 NOPs (if you clock at the usual 16MHz).
09:05 AM cehteh: yes
09:05 AM LeoNerd: That's plenty of time to thread a /second/ program into those slots, to do some other processing
09:05 AM cehteh: ah
09:06 AM cehteh: ok
09:06 AM LeoNerd: So long as you use a totally disjoint set of registers and don't JMP
09:06 AM LeoNerd: So I did that :)
09:06 AM cehteh: totally sux
09:06 AM twnqx: hm
09:06 AM cehteh: and not using mul :)
09:06 AM LeoNerd: Oh.. yeah. MUL :(
09:06 AM twnqx: i guess... 6+9+6 might be enough to create the next data byte(s)
09:06 AM LeoNerd: Actually you can get away with a single MUL at the end of a byte, because the timing there is more flexible
09:06 AM twnqx: it's basically 16 shifts i need per byte, assuming i load all bytes into registers
09:06 AM LeoNerd: But yeah; what I use the NOP slots for is just managing my DMX buffer
09:06 AM cehteh: sounds like no-fun when you really need that, only fun when you do it for fun
09:07 AM LeoNerd: When I send 2812, I have to turn off interrupts, but doing that means I can lose DMX512 bytes
09:07 AM LeoNerd: But it turns out a single byte of 2812 writes faster than the byte time of DMX512, so... as long as somewhere within the loop I check for a new byte in UART and pull it into the buffer, I don't lose any
09:07 AM LeoNerd: Once I finish sending LED data, I can return to main program and actually process the incoming DMX buffer
09:08 AM cehteh: i never used 2812, but i would use some dedicated tiny for those
09:08 AM LeoNerd: Yeah that was my other plan
09:08 AM cehteh: input serial/spi/i2c or whatever
09:08 AM LeoNerd: But then that only moves the problem. How do you control the 2812?
09:08 AM LeoNerd: Er.. control the tiny?
09:08 AM LeoNerd: Yah - but how would it respond to UART/I²C/SPI ?
09:09 AM LeoNerd: This is why I wanted the dualport SPI RAM chip. The tiny can -pull- bytes from the SPI RAM framebuffer on its own timing and write them to the LEDs
09:09 AM cehteh: static timed non isr mainloop polling the serial with constant time banches
09:09 AM LeoNerd: Yeah; I guess it could. Ultimately that's the same as my DMX'ed nopthread
09:09 AM LeoNerd: DMX is just UART serial, at 250kBaud
09:09 AM cehteh: also you can have some pauses in the 2812 protocol where you can handle input
09:09 AM cehteh: i know dmx
09:10 AM cehteh: when you 'only' dmx mkay then
09:10 AM cehteh: i thought you do more
09:10 AM LeoNerd: I don't do the full processing while talking LEDs, no
09:10 AM cehteh: hey could you even derrive the timebase for the 2812 from dmx?
09:11 AM LeoNerd: I just have to keep receiving bytes of data into a buffer, and when I'm done with the 2812s, I return to main calc code that re-generates the LED data
09:11 AM LeoNerd: You -could- but most DMX masters don't time outputs very well
09:11 AM cehteh: ok
09:11 AM LeoNerd: You also tend to get bursty traffic. Lots of frames if values are changing, with only occasional keepalives if not
09:12 AM LeoNerd: You really want to treat DMX as simply an asynchronous one-way cache-coherency protocol to push updates
09:12 AM cehteh: well 2812 are bit pita
09:13 AM LeoNerd: They're not great. But outweighed by cheap cost, and reliability
09:13 AM LeoNerd: and ease of obtaining them
09:13 AM cehteh: you cant easily and efficiently code them .. its either inefficient, doesnt work or not easy
09:13 AM LeoNerd: Honestly, the APA-102s look much better on paper but in practice they're not
09:13 AM LeoNerd: A great thing about the one-wire protocol of 2812 is that being only one wire (plus power) is that there's no clock skew
09:13 AM LeoNerd: Which is great for longer cabling across stage props, for instance
09:14 AM LeoNerd: I wouldn't want to run an SPI-like system in a stage. That's going to go wrong
09:14 AM cehteh: since some time i have a one wire like signal on my todo list which has not so hard timing constraints
09:14 AM cehteh: sync on falling edge and rising edge timing transfers a few bits
09:14 AM LeoNerd: Oh it's also why I like the UPDI of these new ATtiny chips
09:15 AM LeoNerd: SPI-like ISP is prone to upsets on longer cables too, so harder to do in-situ reprogramming of my stage kit
09:15 AM cehteh: all on a shared bus without master
09:15 AM * twnqx liks JTAG programming
09:15 AM cehteh: anyway .. work cu
09:15 AM LeoNerd: Bah.. JTAG is -basically- SPI anyhow
09:16 AM twnqx: but it can be chained!
09:16 AM LeoNerd: Yeah, that's a plus. That has been an issue for me in my multicore stage box
10:22 AM rue_mohr: what is a 'longer' cable
10:22 AM LeoNerd: More than a metre or so
10:22 AM rue_mohr: back in the parallel port days, I had an stk200 on a 25' printer cable
10:23 AM rue_mohr: on the microcontroller workstation now, I use a ~1m cable on a 1.5m usb extension
10:23 AM rue_mohr: with an usbasp
10:23 AM rue_mohr: and toms programmer
10:24 AM LeoNerd: USB over long cables is fine, because that is a single async serial lane
10:24 AM LeoNerd: I just don't have a lot of success with SPI over long cables
10:25 AM LeoNerd: (and ISP and JTAG are both SPI-like)
10:28 AM rue_mohr: oh the actual spi lines, yea,
10:28 AM rue_mohr: those should be about 8" long max
10:29 AM LeoNerd: Right. That was my point
10:29 AM rue_mohr: if you had drivers on each end with termination resistors, I'm sure it'd be fine
10:29 AM LeoNerd: Once you add the few inches at least of internal cabling to get the ISP header out to the connector on the enclosure itself that doesn't leave much slack for cabling to the programmer, for doing in-situ reprogramming
10:29 AM rue_mohr: but yea
10:30 AM LeoNerd: That said, I do have a lovely pair of SPI-over-twisted-pair converter chips I should play with someday
10:30 AM LeoNerd: They supposedly let you run an SPI slave over maybe up to 200m of cat5 on a single pair
10:31 AM LeoNerd: Oh. My mistake - "only" 100m - https://www.analog.com/en/products/ltc6820.html
10:31 AM LeoNerd: They're proper-cute though :)
10:31 AM rue_mohr: :)
10:31 AM LeoNerd: Oh - did I add - magnetically-coupled galvanically-isolated cat5 at that
10:32 AM rue_mohr: hey, if ethernet can do it
10:32 AM LeoNerd: Oh it's easily possible; it's more that these chips are a lovely self-contained way to just convert it
10:33 AM LeoNerd: Stick one on each end and hey presto: it behaves just like SPI
10:33 AM LeoNerd: So neither master nor slave really has to care
10:33 AM polprog: i wonder what is the standard those chips send and rceive ovet TP
10:33 AM polprog: over*
10:33 AM polprog: receive*
10:33 AM rue_mohr: does it take the reset line too?
10:33 AM LeoNerd: Yes; it carries CS
10:33 AM polprog: cool
10:34 AM LeoNerd: polprog: they're DC-balanced pulses
10:34 AM rue_mohr: RZ
10:34 AM polprog: yeah, but im curious how a 0x55 over spi looks like on the signal line
10:34 AM polprog: or something
10:34 AM LeoNerd: A CLK transition is sent with a little +/- or -/+ pulse, depending on the state of MOSI; the other end then replies with a pulse of its own to send MISO back
10:34 AM rue_mohr: manchester
10:34 AM LeoNerd: A CS transition is..I forget - either 3 in a row, or something slower
10:34 AM polprog: neat
10:34 AM LeoNerd: The datasheet explains it - go take a look
10:35 AM polprog: its probably in the datahseet
10:35 AM polprog: yeah :D
04:22 PM paulo_ is now known as Guest36490
04:48 PM LeoNerd: polprog++ # chemistry puns
05:00 PM polprog: LeoNerd: ;)
11:43 PM day_ is now known as day