#avr Logs

Apr 03 2021

04:15 AM DusXMT: I have a bit of an embarrassing question. Does anyone know if an STM32 chip can be restored into working order if a program was flashed onto it that incorrectly configured the clock?
04:22 AM DusXMT: I'm seeing something about a boot0 pin, I'm investigating what that does currently
04:29 AM exp: DusXMT: whoops! I am afraid I don't know, but someone here should
04:29 AM exp: stick around
04:34 AM DusXMT: Okay, managed to find the boot0 pin on my board, and thankfully it's right next to a VDD pin, so I can just temporarily short them, it was probably designed with that in mind
04:39 AM DusXMT: Excellent! That worked! :3
04:40 AM DusXMT: moral of the day: don't copy/paste code in hastilly trying to get something to work without thoroughly understanding both it and the context that it's used in first.
04:50 AM * exp has a few AVRs with misset fuses to bear testament
04:51 AM DusXMT: https://www.dooshki.net/pub-unlisted/IMG_20210403_112228.jpg <- makes me glad that I kept these pin headers around, didn't need to modify the board thanks to them
04:52 AM exp: i see isolation slots, but no sign of high voltage
04:53 AM exp: i have not used that nucleo, i wonder why?
04:53 AM DusXMT: I think it's mostly a functional separation, the part on the left is the ST-Link programmer, whereas the part on the right is the MCU and its I/Os
04:53 AM DusXMT: Who knows, perhaps the programmer can be snapped off if you no longer need it
04:54 AM exp: oh that's cute!
04:54 AM DusXMT: it can be used with external pins on the pin headers
04:54 AM exp: i've not made a 'proper' snappable board yet
04:54 AM exp: just some LED PCBs you can cut to length
04:55 AM DusXMT: And I mixed up my sides once again :D Swap left/right
04:56 AM DusXMT: exp: https://www.st.com/en/evaluation-tools/nucleo-l152re.html <- This is my specific model (re: i have not used that nucleo, i wonder why?)
04:57 AM exp: DusXMT: i'm gonna have to have a look through my dev kit bucket :)
06:56 AM Sponge5: Hi, I'm trying to use a library for controlling LEDs with ATMega2560 and the way my prototype board is wired means I have to use PORTH - PH5 for data. In avr/iomxx0_1.h PORTH is defined as _SFR_MEM8(0x102). In the library the inline assembler uses `out` instructions with "I" (_SFR_MEM_ADDR(ws2812_PORTREG)). ws2812_PORTREG is set to PORTH. When trying to compile this I get this
06:56 AM Sponge5: https://github.com/cpldcpu/light_ws2812/issues/84
06:57 AM Sponge5: My problem is, I don't have options to use a different PORT, is that possible?
07:01 AM Sponge5: Basically I think PORTH is outside the I/O region they are talking about in the issue. I'd like to use it for controlling the LEDs anyway
07:05 AM exp: when you say 'ws2812_PORTREG is set to PORTH' do you mean `ws2812_port` is set to `H`?
07:05 AM exp: as that seems to be the way it's handled, through a substituting macro
07:08 AM Sponge5: Yes
07:09 AM Sponge5: exp: sorry for late reply
07:10 AM exp: Sponge5: ok, I don't know enough about AVR asm to know if this is an unacceptable IO address, but I'll have a casual read :-)
07:11 AM Sponge5: If it was an acceptable IO address it would be _SFR_IO8() instead of _SFR_MEM8() no?
07:12 AM Sponge5: exp: Oh I pasted wrong thing, the inline assembler is using `out` instruction with "I" (_SFR_IO_ADDR(ws2812_PORTREG))
07:12 AM Sponge5: the _MEM_ was me trying to hack my way around the error :)
07:13 AM exp: i understand, i'm just trying to quickly learn about the io port offsetting
07:14 AM exp: i think that instruction is in rather than out, and "I" may restrict its size, but you may be restricted by the IO port anyway
07:14 AM exp: reading datasheet now
07:16 AM Sponge5: I have the datasheet open too, where are you looking?
07:16 AM exp: page 12, the 'Extended I/O space'
07:18 AM Sponge5: These code examples assume that the part specific header file is included before compilation. For I/O registers
07:18 AM Sponge5: located in extended I/O map, "IN", "OUT", "SBIS", "SBIC", "CBI", and "SBI" instructions must be replaced with
07:19 AM Sponge5: instructions that allow access to extended I/O. Typically "LDS" and "STS" combined with "SBRS", "SBRC", "SBR",
07:19 AM Sponge5: and "CBR".
07:19 AM exp: yes, but the asm in the code you're using is already using SBRS and LSL
07:19 AM exp: for these addresses
07:19 AM exp: so i'm a little confused as to why it's using a parameter with limited size
07:20 AM exp: wait i misread LDS and LSL, LOL
07:21 AM Sponge5: That might be a problem also?
07:23 AM exp: right yes i'm ignorant and it's using the `out` operation, which is limited to the first 64 addresses, with an 32 offset for the register file
07:23 AM exp: so if you need to use PORTH you'll have speed penalties it seems
07:23 AM exp: not 100% confident on any of that, no expert on asm here
07:24 AM Sponge5: Me neither
07:24 AM Sponge5: But what you're saying makes sense
07:25 AM Sponge5: So I guess the better course of action is to move the output to a port inside the first 64 adresses
07:25 AM exp: so OUT is a single cycle, STS is 2 apparently
07:25 AM exp: althoug STS (16 bit) is listed as 1 cycle as it's 2 bytes not 4?
07:26 AM exp: not quite sure there :-)
07:28 AM Sponge5: I don't think that working with speed penalties is the way to go
07:29 AM exp: depends what your constraints are
07:30 AM Sponge5: Speed penalties would mean that the timing on the signals would be off, which could make the library useless, no?
07:30 AM exp: i've no idea, haven't worked with WS2812s
07:31 AM Sponge5: Is there a way to test it? How would I bypass the limitation to first 64 addresses
07:32 AM Sponge5: I'd have to use a different instruction in the asm instead of `out`, correct?
07:32 AM exp: yep as far as i understand
07:32 AM Sponge5: Okay, I'll try that
07:32 AM Sponge5: exp: tyvm
07:33 AM exp: hah don't thank me i'm mostly just speculating, there will be someone here who actually knows facts i'm sure :)
07:35 AM Sponge5: at least you pushed me in the right direction :)
07:39 AM exp: so it looks like the ws2812 uses a self clocked signal with relatively tight timing constraints, ±150ns
07:40 AM exp: so yeah, 2 cycles is 125ns? i think?
07:41 AM exp: so you may need to shift to a port that takes only a cycle, i'd have to go draw out the timing i think but it sounds like there's no margin here
07:41 AM exp: if there is, it's slim
07:47 AM exp: ok with a bit more research this probably is feasible as people have reported this working at 4mhz
07:48 AM exp: the #ifs you can see in the source file include nops for timing purposes, and so you can sub some of those out in theory if you're running at faster clock speeds
07:48 AM exp: turns out I do actually have some WS2812s in stock, boy do i have a big random pile 'o' crap :-)
07:49 AM Sponge5: exp: I'm have mega2560 at 16mhz
07:50 AM Sponge5: *I have
07:50 AM exp: Sponge5: then in theory i think this is feasible, but i don't want to promise
07:50 AM exp: you'll need to adjust the nop entries so the loop times correctly
07:55 AM Sponge5: exp: and what would I use instead of `out`? I'm thinking `sbr`
07:56 AM exp: Sponge5: you'd use STS, OUT stores the contents of a register in the IO space
07:56 AM exp: wheras STS stores it in memory space
07:58 AM Sponge5: aaah got it, so even though they're two different spaces, they share adress space
07:58 AM Sponge5: and I have to use different instructions because of that
07:59 AM exp: physically there'll be some difference in how they're connected to the core, but more than that i don't really know the details
07:59 AM exp: i assume that the extended io space is implemented as part of SRAM
07:59 AM exp: the io space also has an address offset to accomodate the register file
08:47 AM specing_ is now known as specing
11:16 AM rue_bed: your running addressable leds from externally mapped memory space?
11:17 AM rue_bed: polprog, has a makefile for compiling stm32 projects with opencm3
11:17 AM rue_bed: I use it for my stuff
03:26 PM polprog: idk who needs the makefile but ill throw it here just in case: https://polprog.net/papiery/stm32/Makefile
08:47 PM specing_ is now known as specing