--- Log opened Wed Apr 01 00:00:07 2026
2026-04-01T00:21:53 < qyx> well, anything networking is the threshold for me to go linux
2026-04-01T00:34:50 < zyp> meh, linux gives you a bunch of conveniences, but adds a ton of complexity too
2026-04-01T00:36:01 < zyp> most linux capable chips is also gonna force you to do external ram+flash, to the point where designing around a premade module is common
2026-04-01T00:36:59 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 245 seconds]
2026-04-01T00:43:25 < qyx> yes, that's why they exist
2026-04-01T00:43:33 < qyx> and why I am using them :P
2026-04-01T00:43:53 < qyx> I already was at that "let's use cm7, sdram and external nor flash!" idea and failed
2026-04-01T00:46:45 < zyp> IME external nor flash is useful even for smaller projects that doesn't justify linux, but if you need external ram you're probably approaching the point where it makes sense, unless you just have some very specific need for big buffers
2026-04-01T00:52:08 < qyx> yeah wrong example, I am using external NOR for many things, basically on nearly every project
2026-04-01T00:53:47 < qyx> oh it is 7 minutes to April which means reset for the internet data plan!
2026-04-01T00:54:00  * qyx shaped to 1mbit/s
2026-04-01T00:55:37 < zyp> my rule of thumb at work is that external flash is typically useful when the project has lte/wifi/ethernet, and typically not necessary if it only has ble
2026-04-01T00:57:35 < zyp> and if the only purpose of the networking is to connect to some mqtt broker or similar, it doesn't really justify running linux
2026-04-01T00:59:13 < zyp> I wouldn't want to push a full update image for some embedded linux system over a typical lte-m plan :p
2026-04-01T01:00:48 < zyp> doesn't really affect the cortex-m market though, does it?
2026-04-01T01:02:56 < zyp> you can get some stm32 in wlcsp12 as well
2026-04-01T01:04:18 < zyp> I've done some hand assembly of wlcsp before, it's not too bad
2026-04-01T01:04:56 < zyp> but I generally don't want to hand assemble much of anything really
2026-04-01T01:07:53 < zyp> try embassy, it's nice
2026-04-01T01:09:45 < zyp> that's irrelevant
2026-04-01T01:10:42 < zyp> the point of rust isn't to catch illegal memory accesses, it's to not make them in the first place
2026-04-01T01:13:39 < specing> you can also program (and I do) stm32 in Ada
2026-04-01T01:13:48 < specing> similar safety but without the hype
2026-04-01T01:15:06 -!- rajkosto [~rajkosto@2a00:e90:2139:3700:0:ff:fe00:10] has joined ##stm32
2026-04-01T01:15:28 < zyp> they typically do, maybe the lowest end ones doesn't
2026-04-01T01:21:21 < qyx> a wild floating adc input to the rescue :P
2026-04-01T01:21:30 < qyx> as a "circuit"
2026-04-01T01:22:35 < qyx> zyp: dsepite the fact I mostly agree wit what you said, I want to do a stm32u5 + 8MB of hyperram + some flash as a low power, "featured" datalogger
2026-04-01T01:22:44 < qyx> in place of my current imx93 boards
2026-04-01T01:23:03 < qyx> solely for the super-low-power use cases when even solar is not feasible
2026-04-01T01:24:25 < qyx> this is apparently *hard* to do, remote data logging + low power + modular + configurable
2026-04-01T01:24:45 < qyx> not counting those single use boxes with lora/zigbee antenna digitizing a single sensor
2026-04-01T01:26:15 -!- PaulFertser [~paul@paulfertser.info] has quit [Ping timeout: 272 seconds]
2026-04-01T01:26:29 -!- PaulFertser [paul@paulfertser.info] has joined ##stm32
2026-04-01T01:31:58 -!- ThatDamnRanga_ [~ThatDamnR@UNASSIGNED-218-100-26-71.3cix.nzix.net] has quit [Ping timeout: 256 seconds]
2026-04-01T01:35:24 -!- ThatDamnRanga [~ThatDamnR@UNASSIGNED-218-100-26-71.3cix.nzix.net] has joined ##stm32
2026-04-01T01:36:10 < qyx> oh yes flash chips prices went up, 2021 1.13e, later that year 1.38e, 2024 1.55e, 2025 1.62e, 2026 1.63e
2026-04-01T01:36:44 < qyx> (64mbit QSPI NOR flash)
2026-04-01T01:37:07 < qyx> ordering infineon now instead of winbond
2026-04-01T02:17:43 < zyp> qyx, yeah, power budget is another point against linux
2026-04-01T02:18:21 < zyp> qyx, what's your experience with low power linux? how much do you have to budget?
2026-04-01T03:00:04 < qyx> so far the best was sama5d27, under 10 mA iirc when in sleep
2026-04-01T03:00:44 < qyx> but sleeping linux is not very useful
2026-04-01T03:01:52 < qyx> my budget for this particular design is to be able to work the whole year on a 100-400 Wh battery pack
2026-04-01T03:02:16 < qyx> but that includes other things as well (digitizers, comms, etc.)
2026-04-01T03:03:09 < qyx> which gives you about 10 mW average, which *should* be achievable with u5 in run mode all the time, even with external ram and flash
2026-04-01T03:03:51 < qyx> a linux in run mode is 400 mW minimum (imx6, sama5d27) or about 600 mW (imx93)
2026-04-01T03:04:19 < qyx> haven't tried mp1/mp2
2026-04-01T03:06:54 < zyp> yeah, this is orders of magnitude above the stuff I work with
2026-04-01T03:07:43 < qyx> I call it mid-power :P
2026-04-01T03:18:48 < zyp> I'm not sure how much my current nrf91 project draws, doing power measurements/optimization is still on my todo list
2026-04-01T03:19:34 < zyp> it's not gonna be super low, it needs to be fairly responsive to received commands, so I'm not using PSM on the LTE connection
2026-04-01T03:42:32 < qyx> cat1bis?
2026-04-01T04:23:01 < zyp> no, catm
2026-04-01T05:19:29 < qyx> ok with lte-m "fairly responsive" has the accurate meaning
2026-04-01T07:30:06 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2026-04-01T07:37:53 < Phantom> I wish uart rx dma had a timeout capability... 
2026-04-01T08:22:11 < jpa-> haha @ wallop
2026-04-01T08:53:27 -!- haritz [~hrtz@user/haritz] has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
2026-04-01T08:54:14 < qyx> there is uart rx interruot and you can disable dma (or do whatever you want) there
2026-04-01T09:03:02 < jpa-> or just have timer interrupt and check there
2026-04-01T09:03:17 < jpa-> though IIRC some stm32's have uart rx timeout interrupt (directly on the uart, not in dma)
2026-04-01T09:04:14 < qyx> yes thats what I mean
2026-04-01T09:12:53 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-01T09:20:59 < Phantom> idle detection
2026-04-01T09:22:29 -!- nerozero [~nerozero@87.253.63.54] has quit [Remote host closed the connection]
2026-04-01T09:23:31 -!- krish2487 [~krishi@cpe.ge-8-1-4-100.henqe12.dk.customer.tdc.net] has joined ##stm32
2026-04-01T09:23:33 < qyx> we said RX timeout
2026-04-01T09:24:21 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2026-04-01T09:27:53 < Phantom> I'll check too for rx timeout if this one have it
2026-04-01T09:28:52 < Phantom> I currently receive 1 byte at a time, but it is too fast and I think I lose some bytes... still need to investigate why it don't work :D
2026-04-01T09:28:58 < qyx> yes G4 has RTOF and RTOIE and a configurable timeout time
2026-04-01T09:30:03 < qyx> although idle frme detection may work too
2026-04-01T09:32:38 < Phantom> I'll check what work with HAL and DMA
2026-04-01T09:39:38 < jpa-> it also has 8-deep RX FIFO if you enable that, which can help if you can't bother scheduling multi-byte transfers
2026-04-01T09:40:35 < Phantom> that is also interessing
2026-04-01T09:41:10 < Phantom> I'll try to figure out the best way to do it...
2026-04-01T09:41:42 < Phantom> for now, bed time, nite
2026-04-01T10:02:49 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2026-04-01T10:03:35 -!- rajkosto [~rajkosto@2a00:e90:2139:3700:0:ff:fe00:10] has quit [Ping timeout: 244 seconds]
2026-04-01T10:19:31 -!- akaWolf [~akaWolf@akawolf.org] has quit [Ping timeout: 264 seconds]
2026-04-01T10:22:03 -!- akaWolf [~akaWolf@akawolf.org] has joined ##stm32
2026-04-01T10:22:53 < zyp> qyx, I mean, it's a relative term
2026-04-01T10:24:54 < zyp> but in my current setup, I have about a one second round trip sending a command via the MQTT broker before I have a response back
2026-04-01T10:26:17 < zyp> and there's apparently still some power saving thing going on, because it takes around a second to do it three times in rapid succession as well
2026-04-01T10:28:24 < zyp> ah, yeah
2026-04-01T10:28:51 < zyp> takes about a second when it's in RRC Idle, near-instant when it's in RRC Connected
2026-04-01T10:30:36 < zyp> hmm, maybe this is eDRX
2026-04-01T10:42:20 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 244 seconds]
2026-04-01T10:53:13 -!- artok [~azo@91-153-163-37.elisa-laajakaista.fi] has quit [Ping timeout: 248 seconds]
2026-04-01T11:25:33 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2026-04-01T11:28:25 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2026-04-01T11:38:43 -!- rajkosto [~rajkosto@2a00:e90:2139:3700:0:ff:fe00:10] has joined ##stm32
2026-04-01T12:18:58 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-01T12:24:10 -!- Livio [~livio@user/livio] has quit [Ping timeout: 265 seconds]
2026-04-01T12:24:22 -!- infisx [~infisc@user/infisc] has joined ##stm32
2026-04-01T12:27:50 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 268 seconds]
2026-04-01T12:34:56 -!- artok [~azo@91-153-163-37.elisa-laajakaista.fi] has joined ##stm32
2026-04-01T12:49:38 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2026-04-01T12:54:16 -!- _Posterdati_ [~posterdat@user/Posterdati] has joined ##stm32
2026-04-01T12:54:37 < _Posterdati_> hi
2026-04-01T12:54:40 < _Posterdati_> please help
2026-04-01T12:54:52 < jpa-> nope
2026-04-01T12:55:09 < _Posterdati_> I have a problem with stm32h723, writing RNG HTCR causes Hard Fault Handler! :)
2026-04-01T12:55:18 < _Posterdati_> jpa-: thanks :)
2026-04-01T12:55:21 < jpa-> so what do CFSR etc say?
2026-04-01T12:55:33 < _Posterdati_> 0x00000000
2026-04-01T12:55:40 < jpa-> HFSR?
2026-04-01T12:56:42 < jpa-> for H7, the general answer is that you forgot to enable some clock :)
2026-04-01T12:57:18 < _Posterdati_> jpa-: I enabled the RNG clock, how can I check if it is a 48 MHz clock?
2026-04-01T12:59:13 < jpa-> only by being careful, i think
2026-04-01T12:59:29 < jpa-> but CFSR 0 doesn't sound like hardfault, how did you determine it? PSR?
2026-04-01T13:00:02 < _Posterdati_> jpa-: no, as I write HTCR with magic number it jumps to the Hard Fault Handler
2026-04-01T13:00:29 < jpa-> well your hard fault handler might be in vector table for multiple different vectors
2026-04-01T13:00:41 < jpa-> so check PSR for which vector is active
2026-04-01T13:01:10 < _Posterdati_> ok, let me check again CFSR
2026-04-01T13:02:33 < _Posterdati_> 0xe000ed28 = 0x00 0x04 0x00 0x00
2026-04-01T13:02:46 < jpa-> but regarding RNG clock, values to check are RCC->D2CCIP2R RNGSEL bits, RCC->AHB2RSTR RNGRST bit, RCC->AHB2ENR RNGEN bit
2026-04-01T13:04:03 < jpa-> so you have usage fault INVPC; if you use stepi and display /i $pc in gdb to step instruction-by-instruction, after which instruction does it jump to hardfault handler?
2026-04-01T13:04:34 < _Posterdati_> wait
2026-04-01T13:04:36 < _Posterdati_> restart
2026-04-01T13:05:59 < _Posterdati_> strb r2, [r3, #0]
2026-04-01T13:06:06 < _Posterdati_> should be accessed at 32 bit_
2026-04-01T13:06:09 < _Posterdati_> should be accessed at 32 bit?
2026-04-01T13:06:20 < jpa-> that won't cause hardfault with INVPC
2026-04-01T13:06:54 < fantanYl> jpa-: H7 generates hardfault if you write to peripheral with disabled clock? 
2026-04-01T13:06:59 < _Posterdati_> after execution: 0xe000ed28 = 0x00 0x04 0x00 0x00
2026-04-01T13:07:16 < jpa-> is that CFSR value in little endian?
2026-04-01T13:07:24 < jpa-> so 0x00000400 really?
2026-04-01T13:07:49 < jpa-> then it is IMPRECISERR so that the faulting write could be a bit before that
2026-04-01T13:08:48 < jpa-> but yeah, in general peripheral registers should be accessed by word, and i'm not sure how you'd manage to make it byte access if you are using the normal headers
2026-04-01T13:08:58 < jpa-> fantanYl: usually it is helpful and just hangs totally :)
2026-04-01T13:09:06 < jpa-> fantanYl: but i think i have gotten a bus error sometimes
2026-04-01T13:09:09 -!- krish2487 [~krishi@cpe.ge-8-1-4-100.henqe12.dk.customer.tdc.net] has quit [Ping timeout: 268 seconds]
2026-04-01T13:09:20 < _Posterdati_> 0xe000ed28 = 0x00000400
2026-04-01T13:09:41 < fantanYl> if I get HardFault/BusFault while accessing peripheral, I check whether that peripheral is accessible in non-privileged user mode
2026-04-01T13:10:02 < fantanYl> some are not, RNG is a rather good candidate for also being one of them
2026-04-01T13:10:14 < jpa-> impreciserr is annoying to debug, but you should manually check every address that the code accesses in a few instructions before the fault triggers
2026-04-01T13:10:52 < jpa-> the byte access to peripheral register is a good guess
2026-04-01T13:11:23 < _Posterdati_> jpa-: only this peripheral is accessed by byte, why?
2026-04-01T13:11:40 < jpa-> how are you accessing it?
2026-04-01T13:12:02 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-01T13:12:04 < _Posterdati_> writing to a pointer to uint32_t
2026-04-01T13:12:09 < jpa-> i mean, actual code
2026-04-01T13:12:45 < _Posterdati_> is a baremetal project no st libraries whatsoever
2026-04-01T13:12:56 < jpa-> so, even more you need to pastebin the actual code
2026-04-01T13:13:02 < _Posterdati_> ok
2026-04-01T13:13:10 < jpa-> there is a bug in your code, but we can't know what the bug is if you don't show the code :)
2026-04-01T13:13:18 < _Posterdati_> yes, seems so
2026-04-01T13:16:18 -!- rajkosto [~rajkosto@2a00:e90:2139:3700:0:ff:fe00:10] has quit [Ping timeout: 244 seconds]
2026-04-01T13:16:47 -!- Livio [~livio@user/livio] has quit [Remote host closed the connection]
2026-04-01T13:16:52 < _Posterdati_> jpa-: https://pastebin.com/XYbqJWtR
2026-04-01T13:17:01 < _Posterdati_> wait for other piece of code :)
2026-04-01T13:18:47 < _Posterdati_> https://pastebin.com/LJ55WEru
2026-04-01T13:19:07 < jpa-> give also definition of m_pHTCR and the struct it uses
2026-04-01T13:19:13 < _Posterdati_> ok
2026-04-01T13:19:28 < jpa-> and in gdb, check that m_pHTCR is actually a valid value and not null or garbage
2026-04-01T13:19:55 < fantanYl> reinterpret_cast< tRNG_HTCR * >((*this)[ RNG_HTCR ]) suggests that there is some juicy stuff inside
2026-04-01T13:20:15 < _Posterdati_> https://pastebin.com/zFvfC7cU
2026-04-01T13:20:55 < jpa-> that's not tRNG_HTCR
2026-04-01T13:21:15 < _Posterdati_> https://pastebin.com/iMTUXdL6
2026-04-01T13:21:32 < _Posterdati_> could be the union definition
2026-04-01T13:22:16 < jpa-> or the attribute packed
2026-04-01T13:23:32 < _Posterdati_> yes, let me check one thing...
2026-04-01T13:24:11 < jpa-> https://godbolt.org/z/rMMzaGjfv   yeah, looks like you shouldn't put packed on the union
2026-04-01T13:24:19 < jpa-> you can put it on the bitfield inside it on the other structs
2026-04-01T13:24:29 < _Posterdati_> yes
2026-04-01T13:24:33 < _Posterdati_> is what I did
2026-04-01T13:24:48 < _Posterdati_> I'm testing it right now
2026-04-01T13:25:03 < jpa-> i hope that you are at least generating these from SVDs instead of writing it manually
2026-04-01T13:25:13 < _Posterdati_> no
2026-04-01T13:25:15 < _Posterdati_> manually
2026-04-01T13:25:25 < jpa-> life is too short for that
2026-04-01T13:25:32 < _Posterdati_> yes I know :)
2026-04-01T13:26:47 < _Posterdati_> it was fun
2026-04-01T13:27:56 < fantanYl> to me it looks too convoluted
2026-04-01T13:28:07 < fantanYl> especially that reinterpret_cast part and a bunch of pointers
2026-04-01T13:28:24 < _Posterdati_> working
2026-04-01T13:28:34 < _Posterdati_> just removed __attribute__ ((packed))
2026-04-01T13:28:44 < _Posterdati_> now all writings is at 32 bit
2026-04-01T13:28:53 < _Posterdati_> thanks jpa-
2026-04-01T13:31:53 < jpa-> (otherwise i'd pester you more about how you need to make a SVD converter, but apparently ST has messed up again and the SVDs lack most of the RNG->CR bits...)
2026-04-01T13:33:00 < qyx> til pester
2026-04-01T13:33:41 < mawk> empestrer
2026-04-01T13:33:49 < mawk> it's from french, like all the good english words
2026-04-01T13:38:18 -!- nerozero [~nerozero@87.253.63.54] has quit [Remote host closed the connection]
2026-04-01T13:40:10 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2026-04-01T13:46:18 < Steffanx> My derriere.
2026-04-01T14:13:50 < _Posterdati_> jpa-: np, thanks again
2026-04-01T14:15:25 < _Posterdati_> jpa-: another question, should RNG enabled with RNGEN to write config?
2026-04-01T14:18:37 < jpa-> _Posterdati_: follow the sequence given in 39.3.5 RNG operation
2026-04-01T14:19:02 -!- akaWolf [~akaWolf@akawolf.org] has quit [Ping timeout: 265 seconds]
2026-04-01T14:22:13 < _Posterdati_> jpa-: thanks
2026-04-01T14:32:12 -!- akaWolf [~akaWolf@akawolf.org] has joined ##stm32
2026-04-01T14:36:36 -!- akaWolf [~akaWolf@akawolf.org] has quit [Ping timeout: 255 seconds]
2026-04-01T14:37:21 -!- akaWolf [~akaWolf@akawolf.org] has joined ##stm32
2026-04-01T15:28:32 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Ping timeout: 245 seconds]
2026-04-01T15:36:10 < karlp> Use the RES11A in an inverse
2026-04-01T15:36:12 < karlp> gain configuration by simply rotating the device
2026-04-01T15:36:14 < karlp> placement by 180°
2026-04-01T15:36:30 < karlp> who knew TI sold resistors?
2026-04-01T15:38:01 < jpa-> CMOS resistors :)
2026-04-01T15:38:44 < jpa-> rather low voltage though
2026-04-01T15:39:17 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2026-04-01T15:39:41 < machinehum> Hello stm32
2026-04-01T15:52:09 < Steffanx> Gooday sir hum
2026-04-01T15:52:41 < machinehum> Steffanx: Do you have some exploits to read firmware of a RDP level 1 STM32G0 device?
2026-04-01T15:53:01 < machinehum> Good day to you as well
2026-04-01T15:54:38 < jpa-> https://www.anvilsecure.com/blog/glitching-stm32-read-out-protection-with-voltage-fault-injection.html  i would expect bootloader glitching to work if it has not been permanently disabled
2026-04-01T15:55:00 -!- akaWolf [~akaWolf@akawolf.org] has quit [Ping timeout: 256 seconds]
2026-04-01T15:56:57 < jpa-> https://www.usenix.org/system/files/conference/woot17/woot17-paper-obermaier.pdf  one of these might work too
2026-04-01T16:02:28 < machinehum> Ahh, I read the g0 rm and it says something about a hardfault I figure it was patched in hardware. But I just read the f0 and it's the exact same language
2026-04-01T16:02:41 < machinehum> Cool that might work
2026-04-01T16:05:50 < karlp> Unfortunately using a single LDO for the supply is not always possible and it is now common to see engineers
2026-04-01T16:05:52 < karlp> place 5-10 LDO’s in parallel.
2026-04-01T16:05:55 < karlp> yess!
2026-04-01T16:25:24 < polprog> 30-50 LDOs in series
2026-04-01T16:26:18 < polprog> 30-50 feral LDOs
2026-04-01T17:19:36 -!- akaWolf [~akaWolf@akawolf.org] has joined ##stm32
2026-04-01T17:24:42 -!- akaWolf [~akaWolf@akawolf.org] has quit [Read error: Connection reset by peer]
2026-04-01T17:24:52 -!- akaWolf [~akaWolf@akawolf.org] has joined ##stm32
2026-04-01T17:29:03 -!- akaWolf [~akaWolf@akawolf.org] has quit [Ping timeout: 246 seconds]
2026-04-01T17:37:31 -!- akaWolf [~akaWolf@akawolf.org] has joined ##stm32
2026-04-01T18:43:07 < _Posterdati_> hi
2026-04-01T18:47:45 < _Posterdati_> please help, on stm32h723 I have a weird behaviour for RNG, after reading DR in IRQ routine, I've got SECS = SEIS = 1, after performing the recovery procedure in 39.3.7 it worked until I read DR again (in the next IRQ)...
2026-04-01T18:48:44 < _Posterdati_> Thanks 
2026-04-01T18:51:10 < zyp> you need to enable protection before you do SECS
2026-04-01T18:51:45 < _Posterdati_> CONFIGLOCK?
2026-04-01T18:52:09 < zyp> I'm just pulling your leg
2026-04-01T18:52:49 < _Posterdati_> zyp: protection not needed if you do SECS coming out
2026-04-01T18:53:30 < qyx> zyp: you mean the general core protection thing?
2026-04-01T18:53:39 < qyx> yeah may be the issue
2026-04-01T18:54:06 < _Posterdati_> or you may end to do SECS over the phone
2026-04-01T18:54:30 < zyp> but hmm, I recall poking at some RNG issue last year, but I forget the specifics
2026-04-01T18:54:44 < _Posterdati_> eh
2026-04-01T18:55:25 < zyp> those bit names sounds really familiar to me, but I can't recall what project this was related to
2026-04-01T19:00:42 < qyx> have you seen this without LEDs? https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcQHdKKUoa92hMedX1VVfcZhzS4GWbuHbsBM1A&s
2026-04-01T19:00:59 < qyx> https://media.rs-online.com/image/upload/bo_1.5px_solid_white,b_auto,c_pad,dpr_2,f_auto,h_399,q_auto,w_710/c_pad,h_399,w_710/F5460558-01?pgw=1
2026-04-01T19:01:19 < zyp> hmm, I think maybe the RNG issue I poked at was due to missing 48 MHz clock
2026-04-01T19:08:48 < _Posterdati_> ok
2026-04-01T19:49:47 < karlp> qyx: what do you mean without leds?
2026-04-01T19:50:00 < karlp> just four leads going nowhere in a plastic box?
2026-04-01T19:51:19 < qyx> to install my leds/combination
2026-04-01T19:51:31 < qyx> just the plastic part itself
2026-04-01T19:51:36 < qyx> I have found some but for single LEd only
2026-04-01T19:52:18 < qyx> I am considering getting it printed, eg. a 10x10 matrix of such parts connected by small tabs, to cut after printing
2026-04-01T19:54:39 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-01T20:30:52 < jpa-> what kind of special leds are you going to stick into it?
2026-04-01T20:42:29 < qyx> white and red
2026-04-01T20:46:18 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-01T20:46:38 < zyp> have you considered lightpipes and SMD LEDs?
2026-04-01T20:47:37 < jpa-> or a small TFT and use ugfx to put LED pictures on it?
2026-04-01T20:52:19 < qyx> yes usih lightpipes now, I don't like it
2026-04-01T20:52:43 < qyx> yes considered small tft :p
2026-04-01T21:14:23 -!- Livio [~livio@user/livio] has quit [Ping timeout: 265 seconds]
2026-04-01T21:14:55 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-01T21:29:00 -!- rajkosto [~rajkosto@2a00:e90:2139:3700:0:ff:fe00:10] has joined ##stm32
2026-04-01T21:59:49 -!- Livio [~livio@user/livio] has quit [Ping timeout: 265 seconds]
2026-04-01T22:02:04 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 265 seconds]
2026-04-01T22:32:02 -!- rgz [uid670983@user/rgz] has joined ##stm32
2026-04-01T22:33:31 < PhantomWork> Beside using a timer, is there a sane way to delay between the uart rx and tx? trying to debug an rs485 OOK issue... that went worse when I slowed it down...
2026-04-01T22:37:28 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-01T22:44:17 -!- Livio [~livio@user/livio] has quit [Ping timeout: 265 seconds]
2026-04-01T22:53:18 < karlp> https://bin.jvnv.net/file/kIbAY/img_thermal_1775072957819.jpg
2026-04-01T22:53:34 < karlp> that's parallel LDOs failing to be parallelled properly.
2026-04-01T22:54:05 < karlp> I guess they need more burden resistance to share load each,
2026-04-01T22:54:50 < karlp> found a cool kicad migration bug though
2026-04-01T22:54:58 < PhantomWork> or you get way too lazy and just rely on the thermal limiter to current limit itself
2026-04-01T22:55:15 < karlp> no, these parallel LDOs are trying to demonstrate Iq
2026-04-01T23:04:55 < qyx> oh ##stm32 mug heater!
2026-04-01T23:07:00 < PaulFertser> USB3813 3-Port USB 2.0 Hi-Speed Hub with additional SPI and GPIO so can do SWD right there on your board https://review.openocd.org/c/openocd/+/9554
2026-04-01T23:09:24 < karlp> cute!
2026-04-01T23:20:19 < srk> +
2026-04-01T23:20:21 -!- hexo [~hexo@user/hexo] has quit [Remote host closed the connection]
2026-04-01T23:34:28 -!- hexo [~hexo@user/hexo] has joined ##stm32
2026-04-01T23:58:54 < karlp> ok, do I make a new pcb with what, 30-50mohm ballasts and remake it?
--- Day changed Thu Apr 02 2026
2026-04-02T00:14:16 < karlp> those smsc hubs, I saw in a few things taht they almost certainly had extra commands for doing i2c/spi through them, but never found anythign else.
2026-04-02T00:14:29 < karlp> neat to see it got done properly eventually
2026-04-02T00:35:44 < qyx> I would say exposing swd over usb during device normal use is a pretty high security risk
2026-04-02T01:06:25 -!- fantanYl [~ventyl@adsl-dyn-83.95-102-77.t-com.sk] has quit [Ping timeout: 245 seconds]
2026-04-02T01:18:14 -!- fantanYl [~ventyl@adsl-dyn16.78-98-109.t-com.sk] has joined ##stm32
2026-04-02T01:19:38 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 244 seconds]
2026-04-02T01:47:08 < karlp> well, no kaboom
2026-04-02T01:47:20 < zyp> aww
2026-04-02T01:47:53 < zyp> what's up with parallel LDOs?
2026-04-02T01:56:28 < Phantom> I'm in the why team...
2026-04-02T02:00:36 < qyx> lm1117 mug heater
2026-04-02T02:00:47 < qyx> if I am not mistaken
2026-04-02T02:01:23 < qyx> to demonstrate coolnest of lm1117 in specific use cases
2026-04-02T02:02:28 -!- _Posterdati_ [~posterdat@user/Posterdati] has quit [Ping timeout: 256 seconds]
2026-04-02T02:09:17 -!- _Posterdati_ [~posterdat@user/Posterdati] has joined ##stm32
2026-04-02T02:16:41 -!- infisx [~infisc@user/infisc] has quit [Ping timeout: 252 seconds]
2026-04-02T02:16:59 -!- infisd [~infisc@user/infisc] has joined ##stm32
2026-04-02T02:17:38 -!- qyx [~qyx@84.245.120.31] has quit [Ping timeout: 248 seconds]
2026-04-02T02:19:21 -!- qyx [~qyx@84.245.120.129] has joined ##stm32
2026-04-02T02:26:01 -!- blathijs [~matthijs@tika.stderr.nl] has quit [Ping timeout: 248 seconds]
2026-04-02T03:02:42 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 246 seconds]
2026-04-02T03:06:26 -!- infisd [~infisc@user/infisc] has joined ##stm32
2026-04-02T03:38:36 -!- cutofmyjib [~cutofmyji@user/cutofmyjib] has quit [Quit: WeeChat 4.1.1]
2026-04-02T03:44:21 -!- rajkosto [~rajkosto@2a00:e90:2139:3700:0:ff:fe00:10] has quit [Ping timeout: 246 seconds]
2026-04-02T04:21:40 -!- rgz [uid670983@user/rgz] has quit [Quit: Connection closed for inactivity]
2026-04-02T08:14:22 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2026-04-02T09:24:17 -!- rajkosto [~rajkosto@2a00:e90:2139:3700:0:ff:fe00:10] has joined ##stm32
2026-04-02T09:30:39 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-02T09:44:51 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2026-04-02T10:13:21 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-02T10:47:20 < _Posterdati_> hi
2026-04-02T11:01:08 < Steffanx> lo
2026-04-02T11:16:19 -!- Livio [~livio@user/livio] has quit [Quit: leaving]
2026-04-02T11:50:03 < _Posterdati_> 0xaa
2026-04-02T12:02:57 -!- tomeaton17 [~tom@user/tomeaton17] has quit [Quit: ZNC 1.9.0+deb2ubuntu0.1~esm2 - https://znc.in]
2026-04-02T12:03:33 -!- tomeaton17 [~tom@user/tomeaton17] has joined ##stm32
2026-04-02T12:55:02 -!- Netsplit *.net <-> *.split quits: System_Error
2026-04-02T14:44:14 < PhantomWork> question guys... I have 2 boards talking to each others via RS485 OOK. B to A work fine, then A talk to B and I get 10% ORE on B. It use DMA. How can I get ORE when I physically checked with a scope and I receive only a 6 bytes packet when the DMA is 20 bytes???
2026-04-02T14:44:53 -!- rajkosto [~rajkosto@2a00:e90:2139:3700:0:ff:fe00:10] has quit [Ping timeout: 268 seconds]
2026-04-02T14:55:55 < jpa-> are the bytes that you get into the DMA buffer valid? does the DMA channel finish?
2026-04-02T14:56:50 < jpa-> it could be that you have some problem with DMA configuration and it is not triggering
2026-04-02T15:07:16 < PhantomWork> Basically, B is: B initially transmit via a timer using HAL_UART_Transmit_DMA.    then UART_TxCpltCallback immediately start the receiving via HAL_UARTEx_ReceiveToIdle_DMA     then HAL_UARTEx_RxEventCallback parse the received data and start a new transmission.    From now on the transmit is after a successfull receiving, or if it has failed the timer restart it.
2026-04-02T15:08:39 < PhantomWork> maybe I should bite the bullet and change my code for a bigger DMA circular buffer instead...
2026-04-02T15:08:57 < jpa-> 6 bytes is less than 20 bytes, so i bet the problem is something else
2026-04-02T15:08:57 < mercenary> Is that the comms-over-power thing?
2026-04-02T15:09:08 < jpa-> just use a debugger or printf and figure out what is going wrong
2026-04-02T15:09:53 < jpa-> check if the DMA has transferred anything (DMA->SNDTR), check the DMA receive buffer for what gets written into it etc.
2026-04-02T15:10:04 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2026-04-02T15:10:18 < jpa-> maybe you have some glitches that trigger extra bytes
2026-04-02T15:14:05 < PhantomWork> mercenary: yup
2026-04-02T15:21:23 < mercenary> what jpa- says then, glitches that the uart sees as extra and/or incomplete bytes
2026-04-02T15:35:52 < PhantomWork> yeah   scope don't seems to show glitch
2026-04-02T15:36:53 < PhantomWork> and the AI show conflicting info (aka DMA is interrupted by __disable_irq(), which shouln't be)
2026-04-02T15:40:01 < machinehum> zyp: I love my orbtrace
2026-04-02T15:55:07 < PhantomWork> interessing...
2026-04-02T15:55:57 < PhantomWork> I decided to put that aside and continue to code. This mean implement more data to be sent. Now B to A also have errors
2026-04-02T16:12:14 -!- blathijs [~matthijs@tika.stderr.nl] has joined ##stm32
2026-04-02T17:14:35 -!- rajkosto [~rajkosto@2a00:e90:2139:3700:0:ff:fe00:10] has joined ##stm32
2026-04-02T17:19:30 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2026-04-02T18:15:40 < PhantomWork> I need help. This function on board A get the total error to count up for EACH packet, but on board B ORE also increment... so different behavior for the same function... afaik there is no more condition, but obiviously there is since no counter beside the total increase... so what am I missing in that function?  
2026-04-02T18:33:12 < mercenary> If the functions are the same, and behave differently, the difference is in the environment. What else is running on A and B, and are both configured/initialized with the same settings?
2026-04-02T18:35:59 < PhantomWork> nm   found the error... I deleted a line elsewhere... that increased another counter..
2026-04-02T18:36:32 < PhantomWork> board A get CRC error... board B get ORE... yay . . . .
2026-04-02T18:43:18 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-02T18:45:15 < PhantomWork> yay B to A work now!     now to fix A to B somehow...
2026-04-02T20:09:28 -!- Livio [~livio@user/livio] has quit [Ping timeout: 265 seconds]
2026-04-02T20:37:17 < PhantomWork> ... somehow it take too much time to enable the rx after a tx... so that was the issue...
2026-04-02T20:41:37 < PhantomWork> there we go, 2400+ updates/sec !   V1 of this was iirc 12 updates/sec
2026-04-02T20:41:45 < PhantomWork> massive increase!
2026-04-02T20:48:25 -!- rajkosto [~rajkosto@2a00:e90:2139:3700:0:ff:fe00:10] has quit [Ping timeout: 248 seconds]
2026-04-02T20:59:11 < mercenary> nice. TX/RX switching with 485 has always been a pain
2026-04-02T21:11:34 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2026-04-02T21:21:50 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2026-04-02T21:29:33 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2026-04-02T21:30:00 -!- nerozero [~nerozero@87.253.63.54] has quit [Read error: Connection reset by peer]
2026-04-02T21:41:59 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Ping timeout: 245 seconds]
2026-04-02T22:14:43 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2026-04-02T22:21:10 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2026-04-02T23:05:43 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 264 seconds]
2026-04-02T23:38:10 < PhantomWork> fricking hell...   so, I made the transmission to go as fast as possible by removing the timer. pure ping pong. 2400 transmissions back and forth a second! Now, I issue an eeprom write and... the µC reboot... WDT trip...
2026-04-02T23:38:52 < PhantomWork> which is set to 2 seconds... I commented all but the HAL_Delay(1); and added a WDT reset... still trip!
2026-04-02T23:39:21 < PhantomWork> somehow... too many interrupts, the µC can't proprely fire the other interrupts?!?!?
2026-04-02T23:40:00 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2026-04-02T23:40:22 < PhantomWork> yet my cpu load indicator say 75% idle...  something is weird..
2026-04-02T23:49:01 < karlp> zyp: was just watching a ti training on "tips and advanced tricks with LDOs" and it brought up parallel LDOs for varioius reasons
2026-04-02T23:49:14 < karlp> dug out my heater board to look at why it probably hadn't worked as designed.
--- Day changed Fri Apr 03 2026
2026-04-03T00:16:54 < qyx> karlp: today I faced an interesting openwrt issue on an old router, there was a LTE modem with /tty/USB0-2 and configured as a "umts/3g" (that is, chat+pppd), the interface never goes up with "no network device"
2026-04-03T00:18:06 < qyx> but! doing uci set network.3g.device=/dev/ttyUSB1 & uci commit & ifup 3g and then again uci set network.3g.device=/dev/ttyUSB0 & uci commit & ifup 3g works flawlessly
2026-04-03T00:18:32 < qyx> yes all vommands are required in order to make it work
2026-04-03T00:18:38 < qyx> including double ifup 3g
2026-04-03T00:20:28 < qyx> I am starting to be pissed off by openwrt more than I am with systemd
2026-04-03T01:41:40 < karlp> I had all sorts of problems with 4g and openwrt.
2026-04-03T01:41:56 < karlp> all of their "NIH" things are "works on my machine" 
2026-04-03T01:42:05 < karlp> I just tossed it and installed modemmanager
2026-04-03T01:42:23 < karlp> the stuff that _everyone_ uses is fine,
2026-04-03T01:43:23 < karlp> uqmi for instance had (at least then) terrrrrible coverage for "not this handful of modems and handful of seervice providers"
2026-04-03T01:47:50 < qyx> hm I wondered why openwrt has modemmanager package
2026-04-03T01:52:39 < qyx> oh I just used RX/TX UART swap for the first time ever!
2026-04-03T01:57:55 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Ping timeout: 264 seconds]
2026-04-03T05:22:52 -!- jpka [~root@176.107.81.139] has quit [Ping timeout: 253 seconds]
2026-04-03T05:39:35 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2026-04-03T05:52:42 -!- catphish [~quassel@user/catphish] has quit [Quit: No Ping reply in 180 seconds.]
2026-04-03T05:54:08 -!- catphish [~quassel@user/catphish] has joined ##stm32
2026-04-03T05:56:51 -!- ferdna [~ferdna@user/ferdna] has quit [Ping timeout: 255 seconds]
2026-04-03T07:19:38 -!- rajkosto [~rajkosto@2a00:e90:2139:3700:0:ff:fe00:10] has joined ##stm32
2026-04-03T07:26:29 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2026-04-03T09:22:27 < antto> and fow does it heel?
2026-04-03T09:44:50 -!- infisc [uid692580@user/infisc] has joined ##stm32
2026-04-03T09:56:31 < qyx> hillarious
2026-04-03T10:50:06 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-03T11:32:42 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2026-04-03T11:33:49 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Read error: Connection reset by peer]
2026-04-03T11:50:36 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2026-04-03T11:54:32 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2026-04-03T13:34:50 -!- infisc [uid692580@user/infisc] has joined ##stm32
2026-04-03T15:16:36 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2026-04-03T15:24:02 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2026-04-03T15:43:53 -!- rajkosto [~rajkosto@2a00:e90:2139:3700:0:ff:fe00:10] has quit [Ping timeout: 248 seconds]
2026-04-03T15:44:32 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2026-04-03T16:24:22 -!- infisc [uid692580@user/infisc] has joined ##stm32
2026-04-03T17:14:38 -!- haritz [~hrtz@140.228.70.141] has joined ##stm32
2026-04-03T17:14:38 -!- haritz [~hrtz@user/haritz] has changed host
2026-04-03T18:05:20 -!- rajkosto [~rajkosto@2a00:e90:2139:3700:0:ff:fe00:10] has joined ##stm32
2026-04-03T18:34:32 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2026-04-03T18:40:32 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2026-04-03T19:00:19 -!- ferdna [~ferdna@user/ferdna] has quit [Ping timeout: 245 seconds]
2026-04-03T19:14:29 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2026-04-03T19:17:32 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Read error: Connection reset by peer]
2026-04-03T19:30:27 -!- ferdna [~ferdna@user/ferdna] has quit [Ping timeout: 255 seconds]
2026-04-03T19:33:04 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2026-04-03T19:33:06 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Remote host closed the connection]
2026-04-03T19:33:35 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2026-04-03T19:34:43 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Remote host closed the connection]
2026-04-03T19:35:03 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2026-04-03T19:57:34 < qyx> now pros, tell me, why my qspi no worky
2026-04-03T19:57:41 < qyx> I cannot even scope it, both are BGA
2026-04-03T19:58:38 < qyx> (the code worked a few years ago)
2026-04-03T19:58:46 < qyx> transfer complete flag is set, but no fifo threshold
2026-04-03T20:04:19 < Steffanx> Fico happened.
2026-04-03T20:04:25 < qyx> oh oh I forgot to set the prescaler and H7 is a bit too fast
2026-04-03T20:04:42 < qyx> did he do something?
2026-04-03T20:05:06 < Steffanx> Idk. But maybe. Who knows.
2026-04-03T20:07:39 < qyx> just checked the local news, you never know
2026-04-03T20:30:13 < Phantom> the good news is that the I2C bus isolator seems to work, the bad news is that the ADC behind gives me invalid data...
2026-04-03T20:31:31 < qyx> ADCs are precision monsters, you need some empathy talking to them
2026-04-03T20:32:15 < Phantom> yeah
2026-04-03T20:33:02 < Phantom> it is a 16 bits one, 3 out of 4 channels should basically read very close to 0, one should read something (didn't made the math yet)... all 4 channels read 32768
2026-04-03T20:33:22 < Phantom> so, definitely something is wrong :D
2026-04-03T20:34:32 < qyx> 32768 is very close to 0
2026-04-03T20:34:41 < qyx> especially if it is a 16bit ADC
2026-04-03T20:34:54 < qyx> you probably missed the chapter about 2's complement reults
2026-04-03T20:36:58 < qyx> my QSPI now reads all zeroes
2026-04-03T20:37:30 < Phantom> even if it was reading 0, it should vary
2026-04-03T20:37:33 < Phantom> have noise
2026-04-03T20:43:46 < Phantom> 2 opamps are after an opamp, one is after a digipot, and one is on a digipot to a vref...  
2026-04-03T20:43:56 < Phantom> so should have atleast a few count of noise
2026-04-03T20:45:09 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 255 seconds]
2026-04-03T20:46:29 < catphish>  my CH569 works perfectly except that just occasionally, sending a packet on my EP1 (SPI) endpoint while receiving a stream on my EP2 (HSPI) endpoint corrupts the EP2 state, not sure if this is my bug, or bvernoux's bug, or an underlying silicon bug
2026-04-03T21:00:46 < mercenary> yes
2026-04-03T21:01:27 < mercenary> can you sync the 'sending of EP1 packet' to a point in the stream plus a configurable delay?
2026-04-03T21:03:12 < catphish> the EP1 packet just happens at an arbitrary time when the user issues a command
2026-04-03T21:03:21 < catphish> meanwhile, EP2 is constantly streaming
2026-04-03T21:03:55 < catphish> just very occasionally sending the EP1 packet causes EP2 to start responding in an invalid manner that causes all its packets to be rejected by linux
2026-04-03T21:04:13 < catphish> the two are supposed to be independent
2026-04-03T21:06:25 < mercenary> for test, syncing the two could point to 'if one side sends exactly at the same time the other side starts sending the next packet, chaos ensues'. If you can pin it down to something like that, you can either avoid it as a workaround, or it gives some indication as where to start looking.
2026-04-03T21:10:33 < catphish> to be honest, the data rate is so fast, i'm not sure i could meaningfully synchronize them, but my suspicion is that the problem is probably a bug in bvernoux's interrupt handler, and probably occurs when two endpoints are both simultaneously waiting on the SS interrupt
2026-04-03T21:10:47 < catphish> that's a lot of speculation, but if it's not that, then the silicon is broken
2026-04-03T21:14:24 < mercenary> hmm. software bugs happen, and can be fixed. broken CH silicon? also happens, and is less easy to fix
2026-04-03T21:19:08 < catphish> sending a packet on one endpoint while streaming another seems fundamental, so hopefully it's just my mistake, or bentamin's
2026-04-03T21:36:59 < catphish> *benjamin
2026-04-03T21:49:42 < catphish> why can't wch just provide the source code, or the reference manual :'(
2026-04-03T22:08:53 -!- srk [~sorki@user/srk] has quit [Ping timeout: 244 seconds]
2026-04-03T22:12:57 -!- srk [~sorki@user/srk] has joined ##stm32
2026-04-03T23:34:04 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 245 seconds]
2026-04-03T23:35:11 < qyx> Phantom: sorry 2's complement 32768 is minus minimum, not zero
2026-04-03T23:35:30 < Phantom> I found one big issue
2026-04-03T23:35:51 < Phantom> data[0] instead of data[1]     
2026-04-03T23:37:49 < Phantom>  Ch1: 50659  Ch2: 54755  Ch3: 58851  Ch4: 62947   <=== kinda better... but not... still no noise, and values too high... but hey, different values!
2026-04-03T23:57:57 -!- rajkosto [~rajkosto@2a00:e90:2139:3700:0:ff:fe00:10] has quit [Ping timeout: 268 seconds]
--- Day changed Sat Apr 04 2026
2026-04-04T01:00:00 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 246 seconds]
2026-04-04T01:56:34 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2026-04-04T02:17:24 -!- qyx [~qyx@84.245.120.129] has quit [Ping timeout: 244 seconds]
2026-04-04T02:19:28 -!- qyx [~qyx@84.245.121.223] has joined ##stm32
2026-04-04T03:50:29 < Phantom> yay 19981 +/- 1 count!     but the 3 other channels are stuck at 32767, no noise...
2026-04-04T03:52:09 -!- jbo [~jbo@user/tct] has quit [Excess Flood]
2026-04-04T03:52:43 -!- jbo [~jbo@user/tct] has joined ##stm32
2026-04-04T04:37:32 < Phantom> qyx: reading back the documentation, it does have negative voltage readout capability, so it return an int instead of an uint, so you were right on that
2026-04-04T05:59:31 -!- jbo [~jbo@user/tct] has quit [Read error: Connection reset by peer]
2026-04-04T05:59:37 -!- jbo_ [~jbo@user/tct] has joined ##stm32
2026-04-04T07:23:58 -!- rajkosto [~rajkosto@2a00:e90:2139:3700:0:ff:fe00:10] has joined ##stm32
2026-04-04T07:25:04 < Phantom> and the data is fine! the channel 2 I forgot I have an inverter on the signal, so it don't idle at 0V but 5V  :D
2026-04-04T07:36:00 -!- jbo_ [~jbo@user/tct] has quit [Read error: Connection reset by peer]
2026-04-04T07:36:06 -!- jbo [~jbo@user/tct] has joined ##stm32
2026-04-04T07:53:25 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2026-04-04T08:41:21 -!- haritz [~hrtz@user/haritz] has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
2026-04-04T08:44:57 -!- jbo_ [~jbo@user/tct] has joined ##stm32
2026-04-04T08:45:14 -!- jbo [~jbo@user/tct] has quit [Read error: Connection reset by peer]
2026-04-04T09:14:28 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-04T11:33:24 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-04T11:40:13 -!- Livio [~livio@user/livio] has quit [Ping timeout: 265 seconds]
2026-04-04T13:41:15 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2026-04-04T13:42:30 -!- rajkosto [~rajkosto@2a00:e90:2139:3700:0:ff:fe00:10] has quit [Ping timeout: 244 seconds]
2026-04-04T16:07:12 -!- jbo_ is now known as jbo
2026-04-04T17:33:41 -!- jpka [~root@176.107.81.139] has joined ##stm32
2026-04-04T17:43:30 -!- Sadale_ [~Sadale@user/sadale] has joined ##stm32
2026-04-04T17:46:22 -!- Sadale [~Sadale@user/sadale] has quit [Ping timeout: 276 seconds]
2026-04-04T18:07:10 -!- rajkosto [~rajkosto@2a00:e90:2139:3700:0:ff:fe00:10] has joined ##stm32
2026-04-04T18:14:42 -!- Sadale_ is now known as Sadale
2026-04-04T18:16:42 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 246 seconds]
2026-04-04T18:19:36 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2026-04-04T18:28:31 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 264 seconds]
2026-04-04T18:30:34 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2026-04-04T18:39:30 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 248 seconds]
2026-04-04T18:41:32 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2026-04-04T18:50:24 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 255 seconds]
2026-04-04T18:52:39 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2026-04-04T19:01:31 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 264 seconds]
2026-04-04T19:04:44 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2026-04-04T19:12:56 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 265 seconds]
2026-04-04T19:14:30 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2026-04-04T19:23:34 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 265 seconds]
2026-04-04T19:25:51 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2026-04-04T19:34:53 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 252 seconds]
2026-04-04T19:36:36 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2026-04-04T19:45:55 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 264 seconds]
2026-04-04T19:48:26 -!- Sadale_ [~Sadale@user/sadale] has joined ##stm32
2026-04-04T19:49:17 -!- Sadale [~Sadale@user/sadale] has quit [Killed (NickServ (GHOST command used by Sadale_))]
2026-04-04T19:49:21 -!- Sadale_ is now known as Sadale
2026-04-04T19:54:30 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2026-04-04T20:02:15 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 245 seconds]
2026-04-04T20:13:50 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2026-04-04T20:28:12 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 268 seconds]
2026-04-04T20:36:24 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2026-04-04T20:42:55 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 264 seconds]
2026-04-04T20:44:34 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2026-04-04T21:38:10 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 248 seconds]
2026-04-04T22:06:58 -!- srk [~sorki@user/srk] has quit [Ping timeout: 248 seconds]
2026-04-04T22:22:18 -!- rajkosto [~rajkosto@2a00:e90:2139:3700:0:ff:fe00:10] has quit [Ping timeout: 256 seconds]
2026-04-04T22:57:07 -!- srk [~sorki@user/srk] has joined ##stm32
2026-04-04T23:09:55 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 264 seconds]
2026-04-04T23:40:58 -!- NoSpark [~quassel@2401:c080:2000:1c51:5400:4ff:fe84:5bdd] has quit [Quit: No Ping reply in 180 seconds.]
2026-04-04T23:44:35 -!- NoSpark [~quassel@2401:c080:2000:1c51:5400:4ff:fe84:5bdd] has joined ##stm32
--- Day changed Sun Apr 05 2026
2026-04-05T02:19:54 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2026-04-05T02:54:38 < karlp> fuckin hell cors is a trainwreck
2026-04-05T03:26:59 < karlp> issue since 2017: https://github.com/nextcloud/server/issues/3131
2026-04-05T07:01:05 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-05T07:39:40 < qyx> are they
2026-04-05T08:20:12 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2026-04-05T09:14:53 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-05T10:12:10 -!- PhantomWork [~PhantomWo@user/phantom] has quit [Ping timeout: 244 seconds]
2026-04-05T11:47:12 < Steffanx> Lol
2026-04-05T12:53:56 < qyx> oh I read "cars"
2026-04-05T13:11:23 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2026-04-05T14:37:00 -!- jpka [~root@176.107.81.139] has quit [Ping timeout: 263 seconds]
2026-04-05T14:37:30 -!- jpka [~root@176.107.81.139] has joined ##stm32
2026-04-05T15:28:11 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 268 seconds]
2026-04-05T17:05:35 -!- quinor [08c0f10716@2a03:6000:1812:100::dad] has quit [Remote host closed the connection]
2026-04-05T17:05:35 -!- jhalmen [373aef909d@sourcehut/user/slowjo] has quit [Remote host closed the connection]
2026-04-05T17:06:28 -!- jhalmen [373aef909d@sourcehut/user/slowjo] has joined ##stm32
2026-04-05T17:06:32 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-05T17:12:01 -!- quinor [08c0f10716@2a03:6000:1812:100::dad] has joined ##stm32
2026-04-05T19:39:46 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2026-04-05T22:03:14 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 248 seconds]
2026-04-05T22:03:34 -!- nerozero [~nerozero@87.253.63.54] has quit [Remote host closed the connection]
2026-04-05T22:05:57 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2026-04-05T22:24:28 < catphish> karlp: are you the same karlp that's in the WCH (CH569) discord?
2026-04-05T22:33:04 < zyp> there's only one karlp
2026-04-05T22:40:01 < catphish> i'm not having a great time with the CH569, I'm increasingly convincing myself that an issue i'm having with the USB superspeed is a hardware bug, but i really hope it's not
2026-04-05T22:40:26 < zyp> fun
2026-04-05T22:41:14 < zyp> I still think staying away from ch569 was probably a good idea
2026-04-05T22:41:42 < catphish> well it's a good idea if it's broken, which i am coming to believe it is
2026-04-05T22:58:18 < catphish> zyp: sadly there really aren't all that many other choices
2026-04-05T22:58:47 < zyp> have you looked at the fx3g2 family?
2026-04-05T22:58:54 < zyp> i.e. fx5/10/10
2026-04-05T23:02:00 < catphish> i haven't looked at FX5. i looked at the FX3 and was a little horrified by the proprietary SDK/IDE/blobs
2026-04-05T23:02:13 < catphish> but tbh i'm running out of option
2026-04-05T23:02:57 < zyp> yeah, I've poked a bit at fx20, and is not a fan of the SDK
2026-04-05T23:03:04 < catphish> i was also trying to avoid BGA, and all the infineon stuff is BGA
2026-04-05T23:03:13 < catphish> but that may not really matter
2026-04-05T23:03:20 < zyp> that's less of a concern for me
2026-04-05T23:03:30 < zyp> most fpgas are bga too
2026-04-05T23:03:55 < catphish> yeah, if i loosen that requirement it opens up some additional options
2026-04-05T23:04:29 < catphish> my current stack of MachXO2 and CH569 are QFP/QFN though, which i rather liked
2026-04-05T23:04:48 < catphish> not that i can solder them myself either way, the benefit is just low cost PCB/assembly
2026-04-05T23:05:37 < zyp> yeah, only disadvantage with bga is that you need dual sided assembly to do bottom side decoupling
2026-04-05T23:06:28 < zyp> not an issue in volume, but it adds like $40-50 NRE when you're doing prototypes
2026-04-05T23:09:49 < catphish> yeah, bottom side decoupling, plus via in hole
2026-04-05T23:10:05 < catphish> both add a nontrivial amount to prototype pricing
2026-04-05T23:10:20 < zyp> via in pad? you don't need that
2026-04-05T23:10:33 < catphish> no? i assumed that was essential for BGA
2026-04-05T23:11:41 < catphish> the FX3 CYUSB3014-BZXC is reasonably priced, and interestingly, if i use that, i might not actually need an FPGA at all
2026-04-05T23:11:57 < zyp> for smaller pitch stuff maybe, but for regular stuff you can just do a normal dogbone fanout
2026-04-05T23:11:58 < catphish> since it has (i believe) a very flexible IO system
2026-04-05T23:12:25 < zyp> i.e. you put the vias between the pads
2026-04-05T23:13:00 < catphish> oh that may be possible if there's space
2026-04-05T23:13:33 < zyp> by the way, if you want to do cheap prototypes with via in pad, just design for the 6L special offer, 6L includes ENIG and via-in-pad by default, and the special offer is $2
2026-04-05T23:13:55 < catphish> this is interesting, JLC say they can do CYUSB3014 on economic (ie single sided) assembly, so could risk decoupling on top
2026-04-05T23:14:49 < zyp> if you want a FX3 logic analyzer, just get one from aliexpress or something?
2026-04-05T23:15:31 < catphish> ooo https://github.com/zeldin/fx3lafw
2026-04-05T23:15:44 < zyp> yeah, that's common shit
2026-04-05T23:16:18 < catphish> interesting, i've not seen any actual finished boards
2026-04-05T23:16:23 < catphish> but i would assume they should exist
2026-04-05T23:17:00 < zyp> first hit on a quick ali search: https://www.aliexpress.com/item/1005007261225859.html
2026-04-05T23:17:50 < catphish> interesting, that's very broadly what i was trying to build
2026-04-05T23:17:57 < catphish> though i was going 32 channels
2026-04-05T23:19:16 -!- jpka [~root@176.107.81.139] has quit [Read error: Connection reset by peer]
2026-04-05T23:19:17 -!- jpka_ [~root@176.107.81.139] has joined ##stm32
2026-04-05T23:20:00 < zyp> the sipeed slogic thing looks kinda interesting, unless I misremember it's based on a gowin fpga with a usb3 softcore
2026-04-05T23:20:15 < zyp> although I might misremember
2026-04-05T23:20:50 < zyp> nope
2026-04-05T23:20:51 < zyp> https://www.whid.ninja/blog/teardown-review-sipeeds-slogic-16u3-an-affordable-logic-analyzer-for-any-wallet
2026-04-05T23:23:10 < zyp> the whole gw5a fpga family seems interesting, AIUI work is ongoing to support it in nextpnr
2026-04-05T23:25:56 -!- jpka_ is now known as jpka
2026-04-05T23:33:11 < catphish> the USB is in the FPGA?
2026-04-05T23:33:49 < catphish> that's rather cool
2026-04-05T23:34:37 < zyp> yeah
2026-04-05T23:35:05 < zyp> physically usb3 is rather similar to pcie
2026-04-05T23:36:28 < zyp> so a fpga with transceivers that can do pcie gen2, can also be persuaded to do usb3, unless the transceivers are married to a hard pcie core
2026-04-05T23:36:31 < catphish> yeah, thunderscope went down this path and ended up using thunderbolt
2026-04-05T23:36:57 < zyp> thunderscope doesn't do usb, it's pcie
2026-04-05T23:37:29 < catphish> it's thunderbolt, doesn't that mean it's both
2026-04-05T23:37:44 < catphish> PCIe over USB C?
2026-04-05T23:38:06 < catphish> in any case, that's definitely the cooler option!
2026-04-05T23:38:08 < zyp> yes, but the thunderscope is a pcie device, hooked to a thunderbolt to pcie adapter
2026-04-05T23:38:28 < catphish> oh yeah, i did see they were using an adapter, is that still the case?
2026-04-05T23:38:57 < zyp> I haven't been following, but I'm not aware of it changing
2026-04-05T23:39:15 < zyp> I think the thunderbolt chips are unobtanium for low volume applications
2026-04-05T23:40:04 < zyp> speaking of thunderbolt, I should do some testing of my pcie stuff over thunderbolt
2026-04-05T23:41:15 < zyp> only issue is that my only thunderbolt hosts are macos, and I don't think macos has userspace APIs for arbitrary pcie access
2026-04-05T23:41:19 < zyp> like vfio on linux
2026-04-05T23:41:41 < zyp> speaking of, I did this today: https://paste.jvnv.net/view/bkoGG
2026-04-05T23:45:14 < catphish> i've never played with PCIe
2026-04-05T23:46:33 < zyp> litepcie normally relies on vendor IP for the lower layers of the stack, but that's not available for the ecp5 without paying $$$ and using the vendor toolchain
2026-04-05T23:47:03 < zyp> but I've implemented my own stack, and today I tried integrating litepcie on top :)
2026-04-05T23:47:35 < catphish> nice
2026-04-05T23:54:16 < catphish> i need to start learning how I2S works, i likely need to build a USB DAC soon, hopefully STM32 will do the job nicely
2026-04-05T23:55:44 < zyp> not much to learn, it's pretty much just continous SPI with some synchronization
2026-04-05T23:57:19 < catphish> marvellous, i'm working under the assumption it won't be too hard, same with the USB part, i've never done USB audio before, but i assume it's pretty much just passing through PCM data
2026-04-05T23:57:26 < zyp> i.e. you have the usual bit clock, and data signal, and then instead of chip select there's another signal that toggles for every sample, so it marks the word boundaries and also indicates whether it's a left or right channel sample
2026-04-05T23:57:52 < catphish> that sounds simple enough
2026-04-05T23:58:06 < zyp> and then there's often also a master-clock that's like 256x the bitclock or something like that, to run the codec chip synchronous with the data rate
2026-04-05T23:58:36 < zyp> USB audio is so-so
2026-04-05T23:58:53 < zyp> the datapath is just an isochronous endpoint passing blocks of data at a fixed rate
2026-04-05T23:59:07 < catphish> i guess there's some care to be taken with bitrates, bit depths, and the like
2026-04-05T23:59:30 < catphish> i'll go read the spec at some point
2026-04-05T23:59:32 < zyp> and then there's some descriptor stuff, AIUI UAC2 added a bunch of flexibility that needs a ton of descriptors to set up
2026-04-05T23:59:44 < zyp> I've only done UAC1 like a decade and a half ago
2026-04-05T23:59:58 < catphish> descriptors seem like a good idea for this, so i can tell the PC what i want
--- Day changed Mon Apr 06 2026
2026-04-06T00:00:00 < zyp> the hard point is synchronization
2026-04-06T00:00:25 < zyp> i.e. ensuring data is flowing in on USB at the same rate as it's flowing out on I2S
2026-04-06T00:00:54 < catphish> makes sense, need to manage a ring buffer i imagine
2026-04-06T00:01:13 < catphish> though if it's isochronous, that may be less painful
2026-04-06T00:01:19 < catphish> except for missing samples
2026-04-06T00:01:21 < zyp> not only that, you need it to fill and drain at the same rate
2026-04-06T00:01:41 < catphish> well that's what i meant about care with bitrates
2026-04-06T00:02:14 < zyp> here's my UAC + I2S experiment on the f4 discovery, from 2012 :) https://cgit.jvnv.net/laks_demo/tree/main.cpp
2026-04-06T00:02:26 < catphish> this is helpful because i need to work out how much to charge for such a work :)
2026-04-06T00:02:31 < zyp> it's not about bitrates, it's about synchronization
2026-04-06T00:03:02 < zyp> if you have two independent clock sources, they won't run at the exact same rate
2026-04-06T00:03:44 < catphish> i was assuming that with a sufficient buffer, the difference would be negligable enough not to underrun / overrun
2026-04-06T00:04:43 < zyp> IIRC in my case, the divisors for the I2S clock couldn't do the exact bitrate
2026-04-06T00:04:59 < catphish> ie if i tell the PC i want samples at 192KHz, i can assume that will at least somewhat match my crystal's bitrate
2026-04-06T00:05:23 < catphish> i suppose i should probably choose a crystal with my I2S clock rates in mind
2026-04-06T00:05:35 < zyp> and with a 1024-sample buffer, it does a 360 degree phase shift every few minutes or so
2026-04-06T00:06:44 < zyp> i.e. every few minutes you get a period with audio artifacts because the usb handler are writing new blocks into the area where the I2S is actively reading
2026-04-06T00:07:15 < zyp> if you have a f4 discovery, you could check out that repo, build it and try it :)
2026-04-06T00:07:45 < catphish> i suspect i'll do what i always do these days and go hardware-first
2026-04-06T00:08:07 < catphish> choose an STM32 and a DAC chip, build a board, and worry about the software details after
2026-04-06T00:08:14 < zyp> I wouldn't :)
2026-04-06T00:08:44 < catphish> does the F4 discovery have a I2S DAC on it?
2026-04-06T00:08:47 < zyp> prototype it on a devboard first, that way you'll discover the hardware limitations you don't want to repeat on your own board
2026-04-06T00:08:54 < zyp> yes, many of the discovery boards do
2026-04-06T00:09:01 < catphish> that's useful
2026-04-06T00:09:26 < catphish> if there's a board with all the hardware i need then i will indeed more likely start there
2026-04-06T00:09:55 < catphish> usually my requirements are too obscure for that, but it might work for this project
2026-04-06T00:11:58 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 268 seconds]
2026-04-06T00:38:17 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 248 seconds]
2026-04-06T01:05:05 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Ping timeout: 272 seconds]
2026-04-06T02:00:01 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2026-04-06T02:17:43 -!- qyx [~qyx@84.245.121.223] has quit [Ping timeout: 264 seconds]
2026-04-06T02:19:31 -!- qyx [~qyx@84.245.120.63] has joined ##stm32
2026-04-06T04:25:25 -!- haritz [~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8] has joined ##stm32
2026-04-06T04:25:25 -!- haritz [~hrtz@user/haritz] has changed host
2026-04-06T07:30:15 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2026-04-06T07:55:08 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-06T07:57:16 -!- haritz [~hrtz@user/haritz] has quit [Ping timeout: 244 seconds]
2026-04-06T07:57:42 -!- haritz [~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8] has joined ##stm32
2026-04-06T07:57:43 -!- haritz [~hrtz@user/haritz] has changed host
2026-04-06T08:10:25 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2026-04-06T08:24:26 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-06T09:15:31 -!- haritz [~hrtz@user/haritz] has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
2026-04-06T10:05:06 -!- jbo [~jbo@user/tct] has quit [Read error: Connection reset by peer]
2026-04-06T10:05:16 -!- jbo_ [~jbo@user/tct] has joined ##stm32
2026-04-06T11:55:50 -!- jbo_ is now known as jbo
2026-04-06T12:33:56 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2026-04-06T13:24:43 < karlp> catphish: like zyp says, yes :) 
2026-04-06T13:46:02 < karlp> (I have nothing to contribute to your wch concerns, I did some work with them a long time ago, nothing in anger, and only got angry at their continued lack of desire to help their community)
2026-04-06T13:49:07 < karlp> I have a ch584 board on the way  back right now, abused myself into thinking I should give them another go...
2026-04-06T15:14:23 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:152a:64f6:40a4:5cac] has quit [Remote host closed the connection]
2026-04-06T15:15:17 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:152a:64f6:40a4:5cac] has joined ##stm32
2026-04-06T15:16:37 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 268 seconds]
2026-04-06T15:16:59 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:152a:64f6:40a4:5cac] has quit [Remote host closed the connection]
2026-04-06T15:17:49 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:152a:64f6:40a4:5cac] has joined ##stm32
2026-04-06T15:55:16 -!- duude__- [~duude__@user/duude/x-4676560] has joined ##stm32
2026-04-06T15:56:00 -!- duude__ [~duude__@user/duude/x-4676560] has quit [Ping timeout: 245 seconds]
2026-04-06T15:59:36 -!- duude__- is now known as duude__
2026-04-06T16:13:45 -!- goodvibrations32 [~user@user/goodvibrations32] has quit [Ping timeout: 248 seconds]
2026-04-06T16:15:38 -!- jbo_ [~jbo@user/tct] has joined ##stm32
2026-04-06T16:16:19 -!- jbo [~jbo@user/tct] has quit [Read error: Connection reset by peer]
2026-04-06T16:38:38 -!- jbo [~jbo@user/tct] has joined ##stm32
2026-04-06T16:38:46 -!- jbo_ [~jbo@user/tct] has quit [Read error: Connection reset by peer]
2026-04-06T16:49:01 -!- goodvibrations32 [~user@user/goodvibrations32] has joined ##stm32
2026-04-06T19:34:08 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-06T20:28:16 < karlp> godfdamn cors again
2026-04-06T20:32:42 < catphish> karlp: thanks, my experience of the CH569 has really been quite poor in terms of random unexpected behaviour to the point that i don't think i can trust it
2026-04-06T20:33:52 < catphish> it could be my own fault, but without proper documentation, there's no way to know, and i don't feel like trying to use their mystery blob
2026-04-06T20:34:25 < catphish> if i want to go the mystery blob route in future, i'll probably switch to infineon
2026-04-06T20:35:49 < qyx> infilol
2026-04-06T20:35:56 < qyx> actually I am starting to like infineon
2026-04-06T20:36:15 < qyx> they have some pretty good parts beating TI
2026-04-06T20:36:19 < catphish> there's also CH32H417 - if i wanted to subject myself again
2026-04-06T20:38:09 < catphish> this is interesting, the CH32H417 has real open source USB SS driver
2026-04-06T20:39:11 < catphish> it also has actual USB SS documentation in its reference manual!
2026-04-06T20:43:09 < catphish> maybe i am tempted to try again :)
2026-04-06T20:50:07 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Ping timeout: 264 seconds]
2026-04-06T20:52:03 < catphish> ah yes, this chip's high speed parallel interface is a mystery "UHSIF"
2026-04-06T20:52:06 < catphish> with no documentation
2026-04-06T20:57:28 < catphish> i'm going to buy this chip though, because i want to try something :)
2026-04-06T22:43:03 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 255 seconds]
2026-04-06T22:47:21 < Posterdati> hi
2026-04-06T22:47:24 < Posterdati> please help
2026-04-06T22:47:29 < Posterdati> how can I generate with the inline assembler the armv7e-m instruction vmov.f32 s0, #value ??? Thanks!
2026-04-06T22:52:30 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 255 seconds]
2026-04-06T23:40:32 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 252 seconds]
--- Day changed Tue Apr 07 2026
2026-04-07T00:33:13 < karlp> god fucking css now.
2026-04-07T00:33:17 < karlp> I hate this so much sometimes.
2026-04-07T00:55:54 < fantanYl> actually, it is probably less messy than it used to be
2026-04-07T00:56:13 < fantanYl> back in the day you had to cascade a bunch of divs to make something like round corner
2026-04-07T00:56:22 < fantanYl> now you can handle this completely within CSS
2026-04-07T01:00:22 < Phantom> so, tomorrow I need to find like the 3-4 pages out of the like 100few pages that are usefull for that i2c digipot...
2026-04-07T01:00:58 < Phantom> more info is better than not enough, but this is getting ridiculous
2026-04-07T01:14:29 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2026-04-07T01:34:21 -!- _Posterdati_ [~posterdat@user/Posterdati] has quit [Ping timeout: 246 seconds]
2026-04-07T01:39:45 < karlp> useful in what regard?
2026-04-07T01:41:23 < Phantom> like the actual commands needed
2026-04-07T01:41:30 < Phantom> and order of commands
2026-04-07T01:41:53 < Phantom> like that ADC is 57 pages, 3 of those is what is needed to use it
2026-04-07T01:49:01 -!- _Posterdati_ [~posterdat@user/Posterdati] has joined ##stm32
2026-04-07T01:51:37 -!- c10ud_ [~c10ud@host-95-237-126-207.retail.telecomitalia.it] has joined ##stm32
2026-04-07T01:54:55 -!- c10ud [~c10ud@user/c10ud] has quit [Ping timeout: 264 seconds]
2026-04-07T01:58:00 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2026-04-07T02:05:27 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2026-04-07T03:23:14 -!- c10ud_ [~c10ud@host-95-237-126-207.retail.telecomitalia.it] has quit [Read error: Connection reset by peer]
2026-04-07T03:23:37 -!- c10ud_ [~c10ud@host-95-237-126-207.retail.telecomitalia.it] has joined ##stm32
2026-04-07T03:27:51 < qyx> saying that only 3 pages out of 57 is enough to use an adc is a gross misunderstanding
2026-04-07T05:59:40 < Phantom> qyx: true, it was about 6 pages...  page 20 for the I2C address, page 24-27 is the I2C registers, page 32 gives an example on how to use it.
2026-04-07T06:00:48 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2026-04-07T06:08:17 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2026-04-07T06:15:04 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2026-04-07T06:20:56 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2026-04-07T07:03:56 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2026-04-07T07:10:46 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2026-04-07T07:30:27 -!- mtoy [~mtoy@user/mtoy] has quit [Ping timeout: 255 seconds]
2026-04-07T07:36:11 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2026-04-07T07:38:39 -!- mtoy [~mtoy@user/mtoy] has joined ##stm32
2026-04-07T07:43:01 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2026-04-07T07:46:02 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2026-04-07T07:51:53 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2026-04-07T07:53:40 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2026-04-07T08:35:33 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-07T08:49:30 < jpa-> Phantom: that's why a table of contents was invented :)
2026-04-07T10:27:20 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 252 seconds]
2026-04-07T10:50:29 -!- fengdaolong [~fengdaolo@171.83.77.161] has joined ##stm32
2026-04-07T10:51:25 -!- fengdaolong [~fengdaolo@171.83.77.161] has quit [Client Quit]
2026-04-07T10:51:38 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-07T11:18:39 -!- grindhold [~quassel@mail.skarphed.org] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
2026-04-07T12:49:52 -!- jpka [~root@176.107.81.139] has quit [Read error: Connection reset by peer]
2026-04-07T12:50:47 -!- jpka [~root@176.107.81.139] has joined ##stm32
2026-04-07T13:47:21 < Phantom> jpa-: yeah, but the TOC is not well made
2026-04-07T13:50:06 -!- sugarbeet [~barbas@81.4.123.134] has quit [Ping timeout: 265 seconds]
2026-04-07T14:00:50 -!- sugarbeet [~barbas@81.4.123.134] has joined ##stm32
2026-04-07T14:05:17 < jpa-> yeah, that sucks
2026-04-07T14:05:59 -!- vampirefrog [~vampirefr@5.12.7.155] has quit [Read error: Connection reset by peer]
2026-04-07T14:06:56 -!- vampirefrog [~vampirefr@5.12.7.155] has joined ##stm32
2026-04-07T14:16:49 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:152a:64f6:40a4:5cac] has quit [Read error: Connection reset by peer]
2026-04-07T14:55:53 -!- haritz [~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8] has joined ##stm32
2026-04-07T14:55:53 -!- haritz [~hrtz@user/haritz] has changed host
2026-04-07T16:03:56 -!- jpka [~root@176.107.81.139] has quit [Remote host closed the connection]
2026-04-07T16:04:53 -!- jpka [~root@176.107.81.139] has joined ##stm32
2026-04-07T16:21:21  * karlp glares at infineon
2026-04-07T16:54:33 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 244 seconds]
2026-04-07T17:35:45 < karlp> when you have a debug only variable, like this: https://paste.jvnv.net/view/PIjA4
2026-04-07T17:35:47 < karlp> what'
2026-04-07T17:35:57 < karlp> s t "best" way of makign the warnings on set but unused go away?
2026-04-07T17:36:38 < karlp> it feels dirty to just (void) it out 100% of the time, checking what the macro does sounds gross too...
2026-04-07T17:42:47 < zyp> so the issue is that the macro is an empty define when building without debug?
2026-04-07T17:43:48 < karlp> yeah
2026-04-07T17:44:11 < zyp> sounds like the alternate define should also «use» the variable somehow
2026-04-07T17:44:15 < karlp> becomes        #define FreeRTOS_printf( MSG )    do {} while( ipFALSE_BOOL )
2026-04-07T17:44:42 < karlp> not sure how to use each item inside the variables though?
2026-04-07T17:44:49 < karlp> hrm, i can try (void)(MSG) perhaps.
2026-04-07T17:45:33 < mercenary> don't use the extra variable :p
2026-04-07T17:45:35 < karlp> nah, it hates that, the vargs on the innter printf get uspet 
2026-04-07T17:45:54 < karlp> "left hand of comma has no effect" blhe
2026-04-07T17:47:50 < karlp> [[maybe_unused]]
2026-04-07T17:47:59 < karlp> fucking fine, that's just the same as (void) all the time.
2026-04-07T17:48:57 < mercenary> hmm, replacing the &ulAddress in the printf with FreeRTOS_GetIPAddress() should work, as long as it has the right prototype
2026-04-07T17:49:38 < mercenary> (and if not, there's a cast for that)
2026-04-07T17:49:39 < karlp> it might on _this_ particular variable, but it doesn't work in general for this problem...
2026-04-07T17:54:13 < mercenary> the generic problem of "the compiler complains about unused variables if I #define away the one spot where it is used" can always be fixed by using whatever gets assigned to that variable in that one spot
2026-04-07T17:55:03 < mercenary> the optimizer does things like that by itself
2026-04-07T17:56:24 < karlp> that's like "it hurts when I pee" "don't pee then"
2026-04-07T17:58:05 < mercenary> if one insists on having a temporary variable so the variable name makes it clear what this thing is, then yeah. decorate the variable.
2026-04-07T17:58:27 < mercenary> something like DEBUGVAR(v) = ....
2026-04-07T18:15:13 < karlp> no, I mean, you can't always move the variable/call into a printf param.
2026-04-07T18:15:44 < karlp> I'm going to just ignore the warnings for now, 
2026-04-07T18:15:57 < karlp> htat module isn't going to be used normally without the debug,
2026-04-07T18:16:17 < karlp> I'm just picking up all the final pieces from my r&d bugfix and putting them back in "nicely" into the real project.
2026-04-07T19:59:12 -!- goodvibrations32 [~user@user/goodvibrations32] has quit [Ping timeout: 256 seconds]
2026-04-07T20:01:11 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-07T20:40:06 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-07T20:59:27 -!- bitmask [~bitmask@static-23-234-100-249.cust.tzulo.com] has joined ##stm32
2026-04-07T21:35:52 < bitmask> well geez
2026-04-07T22:12:01 -!- grindhold [~quassel@2a0a:4cc0:c0:70c9::1] has joined ##stm32
2026-04-07T22:33:40 -!- DKordic [~DKordic@188.255.243.10] has joined ##stm32
2026-04-07T22:39:57 -!- DKordic [~DKordic@188.255.243.10] has quit [Ping timeout: 246 seconds]
2026-04-07T22:53:22 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 265 seconds]
2026-04-07T22:57:28 < Steffanx> Gooday mr sir bitmask 
2026-04-07T22:59:06 < bitmask> how goes it senor steffan
2026-04-07T22:59:26 < qyx> hey nigh shift
2026-04-07T22:59:27 < Steffanx> ¿Not too bad and yourself señor?
2026-04-07T23:00:29 < bitmask> stomach hurts and puppy wont stop biting and eating her own shit but other than that things are good
2026-04-07T23:07:22 < bitmask> well I guess I should start work for the day... its already 4pm
2026-04-07T23:07:53 < Steffanx> Still doing the AI thing?
2026-04-07T23:07:56 < bitmask> yup
2026-04-07T23:08:19 < Steffanx> Training or whatever it was
2026-04-07T23:08:59 < bitmask> yea, ask it questions and it gives you two different responses (different models or different internal settings) and you rate which is better based on certain criteria
2026-04-07T23:10:28 < bitmask> I stick to this one project that is pretty open ended, they want challenging prompts so I just work on my vulkan game engine with it
2026-04-07T23:21:40 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-07T23:46:51 < catphish> i was just starting to look at a choice of STM32 for a USB Audio -> I2C bridge, i feel like this is a difficult choice because the answer is probably almost any STM32, and maybe i just fall back on my old favourite G431 but i don't really know what to consider
2026-04-07T23:53:42 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 255 seconds]
--- Day changed Wed Apr 08 2026
2026-04-08T00:12:01 < catphish> actually, for starters, USB FS is probably a bit too slow
2026-04-08T00:12:06 -!- Livio [~livio@user/livio] has quit [Quit: leaving]
2026-04-08T00:47:03 < zyp> for what?
2026-04-08T00:49:19 < zyp> I haven't done a design with g431 myself yet, but it seems like a pretty good option for usb interfaces in general, so as long as it can do I2S with a reasonable clocking setup, I would think it's a good option
2026-04-08T00:50:06 < zyp> and FS should be plenty unless you're planning to have a ton of channels or ridiculous bitrates
2026-04-08T00:50:10 < catphish> i have used the G431 for half a dozen crystal-less USB projects and it works great
2026-04-08T00:51:08 < zyp> I've used g0b1, which is like the little brother that's actually more expensive because it's only available in variants with more flash
2026-04-08T00:51:45 < catphish> the DAC i'm looking at is 32-bit 192khz, so i figured i should support that, but that's a little too much for FS. however i'm not sure if i actulaly need 192khz, if not, it makes things much simpler, so i should clarify that
2026-04-08T00:51:57 < zyp> how many channels?
2026-04-08T00:52:06 < catphish> 2
2026-04-08T00:52:37 < zyp> what bit depth?
2026-04-08T00:52:44 < catphish> 192000 x 32 x 2 = 12.3Mbps
2026-04-08T00:52:53 < catphish> 32-bit is definitely a requirement
2026-04-08T00:53:02 < catphish> i'm not certain about the bitrate
2026-04-08T00:53:29 < zyp> yeah, that's in the territory of ridiculous bitrates
2026-04-08T00:54:15 < zyp> is this some audiophile shit?
2026-04-08T00:55:58 < catphish> it's for generating test signals for something, not really "audio"
2026-04-08T00:56:09 < karlp> 32bit? yeah, that's audiophool grade
2026-04-08T00:56:58 < Phantom> yay  digipot read and set work, need to test eeprom write...  but now I need to figure out the math for the shift and scale circuit... that is an headache :D
2026-04-08T00:57:34 < catphish> the critical part is that 100+dB dynamic range
2026-04-08T00:57:52 < zyp> catphish, if you're not doing audio, you should state so from the start, so you can skip all the complexities and bullshit audio stuff has to deal with
2026-04-08T00:58:13 < zyp> like the synchronization I mentioned the other day
2026-04-08T00:58:22 < catphish> i'm not sure i understand why that would be different
2026-04-08T00:58:32 < zyp> that goes right out the window if you don't need to synchronize to anything
2026-04-08T00:58:59 < catphish> i just need to take a series of samples from a PC and output them at at exact bitrate to I2S
2026-04-08T00:59:04 < zyp> exactly
2026-04-08T00:59:14 < catphish> isn't that exactly how audio works too>?
2026-04-08T00:59:25 < zyp> whereas for audio, synchronization is required so that e.g. the audio track lines up with the video track shown on the screen
2026-04-08T00:59:34 < zyp> and low latency is required too
2026-04-08T00:59:40 < catphish> anyway, i have a more specific question, if i want to to 48/96/192khz, what crystal do i need?
2026-04-08T00:59:54 < catphish> it seems you can't do this from normal crystals like 16MHz
2026-04-08T01:00:08 < catphish> zyp: oh i see, yeah that's not a concern
2026-04-08T01:00:32 < catphish> the buffer can be totally arbitrary
2026-04-08T01:00:41 < zyp> if neither synchronization nor latency matters, you can drop isochronous usb, just have a normal bulk pipe feed a reasonable buffer with normal flow control, and have I2S drain it as it likes
2026-04-08T01:00:54 < zyp> much easier
2026-04-08T01:01:03 < catphish> that makes sense, i'll likely do that
2026-04-08T01:01:36 < catphish> as long as the latency isn't so ridiculous that it doens't confuse an end user it'll be fine
2026-04-08T01:02:00 < zyp> IIRC I2S MCLK is typically 256x the sample rate, which for 192kHz would be 49.152MHz
2026-04-08T01:02:15 < zyp> 128x or 64x are probably also options
2026-04-08T01:02:37 < catphish> thanks, i'll punch that number into cubemx and see if it likes it
2026-04-08T01:02:52 < zyp> of course, crystal doesn't have to be that freq, but crystal needs to be a freq that can feed the PLL generating the I2S clock
2026-04-08T01:03:50 < zyp> maybe pick a 16.384 MHz crystal
2026-04-08T01:05:17 < zyp> 16.384 is 64kHz * 256, and then just pick a VCO multiplier that includes a factor 3
2026-04-08T01:07:58 < zyp> 12.288 MHz would also be good
2026-04-08T01:11:33 < catphish> am i being dumb, why a factor of 3?
2026-04-08T01:12:47 < zyp> because 192 is 64*3
2026-04-08T01:13:21 < catphish> oh yeah
2026-04-08T01:13:23 < zyp> when you're doing PLL math, remember prime factorization
2026-04-08T01:14:17 < catphish> (chosen at random) 16.384 / 8 * 120 / 2 = 122.88MHz (and that works)
2026-04-08T01:15:26 < zyp> the PLL VCO freq must be divisible by both the output freq and the PLL reference freq, so I usually start by factoring the output freq to figure out which factors the crystal should have and which can come from dividers
2026-04-08T01:15:39 < catphish> the obvious problem is that i can't drive 48MHz from this, so i would need a MCU with a crystal-less USB
2026-04-08T01:15:50 < zyp> or independent PLLs
2026-04-08T01:16:28 < zyp> some older chips have a second PLL specifically meant for I2S (it has I2S in the name)
2026-04-08T01:16:44 < zyp> in newer chips it's more common that they just have PLL1, PLL2 and PLL3 or something 
2026-04-08T01:17:36 < zyp> although, I'm not sure they have more than one HSE, so you might be restricted to a single crystal anyway
2026-04-08T01:17:48 < catphish> this chip has 3 PLLs that run from the high speed oscillator, and an independent I2S clock input
2026-04-08T01:17:49 < zyp> so getting something with HSI48 is probably good in any case :)
2026-04-08T01:18:09 < zyp> that said
2026-04-08T01:18:21 < zyp> I think the I2S peripheral itself can run with MCLK as input
2026-04-08T01:18:55 < zyp> so you could generate MCLK externally and not have to deal with that internally
2026-04-08T01:19:10 < catphish> this has a thing called I2S_CLKIN
2026-04-08T01:20:09 < catphish> so i could just generate it externally
2026-04-08T01:23:06 < zyp> yeah, do that
2026-04-08T01:23:34 < catphish> it's not at all clear what frequency input it wants
2026-04-08T01:23:52 < zyp> look at the clock tree behind it
2026-04-08T01:24:23 < catphish> it likes 122.88MHz, though i have no idea why
2026-04-08T01:24:27 < zyp> and before you think too hard about it, figure out what mclk your codec chip wants first
2026-04-08T01:28:31 < catphish> oh, i see now, it likes a large binary multiple of the sample rate, like 256 x 192,000
2026-04-08T01:28:48 < catphish> 49.152MHz
2026-04-08T01:30:57 < catphish> if that frequency needs to be fed to the DAC chip too then makes sense to generate it externally
2026-04-08T01:34:54 < catphish> looks like these are standard frequencies for oscillators, so i can just run an extenral oscillator, make sure i use an STM32 with a I2S_CLK input, work out if i need USB HS or nor (based on sample rate) and choose chip accordingly
2026-04-08T01:35:58 < zyp> if you need HS, you probably want to look at the parts with integrated HS PHY, which I think are mainly some H7 parts
2026-04-08T01:36:21 < zyp> not sure if there's any non-bga options with integrated HS PHY though
2026-04-08T01:36:47 < catphish> this chip i'm looking at now is F723 which has HS PHY
2026-04-08T01:37:13 < zyp> but remember to check whether the package option you're looking at has it
2026-04-08T01:37:13 < catphish> it also looks like the STM32 can output the I2S "master clock" if needed
2026-04-08T01:37:19 < catphish> so there's a couple of ways to structure it
2026-04-08T01:37:26 < zyp> yup
2026-04-08T01:37:30 < catphish> not many chips have the HS PHY
2026-04-08T01:39:12 < catphish> if i only need USB FS, i can use the G431, it can input the I2S clock, or output it, or both, and has HSI48, so that would be the easiest
2026-04-08T01:40:12 < catphish> but alternatively, i can run something like F723 which can run USB HS with an internal PHY and external crystal
2026-04-08T01:40:15 < zyp> ah, looks like f723 in qfp100 indeed has internal phy, nice
2026-04-08T01:40:28 < catphish> yeah that's the chip i'm looking at
2026-04-08T01:40:38 < catphish> i think i'll use that if i need HS
2026-04-08T01:40:57 < catphish> still massive overkill pin count
2026-04-08T01:41:19 < zyp> who cares
2026-04-08T01:41:24 < catphish> nobody :)
2026-04-08T01:41:27 < zyp> do you need it to be compact?
2026-04-08T01:42:04 < catphish> it needs to fit in a 1U or 2U 19" rackmount chassis
2026-04-08T01:42:11 < catphish> so... no
2026-04-08T01:42:13 < zyp> :D
2026-04-08T01:43:18 < zyp> if the qfp100 was too large, you could do the ufbga144, it's physically smaller
2026-04-08T01:43:46 < catphish> i could indeed, but i won't :)
2026-04-08T01:52:24 < catphish> looking at the requrements, it will indeed need to be 192kHz @ 32 bits, however it might only need to be one channel so i'll clarify
2026-04-08T01:52:29 < catphish> thanks for the pointers
2026-04-08T02:04:56 < catphish> oh, i can generate both frequencies from a single crystal just fine
2026-04-08T02:06:44 < catphish> (48MHz for USB and 122.88MHz for I2S) - both can be generated from a 24MHz crystal using two PLLs
2026-04-08T02:18:28 -!- qyx [~qyx@84.245.120.63] has quit [Ping timeout: 276 seconds]
2026-04-08T02:19:39 -!- qyx [~qyx@84.245.121.111] has joined ##stm32
2026-04-08T02:20:10 -!- haritz [~hrtz@user/haritz] has quit [Remote host closed the connection]
2026-04-08T02:33:38 -!- _Posterdati_ [~posterdat@user/Posterdati] has quit [Ping timeout: 248 seconds]
2026-04-08T02:36:27 -!- haritz [~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8] has joined ##stm32
2026-04-08T02:36:27 -!- haritz [~hrtz@user/haritz] has changed host
2026-04-08T02:58:32 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 256 seconds]
2026-04-08T03:23:51 -!- yukam [~yukam@user/yukam] has quit [Ping timeout: 244 seconds]
2026-04-08T03:26:43 -!- _Posterdati_ [~posterdat@user/Posterdati] has joined ##stm32
2026-04-08T03:32:37 -!- yukam [~yukam@user/yukam] has joined ##stm32
2026-04-08T03:35:06 -!- _Posterdati_ [~posterdat@user/Posterdati] has quit [Ping timeout: 255 seconds]
2026-04-08T04:49:30 -!- _Posterdati_ [~posterdat@user/Posterdati] has joined ##stm32
2026-04-08T05:00:09 -!- _Posterdati_ [~posterdat@user/Posterdati] has quit [Ping timeout: 255 seconds]
2026-04-08T05:02:04 -!- _Posterdati_ [~posterdat@user/Posterdati] has joined ##stm32
2026-04-08T05:10:43 -!- _Posterdati_ [~posterdat@user/Posterdati] has quit [Ping timeout: 276 seconds]
2026-04-08T05:11:28 -!- _Posterdati_ [~posterdat@user/Posterdati] has joined ##stm32
2026-04-08T05:22:28 -!- _Posterdati_ [~posterdat@user/Posterdati] has quit [Ping timeout: 256 seconds]
2026-04-08T05:56:01 -!- _Posterdati_ [~posterdat@user/Posterdati] has joined ##stm32
2026-04-08T06:00:45 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2026-04-08T06:08:13 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2026-04-08T06:54:03 < octorian> So I've been trying to figure out why my firmware code size grew by like 18KB when I move from ST's GCC13 to GCC14.  Finally found the answer in a changes blog post for some related product...
2026-04-08T06:54:20 < octorian> They've rebuilt newlib with -02, which the post says trades code size for performance.
2026-04-08T06:54:42 < octorian> (and claim upstream Arm toolchains already do this)
2026-04-08T07:23:36 < octorian> Though digging through the actual build scripts (gnu-tools-for-stm32) it seems like this change mostly affects base newlib, and newlib-nano is still built with -Os.
2026-04-08T07:23:51 < octorian> So maybe I should try and figure out what's actually getting linked into my code.
2026-04-08T07:25:03 < octorian> And I thought I was linking nano the whole time.
2026-04-08T07:34:15 -!- haritz [~hrtz@user/haritz] has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
2026-04-08T07:45:59 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-08T07:58:54 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2026-04-08T08:08:37 < octorian> Finally wrangled my linker config correctly, and now I've got it linking newlib-nano with printf_float (long story) and I think the issue is resolved.
2026-04-08T08:29:54 -!- bitmask [~bitmask@static-23-234-100-249.cust.tzulo.com] has quit [Quit: bitmask]
2026-04-08T08:33:18 < qyx> so, when I am getting SPI mode fault, I have SSM/SSI set wrong, right?
2026-04-08T08:33:45 < qyx> do I have to set both to 1?
2026-04-08T08:42:12 < Phantom> you know it's getting exciting when things is almost completed and work
2026-04-08T08:42:52 < qyx> no, it is called "80% done" syndrome and it is the worst part of the project
2026-04-08T08:42:58 < jpa-> qyx: do you want to use hardware chip select or software?
2026-04-08T08:43:01 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2026-04-08T08:43:05 < qyx> jpa-: software
2026-04-08T08:43:24 < qyx> stepping through the code and the SPE bit is refusing to be set
2026-04-08T08:43:27 < Phantom> yes and no, it also show that I was right to use those parts, and that I didn't made an horrible mistake!
2026-04-08T08:44:00 < Phantom> this need to be functionning (not fully production) by the end of the month
2026-04-08T08:44:01 < qyx> https://paste.jvnv.net/view/RBo3z
2026-04-08T08:44:12 < jpa-> qyx: then yeah, SSM = 1 and SSI = 1
2026-04-08T08:44:41 < Phantom> it got pushed back because... fricking kawasaki... they are idiots!
2026-04-08T08:44:42 < qyx> after the code abofe is run, CR1 is still 0x1000 instead of 0x1001
2026-04-08T08:44:56 < qyx> and MODF is not set
2026-04-08T08:45:08 < qyx> it is set after I enable CSTART and put something into the FIFO
2026-04-08T08:45:47 < Phantom> where is the japanese efficiency??? grr
2026-04-08T08:48:34 < jpa-> qyx: if this is on STM32F7 or similar, make sure you have the peripheral clock (not just bus clock) enabled
2026-04-08T08:51:19 < qyx> jpa-: that's exactly the question, i indeed enabled the bus clock and according the datasheet, spi_ker_ck should be selected to some not-disabled clock
2026-04-08T08:51:22 < qyx> oh lol
2026-04-08T08:51:37 < qyx> yes but the default clock is pll and my pll is not plling
2026-04-08T08:51:51 < qyx> I checked that 10 times and it wasn't enough
2026-04-08T09:11:10 < qyx> so now I have hsi_ker_ck clock selected as per_ck clock, per_ck selected as SPI1/2/3 ker_ck
2026-04-08T09:11:26 < antto> PLLCOOLJ
2026-04-08T09:12:37  * antto recently wrote some library code for the clock setup for SAME54/SAMD20/SAMD21 families, it was "interesting" x_x
2026-04-08T09:14:10 < antto> it looks like this https://paste.debian.net/hidden/5481c064
2026-04-08T09:24:33 -!- krish2487 [~krishi@cpe.ge-8-1-4-100.henqe12.dk.customer.tdc.net] has joined ##stm32
2026-04-08T09:26:10 < qyx> the basic problem of H7 is that clock shit doesn't work after reset
2026-04-08T09:26:27 < qyx> it doesn't have sane defaults as was always the case
2026-04-08T09:26:56 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-08T09:33:53 < antto> huh? is that for all H7?
2026-04-08T09:35:31 < qyx> idk but usually some PLL is configured as the peripheral clock
2026-04-08T09:35:36 < qyx> and PLLs are disabled after reset
2026-04-08T09:35:41 -!- krish2487 [~krishi@cpe.ge-8-1-4-100.henqe12.dk.customer.tdc.net] has quit [Quit: WeeChat 4.8.2]
2026-04-08T09:35:53 < antto> i have an unfinished project with H723 because i needed MCU with FPU and muchos MHz (more than 400MHz), but i'm really interested in the cortex-M85 now, so.. it'd be nice to find an even faster MCU
2026-04-08T09:36:00 < jpa-> yeah, they kinda assume you'll clock the PLL up as soon as your firmware boots
2026-04-08T09:36:16 < antto> wut, so how does the MCU "think" after reset if there's no clock?
2026-04-08T09:36:32 < qyx> anyway, reconfigured clocks and still cannot set SPE high
2026-04-08T09:36:36 < qyx> everything else works
2026-04-08T09:37:42 < qyx> and MODF flag is being set
2026-04-08T09:38:11 < qyx> I don't get it, the peripheral works as intended, I can write the fifo, flags are being set but the SPE is still zero
2026-04-08T09:43:47 < qyx> okay, actually the MODF flag is set right after setting SSI to 1
2026-04-08T09:43:52 < qyx> even before enabling SPE
2026-04-08T09:44:20 < zyp> Phantom, first you use 90% of the time on the first 90% of the project, and then you use 90% of the time on the remaining 10% of the project
2026-04-08T09:44:20 < qyx> that's probably the reason that SPE cannot go high (while MODF is set)
2026-04-08T09:45:51 < qyx> lol it works
2026-04-08T10:14:18 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 256 seconds]
2026-04-08T10:59:49 < mawk> qyx you still want to use javacards for security in your project? I have a ton now, including in SIM format
2026-04-08T10:59:53 < mawk> I can send you a couple
2026-04-08T11:21:04 -!- goodvibrations32 [~user@user/goodvibrations32] has joined ##stm32
2026-04-08T11:21:54 -!- goodvibrations32 [~user@user/goodvibrations32] has left ##stm32 []
2026-04-08T11:22:11 -!- goodvibrations32 [~user@user/goodvibrations32] has joined ##stm32
2026-04-08T11:53:22 < qyx> mawk: it is long planned but nobody is able to give me cards and the required tooling
2026-04-08T11:53:41 < mawk> the tooling is all open source stuff
2026-04-08T11:53:57 < mawk> unless you have tens of millions in revenue NXP won't give you the time of day for their own tools
2026-04-08T11:54:02 < mawk> and you don't even need them
2026-04-08T11:54:14 < mawk> the javacard devkit is freely downloadable on oracle's website
2026-04-08T11:54:15 < zyp> having «java» in the name sounds like a suggestion to stay away
2026-04-08T11:54:49 < mawk> well in this case I understand why it's java
2026-04-08T11:55:05 < qyx> we can talk about it later, the usual requirement is the ability to replace the device without touching the key material
2026-04-08T11:55:07 < mawk> the JVM and JCRE is fully controlled by the card's OS to ensure you don't do anything dumb
2026-04-08T11:55:16 < mawk> and to enforce all the security mitigations
2026-04-08T11:55:42 < qyx> so it needs to be on a secure storage element which is replaceanle
2026-04-08T11:55:58 < mawk> it's possible to write C for it (it's a 8 bit mcu) but you need to sell your soul to NXP first
2026-04-08T11:56:17 < mawk> yeah then SIM format is perfect 
2026-04-08T11:56:25 < mawk> and it's just a USART in the end
2026-04-08T12:02:23 < fantanYl> it seems that someone is copycating CreepyOS :>
2026-04-08T12:14:13 < mawk> sue them
2026-04-08T12:24:58 < fantanYl> nah, why? it is actually honour
2026-04-08T12:33:10 < karlp> qyx: are you running into all the second level pclksel bits? :)
2026-04-08T12:34:36 < qyx> karlp: nope the problem was SSI, SSM and MASTER bit setting ordering
2026-04-08T12:34:53 < qyx> also the nonworking ker_ck, yeah
2026-04-08T12:44:19 < qyx> anyway, now the fun part begins, getting the data and see if they are useful
2026-04-08T12:45:21 < qyx> it should be 9 ug/rtHz over the full bw (19 Hz)
2026-04-08T13:22:11 < karlp> imagine actually measuring and evaluating, instead of just planning and getting to the 80% stage ;)
2026-04-08T13:37:18 < qyx> https://bin.jvnv.net/file/Us1lT/2026-04-08T12:36:47.930268.png
2026-04-08T13:37:29 < qyx> does this mean I just won the jackpot?
2026-04-08T13:38:31 < qyx> I just vibecoded some pythonz, basically doing welch transform to get noise spectral density
2026-04-08T13:41:16 < karlp> looks good?
2026-04-08T13:43:07 < qyx> looks about 9 ug/rtHz max
2026-04-08T13:45:49 < karlp> so, how did you calculate your "should be 9" before hand?
2026-04-08T13:47:26 < qyx> I didn't, TDK did
2026-04-08T13:47:32 < qyx> it is listed in their datasheed
2026-04-08T13:47:34 < qyx> t
2026-04-08T13:54:58 -!- krish2487 [~krishi@cpe.ge-8-1-4-100.henqe12.dk.customer.tdc.net] has joined ##stm32
2026-04-08T14:09:00 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 268 seconds]
2026-04-08T14:14:41 -!- haritz [~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8] has joined ##stm32
2026-04-08T14:14:41 -!- haritz [~hrtz@user/haritz] has changed host
2026-04-08T14:19:07 < karlp> so you just read a ton of samples and plotted distrib?
2026-04-08T14:19:09 -!- rkta [~rkta@user/rkta] has left ##stm32 []
2026-04-08T14:19:27 < karlp> how dod you makei t flat and calm enough to see just the part noise?
2026-04-08T15:50:02 -!- goodvibrations32 [~user@user/goodvibrations32] has left ##stm32 [ERC 5.6.0.30.1 (IRC client for GNU Emacs 30.2)]
2026-04-08T16:02:59 < karlp> have you guys seen this cmsis cbuild thing?
2026-04-08T16:20:43 < Steffanx> Do I want to see it?
2026-04-08T16:33:57 -!- krish2487 [~krishi@cpe.ge-8-1-4-100.henqe12.dk.customer.tdc.net] has quit [Ping timeout: 272 seconds]
2026-04-08T16:47:48 -!- specing [~specing@user/specing] has quit [Remote host closed the connection]
2026-04-08T16:48:11 -!- specing [~specing@user/specing] has joined ##stm32
2026-04-08T16:49:59 < qyx> karlp: basically, it doesn't need to be flat, calm is enough
2026-04-08T16:50:03 < qyx> and temp stabilized
2026-04-08T16:50:07 < qyx> *stable
2026-04-08T17:20:06 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-08T17:41:30 -!- bitmask [~bitmask@static-23-234-100-249.cust.tzulo.com] has joined ##stm32
2026-04-08T20:41:01 -!- hexo [~hexo@user/hexo] has quit [Remote host closed the connection]
2026-04-08T20:43:58 -!- PhantomWork [~PhantomWo@user/phantom] has joined ##stm32
2026-04-08T20:51:52 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-08T21:36:25 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-08T23:57:13 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 248 seconds]
--- Day changed Thu Apr 09 2026
2026-04-09T00:30:56 -!- Livio [~livio@user/livio] has quit [Quit: leaving]
2026-04-09T00:35:46 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 268 seconds]
2026-04-09T00:53:53 < karlp> qyx: fair, I just know that our loadcells will pick up footsteps in the hallway
2026-04-09T00:54:39 < karlp> Steffanx: I'm not sure, it seems like... it might be nice, in a way? but... wow, rebuild _everything_
2026-04-09T00:54:53 < karlp> and pyocd all in, supports it's otuput files natively.
2026-04-09T00:55:42 < qyx> karlp: oh yes my strain gauges and other accels too but these particular ones are somewhat deaf
2026-04-09T00:56:25 < karlp> was kinda cute though, I used the "ARM CMSIS SOlution" extension in vscode, made a new project, and it gives you anice view with datasheet, errata, refman, all right there out of the box, a nice templated linker script, 
2026-04-09T00:56:28 < karlp> it didn't... build
2026-04-09T00:56:47 < karlp> there's some missing gui step somewhere to select a compiler I think, but... someone's been doing a _shit ton_ of work on this.
2026-04-09T01:24:42 -!- haritz [~hrtz@user/haritz] has quit [Ping timeout: 246 seconds]
2026-04-09T01:26:14 -!- haritz [~hrtz@140.228.70.141] has joined ##stm32
2026-04-09T01:27:57 -!- haritz [~hrtz@user/haritz] has changed host
2026-04-09T01:29:17 -!- haritz [~hrtz@user/haritz] has quit [Excess Flood]
2026-04-09T01:31:13 -!- haritz [~hrtz@140.228.70.141] has joined ##stm32
2026-04-09T01:32:55 -!- haritz [~hrtz@user/haritz] has changed host
2026-04-09T01:38:32 -!- haritz [~hrtz@user/haritz] has quit [Read error: Connection reset by peer]
2026-04-09T01:38:43 -!- haritzondo [~hrtz@140.228.70.141] has joined ##stm32
2026-04-09T02:35:05 -!- c10ud_ [~c10ud@host-95-237-126-207.retail.telecomitalia.it] has quit [Ping timeout: 248 seconds]
2026-04-09T03:05:22 -!- catphish [~quassel@user/catphish] has quit [Quit: No Ping reply in 180 seconds.]
2026-04-09T03:06:48 -!- catphish [~quassel@user/catphish] has joined ##stm32
2026-04-09T03:13:11 -!- bitmask [~bitmask@static-23-234-100-249.cust.tzulo.com] has quit [Ping timeout: 252 seconds]
2026-04-09T03:14:27 -!- c10ud [~c10ud@host-95-233-182-170.retail.telecomitalia.it] has joined ##stm32
2026-04-09T03:14:27 -!- c10ud [~c10ud@user/c10ud] has changed host
2026-04-09T04:04:28 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2026-04-09T06:08:43 -!- ferdna [~ferdna@user/ferdna] has quit [Ping timeout: 264 seconds]
2026-04-09T06:30:39 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2026-04-09T08:03:28 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-09T08:27:15 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2026-04-09T08:48:08 -!- haritzondo [~hrtz@140.228.70.141] has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
2026-04-09T09:20:58 -!- krish2487 [~krishi@80.167.234.142] has joined ##stm32
2026-04-09T09:21:58 -!- catphish [~quassel@user/catphish] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
2026-04-09T09:22:15 -!- catphish [~quassel@user/catphish] has joined ##stm32
2026-04-09T09:44:21 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2026-04-09T09:51:53 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2026-04-09T09:54:42 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 248 seconds]
2026-04-09T11:04:27 -!- yukam [~yukam@user/yukam] has quit [Quit: quit]
2026-04-09T11:05:31 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-09T11:20:08 < _Posterdati_> hi
2026-04-09T11:21:00 < _Posterdati_> please help, it is normal that CEIS and SEIS become 1 after reading DR register on IRQ handler for the stm32h723? Thanks!
2026-04-09T11:21:39 < zyp> what peripheral?
2026-04-09T11:22:07 < _Posterdati_> RNG
2026-04-09T11:31:40 < _Posterdati_> then DRDY never gets to 1 if I don't reset using CONDRST
2026-04-09T11:33:30 < _Posterdati_> I followed RM0468 page 1434 procedure to recover the seed error
2026-04-09T11:42:17 < _Posterdati_> and RM0468 page 1432 for irq operation
2026-04-09T11:45:59 < _Posterdati_> ?
2026-04-09T11:46:06 < _Posterdati_> any hints?
2026-04-09T12:14:49 < _Posterdati_> I selected the hsi48ck for rng
2026-04-09T12:20:26 < zyp> how does the CECS/SECS bits read?
2026-04-09T12:25:10 < zyp> are you sure the HSI48 is enabled?
2026-04-09T12:32:10 < _Posterdati_> zero
2026-04-09T12:32:26 -!- tomeaton17 [~tom@user/tomeaton17] has quit [Quit: ZNC 1.9.0+deb2ubuntu0.1~esm2 - https://znc.in]
2026-04-09T12:32:29 < _Posterdati_> no, I'm not sure
2026-04-09T12:32:43 < _Posterdati_> I will output it to an mco pin then
2026-04-09T12:32:45 -!- tomeaton17 [~tom@user/tomeaton17] has joined ##stm32
2026-04-09T12:53:25 < _Posterdati_> zyp: I placed a 12MHz signal on MCO1, seems to work then
2026-04-09T12:53:51 < _Posterdati_> so HSI48 is on and working
2026-04-09T12:53:55 < zyp> as in HSI48/4?
2026-04-09T12:54:09 < _Posterdati_> yes I dividev by 4
2026-04-09T12:54:15 < _Posterdati_> on the MCO1
2026-04-09T12:54:17 < zyp> okay, good
2026-04-09T12:54:24 < _Posterdati_> now
2026-04-09T12:54:31 < _Posterdati_> I read DR four times
2026-04-09T12:54:36 < _Posterdati_> first time = OK
2026-04-09T12:54:45 < zyp> have you checked the errata sheet that there's no errata fuckups that require workarounds?
2026-04-09T12:54:46 < _Posterdati_> then SEIS = 1 and SECS = 1
2026-04-09T12:55:06 < _Posterdati_> zyp: I search the net, but do not cared too much
2026-04-09T12:55:42 < _Posterdati_> first read of DR = OK, then SEIS = 1 and SECS = 1
2026-04-09T12:55:55 < _Posterdati_> other 3 readings of DR = 0
2026-04-09T13:12:48 -!- om3ga [~om3ga@93.177.187.134] has quit [Ping timeout: 244 seconds]
2026-04-09T13:23:53 < _Posterdati_> :(
2026-04-09T13:39:12 < zyp> I checked the errata sheet for you, it doesn't list any RNG errata, so you're probably just doing something wrong
2026-04-09T13:59:24 -!- om3ga [~om3ga@93.177.187.134] has joined ##stm32
2026-04-09T14:13:38 < fantanYl> i have to say that pico-sdk api for i2c is completely brain-dead
2026-04-09T14:14:06 < fantanYl> i have probably said that already
2026-04-09T14:16:49 < zyp> this? https://www.raspberrypi.com/documentation/pico-sdk/hardware.html#functions-11
2026-04-09T14:17:42 < fantanYl> yes
2026-04-09T14:20:10 < _Posterdati_> zyp: sure I did, but what?
2026-04-09T14:20:21 < zyp> if I knew, I'd tell you :)
2026-04-09T14:20:57 < _Posterdati_> zyp: I read the errata too, no mention to any rng problem there :)
2026-04-09T14:22:52 < zyp> fantanYl, what's the issue with it? looks about on par with what I'd expect from a C API
2026-04-09T14:23:19 < zyp> no i2c_exchange(), but that's just a combination of i2c_write_blocking() and i2c_read_blocking()
2026-04-09T14:24:18 < fantanYl> zyp: i2c_read/write_byte_raw are kind-of hanging in vacuum with no clear way to start transmission and clock bytes one by one
2026-04-09T14:24:35 < fantanYl> and unclear connection to DMA (if there is any)
2026-04-09T14:25:02 < qyx> you probably shouldn't use "raw"
2026-04-09T14:25:22 < qyx> as zyp says, i2c_write_blocking
2026-04-09T14:25:37 < qyx> if you want to read, i2c_write_blocking with no_stop, then i2c_read_blocking most probably
2026-04-09T14:26:01 < fantanYl> that's not going to work, will it? can you flip read/write mid transmission?
2026-04-09T14:26:12 < qyx> of course, it is called repeated start
2026-04-09T14:26:15 < zyp> huh? have you ever done i2c before?
2026-04-09T14:26:20 < qyx> and it probably handles it automatically
2026-04-09T14:26:56 < fantanYl> yes I did. apparently never used this feature
2026-04-09T14:27:36 < fantanYl> OK, kids probably don't need to know about it at this stage either. it will confuse them
2026-04-09T14:29:51 < _Posterdati_> zyp: seem fixed
2026-04-09T14:32:17 < _Posterdati_> zyp: I wrote HTCR after configuring CR (RNGEN=1) and before locking the configuration
2026-04-09T14:45:59 -!- haritz [~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8] has joined ##stm32
2026-04-09T14:45:59 -!- haritz [~hrtz@user/haritz] has changed host
2026-04-09T15:46:03 -!- haritzondo [~hrtz@140.228.70.141] has joined ##stm32
2026-04-09T15:46:08 -!- haritz [~hrtz@user/haritz] has quit [Ping timeout: 252 seconds]
2026-04-09T16:27:40 -!- krish2487 [~krishi@80.167.234.142] has quit [Ping timeout: 268 seconds]
2026-04-09T16:58:04 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 244 seconds]
2026-04-09T17:24:47 -!- t4nk_freenode [~Go@user/t4nk] has joined ##stm32
2026-04-09T17:24:48 -!- LFSveteran_ [~LFSvetera@keymaker.msrv.nl] has joined ##stm32
2026-04-09T17:27:00 -!- teknix_ [~unknown@user/hsv] has joined ##stm32
2026-04-09T17:34:02 -!- Netsplit *.net <-> *.split quits: quinor, octorian, t4nk_fn, machinehum, LFSveteran, \dev\ice, teknix, soweli_iki, hackkitten
2026-04-09T17:34:05 -!- LFSveteran_ is now known as LFSveteran
2026-04-09T18:07:14 -!- t4nk_freenode is now known as t4nk_fn
2026-04-09T18:25:29 -!- quinor [08c0f10716@2a03:6000:1812:100::dad] has joined ##stm32
2026-04-09T18:25:29 -!- hackkitten [~hackkitte@2a00:6020:adca:e400:ab10:8b2d:2528:73c3] has joined ##stm32
2026-04-09T18:25:29 -!- \dev\ice [~eabdb@user/device/x-9920846] has joined ##stm32
2026-04-09T18:25:29 -!- machinehum [machinehum@2a01:7e01::f03c:94ff:fe4d:b21c] has joined ##stm32
2026-04-09T18:25:29 -!- octorian [octo@2600:3c00::f03c:91ff:fe93:a61c] has joined ##stm32
2026-04-09T18:25:29 -!- soweli_iki [soweli_iki@user/soweli-iki:47461] has joined ##stm32
2026-04-09T18:35:17 -!- Netsplit *.net <-> *.split quits: \dev\ice, soweli_iki, octorian, quinor, machinehum, hackkitten
2026-04-09T18:35:19 -!- soweli_iki [soweli_iki@2600:3c02::f03c:93ff:fe5b:9fc] has joined ##stm32
2026-04-09T18:35:19 -!- soweli_iki [soweli_iki@user/soweli-iki:47461] has changed host
2026-04-09T18:35:25 -!- Netsplit over, joins: quinor, hackkitten
2026-04-09T18:35:25 -!- \dev\ice [~eabdb@2a01:4f8:1c1e:b0a8::1] has joined ##stm32
2026-04-09T18:35:25 -!- octorian [~octo@173.255.195.32] has joined ##stm32
2026-04-09T18:35:30 -!- Netsplit over, joins: machinehum
2026-04-09T18:54:44 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-09T19:21:59 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2026-04-09T19:25:32 < Posterdati> hi
2026-04-09T19:25:59 < Posterdati> please help, is arm-none-eabi toolchain suitable for cortex-m7? Thanks!
2026-04-09T19:36:41 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Ping timeout: 244 seconds]
2026-04-09T19:46:21 < fantanYl> yes
2026-04-09T19:46:48 < Posterdati> fantanYl: does it use fpu instructions in m library?
2026-04-09T19:53:44 < jpa-> if it has be3n compiled to do so (or has multilib)
2026-04-09T19:59:56 < fantanYl> Posterdati: as jpa- said, depends on which specific arm-none-eabi you are talking about. ARM's one has multilib support and if you use fpu, it will use fpu instructions to implement floating point math
2026-04-09T20:00:37 < Posterdati> ok
2026-04-09T20:00:41 < Posterdati> thanks
2026-04-09T20:44:54 < catphish> Posterdati: i believe it supports lots of options including both hard and soft floating point maths
2026-04-09T20:46:11 < catphish> I'm not sure i have specific experience with m7, but i'd be very surprised if it didn't have ful support for the FPU
2026-04-09T20:56:14 < jpa-> "arm-none-eabi" is just the system type, it tells nothing about the compiler (gcc or clang or something else?) or the version (maybe you are using izua's toolchain from 2010? it won't know about cortex-m7)
2026-04-09T20:56:30 < jpa-> let alone what features were enabled in compilation
2026-04-09T20:56:55 < zyp> doesn't have to know about cortex-m7 to be usable though, since it's a superset :p
2026-04-09T20:57:47 < jpa-> true, m4f instructions should work :)
2026-04-09T20:57:59 < jpa-> you'd miss out on doubles though
2026-04-09T21:05:47 < catphish> my replies assume that he was referring to the free version of GCC, but yeah, all kinds of things might call themseles arm-none-eabi
2026-04-09T21:06:42 < jpa-> is there a non-free version of gcc?
2026-04-09T21:17:16 < specing> sure
2026-04-09T21:47:03 < catphish> that's a good question, i know there are nonfree compilers, and modified versions of gcc, whether those are nonfree (officially or illegally) i never really looked into
2026-04-09T21:53:02 < specing> I use GNAT CE for stm32, but there also exists non-gratis GNAT Pro
2026-04-09T21:53:35 < specing> pretty sure the actual gcc is the same, but the latter is "officially verified" and probably has extra plugins
2026-04-09T21:56:13 < specing> jpa-: now did you mean non-free where free stands for freedoom or price? The former obviously isn't possible due to gcc's license
2026-04-09T22:02:17 -!- hexo__ [~hexo@user/hexo] has quit [Read error: Connection reset by peer]
2026-04-09T22:02:22 -!- hexo_ [~hexo@user/hexo] has joined ##stm32
2026-04-09T22:20:15 < catphish> i only ever use stock gcc (whatever my linux distro provides)
2026-04-09T22:22:12 < qyx> same here, not downloading any toolchains anymore
2026-04-09T22:22:47 < qyx> even debian has gcc-arm-none-eabi 14.2
2026-04-09T22:24:55 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-09T22:28:36 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Remote host closed the connection]
2026-04-09T22:28:59 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-09T22:35:24 < antto> arm-none-habibi
2026-04-09T22:36:09 < antto> arm-none-punjabi
2026-04-09T22:36:16  * antto runs
2026-04-09T23:12:58 < Steffanx> antto how fast can you run?
2026-04-09T23:18:32 -!- hexo__ [~hexo@user/hexo] has joined ##stm32
2026-04-09T23:18:45 -!- hexo__ is now known as hexo
2026-04-09T23:34:54 -!- yukam [~yukam@user/yukam] has joined ##stm32
2026-04-09T23:39:34 -!- yukam [~yukam@user/yukam] has quit [Ping timeout: 268 seconds]
--- Day changed Fri Apr 10 2026
2026-04-10T00:04:12 < fantanYl> 10mbit/s
2026-04-10T00:06:15 < fantanYl> ok, creepyOS apparently survived merge of performance improvements with rp2040-specific hacks
2026-04-10T00:15:43 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 265 seconds]
2026-04-10T00:20:55 -!- haritzondo [~hrtz@140.228.70.141] has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
2026-04-10T01:27:18 -!- yukam [~yukam@user/yukam] has joined ##stm32
2026-04-10T02:18:06 -!- qyx [~qyx@84.245.121.111] has quit [Ping timeout: 256 seconds]
2026-04-10T02:19:50 -!- qyx [~qyx@84.245.120.235] has joined ##stm32
2026-04-10T02:39:01 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 268 seconds]
2026-04-10T03:49:38 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2026-04-10T05:11:24 -!- ferdna [~ferdna@user/ferdna] has quit [Ping timeout: 255 seconds]
2026-04-10T08:46:33 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2026-04-10T08:55:24 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2026-04-10T09:03:32 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2026-04-10T09:05:29 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-10T09:09:22 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2026-04-10T09:15:15 -!- krish2487 [~krishi@cpe.ge-8-1-4-100.henqe12.dk.customer.tdc.net] has joined ##stm32
2026-04-10T10:15:38 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 244 seconds]
2026-04-10T11:17:16 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-10T11:21:22 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-10T11:50:05 < karlp> qyx: does debian's work?
2026-04-10T11:50:57 < karlp> has https://github.com/karlp/newlib-inttypes-wat been fixed?
2026-04-10T11:51:10 < karlp> I got tired of trying to track down where and who to repor it to.
2026-04-10T11:57:53 < qyx> huh idk
2026-04-10T12:15:13 < qyx> so anyone of you, irc pros, used USART in sync mode?
2026-04-10T12:15:48 < qyx> https://electronics.stackexchange.com/questions/429138/stm32-usart-synchronous-mode-receive-does-not-work
2026-04-10T12:16:01 < qyx> but my ORE is not set, I have set OVRDIS
2026-04-10T12:16:19 < qyx> I can't see anything suspicious except I read all 0x00 from RDR
2026-04-10T12:20:38 < qyx> yes, the receiver is enabled
2026-04-10T12:33:56 -!- Livio [~livio@user/livio] has quit [Ping timeout: 265 seconds]
2026-04-10T12:49:49 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-10T13:15:25 < qyx> ah the fifo is apparently not more than 4 bytes deep
2026-04-10T13:53:27 -!- Livio [~livio@user/livio] has quit [Quit: leaving]
2026-04-10T14:02:11 < mawk> you're not DMAing?
2026-04-10T14:08:06 < karlp> fucking, workbr0 heard I had a plan to use zephyr on one baord as a trial,
2026-04-10T14:08:30 < karlp> he's concerned we would need a more powerfucl cpu, prferably with external memory and better memory management...
2026-04-10T14:08:44 < karlp> should have kept this work secret longer.
2026-04-10T14:10:31 < Steffanx> Did you point him to H5 and call it a day?
2026-04-10T14:39:34 < karlp> no, he's just out of his mind.
2026-04-10T14:40:20 < karlp> this is the guy who runs all his tasks at equal priority with no taskdelays, and sped the freertos time to 500usecs so that his digital ios softare filtered doesn't have any jitter.
2026-04-10T14:40:30 < karlp> and he complains that i call it fragile, 
2026-04-10T14:40:33 < karlp> "it's proven working"
2026-04-10T14:41:10 < karlp> weðve got like 256k ram and 2M flash, but zephyr will be too big and need external ram...
2026-04-10T14:42:15 < zyp> ah, looking forward to hear karlp ranting about the things he hates about zephyr :)
2026-04-10T14:43:46 < karlp> well, I have quirks with it already, but it's significantly less suck than it was last I tried it.
2026-04-10T14:44:24 < karlp> I'm just trying to setup a zephyr system to demo what our projects could be like, and it sure can't be worse than the fragile mountain of crap we have in some projects already
2026-04-10T15:23:01 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2026-04-10T15:23:07 < Laurenceb_> supp
2026-04-10T15:23:14 < Laurenceb_> anyone here used stm32duino?
2026-04-10T15:23:24 < Laurenceb_> hardwaretimer is causing hardfault :(
2026-04-10T15:25:19 < zyp> ok
2026-04-10T15:30:03 < Laurenceb_> UFSR is 0x4000
2026-04-10T15:31:55 < fantanYl> why would we do that?
2026-04-10T15:32:04 < Laurenceb_> lol
2026-04-10T15:33:06 < zyp> uh, bit 14 in UFSR looks reserved?
2026-04-10T15:33:52 < Laurenceb_> yeah
2026-04-10T15:34:42 < zyp> that suggests it's not a real UFSR value, i.e. it's likely either you or your tools fucked up
2026-04-10T15:36:03 < Laurenceb_> ah yeah there is an off by one error
2026-04-10T15:36:44 < Laurenceb_> IACCVIOL
2026-04-10T15:37:28 < zyp> invalid vector in the vector table?
2026-04-10T15:39:56 < Laurenceb_> error is inside HAL_TIM_Base_Init
2026-04-10T15:41:15 < zyp> that doesn't sound like a function that'll cause an IACCVIOL
2026-04-10T15:42:48 < Laurenceb_> hmm I dont have debugging - this is someones tarduino project
2026-04-10T15:43:09 < Laurenceb_> error occurs during new HardwareTimer(TIM5);
2026-04-10T15:43:21 < zyp> if it were a DACCVIOL, you could have fucked up a function argument or something, but it shouldn't cause IACCVIOLs unless it's taking function pointers (e.g. callback)
2026-04-10T15:44:04 < zyp> except if this causes because it turns on an interrupt and then the interrupt fires and hits an invalid vector
2026-04-10T15:46:41 < Laurenceb_> maybe it is a fake stm32 - its from jlpcb stock
2026-04-10T15:47:18 < Laurenceb_> disasm looks like error happens when it tries to hit the timer registers
2026-04-10T15:47:43 < zyp> to turn on the timer interrupt?
2026-04-10T15:48:08 < qyx> maybe a stupid question, is there TIM5?
2026-04-10T15:49:06 < qyx> oh invalid interrupt
2026-04-10T15:53:11 -!- krish2487 [~krishi@cpe.ge-8-1-4-100.henqe12.dk.customer.tdc.net] has quit [Ping timeout: 272 seconds]
2026-04-10T15:58:45 < tomeaton17> what is the appropriate punishment for hw guy speccing afe with wrong comms protocol on its otp to asm house meaning I have to program the otp on all of them?
2026-04-10T15:59:34 < qyx> is it a two times programmable "otp"?
2026-04-10T16:02:17 < mercenary> one "We will do it my way" credit for every unit programmed, to be used in discussions on future projects.
2026-04-10T16:03:21 < tomeaton17> depends if you define it being programmed by chip manufacturer as one time
2026-04-10T16:03:49 < tomeaton17> I think you can do 8 partial writes, but only 0->1
2026-04-10T16:04:39 < Laurenceb_> will I see in stack if timer isr was triggered?
2026-04-10T16:05:11 < zyp> depends if your tools are shit or not
2026-04-10T16:05:20 < tomeaton17> problem is I need to get a least a few of the boards out today so need to set up a janky bootstrap with the eval board to burn the otp, digikey is fucked at the moment so wont be able to put the new chips on till next week
2026-04-10T16:05:30 < Laurenceb_> https://community.platformio.org/t/problem-with-hardwaretimer/16364
2026-04-10T16:10:07 < Laurenceb_> looks like any timer causes the same fault
2026-04-10T16:15:26 < qyx> you can ask Jan-
2026-04-10T16:24:32 -!- qyx [~qyx@84.245.120.235] has quit [Ping timeout: 244 seconds]
2026-04-10T16:26:25 -!- qyx [~qyx@84.245.120.235] has joined ##stm32
2026-04-10T16:27:12 -!- hexo__ [~hexo@user/hexo] has joined ##stm32
2026-04-10T16:27:36 < Laurenceb_> https://pastie.io/dbwkmg.yml
2026-04-10T16:27:38 < Laurenceb_> hmm wtf
2026-04-10T16:28:07 < Laurenceb_> I see 08010ED1 in stack
2026-04-10T16:28:52 < karlp> lol, locm3 usb keeps breaking existing stuff, and going "well, u5 works"
2026-04-10T16:29:42 -!- yukam [~yukam@user/yukam] has quit [Ping timeout: 244 seconds]
2026-04-10T16:29:42 -!- hexo [~hexo@user/hexo] has quit [Ping timeout: 244 seconds]
2026-04-10T16:38:28 -!- yukam [~yukam@user/yukam] has joined ##stm32
2026-04-10T16:46:47 < Laurenceb_> ok I misread the stack
2026-04-10T16:47:02 < Laurenceb_> its trying to jump to the address in R3 for some reason
2026-04-10T16:54:45 < Laurenceb_> found the error
2026-04-10T16:54:47 < Laurenceb_> 8010ece:    4798          blx    r3
2026-04-10T16:54:47 < Laurenceb_>  8010ed0:    e7d6          b.n    8010e80 <HAL_TIM_Base_Init+0xc>
2026-04-10T16:59:46 < Laurenceb_> dunno wtf this asm is trying to do
2026-04-10T17:00:37 < Laurenceb_> home time, nvm
2026-04-10T17:35:23 < jpa-> well it's trying to call function pointer r3, and then call the init func
2026-04-10T17:35:51 < jpa-> and the init func call is tail optimized
2026-04-10T17:40:21 -!- jpka [~root@176.107.81.139] has quit [Ping timeout: 252 seconds]
2026-04-10T17:45:01 -!- hexo__ is now known as hexo
2026-04-10T17:47:30 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-10T17:54:57 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 244 seconds]
2026-04-10T18:46:31 < tomeaton17> great news the peak transceiver we have does not support FD, guess it is home time now
2026-04-10T18:47:21 -!- sugarbeet [~barbas@81.4.123.134] has quit [Ping timeout: 248 seconds]
2026-04-10T18:52:18 -!- sugarbeet [~barbas@81.4.123.134] has joined ##stm32
2026-04-10T19:34:55 -!- Livio [~livio@user/livio] has quit [Ping timeout: 265 seconds]
2026-04-10T19:48:11 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-10T20:07:58 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-10T21:03:17 < catphish> i'm bored
2026-04-10T21:03:23 < catphish> i need to make something good
2026-04-10T21:10:00 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-10T21:49:17 -!- Livio [~livio@user/livio] has quit [Ping timeout: 265 seconds]
2026-04-10T21:57:26 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-10T21:58:18 < catphish> can everyone give me their best electronics business ideas so i can implement them and make money and not be bored?
2026-04-10T22:03:55 < antto> catphish, make a 10GHz single core Cortex-M85 MCU for me
2026-04-10T22:04:06 < antto> thanks
2026-04-10T22:04:42 < antto> no BGA pls
2026-04-10T22:04:51 < antto> nor WLCSP or such
2026-04-10T22:06:07 -!- Livio [~livio@user/livio] has quit [Quit: leaving]
2026-04-10T22:06:46 < zyp> or just a mcu with pcie
2026-04-10T22:07:50 < zyp> I want something that's able to do pcie, but doesn't come with all the complexity of a typical cortex-a soc
2026-04-10T22:15:30 < catphish> i was under the impression that you could run PCIe as slow as you like, but now i can't find anything to back that up so maybe you can't
2026-04-10T22:18:50 < zyp> you absolutely can't
2026-04-10T22:19:48 < zyp> at least not without nonstandard lower layers in the stack
2026-04-10T22:20:42 < catphish> zyp: more seriously, can you do it with Zynq? seems like a viable option if you can
2026-04-10T22:20:43 < zyp> i.e. pcie needs support for at least a 2.5 GT/s phyiscal link
2026-04-10T22:21:03 < specing> what if you transfer the same ting a hundred times?
2026-04-10T22:21:09 < specing> then only 25 MT/s needed.
2026-04-10T22:21:25 < zyp> that makes no sense
2026-04-10T22:21:44 < zyp> but
2026-04-10T22:21:59 < specing> if you can't send at 2.5 GT/s, but only at 25 MT/s then it's effectively sampling one transfer a hundred times
2026-04-10T22:22:11 < specing> so you get the same info across 100 times
2026-04-10T22:22:18 < zyp> the stack implements flow control for the transaction layer
2026-04-10T22:23:07 < zyp> so you can run the transaction layer almost as slow as you want, as long as you reply within timeouts
2026-04-10T22:23:11 < catphish> zyp: i'm fairly sure the flow control is what i was thinking of, you can make the system wait as long as you like, but i guess you still need the symbol rate
2026-04-10T22:23:57 < zyp> yes, you need a 2.5 GT/s physical layer and a data link layer that keeps up with that, but the transaction layer can run slower
2026-04-10T22:25:18 < zyp> but I'm not sure how much point there is to that
2026-04-10T22:26:38 < catphish> well it would be useful if you tied a fast lower layer to a slower MCU - that's why i wondered if zynq would work
2026-04-10T22:28:10 < zyp> the thing is, 2.5 GT/s implies a peak burst throughput of 2 Gb/s because of the 8b10b encoding, and if you divide that by a 32b memory bus width, that's 62.5 MHz
2026-04-10T22:29:08 < zyp> so if you have a Gen1x1 link on one side of the stack and a 32b wide memory system on the other side, the memory system only needs to run at 62.5 MHz to be able to fully saturate the pcie link
2026-04-10T22:29:13 < catphish> makes sense, the more i look, the more i think zynq would work if you wanted a "MCU with PCIe"
2026-04-10T22:29:44 < zyp> it would, but it also kinda defeats the point
2026-04-10T22:30:45 < catphish> you'd need to set up your own PCIe peripheral in the FPGA, but still a viable single chip solution :)
2026-04-10T22:31:05 < zyp> part of the reason I want a mcu with pcie is so that I can pair the mcu+fpga without having to use a zynq :p
2026-04-10T22:31:35 < zyp> also zynq is cortex-a and comes with associated complexities
2026-04-10T22:31:55 < catphish> well then i guess you gotta use a separate FPGA then :)
2026-04-10T22:32:34 < specing> zyp: lattice had fairly inexpensive FPGA PCi-e cards for regular PC
2026-04-10T22:32:49 < zyp> I've got the fpga side solved, what I want is a simple mcu to pair with it
2026-04-10T22:32:49 < specing> I think it was $100
2026-04-10T22:33:00 < specing> but I ended up not buying because the software was only free trial for a year
2026-04-10T22:33:03 < catphish> making a PCIe card might be fun, but not sure i have a useful application
2026-04-10T22:33:04 < specing> or some such
2026-04-10T22:33:24 < zyp> specing, you're thinking of the discount they ran on the versa boards some years ago?
2026-04-10T22:33:33 < specing> catphish: could sell it to unis for students to have fun "speeding up" their PCs in time consuming ways
2026-04-10T22:33:45 < specing> zyp: perhaps
2026-04-10T22:33:53 < specing> dont' recall board name
2026-04-10T22:34:26 < zyp> https://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/ECP55GVersaDevKit
2026-04-10T22:34:45 < catphish> that doesn't seem outragously cheap for a board with an FPGA on it
2026-04-10T22:35:13 < catphish> that is rather cool though with RAM and ethernet too
2026-04-10T22:35:17 < zyp> I remember they had a discount on it some years ago, but I didn't see it until after it ended
2026-04-10T22:35:32 < zyp> anyway, that's the board I've been prototyping my pcie stack on
2026-04-10T22:35:48 < catphish> awesome
2026-04-10T22:35:57 < catphish> what are you using it for?
2026-04-10T22:36:07 < zyp> https://photos.app.goo.gl/BEmYoF41G4ohD5LWA
2026-04-10T22:36:14 < zyp> prototyping my pcie stack :p
2026-04-10T22:37:27 < catphish> i have 2 questions
2026-04-10T22:38:01 < zyp> specing, so the nice thing about the ecp5 is that it's well supported by yosys/nextpnr, so you don't need the vendor toolchain at all
2026-04-10T22:38:04 < catphish> 1) how is it connected to a PC? is that thunderbolt, or just a PCIe extender?
2026-04-10T22:38:04 < catphish> 2) do you have an actual use for it, or just for the pure joy of PCIe?
2026-04-10T22:38:36 < zyp> it's connected via an oculink cable
2026-04-10T22:39:38 < catphish> i've never even heard of that - is it just a pci-e port for laptops?
2026-04-10T22:39:51 < zyp> there's a m.2 to oculink adapter in the little blue pc behind it with a cable running out underneath the lid, running to an oculink to m.2 adapter, holding a m.2 to regular pcie slot adapter that the board is plugged into
2026-04-10T22:40:10 < zyp> I think it's more of a server thing really
2026-04-10T22:40:14 < catphish> lol makes sense
2026-04-10T22:40:32 < catphish> but it's basically just raw PCIe on a cable?
2026-04-10T22:41:07 < zyp> there's x4 and x8 variants, the 2U server I bought last year uses oculink cables to hook up pcie for the u.2-capable slots of the drive backplane
2026-04-10T22:41:10 < zyp> yup
2026-04-10T22:42:28 < zyp> so the x4 variant is a cable carrying four data lanes in each direction, a refclk and some other sideband channels (reset, wake, etc…)
2026-04-10T22:42:38 < zyp> sideband signals*
2026-04-10T22:43:14 < zyp> but yeah
2026-04-10T22:43:48 < zyp> since it's a way to get multilane pcie in a cable, there's a bunch of people using it to run external gpus and shit
2026-04-10T22:43:56 < zyp> so there's a bunch of adapters and shit available
2026-04-10T22:44:47 < zyp> and it's more convenient to have a devboard sitting on the desk attached to a cable than inserted into a computer somewhere
2026-04-10T22:46:36 < zyp> as for what I'm gonna use it for, the primary application I have in mind is robot control
2026-04-10T22:49:08 < specing> zyp: oh nice!
2026-04-10T22:49:13 < specing> zyp: and the non-nice thing?
2026-04-10T22:50:02 < specing> zyp: please stop using big tech infra, use e.g. p.more.coffee for picture sharing
2026-04-10T22:50:28 < specing> upload2coffee ()  { curl --upload-file "$1" https://p.mort.coffee; }
2026-04-10T22:51:02 < qyx> zyp and big tech infra for picture sharing?
2026-04-10T22:51:29 < qyx> ohvlol googl
2026-04-10T22:51:39 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-10T22:51:50 < zyp> qyx, I'm sometimes too lazy to put stuff on bin.jvnv.net when my phone already put it on google photos :p
2026-04-10T23:11:27 -!- Livio [~livio@user/livio] has quit [Ping timeout: 265 seconds]
2026-04-10T23:20:04 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-10T23:24:13 < catphish> I like the motherboards that have a ton of PCIe x1 ports that you can extend to run a bunch of GPUs
--- Day changed Sat Apr 11 2026
2026-04-11T00:54:49 -!- Livio [~livio@user/livio] has quit [Quit: leaving]
2026-04-11T00:58:03 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 255 seconds]
2026-04-11T01:02:45 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 244 seconds]
2026-04-11T03:45:42 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Remote host closed the connection]
2026-04-11T03:46:02 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2026-04-11T04:12:25 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Quit: Client closed]
2026-04-11T04:21:27 -!- hexo_ [~hexo@user/hexo] has quit [Remote host closed the connection]
2026-04-11T04:21:50 -!- hexo_ [~hexo@user/hexo] has joined ##stm32
2026-04-11T09:16:18 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Quit: KVIrc 5.2.6 Quasar http://www.kvirc.net/]
2026-04-11T09:41:29 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-11T10:18:14 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has joined ##stm32
2026-04-11T11:34:33 -!- teknix_ [~unknown@user/hsv] has quit [Ping timeout: 246 seconds]
2026-04-11T11:41:24 -!- teknix [~unknown@user/hsv] has joined ##stm32
2026-04-11T12:55:06 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-11T14:36:58 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2026-04-11T14:37:30 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-11T17:05:25 -!- Livio [~livio@user/livio] has quit [Ping timeout: 265 seconds]
2026-04-11T17:13:40 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-11T17:48:41 -!- jpka [~root@176.107.81.139] has joined ##stm32
2026-04-11T18:15:34 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 244 seconds]
2026-04-11T18:26:00 -!- xu-_^eXS [~^-e_XSSE-@188.242.99.109] has joined ##stm32
2026-04-11T18:32:11 -!- Livio [~livio@user/livio] has quit [Quit: leaving]
2026-04-11T18:50:59 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-11T18:54:53 -!- Livio [~livio@user/livio] has quit [Remote host closed the connection]
2026-04-11T18:56:01 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-11T19:00:53 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2026-04-11T19:20:45 -!- Livio [~livio@user/livio] has quit [Ping timeout: 265 seconds]
2026-04-11T19:35:50 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-11T19:45:50 -!- xu-_^eXS [~^-e_XSSE-@188.242.99.109] has quit [Read error: Connection reset by peer]
2026-04-11T20:03:33 -!- ferdna [~ferdna@user/ferdna] has quit [Ping timeout: 244 seconds]
2026-04-11T20:12:34 < antto> bootloaders and firmwares which work on chips with bootloaders - do they use a soft-reset between jumping from/to each "side" or do they just merely "jump" and don't ever use soft-reset?
2026-04-11T20:14:03 < qyx> I always do full reset
2026-04-11T20:17:36 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2026-04-11T20:19:01 < antto> in my latest bootloader (which is the fanciest so far), the bootloader has one early point where it can "jump" to the firmware, if it doesn't - it continues forward and initializes peripherals for communication, initializes crystals so it can switch to faster clock, and waits to communicate... then if the Host tells it to run the firmware from that point - it doesn't just go and jump to it - it does a system reset and jumps to the firmware from the "early" 
2026-04-11T20:19:01 < antto> point
2026-04-11T20:19:30 < antto> when the firmware wants to run the bootloader - it does a system reset too
2026-04-11T20:20:41 < antto> now i've been wondering if i'll manage to make USB serial on these MCUs (the one that doesn't need special OS drivers), and whether this could be used for both the bootloader<->PC and firmware<->PC
2026-04-11T20:21:08 < antto> but i think this system resetting will probably cause the USB device as seen from the PC to vanish and re-appear
2026-04-11T20:27:47 < qyx> probably but it doesn't matter, some lte modems do that too
2026-04-11T20:31:03 < antto> other than that, any recommendation for a USB-serial chip (i want to have a backup in case i can't figure out how to do it on the MCU), i know FTDI and microsh*t have options, but i saw a chip from silabs which uses the "no drivers" way
2026-04-11T20:36:02 < qyx> i am using cp2102
2026-04-11T20:37:13 < antto> i think it's that one
2026-04-11T20:37:48 < antto> oh, i think FTDI also has such, FT260
2026-04-11T20:38:43 < zyp> antto, you generally want the USB to disconnect and reconnect
2026-04-11T20:39:11 < zyp> usually when you have a USB-capable bootloader, it has a different configuration descriptor than the normal application
2026-04-11T20:39:47 < zyp> in which case the disconnect is entirely necessary to make the host see the bootloader as a new device
2026-04-11T20:39:53 < zyp> also
2026-04-11T20:40:17 < zyp> even if they both presented an identical USB serial interface, it is stateful
2026-04-11T20:40:21 < antto> well, my problem is that on the PC side i use my own program that talks to the serial port, and it's written kinda dumb and doesn't know that the device vanishes, so when the device re-appears - linux gives it a different number ;P~
2026-04-11T20:40:33 < antto> i guess i should change my serial port code
2026-04-11T20:41:33 < veverak> I think that you can setup udev rules for the naming to stay consistent 
2026-04-11T20:41:53 < zyp> use /dev/serial/by-path/ or something
2026-04-11T20:42:07 < zyp> alternatively /dev/serial/by-id/
2026-04-11T20:42:42 < antto> my program just keeps the "file" open untill i manually press Disconnect
2026-04-11T20:42:51 < qyx> idk under linux all are "driverless"
2026-04-11T20:42:52 < antto> i should "fix" it
2026-04-11T20:43:26 < antto> qyx, i meant that the driver is not for a particular $vendor
2026-04-11T20:44:01 < antto> e.g. like the USB serial in the daplink
2026-04-11T20:44:16 < antto> it doesn't come out as ttyUSB it comes out as ttyACM
2026-04-11T21:00:38 < qyx> no, it is ttyUSB
2026-04-11T21:01:05 < qyx> at least cp2102
2026-04-11T21:15:01 < antto> i think i see, there's too many versions of the "CP2102", some old ones too, they have custom drivers, the newest version on silabs (has a C at the end) is without custom drivers i think
2026-04-11T21:17:04 < antto> slightly pricier than the FT260
2026-04-11T21:54:05 < catphish> antto: you 
2026-04-11T21:54:23 < antto> moi?!
2026-04-11T21:54:42 < catphish> antto: the simplest option is just to use the MCU's USB for both the ROM bootloader programming and then for CDC when it's booted
2026-04-11T21:54:50 < catphish> i pressed enter too soon :)
2026-04-11T21:56:05 < catphish> however the bootloader is unlikely to present a serial port, it'll usually present DFU, not sure if that's a problem for you
2026-04-11T21:56:08 < antto> sure, but that MCU will have to do a lot of things, timing-sensitive, complex sh*t (musical instrument type of sh*t), and i have zero experience with USB, so i don't wanna risk finding out that the USB plus the other things don't mix well together
2026-04-11T21:56:49 < antto> the bootloader which i am likely to put on this will be my own bootloader, which doesn't have "DFU"
2026-04-11T21:56:56 < antto> nor USB right now ;P~
2026-04-11T21:57:36 < catphish> well, you can absolutely use an external USB UART chip, and then use the same mictrocontroller UART for both programming and for communicarions then
2026-04-11T21:57:40 -!- akaWolf [~akaWolf@akawolf.org] has quit [Ping timeout: 265 seconds]
2026-04-11T21:57:45 < antto> i know
2026-04-11T21:58:16 < catphish> i just love using an STM32 with USB and DFU, not much that can go wrong
2026-04-11T21:58:18 < antto> if i could figure it out, it'd be great if i can get the MCU to do USB-serial and USB-MIDI at the same time
2026-04-11T21:58:49 < antto> and if that doesn't "get in the way" of all the other things that the MCU must do too
2026-04-11T21:59:04 < catphish> i'm pretty sure you can do that, but it'll be a bit less "out of the box" and need some learning of how to manage all the endpoints
2026-04-11T21:59:08 < antto> but i don't know yet, so i'd wanna have a backup
2026-04-11T21:59:20 < catphish> IMO it'll work and it'd be worth the effort
2026-04-11T21:59:52 < catphish> if you need USB MIDI anyway then an extra external chip would mean you also need a USB hub i assume
2026-04-11T21:59:52 < antto> yeah, i've read a little bit about the USB, it has dedicated DMA and built-in resistors and sh*t, you just put a TVS thing and a USB connector on it
2026-04-11T22:00:19 < antto> nah, the USB-MIDI was only a possible bonus
2026-04-11T22:00:31 < antto> i already have "real" MIDI on this device
2026-04-11T22:00:44 < catphish> basically yes, you just connect D+ and D- and ideally a (easily available) ESD protection chip, and that's it
2026-04-11T22:01:36 < catphish> (and GND) :)
2026-04-11T22:02:02 < antto> the only USB experience i have is in my samd21_daplink board, i added auto-generated code for USB-serial from atmel.start, and that code "worked", i got a ttyACM0 device from there and it echo'ed everything you send to it
2026-04-11T22:02:22 < antto> but.. autogenerated $vendor code is muchos x_x
2026-04-11T22:03:03 < catphish> yeah the USB code is probably quite verbose, though mostly just boilerplate to send the descriptors
2026-04-11T22:05:13 < catphish> on the other hand, i guess UART is simple, and maybe more robust if you are implementing your own bootloader
2026-04-11T22:06:44 < catphish> i am however a masochist who would want to make sure every possible feature is possible, and OCD minimize the BOM
2026-04-11T22:09:47 < zyp> > maybe more robust
2026-04-11T22:09:48 < zyp> heh
2026-04-11T22:10:46 < zyp> keep in mind USB includes reliable delivery (checksumming, discarding corrupting packets and retransmitting lost packets)
2026-04-11T22:11:04 < zyp> you need a bunch of stuff on top of a UART to make it as reliable as USB
2026-04-11T22:16:33 < jpa-> but how much stuff do you need to make USB + CH340 + UART reliable? ;)
2026-04-11T22:18:28 < catphish> it's more that i feel like i'd be less likely to mess up writing a bootloader with UART vs one with a full USB stack
2026-04-11T22:18:49 < catphish> (hence why i use the ROM DFU) :)
2026-04-11T22:19:29 < qyx> my bootloader doesn't do any comms
2026-04-11T22:19:54 < qyx> there is no point in supporting that for OTA
2026-04-11T22:20:23 < catphish> what's the purpose of a bootloader if all it does it... loads and boots
2026-04-11T22:20:44 < qyx> it manages updates, rollbacks, etc.
2026-04-11T22:20:51 < qyx> also authentication
2026-04-11T22:21:13 < catphish> oh yeah that makes sense, so you can have multiple slots, verify, and boot the latest valid one
2026-04-11T22:21:20 < catphish> (or something like that)
2026-04-11T22:21:24 < qyx> yes
2026-04-11T22:21:40 < qyx> and the firmware image store is managed from the app code
2026-04-11T22:21:47 < catphish> yeah that does seem very sensible
2026-04-11T22:22:04 < catphish> assuming the app is smart enough to never erase itself
2026-04-11T22:23:15 < qyx> well, the flash could be locked (and should be) but I am not managing that yet
2026-04-11T22:23:20 < qyx> also a reset is enough
2026-04-11T22:23:34 < qyx> bootloader sees the app is corruoted and flashes it back
2026-04-11T23:32:17 -!- akaWolf [~akaWolf@akawolf.org] has joined ##stm32
2026-04-11T23:34:15 -!- nerozero [~nerozero@87.253.63.54] has quit [Remote host closed the connection]
2026-04-11T23:36:36 -!- akaWolf [~akaWolf@akawolf.org] has quit [Ping timeout: 255 seconds]
2026-04-11T23:37:25 -!- akaWolf [~akaWolf@akawolf.org] has joined ##stm32
2026-04-11T23:39:22 < antto> UART being async is not too cool, what's more reliable is syncronous USART
2026-04-11T23:41:54 -!- akaWolf [~akaWolf@akawolf.org] has quit [Ping timeout: 248 seconds]
2026-04-11T23:42:33 -!- akaWolf [~akaWolf@akawolf.org] has joined ##stm32
2026-04-11T23:44:50 < antto> i have two MCUs on this board so far, and they need to talk to each other "fast", so i slapped a whole SERCOM on each (4 signals) for that, i can make it work as synchronous USART or SPI
--- Day changed Sun Apr 12 2026
2026-04-12T00:06:14 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 265 seconds]
2026-04-12T00:43:23 < teknix> so, just a USRT?
2026-04-12T01:30:20 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has quit [Quit: Bye]
2026-04-12T01:37:53 < antto> yes
2026-04-12T02:17:31 -!- qyx [~qyx@84.245.120.235] has quit [Ping timeout: 244 seconds]
2026-04-12T02:19:33 -!- qyx [~qyx@84.245.120.37] has joined ##stm32
2026-04-12T02:34:54 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 245 seconds]
2026-04-12T02:53:07 -!- ferdna [~ferdna@user/ferdna] has quit [Ping timeout: 264 seconds]
2026-04-12T04:19:27 -!- hexo_ [~hexo@user/hexo] has quit [Remote host closed the connection]
2026-04-12T04:19:51 -!- hexo_ [~hexo@user/hexo] has joined ##stm32
2026-04-12T05:29:34 -!- cutofmyjib [~cutofmyji@user/cutofmyjib] has joined ##stm32
2026-04-12T07:23:16 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2026-04-12T09:52:43 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-12T09:59:47 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has joined ##stm32
2026-04-12T10:06:04 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-12T11:00:47 < catphish> SPI is awesome, not only because it's synchronous, but also because chip select gives you framing - i'm sure you can achieve the same thing with a UART, but with SPI it's always there
2026-04-12T11:03:19 < antto> SPI is slightly less fun, sync USART allows both sides to talk whenever they want to
2026-04-12T11:04:10 < antto> with SPI, the sl*ve cannot talk when the master stops generating clock
2026-04-12T11:17:38 < catphish> that's true, i guess it depends on the application, i guess i rarely run into a situation where i want both sides speaking whenever they want but i'm sure there are times you want that
2026-04-12T11:19:40 < catphish> are we not saying slave now in case we accidentally remind people of human slavery?
2026-04-12T11:52:33 < jpa-> implementing spi peripherals in software is annoying in that you need to respond quickly when host starts talking, or specify the protocol so that response is available only after a delay
2026-04-12T11:59:48 < antto> jpa-, exactly, thus i generally prefer sync usart
2026-04-12T12:00:19 < antto> it's like UART with a clock, so no baudrate guessing and sh*t
2026-04-12T12:00:46 < antto> unfortunately, not many MCUs have this
2026-04-12T12:01:23 < antto> i was looking for a USB-serial chip with a sync USART output, but didn't find one, they were all UART
2026-04-12T12:02:22 < antto> perhaps i could make one with a samd21 if i can do the firmware part myself
2026-04-12T12:04:37 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-12T12:08:04 < jpa-> some people are able to agree on a baudrate instead of having to guess it
2026-04-12T12:08:17 < jpa-> especially in 1 person projects it can be done
2026-04-12T12:10:26 < zyp> the sync USARTs I've looked at really only have sync support in the transmitter side, receiver side doesn't give a fuck and still just recovers the clock from the data
2026-04-12T12:12:22 -!- Livio [~livio@user/livio] has quit [Ping timeout: 265 seconds]
2026-04-12T12:24:17 < antto> zyp, you've looked in the wrong places then ;P~
2026-04-12T12:24:48 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-12T12:25:12 < zyp> that's okay, I don't feel any need to use sync USART
2026-04-12T12:25:12 < antto> the whole point of it being "sync" is that the sl*ve does not have to guess the clocks or look for edges in the data
2026-04-12T12:26:47 < antto> basically, it's like SPI without CS, there's also a UART "frame" around the data (start bit, stop bits, etc) and the m*ster generates clock all the time
2026-04-12T12:26:56 < zyp> if you don't want to write «slave», can't you just use a better word? I would suggest «receiver» in this context
2026-04-12T12:27:10 < zyp> the asterisks just makes you look stupid
2026-04-12T12:27:18 < antto> i wanna write sl*ve but with a missing letter ;P~
2026-04-12T12:27:32 < antto> great, i don't want to look clever
2026-04-12T12:27:38 < zyp> fair enogh
2026-04-12T12:43:47 -!- Livio [~livio@user/livio] has quit [Ping timeout: 265 seconds]
2026-04-12T13:23:05 < Steffanx> I don't know how to write the « and » .
2026-04-12T13:45:02 < antto> Steffanx, save them in a .txt file and copy them from there later
2026-04-12T15:44:31 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-12T16:20:48 -!- Livio [~livio@user/livio] has quit [Ping timeout: 265 seconds]
2026-04-12T16:54:56 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has quit [Quit: Bye]
2026-04-12T17:45:50 -!- JazzEnjoyer [~void@user/JazzEnjoyer] has joined ##stm32
2026-04-12T18:15:51 < mawk> I programmed, printed, put in a sleeve and attached a keyring on 100 NFC cards
2026-04-12T18:15:55 < mawk> especially putting the keyring hurts the fingers
2026-04-12T18:15:59 < mawk> idk how they do it in factories
2026-04-12T20:05:55 -!- JazzEnjoyer [~void@user/JazzEnjoyer] has quit [Quit: WeeChat 4.8.2]
2026-04-12T20:12:08 < catphish> zyp: i don't see how you could recover the clock from a USART frame, there is no clock in the data
2026-04-12T20:12:30 < catphish> or do you mean they will only work with a known baud rate?
2026-04-12T20:16:02 < catphish> i would probably still stick with SPI personally, and if i really need both ends to be able to control when data is sent then i'd just use two SPI peripherals (a master and a slave on both devices). i'm not really a fan of the fr*ming that USART gives you as it only fr*mes one byte at a time, not a whole message
2026-04-12T20:26:37 < qyx> you can switch spi roles on the fly, so the clock is always provided by the sender
2026-04-12T20:27:03 < qyx> and also use only 3 wires, miso and mosi fused together
2026-04-12T20:27:15 < qyx> so you have data, clk and frame signal
2026-04-12T20:27:23 < qyx> (miso+mosi, sck, cs)
2026-04-12T20:27:47 < qyx> I used it that way, even for a multidrop short bus
2026-04-12T20:45:52 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 244 seconds]
2026-04-12T20:49:24 < catphish> i never considered multi master SPI
2026-04-12T21:25:46 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-12T22:03:58 -!- Livio [~livio@user/livio] has quit [Ping timeout: 265 seconds]
2026-04-12T22:12:58 -!- drzacek [~quassel@2a01:3d8:3d0:2700:455e:7823:265d:2761] has joined ##stm32
2026-04-12T23:35:35 -!- hexo__ [~hexo@user/hexo] has joined ##stm32
2026-04-12T23:39:07 -!- nerozero [~nerozero@87.253.63.54] has quit [Remote host closed the connection]
2026-04-12T23:53:11 -!- drzacek [~quassel@2a01:3d8:3d0:2700:455e:7823:265d:2761] has quit [Quit: quit]
--- Day changed Mon Apr 13 2026
2026-04-13T00:24:43 -!- hexo__ [~hexo@user/hexo] has quit [Ping timeout: 268 seconds]
2026-04-13T00:30:19 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 264 seconds]
2026-04-13T00:30:30 < qyx> it is pretty usable, I did 1 mbit/s between 2 or 3 boards connected by mezzanine connectors
2026-04-13T00:31:40 < qyx> today I would just use a single wire uart with protocol-level framing
2026-04-13T00:32:04 < qyx> my main motivation for multi-master spi was the ability to change bitrate easily
2026-04-13T00:33:23 < qyx> but in the end I had to send the frame header always at 1 mbit/s because if any of the boards wasn't able to go faster, it would be confused and disrupt the traffic probably
2026-04-13T00:34:01 < qyx> so I planned to dynamically change the baudrate intra-frame like can-fd does
2026-04-13T00:34:19 < qyx> at that point it became so complex I lost the motivation
2026-04-13T04:16:30 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-13T07:33:45 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 248 seconds]
2026-04-13T08:14:21 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-13T09:04:46 -!- krish2487 [~krishi@cpe.ge-8-1-4-100.henqe12.dk.customer.tdc.net] has joined ##stm32
2026-04-13T10:04:38 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 244 seconds]
2026-04-13T10:16:28 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2026-04-13T10:19:57 < zyp> catphish, one issue with using CS for framing is that the SPI peripheral doesn't necessarily tell you when it gets deasserted, IIRC stm32 just uses it to gate the receiver/transmitter
2026-04-13T10:20:55 < zyp> so you'd have to poll it or use EXTI or something and manually synchronize that against the data received
2026-04-13T10:21:29 < zyp> and at that point, what prevents you from using a sideband signal next to a UART for framing?
2026-04-13T10:26:10 < zyp> personally I think SPI is great when you're accessing hardware registers, since shift registers are easy to do in hardware and doesn't need flow control or whatever
2026-04-13T10:27:37 < zyp> when you're doing a command/response kinda thing where firmware needs time to prepare the response, it's more convenient to just let the device send the response whenever it's ready
2026-04-13T10:51:36 < antto> i've thought about using SPI for communication between 2 MCUs and... sync USART is just better and simpler... yes, it has 2 bits overhead, but i don't mind
2026-04-13T10:52:47 < antto> with SPI things need to be more coordinated
2026-04-13T11:04:40 < zyp> and async UART is even simpler
2026-04-13T11:26:40 < antto> eh, no
2026-04-13T11:26:52 < antto> well, only electrically
2026-04-13T11:28:20 < antto> with async, the sl*ve has to be told what the bitclock rate is, then it has to internally generate it and try to sync it with the data edges.. thus you have oversampling and sh*t
2026-04-13T11:29:05 < antto> with sync, you have a 3rd signal, but the sl*ve doesn't care about the rate, it doesn't generate a clock, it just takes it from outside, it doesn't have to oversample
2026-04-13T11:32:38 < antto> now, in my current project, i will probably try to use SPI at first, because i will probably make a very tight structure of data which has to be tossed every 1ms or so, and it might work, but if that turns out too awkward, i can switch both MCUs to sync USART on the same pins
2026-04-13T11:42:49 < tomeaton17> another week of pain I am really excited
2026-04-13T11:43:04 < tomeaton17> why are you censoring slave antto 
2026-04-13T11:43:45 < antto> so someone doesn't feel insulted ;P~
2026-04-13T11:43:54 < antto> and to mock the idea of censorship
2026-04-13T11:44:20 < antto> but, are you sure i meant sl*ve and not sl*ve?
2026-04-13T11:46:02 < tomeaton17> I agree, I think we should abandon our long standards and instead use different terms for miso and mosi across chip manufacturers to confuse the fuck out of everyone that is good progress
2026-04-13T11:47:25 < tomeaton17> thanks adafruit
2026-04-13T11:48:33 < antto> HOCI/HICO ... it doesn't sound nice
2026-04-13T11:49:23 < tomeaton17> lol that somes it up, oshwa wants pico and poci
2026-04-13T11:49:32 < tomeaton17> s/somes/sums
2026-04-13T11:50:12 < antto> pizzo and pozzi
2026-04-13T11:51:13 < antto> on my sync USART i named the signals MRST and MTSR
2026-04-13T11:51:30 < antto> (so they're distinct from the SPI which i have there too)
2026-04-13T12:00:09 < tomeaton17> based?
2026-04-13T12:01:22 < qyx> idk, I am using miso and mosi
2026-04-13T12:02:42 < tomeaton17> qyx: good
2026-04-13T13:33:47 -!- hexo [~hexo@user/hexo] has quit [Remote host closed the connection]
2026-04-13T13:34:33 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2026-04-13T13:46:17 -!- hexo [~hexo@user/hexo] has joined ##stm32
2026-04-13T14:39:36 -!- haritz [~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8] has joined ##stm32
2026-04-13T14:39:36 -!- haritz [~hrtz@user/haritz] has changed host
2026-04-13T14:56:36 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-13T15:47:08 -!- rajkohaxor [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-13T15:49:49 -!- rajkohaxor [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Client Quit]
2026-04-13T15:50:11 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 244 seconds]
2026-04-13T16:08:49 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2026-04-13T16:10:05 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-13T16:13:54 < Posterdati> hi
2026-04-13T16:37:49 -!- krish2487 [~krishi@cpe.ge-8-1-4-100.henqe12.dk.customer.tdc.net] has quit [Ping timeout: 276 seconds]
2026-04-13T17:18:13 -!- rob_w_ [~bob@2001:a61:6156:3d01:a5c6:beef:d8b2:d2d5] has joined ##stm32
2026-04-13T17:18:15 -!- rob_w_ [~bob@2001:a61:6156:3d01:a5c6:beef:d8b2:d2d5] has quit [Remote host closed the connection]
2026-04-13T17:26:39 < karlp> man I love when there's an APi with a whole slew of return codes, and there's not a single palce in the entire codebase where the return code is ever checked.
2026-04-13T17:29:06 < zyp> imagine if you could be forced to
2026-04-13T17:36:27 < karlp> let me guess, starts with r and ends with ust?
2026-04-13T17:39:16 < tomeaton17> robust?
2026-04-13T17:40:53 < qyx> oh yeah we indeed have robust static checkers for that so people are not required to reinvent new languages
2026-04-13T17:55:20 < jpa-> i just write (void) in front of every function call, no matter what it returns
2026-04-13T18:04:38 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2026-04-13T18:08:54 < zyp> karlp, nah, it's just a warning in rust, equivalent to [[nodiscard]] in C/C++
2026-04-13T18:09:36 < zyp> and yes, it's standardized even in C since C23: https://en.cppreference.com/w/c/language/attributes/nodiscard.html
2026-04-13T18:10:49 < zyp> if you want error conditions that can't be ignored, you'd have to use exceptions or something :)
2026-04-13T18:32:57 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2026-04-13T18:40:07 < c10ud> so you can pokemon exception handling all over the code :D
2026-04-13T18:40:08 < tomeaton17> Laurenceb_: idnet are a nice isp
2026-04-13T18:59:07 < Laurenceb_> hi all
2026-04-13T18:59:48 < Laurenceb_> anyone know how to get inline source code with arm-none-eabi-objdump?
2026-04-13T19:00:09 < Laurenceb_> arm-none-eabi-objdump -dgSxtsC    is not doing it for me
2026-04-13T19:49:06 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-13T19:58:39 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-13T20:14:06 -!- Livio [~livio@user/livio] has quit [Ping timeout: 265 seconds]
2026-04-13T20:17:03 -!- h200 [~h200@2401:4900:1c96:14a6:cc2e:a92f:da53:cbe3] has joined ##stm32
2026-04-13T20:50:57 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-13T20:53:52 < catphish> zyp: that's interesting, i'm more familiar with sending it than receiving it, and lots of ASICs use the CS to frame a whole message
2026-04-13T20:54:19 < catphish> i've never actually implemented an SPI slave in STM32
2026-04-13T20:55:25 < zyp> doing a SPI target is easy when you can do it in HDL, less so when you do it in firmware :)
2026-04-13T20:55:42 < catphish> but yes, very little difference between CS vs using sync serial with a GPIO for framing
2026-04-13T20:56:07 < h200> any group to learn stm inclination towards edge device
2026-04-13T20:56:09 < catphish> yeah, i've only implemented it in FPGA
2026-04-13T20:56:25 < zyp> seems silly to use a sideband GPIO for framing though
2026-04-13T20:56:32 < zyp> if you need framing, just slap COBS on it
2026-04-13T20:57:09 < catphish> zyp: i've never heard of that but i feel like it might be time i learned it, because i love framing
2026-04-13T20:57:27 < zyp> https://en.wikipedia.org/wiki/Consistent_Overhead_Byte_Stuffing
2026-04-13T20:58:01 < zyp> it's an escape scheme to escape null bytes from your frames so you can use null as a frame delimiter
2026-04-13T20:58:22 < zyp> for small messages, it adds exactly one byte of overhead
2026-04-13T21:01:35 < zyp> then once you have your messages framed, just add a checksum to the end, and then whenever you receive a null byte you check if whatever you received has a valid checksum and discard it otherwise
2026-04-13T21:01:39 < zyp> simple and robust
2026-04-13T21:02:00 < zyp> so it's my goto whenever I need to add framing to a bytestream
2026-04-13T21:02:56 < catphish> yeah i like that
2026-04-13T21:04:00 < zyp> other schemes like prefixing messages with length can run into issues where the receiver reads some garbage as length and ends up stuck waiting forever for a huge message to finish
2026-04-13T21:04:20 < zyp> with COBS it's unabiguous when you get a null byte that a new message will start after
2026-04-13T21:06:59 < rajkosto> zyp, the whole planet is on a COB ?
2026-04-13T21:07:29 < zyp> I don't have an answer to that
2026-04-13T21:07:31 < catphish> zyp: yeah, i prefer trailing information rather than leading, that way you can just wait for it before making a decision about anything
2026-04-13T21:09:23 < veverak> he nice thing that with starting/ending each message with 0 you can reset the stream quite reliably
2026-04-13T21:09:26 < veverak> :)
2026-04-13T21:09:34 < veverak> anyway, COBS is also goto framing solution at my work
2026-04-13T21:10:27 < veverak> COBS+protobuf is our default
2026-04-13T21:11:55 < aandrew> COBS is pretty popular, I tend to like SLIP for its simplicity but admit it's got limitiations
2026-04-13T21:12:38 < zyp> client asked my boss last week if we had made the protocol specification for some UART interface yet, so boss asked me, I'm like «I don't even know what we're gonna use this UART for, so somebody needs to specify that first, and then I can write a protocol specification»
2026-04-13T21:13:07 < zyp> «but in any case I figure I'd propose COBS for framing and maybe protobuf messages on top»
2026-04-13T21:15:42 < aandrew> yeah protobuf is pretty good and is inherently extensible if you're smart about the messaging. I just hate how people end up doing it stupidly and end up encoding a bunch of binary hasSomeParameterType booleans 
2026-04-13T21:16:28 < aandrew> COBS downside is the frame buffer
2026-04-13T21:16:55 < aandrew> the encoding side has to keep a buffer of 256 bytes around before it can send anything
2026-04-13T21:19:16 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 276 seconds]
2026-04-13T21:21:51 -!- h200 [~h200@2401:4900:1c96:14a6:cc2e:a92f:da53:cbe3] has quit [Quit: Client closed]
2026-04-13T21:24:11 < ColdKeyboard> Anyone have a recommendation on how to route USB3.x lines on 4L/6L board?
2026-04-13T21:24:29 < ColdKeyboard> Having A and B on opposite sides is PITA unless I'm missing something obvious
2026-04-13T21:25:01 < veverak> aandrew: wdym?
2026-04-13T21:25:15 < veverak> we usually have output buffer anyway so worst case I have to increase it by few bytes
2026-04-13T21:25:23 < veverak> (you get 1+255/n overload)
2026-04-13T21:26:08 < veverak> zyp: I wrote generic high level guideline for firmware development last month, one of the points is: use proto+cobs unless you have a good reason not to
2026-04-13T21:51:01 < aandrew> veverak: you cannot emit the start of your COBS frame until you know how long your frame is, and you can't do that until you see the next zero or 254 bytes later
2026-04-13T21:51:12 < aandrew> that's my only real beef with it
2026-04-13T21:51:22 < aandrew> you can dick around with rCOBS or something but that's kind of yuck
2026-04-13T21:51:27 < veverak> aandrew: that does not really pose an issue in our codebase
2026-04-13T21:51:41 < veverak> I have buffer somewhere along the road anyway, so I just slap it on some
2026-04-13T21:52:01 < veverak> (mostly there is output buffer in UART driver which is filled for _Transmit that runs via DMA)
2026-04-13T21:52:37 < aandrew> SLIP is nice in that there's none of that although you can really blow out your bandwidth needs if your datastream has a lot of 0xc0 and 0xdb in it
2026-04-13T21:53:22 < aandrew> so it's a kind of "pick your poison" kind of thing. neither are particlarly onerous 
2026-04-13T21:53:38 < veverak> frankly, I can't think of a situation where It would be a bother to have a buffer somewhere?
2026-04-13T21:53:44 < veverak> there usually is at least one
2026-04-13T21:54:12 < veverak> (might be ym lack of fantasy)
2026-04-13T21:54:23 < aandrew> sometimes the memory available is awfully small so a 254 byte buffer is taxing
2026-04-13T21:54:36 < aandrew> but admittedly that is rare
2026-04-13T21:54:46 < veverak> seems like it
2026-04-13T22:07:59 < qyx> nah I went from protobuf to cbor
2026-04-13T22:11:05 < aandrew> what were your reasons?
2026-04-13T22:11:11 < aandrew> (no judgement, just curious)
2026-04-13T22:18:53 < qyx> json compatibility, no IDL compile step, no IDL at all (not forced to use one), a bit more standardized than protobuf, which is google's one man show
2026-04-13T22:19:55 < qyx> and most protobuf libraries decode messages in one step, although not required to do so, you can do it manually if you are adventurous enough
2026-04-13T22:20:06 < qyx> on the other hand, with cbor libs available, it is the default modus operandi
2026-04-13T22:20:18 < catphish> ColdKeyboard: i think you need to be more specific - ideally the parts are on the top and you just run the lines on the top and the number of layers doesn't matter
2026-04-13T22:22:17 < catphish> ColdKeyboard: what do you mean about A and B on opposite sides? are you aware that the polarity of the SSTX and SSRX pairs doesn't matter?
2026-04-13T22:22:59 < aandrew> the part I disliked about protobufs was needing proto-c even if not using it for the code
2026-04-13T22:24:12 < aandrew> I typically used nanopb which worked quite nicely and was self-contained (except for the reliance on proto-c on the host, which needed the host to have proto-c's dependenices) - got around that-ish with cmake making a venv which is a disgusting hack but works
2026-04-13T22:24:41 -!- Livio_ [~livio@user/livio] has joined ##stm32
2026-04-13T22:27:59 -!- Livio [~livio@user/livio] has quit [Ping timeout: 265 seconds]
2026-04-13T22:36:51 -!- PaulFertser [paul@paulfertser.info] has quit [Read error: Connection reset by peer]
2026-04-13T22:39:30 < ColdKeyboard> catphish I've mostly done USB2.0. Now I have to route USB3.0 HUB and the "annoying" part is that for example TX pair is B10/11 an A10/11 but they are "mirrored" across the connector
2026-04-13T22:40:27 < ColdKeyboard> So I guess I would have to route using vias from B-to-A to join them, and then route everything to the hub IC
2026-04-13T22:40:33 -!- Livio_ [~livio@user/livio] has quit [Quit: leaving]
2026-04-13T22:40:52 < zyp> haha, no
2026-04-13T22:41:39 < zyp> connecting the A and B sides together works for USB2, but for USB3 you need an active mux chip
2026-04-13T22:43:09 < zyp> for USB2, the plug only terminates the A side, so you get a little stub on the signals that ends up on the plug's B side, but not major enough to break USB2
2026-04-13T22:44:03 < zyp> for USB3, there's actually four full data pairs in the cable, and you can't connect them together
2026-04-13T22:45:05 < qyx> missing something obvious then
2026-04-13T22:45:07 < zyp> USB 3.2 supports an x2 mode using two tx and two rx lanes
2026-04-13T22:45:52 < zyp> and there's hybrid modes like all the usb-c docks that runs usb3 over two pairs and displayport over the other two
2026-04-13T22:46:06 < zyp> anyway
2026-04-13T22:46:25 < zyp> if you're doing a hub thing, just grab a hub chip with usb-c support
2026-04-13T22:46:37 < zyp> then you just run all four pairs directly to the hub chip
2026-04-13T22:51:15 < ColdKeyboard> That's what I have (USB5734) but I still have to route both A and B signals from the connector, right?
2026-04-13T22:54:11 < ColdKeyboard> The D-/D+ is USB2.0 and then there is one TX and one RX pair going to the hub.
2026-04-13T22:54:31 < ColdKeyboard> But on the USB-C connector, I have TX/RX pairs on A and B side and they are on the opposite ends of the connector :)
2026-04-13T23:00:50 < ColdKeyboard> But I assume I messed something up like usual :)
2026-04-13T23:03:44 < ColdKeyboard> "The TX and RX pairs are also flipped. Resolving this was a bit more complicated. Unlike the D+ and D– lines,
2026-04-13T23:03:44 < ColdKeyboard> you cannot simply short the common lines together because that will create a stub. At USB 2.0 speeds, a stub is
2026-04-13T23:03:44 < ColdKeyboard> acceptable, but at USB 3.1 speeds, a stub degrades signal integrity too much"
2026-04-13T23:04:49 < ColdKeyboard> So I have to find a MUX now... let me know if you have a PN you used and liked :)
2026-04-13T23:28:18 < catphish> ColdKeyboard: oh, you can't connect the mirrored pairs in parallel with USB 3
2026-04-13T23:29:21 < catphish> with USB 2 on USB C, you can just connect the two D+ in parallel and the two D- in paralle, you can't do that with superspeed, the extra stubs will break the high speed link
2026-04-13T23:32:27 < ColdKeyboard> Thanks catphish, I copied the above from the app note I found so as usual I messed up :)
2026-04-13T23:32:42 < ColdKeyboard> Now I have to find a mux that I can use
2026-04-13T23:33:46 < catphish> yeah you need a mux
2026-04-13T23:34:15 < catphish> ColdKeyboard: i have only done one USB 3 board, and i made it easy for myself by using USB B https://iili.io/qmX1kYu.png
2026-04-13T23:34:45 < catphish> USB C is a huge pain in the ass
2026-04-13T23:35:07 < ColdKeyboard> I have B on the host side. But have to use USB C on the device side because I have PD as well :\
2026-04-13T23:35:13 < catphish> the only saving grace is you can reverse the polarity of the superspeed data lines, but you need to multiplex them :(
2026-04-13T23:35:49 < catphish> i assume you mean A on the host side, unless you're a lunatic :)
2026-04-13T23:37:03 < catphish> so yeah, for PD you're gonna need C, and a multiplexer chip, sadly i have no experience of that, but i'd *hope* the multiplexer chip was designed with the pad layout of USB C in mind, any other design would be sadistic
2026-04-13T23:37:06 < ColdKeyboard> On the host side it is A obviously, but on the PCB host plugs in to type B
2026-04-13T23:37:31 < ColdKeyboard> So you are using A-to-B cable to connect the hub to the PC
2026-04-13T23:38:19 < ColdKeyboard> Yeah, I'm looking for a mux, but then I need to find one that detects cable orientation or use another IC for that because my PD chip does not indicate cable orientation :(
2026-04-13T23:49:11 < catphish> ColdKeyboard: yes A to B cable, though i assume C to B would work too (i don't have one)
2026-04-13T23:49:36 < catphish> one moment i might be able to find you something
2026-04-13T23:49:57 < ColdKeyboard> catphish I had to get one of those C-to-B in orer to use J-Link with my laptop... honestly didn't know they existed until I needed it
2026-04-13T23:50:39 < catphish> C is very flexible, so connecting half of its pins to a B at the other end should work
2026-04-13T23:52:02 < catphish> ColdKeyboard: check HD3SS3220IRNHT
2026-04-13T23:52:18 < catphish> this might take care of your PD too
2026-04-13T23:56:14 < ColdKeyboard> Thanks catphish! I'll look at it. Seems to have more than I need so that's good. As long as it's not in conflict with the PD chip :D
2026-04-13T23:56:53 < catphish> ColdKeyboard: it's not really a recommendation, just something i saw in another project that seems quite capable
2026-04-13T23:58:40 < ColdKeyboard> Still, it points me in the right direction so I appreciate it :)
--- Day changed Tue Apr 14 2026
2026-04-14T00:05:46 < ColdKeyboard> I guess just to be sure I can buffer CC1/2 pins and send the buffered signal to the mux and then unbuffered would go to the PD chip
2026-04-14T00:06:37 < ColdKeyboard> Or is there some simple way to detect which CC is active and convert it to SEL signal? 
2026-04-14T00:08:46 < jbo> many chips have a "flipped" output
2026-04-14T00:11:39 < jbo> HD3SS3220IRNHT has it named as "DIR"
2026-04-14T00:13:51 < ColdKeyboard> jbo but if I want to use passive mux, I have to drive SEL pin to select how the mux shold connect
2026-04-14T00:14:32 < ColdKeyboard> I guess if I use active mux, I can just buffer the CC pins and hope it does not interfere when CC is used for PD negotiation
2026-04-14T00:19:14 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 248 seconds]
2026-04-14T00:20:07 < zyp> what's doing PD negotiation?
2026-04-14T00:20:25 < zyp> usually chips that are capable of doing PD negotiation are also capable of driving the DIR signal of a mux
2026-04-14T00:25:17 < ColdKeyboard> I'm using APK43070DKZ-13-FA01
2026-04-14T00:25:35 < ColdKeyboard> It has the PD negotiation and also driving the H/L DC-DC switch
2026-04-14T00:25:43 < ColdKeyboard> but it does not have direction indicator :\
2026-04-14T00:28:22 < jbo> that is a source - not a sink
2026-04-14T00:29:54 < ColdKeyboard> jbg correct, the hub has to be the DFP/source so the UFP/sink can ask for higher power
2026-04-14T00:30:15 < ColdKeyboard> I want the device connected to the USB hub also to be able to ask for higher power
2026-04-14T00:30:52 < ColdKeyboard> zyp If you have an alternative IC that does the same thing but also has DIR/Flip indicator, please let me know :)
2026-04-14T00:34:25 < zyp> idk, my PD knowledge is mostly theoretical so far
2026-04-14T00:36:07 < zyp> I've got a project at work for a device that'll be both sink and source, will use a stm32g0 to handle PD negotiation
2026-04-14T00:42:47 < ColdKeyboard> Now I'm curious why the CC-to-Orientation IC does not exist...
2026-04-14T00:43:25 < ColdKeyboard> Although my PD IC is not aimed for this application, but it's the only one I could find that does not use I2C to DC/DC regulator nonsense
2026-04-14T00:46:30 < qyx> hey pros, my timer is not counting, did I mention that
2026-04-14T00:46:51 < qyx> on h7, is there any catch besides setting CEN?
2026-04-14T00:47:03 < qyx> no master enable on TIM2
2026-04-14T01:07:23 < qyx> oh it works
2026-04-14T01:49:58 -!- tabemann [~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net] has quit [Ping timeout: 268 seconds]
2026-04-14T02:02:06 -!- tabemann [~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net] has joined ##stm32
2026-04-14T02:07:13 -!- PaulFertser [paul@paulfertser.info] has joined ##stm32
2026-04-14T02:13:26 -!- Phantom [~Phantom@user/phantom] has quit [Remote host closed the connection]
2026-04-14T02:17:42 -!- qyx [~qyx@84.245.120.37] has quit [Ping timeout: 256 seconds]
2026-04-14T02:19:38 -!- qyx [~qyx@84.245.120.133] has joined ##stm32
2026-04-14T02:20:48 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 268 seconds]
2026-04-14T02:32:06 -!- flatmush [~benbrewer@149.57.123.192] has quit [Ping timeout: 255 seconds]
2026-04-14T02:34:42 -!- flatmush [~benbrewer@149.57.118.164] has joined ##stm32
2026-04-14T02:51:11 -!- flatmush [~benbrewer@149.57.118.164] has quit [Ping timeout: 272 seconds]
2026-04-14T02:52:28 -!- flatmush [~benbrewer@149.57.121.233] has joined ##stm32
2026-04-14T03:25:09 < ColdKeyboard> qyx classic. Been there done that. :)
2026-04-14T03:55:03 -!- tabemann [~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net] has quit [Ping timeout: 246 seconds]
2026-04-14T03:56:51 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2026-04-14T03:59:04 < ColdKeyboard> So apparently Microchip holds a pattent on "USB-C Orientation Detection" which is basically, try communicating over A pair, if nothing, try B and that's it...
2026-04-14T03:59:53 < ColdKeyboard> This is why we have to use stupid mux, because a company patented an idea (pretty obvious one too) and it's not even using it. yay!
2026-04-14T04:00:46 < ColdKeyboard> https://patentimages.storage.googleapis.com/ed/d0/0a/bc36c5a7eb0973/WO2023164109A1.pdf
2026-04-14T04:01:34 -!- tabemann [~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net] has joined ##stm32
2026-04-14T04:04:16 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2026-04-14T04:11:18 -!- tabemann [~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net] has quit [Remote host closed the connection]
2026-04-14T04:13:07 -!- tabemann [~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net] has joined ##stm32
2026-04-14T04:33:03 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2026-04-14T05:02:13 -!- tabemann [~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net] has quit [Ping timeout: 265 seconds]
2026-04-14T05:04:45 -!- tabemann [~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net] has joined ##stm32
2026-04-14T05:12:47 -!- tabemann [~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net] has quit [Read error: Connection reset by peer]
2026-04-14T05:15:35 -!- tabemann [~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net] has joined ##stm32
2026-04-14T06:59:55 -!- teknix [~unknown@user/hsv] has quit [Ping timeout: 268 seconds]
2026-04-14T07:06:40 -!- teknix [~unknown@user/hsv] has joined ##stm32
2026-04-14T07:09:08 -!- infisd [~infisc@user/infisc] has joined ##stm32
2026-04-14T07:47:14 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Quit: Client closed]
2026-04-14T08:11:16 < antto> f*cking microsh*t
2026-04-14T08:12:46 < antto> ColdKeyboard, try B then A, to avoid the patent ;P~
2026-04-14T08:14:55 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2026-04-14T08:37:58 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-14T08:41:48 -!- haritz [~hrtz@user/haritz] has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
2026-04-14T09:16:01 -!- krish2487 [~krishi@cpe.ge-8-1-4-100.henqe12.dk.customer.tdc.net] has joined ##stm32
2026-04-14T09:44:16 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Quit: KVIrc 5.2.6 Quasar http://www.kvirc.net/]
2026-04-14T09:44:28 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2026-04-14T10:20:46 -!- ferdna [~ferdna@user/ferdna] has quit [Remote host closed the connection]
2026-04-14T10:26:07 -!- martinmoene_ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 268 seconds]
2026-04-14T10:36:25 < catphish> that patent is slop. unless i'm missing something findamental, what it describes (in far too many words) is so obvious i find it hard to believe anyone would take it seriously
2026-04-14T10:36:55 < zyp> probably also is not a valid approach per the usb-c spec
2026-04-14T10:37:17 < zyp> but who cares about following spec, eh
2026-04-14T10:37:30 < catphish> it's tempting to email andrew rogers and ask how he came up with such an innovation
2026-04-14T10:38:18 < catphish> i don't actually know what a multiplexer does
2026-04-14T10:38:19 < qyx> ask him if you can use the second trash bin when you find the first one full
2026-04-14T10:38:43 < qyx> or you need to pay royalty fees to do that
2026-04-14T11:15:00 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 246 seconds]
2026-04-14T11:37:55 < _Posterdati_> hi
2026-04-14T11:46:05 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2026-04-14T11:46:26 < Laurenceb_> anyone here know how to persuade objdump to output source code lines?
2026-04-14T11:46:36 < _Posterdati_> lol
2026-04-14T11:46:55 < _Posterdati_> do you mean to produce a .lst file?
2026-04-14T11:47:13 < _Posterdati_> with asm source code?
2026-04-14T11:47:39 < Laurenceb_> no I want to see the c source lines
2026-04-14T11:47:44 < _Posterdati_> ah
2026-04-14T11:47:49 < Laurenceb_>  -S is not working
2026-04-14T11:48:10 < _Posterdati_> arm-none-eabi-objdump ?
2026-04-14T11:51:11 < _Posterdati_> I use: arm-none-eabi-objdump -S -R .data file.elf
2026-04-14T11:51:15 < _Posterdati_> for asm
2026-04-14T11:53:07 < _Posterdati_> -S emit asm code
2026-04-14T11:56:09 < _Posterdati_> but decompilation is an hard task, I think objdump cannot emit C code starting from elf or binary code
2026-04-14T11:59:40 < Laurenceb_> oh ok
2026-04-14T11:59:46 < Laurenceb_> google says it can
2026-04-14T12:00:08 < Laurenceb_> if compilation uses -g to embed source line numbers
2026-04-14T12:00:09 < _Posterdati_> https://reverseengineering.stackexchange.com/questions/18970/generate-c-like-pseudo-code-from-objdump-output
2026-04-14T12:00:31 < _Posterdati_> ah ok, I was thinking you mean to reverse engineer a binary code
2026-04-14T12:00:57 < Laurenceb_> nah just my project
2026-04-14T12:01:04 < _Posterdati_> yes
2026-04-14T12:01:11 < _Posterdati_> let me see
2026-04-14T12:01:17 < _Posterdati_> I have an elf compiled with g
2026-04-14T12:05:56 < _Posterdati_> what was the -g switch parameter?
2026-04-14T12:10:48 < Laurenceb_> I think it enabled DWARF debug info
2026-04-14T12:12:08 < _Posterdati_> -gdwarf
2026-04-14T12:14:51 < Laurenceb_> yeah
2026-04-14T12:14:59 -!- jpka [~root@176.107.81.139] has quit [Read error: Connection reset by peer]
2026-04-14T12:18:27 -!- jpka [~root@176.107.81.139] has joined ##stm32
2026-04-14T12:27:52 -!- infisd [~infisc@user/infisc] has joined ##stm32
2026-04-14T12:31:59 < Laurenceb_> addr2line is also failing
2026-04-14T12:39:16 < Laurenceb_> think I found the issue:  arm-none-eabi-readelf --string-dump=.debug_info cannot find the section
2026-04-14T12:40:36 < _Posterdati_> ok
2026-04-14T12:44:33 < Laurenceb_> it was compiled with arduino ide, looks like "-g" option in the menu is actually ignored going from the verbose output
2026-04-14T12:45:04 < _Posterdati_> ah
2026-04-14T12:59:28 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2026-04-14T13:07:15 < _Posterdati_> Laurenceb_: that's why I prefer baremetal
2026-04-14T13:08:08 < Laurenceb_> fixed it, added -g to build_opt.h
2026-04-14T13:08:27 < Laurenceb_> looks like "debug" checkbox in arduino does nothing
2026-04-14T13:43:25 < tomeaton17> has anyone tried HAL 2 yet?
2026-04-14T13:45:17 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-14T13:55:01 -!- Livio [~livio@user/livio] has quit [Ping timeout: 265 seconds]
2026-04-14T14:25:08 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Quit: Client closed]
2026-04-14T14:36:43 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2026-04-14T14:36:47 < Laurenceb_> any c++ gurus here?
2026-04-14T14:37:12 < Laurenceb_> I'm creating a derived class for hardware timers
2026-04-14T14:37:14 < Laurenceb_> class HardwareTimer_ : public HardwareTimer {
2026-04-14T14:37:14 < Laurenceb_>   public:
2026-04-14T14:37:15 < Laurenceb_>     HardwareTimer_(TIM_TypeDef *instance) : HardwareTimer();
2026-04-14T14:37:27 < Laurenceb_> how do I create an initialiser prototype?
2026-04-14T14:37:44 < Laurenceb_> atm I'm getting error: redefinition of 'HardwareTimer_::HardwareTimer_(TIM_TypeDef*)'
2026-04-14T14:38:42 -!- mtoy [~mtoy@user/mtoy] has quit [Ping timeout: 246 seconds]
2026-04-14T14:46:48 -!- mtoy [~mtoy@user/mtoy] has joined ##stm32
2026-04-14T14:58:40 -!- haritz [~hrtz@140.228.70.141] has joined ##stm32
2026-04-14T14:58:40 -!- haritz [~hrtz@user/haritz] has changed host
2026-04-14T15:08:01 -!- tomeaton17 [~tom@user/tomeaton17] has quit [Quit: ZNC 1.9.0+deb2ubuntu0.1~esm2 - https://znc.in]
2026-04-14T15:08:39 -!- tomeaton17 [~tom@user/tomeaton17] has joined ##stm32
2026-04-14T15:41:37 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2026-04-14T15:48:07 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Ping timeout: 245 seconds]
2026-04-14T16:06:02 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2026-04-14T16:40:09 -!- krish2487 [~krishi@cpe.ge-8-1-4-100.henqe12.dk.customer.tdc.net] has quit [Ping timeout: 246 seconds]
2026-04-14T16:43:56 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-14T17:14:27 < karlp> well, I will agree that the quality of the errors you get form dts issues in zephyr is.... not friendly, but at least, it's a fairly straightforward pattern.
2026-04-14T17:14:37 < karlp> not having to setup i2c by hand is ace.
2026-04-14T17:14:57 < karlp> SHT3XD: 26.17 Cel ; 28.05 %RH
2026-04-14T17:41:48 < zyp> Laurenceb_, remove the colon and shit behind it, that goes on the definition, not the declaration
2026-04-14T17:42:00 < zyp> so having it there means you've got two definitions
2026-04-14T17:42:49 < zyp> or alternatively fuck prototypes and just put the definition in the header :p
2026-04-14T17:55:22 < Laurenceb_> yeah thanks, I need to learn to c++
2026-04-14T17:55:33 < Laurenceb_> compiles and runs now
2026-04-14T17:56:57 < zyp> I'd advise dropping it and learning rust instead
2026-04-14T17:57:55 < ColdKeyboard> Come on zyp, it's been almost 20hrs since I heard someone mention Rust... I hoped for at least a day :P
2026-04-14T17:58:13 < zyp> :D
2026-04-14T17:59:44 < ColdKeyboard> Wasn't there some kind of a shit-show within the Rust dev/maintener group and rust has forked/split and now there are two "rusts"... I think I read something like that
2026-04-14T18:02:01 < Laurenceb_> c++ unironically seems quite nice in modern versions
2026-04-14T18:05:03 < zyp> it is, modern c++ has improved a lot
2026-04-14T18:05:33 < zyp> but it's still burdened by legacy bullshit rust doesn't have to care about
2026-04-14T18:11:20 -!- martinmoene_ [~martinmoe@132.229.46.129] has joined ##stm32
2026-04-14T18:11:26 < specing> C++ is Borg language
2026-04-14T18:11:43 < specing> it will assimilate Rust's technological distinctiveness and add it to its own..
2026-04-14T18:11:51 -!- martinmoene [~martinmoe@132.229.46.129] has quit [Ping timeout: 246 seconds]
2026-04-14T18:12:13 < specing> zyp: maybe we'll see some serious compat breaking now that they dared introducing modules
2026-04-14T18:12:47 < zyp> does anybody support modules yet?
2026-04-14T18:13:06 < zyp> I got tired of waiting for build systems that do, so I wrote my own
2026-04-14T18:13:20 < specing> gcc probably
2026-04-14T18:13:46 < zyp> yeah, but somebody needs to call gcc with the appropriate arguments
2026-04-14T18:14:05 < zyp> https://github.com/zyp/erect
2026-04-14T18:14:16 < zyp> https://github.com/zyp/erect/tree/main/examples/hello_modules
2026-04-14T18:17:44 < zyp> I also refactored laks to use modules: https://github.com/zyp/laks/compare/main...dev_modules
2026-04-14T18:18:14 < zyp> ran into a couple of places where I crashed the compiler
2026-04-14T18:18:38 < zyp> but then again, this was 1.5 years ago, so it has probably matured some since
2026-04-14T18:20:49 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2026-04-14T18:47:33 < c10ud> nice uh choice of name for the prj
2026-04-14T18:48:26 < Laurenceb_> lmao
2026-04-14T18:49:01 -!- mercenary [~mercenary@user/mercenary] has quit [Quit: ZNC 1.10.1 - https://znc.in]
2026-04-14T18:50:22 -!- mercenary [~mercenary@user/mercenary] has joined ##stm32
2026-04-14T19:22:01 -!- cutofmyjib [~cutofmyji@user/cutofmyjib] has quit [Ping timeout: 248 seconds]
2026-04-14T19:24:29 < karlp> oik, second game with dt and I can't figure out it's issue this time :)
2026-04-14T19:24:37 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2026-04-14T19:26:15 -!- cutofmyjib [~cutofmyji@user/cutofmyjib] has joined ##stm32
2026-04-14T19:29:34 < zyp> welcome to zephyr :)
2026-04-14T19:29:45 < karlp> lol
2026-04-14T19:30:35 < karlp> want to do spi device first, before I write a full driver for it,
2026-04-14T19:30:41 < karlp> check that I've got th spi bits in place,
2026-04-14T19:30:58 < karlp> and before I go back to trying to turn on the usb peripherap, which didnt' come on "easily" :)
2026-04-14T19:32:08 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2026-04-14T20:12:06 -!- martinmoene__ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-14T20:14:46 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2026-04-14T20:39:06 < Posterdati> hi
2026-04-14T20:39:44 < Posterdati> please help, which is the best PendSV IRQ frequency for the stm32h723? Tanks!
2026-04-14T20:43:51 -!- hexo__ [~hexo@user/hexo] has joined ##stm32
2026-04-14T20:49:46 < zyp> frequency?
2026-04-14T20:50:50 < zyp> as in rescheduling frequency?
2026-04-14T21:13:49 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 276 seconds]
2026-04-14T21:29:44 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-14T22:28:17 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Quit: bitmask]
2026-04-14T22:38:53 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2026-04-14T22:54:10 < qyx> I am sad
2026-04-14T22:54:55 < qyx> I connected my external sources to PE12 and PA12
2026-04-14T22:55:08 < qyx> it looks like I can't have both enabled for EXTI
2026-04-14T23:08:59 -!- Livio [~livio@user/livio] has quit [Remote host closed the connection]
2026-04-14T23:10:38 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Quit: Client closed]
2026-04-14T23:11:58 < aandrew> yeah you can't
2026-04-14T23:12:03 < aandrew> I ran into that before as well
2026-04-14T23:12:16 < aandrew> Px# are all connected together
2026-04-14T23:13:32 < qyx> that makes me an extraordinary sad panda
2026-04-14T23:14:03 < qyx> wait what
2026-04-14T23:14:33 < qyx> yes that would not be an issue if they were conneted *both* to the *same* EXTI line
2026-04-14T23:14:42 < qyx> buf ai can only select either of them, not both
2026-04-14T23:14:47 < qyx> s/ai/I
2026-04-14T23:15:08 < aandrew> it's correct even without the correction. you can't do it, and neither can AI
2026-04-14T23:23:11 < Steffanx> What stm32 is this qyx?
2026-04-14T23:25:56 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 244 seconds]
2026-04-14T23:27:02 < zyp> every
2026-04-14T23:36:47 < Steffanx> Qyx doesn't use every stm32 on this board
2026-04-14T23:36:58 < Steffanx> He's crazy but not that crazy
2026-04-14T23:43:23 < qyx> Steffanx: h7, long time no see
2026-04-14T23:43:32 < qyx> and immediate fail
2026-04-14T23:44:16 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Quit: bitmask]
2026-04-14T23:51:18 < Posterdati> zyp: I set the reload value to obtain 1 us
2026-04-14T23:52:00 < qyx> 1 us what?
2026-04-14T23:52:14 < zyp> you said PendSV, are you talking about systick?
2026-04-14T23:52:14 < qyx> 1000 Hz tick rate is common
2026-04-14T23:52:18 < zyp> those are different things
2026-04-14T23:52:25 < Posterdati> systick
2026-04-14T23:52:51 < qyx> remember that you are cooperating by yielding, not by preemption
2026-04-14T23:52:53 < Posterdati> PendSV is triggered in the SYSTICK IRQ routine
2026-04-14T23:53:23 < qyx> if you need 1 MHz systick to keep your things tidy, you are doing soemthing wrong
2026-04-14T23:54:10 < Posterdati> qyx: no it worked ok even at 1 kHz
2026-04-14T23:54:31 < zyp> «worked ok» by what measure?
2026-04-14T23:55:15 < Posterdati> by the three working tasks
2026-04-14T23:56:47 < Posterdati> I have 1 us ticks
2026-04-14T23:57:08 < zyp> as in «I can context switch at 1 MHz and still have some time left over to actually run the tasks»?
2026-04-14T23:57:57 < Posterdati> the time left is PendSV, RNG and HSEM irqs
2026-04-14T23:58:43 < zyp> so according to a quick google search: Cortex-M context switch cycles typically range from 100 to 500+ CPU cycles in typical RTOS implementations
2026-04-14T23:59:13 < Posterdati> the h723zg runs at 550 MHz
2026-04-14T23:59:54 < zyp> yeah, so rough math says you're wasting 18-91% of your capacity on context switching overhead
--- Day changed Wed Apr 15 2026
2026-04-15T00:00:37 < zyp> and sure, if your actual work to do doesn't need more than 9% of the cpu capacity, it'll work to do it like that
2026-04-15T00:01:06 < qyx> but but
2026-04-15T00:01:20 < qyx> oh well
2026-04-15T00:01:26 < zyp> but it does sound like bad design in some way or another
2026-04-15T00:02:24 < qyx> i wouldn't call it a bad design, it is an misunderstanding of what an rtos does and should do
2026-04-15T00:03:05 < Posterdati> no, rtos has only one requirement: fixed time latency
2026-04-15T00:03:47 < qyx> *deterministic*
2026-04-15T00:03:54 < Posterdati> no latency
2026-04-15T00:14:53 < Posterdati> is anyone using stm32mp2xx?
2026-04-15T00:15:51 < Posterdati> I saw that it is impossible to buy it and have until august 2026
2026-04-15T00:16:14 < zyp> I have a devboard with one that I've poked briefly at
2026-04-15T00:16:56 < Posterdati> st?
2026-04-15T00:17:07 < zyp> I tried bringing up some baremetal stuff on the cortex-a, and something in the trustzone stuff were uncooperative until I ran out of patience
2026-04-15T00:17:22 < zyp> no, I got the myir one
2026-04-15T00:18:01 < Posterdati> zyp: even the stm32h series it is hard to program and make it work...
2026-04-15T00:18:14 < zyp> this one: https://www.myirtech.com/list.asp?id=780
2026-04-15T00:18:27 < Posterdati> zyp: sometimes I found the RM is a bit obscure
2026-04-15T00:19:12 < zyp> next time I'm probably gonna try without the trustzone stuff, just have my code start earlier in the boot chain
2026-04-15T00:19:18 < Posterdati> zyp: interesting, any linux distro working with it?
2026-04-15T00:19:53 < qyx> so I am apparently doing something wrong, when I have two sensors soldered, my EXTI handler runs when either of their DRDY is asserted
2026-04-15T00:19:57 < zyp> they supplied some example linux stuff, I didn't spend time on it because I specifically wanted to use it baremetal
2026-04-15T00:20:13 < qyx> and idk why
2026-04-15T00:20:41 < Posterdati> qyx: very strange, a noise?
2026-04-15T00:21:09 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2026-04-15T00:21:11 < Posterdati> zyp: would be interesting to run a BSD on it
2026-04-15T00:21:24 < bitmask> hi hi
2026-04-15T00:21:30 < zyp> now you're making jbo happy
2026-04-15T00:22:38 < Posterdati> qyx: what micro? h7?
2026-04-15T00:23:14 -!- hexo__ [~hexo@user/hexo] has quit [Ping timeout: 245 seconds]
2026-04-15T00:23:58 < qyx> https://paste.jvnv.net/view/VMjfX
2026-04-15T00:24:13 < qyx> exti9_5_isr should only catch PC7
2026-04-15T00:24:20 < qyx> but it also catches PA12
2026-04-15T00:26:06 -!- martinmoene__ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 255 seconds]
2026-04-15T00:36:32 < Posterdati> qyx: ports pull-up?
2026-04-15T00:44:29 < qyx> no, everything is okay electrically, I can scope it and I see it triggers at gyro's DRY, which is PA12
2026-04-15T00:44:40 < qyx> but it is configured to trigger on accel's DRY, which is PC7
2026-04-15T00:58:13 < qyx> well, me dumb
2026-04-15T01:04:34 < qyx> now I have a nice data https://paste.jvnv.net/view/oWzyI
2026-04-15T01:04:50 < qyx> the first column is a microsecond diff since the previous sample
2026-04-15T01:37:34 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2026-04-15T01:51:25 -!- jpka_ [~root@176.107.81.139] has joined ##stm32
2026-04-15T01:51:35 -!- jpka [~root@176.107.81.139] has quit [Ping timeout: 258 seconds]
2026-04-15T02:36:08 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 268 seconds]
2026-04-15T03:22:46 -!- teknix [~unknown@user/hsv] has quit [Ping timeout: 256 seconds]
2026-04-15T03:39:23 -!- teknix [~unknown@user/hsv] has joined ##stm32
2026-04-15T03:57:27 -!- hexo_ [~hexo@user/hexo] has quit [Remote host closed the connection]
2026-04-15T03:57:51 -!- hexo_ [~hexo@user/hexo] has joined ##stm32
2026-04-15T04:07:30 -!- infisd [~infisc@user/infisc] has joined ##stm32
2026-04-15T04:54:53 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 272 seconds]
2026-04-15T05:02:06 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2026-04-15T06:51:53 < mrec> it's a pity that the yosys / nextpnr sta memory model is not good
2026-04-15T07:02:50 -!- infisd [~infisc@user/infisc] has joined ##stm32
2026-04-15T07:28:31 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2026-04-15T07:49:03 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Quit: bitmask]
2026-04-15T08:00:56 < jpa-> mrec: for any device or for some specific device?
2026-04-15T08:09:00 < mrec> at least for the ice50up5k
2026-04-15T08:09:40 < mrec> pure logic seems to be okay, but once memory comes in the equation changes drastically I need +20% headroom
2026-04-15T08:11:42 < mrec> 11% headroom ... I'll go with that for now
2026-04-15T08:12:37 < mrec> finally it needs to move to radiant anyway because I want to put it into nvram and nextpnr doesn't support that
2026-04-15T08:14:05 < mrec> that design basically replaces 2 old mitsubishi ICs, and wires it up with the STM32H723, the entire design is very nice
2026-04-15T08:30:29 -!- haritz [~hrtz@user/haritz] has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
2026-04-15T08:36:15 -!- martinmoene__ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-15T09:48:15 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2026-04-15T10:23:00 -!- martinmoene__ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 265 seconds]
2026-04-15T11:09:12 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-15T12:25:03 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2026-04-15T12:25:33 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Client Quit]
2026-04-15T12:26:54 < _Posterdati_> hi
2026-04-15T12:27:49 < _Posterdati_> is anyone successful in implementing std::chrono::steady_clock on stm32h7xx?
2026-04-15T12:55:21 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2026-04-15T13:00:45 < Laurenceb_> wtf https://kurt.energy/wp-content/uploads/2024/08/Datasheet-18650_030_040.pdf
2026-04-15T13:01:03 < Laurenceb_> supercap tesla when
2026-04-15T13:05:27 < Laurenceb_> not bad  https://static.atdenergy.com/ATDE-EM-48V6500-G.pdf
2026-04-15T13:08:23 < Laurenceb_> https://static.atdenergy.com/ATDE-EM-96V20K-B.pdf  106Wh/kg
2026-04-15T13:14:25 -!- haritz [~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8] has joined ##stm32
2026-04-15T13:16:08 -!- haritz [~hrtz@user/haritz] has changed host
2026-04-15T13:27:31 < zyp> _Posterdati_, what's the challenge? selecting the appropriate clock source, or getting it hooked into the lib?
2026-04-15T13:29:23 < zyp> it's just just a monotonic clock, so you'd typically use your uptime/tick counter, 64-bit to avoid overflows
2026-04-15T13:29:54 < zyp> so set rep=uint64_t and period matching your tick rate
2026-04-15T13:31:11 < _Posterdati_> zyp: no, understaing how chrono libs works :) lol
2026-04-15T13:31:18 < zyp> not sure how to hook it into STL, I'd consider just defining your own name for it, but still using the STL clock concept, so you can use it with std::chrono
2026-04-15T13:31:46 < _Posterdati_> very simple indeed
2026-04-15T13:32:46 < zyp> https://en.cppreference.com/w/cpp/named_req/Clock.html
2026-04-15T13:33:14 < zyp> then anything that works with generic Clocks can work with your specific clock
2026-04-15T13:46:50 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Quit: Client closed]
2026-04-15T13:47:10 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2026-04-15T14:35:39 < _Posterdati_> I provide only ticks from SYSTICK timer
2026-04-15T14:51:48 < karlp> right, after x years, I finally added a pullup on rx serial to my odroid, so it boots properly on power cycle now.
2026-04-15T14:52:14 < karlp> apparently the dangling wires on the rx line out have always been enough to float rx poorly.
2026-04-15T14:52:37 < karlp> it woudl work with the serial port disconnected, or connected, but not with wires to the outside ready to plugged in if needed.
2026-04-15T15:52:08 < Posterdati> can be the stm32h7xx USART connected directly to a PC serial port?
2026-04-15T15:52:50 < Posterdati> or a max232 should be used?
2026-04-15T15:52:56 < zyp> no
2026-04-15T15:52:58 < qyx> must
2026-04-15T15:52:58 < zyp> yes
2026-04-15T15:53:01 < qyx> yes
2026-04-15T15:53:04 < zyp> in that order
2026-04-15T15:53:09 < qyx> definitely
2026-04-15T15:53:56 < Posterdati> and waht about signals other than RX and TX lines?
2026-04-15T15:54:12 < zyp> optional
2026-04-15T15:54:34 < Posterdati> should they be translated too?
2026-04-15T15:55:01 < qyx> they must be translated, not should
2026-04-15T15:55:08 < Posterdati> yes ok
2026-04-15T15:55:37 < Posterdati> so it is better to use a ttl 3.3 V level to USB converter
2026-04-15T15:55:53 < Posterdati> and use GND, TX and RX only
2026-04-15T15:56:35 < zyp> depends what you want to connect to
2026-04-15T15:56:57 < Posterdati> minimal hardware to implement a console like communication
2026-04-15T15:56:59 < zyp> if you want to connect to a RS232 port, use a RS232 chip, if you want to connect to a USB port, use a USB chip
2026-04-15T15:57:36 < zyp> minimal hardware would be using the built in USB controller
2026-04-15T15:57:39 < Posterdati> I saw that using the User USB port on nucleo-h723zg is quite expensive and complex
2026-04-15T15:57:56 < Posterdati> zyp: do you mean the User USB?
2026-04-15T15:58:10 < zyp> probably
2026-04-15T15:58:17 < Posterdati> or what?
2026-04-15T15:58:47 < zyp> if you're talking about the nucleo in particular, not a custom board, I think the onboard stlink can be used for USB-serial
2026-04-15T16:00:20 < Posterdati> I'm looking for some application note then
2026-04-15T16:00:57 < zyp> https://www.st.com/resource/en/user_manual/um2407-stm32h7-nucleo144-boards-mb1364-stmicroelectronics.pdf section 7.6.5 on page 28
2026-04-15T16:02:31 < zyp> if I'm reading it right, it's by default hooked up to USART3 on PD8/PD9
2026-04-15T16:03:02 < zyp> so you can just use that UART and those pins, open the COM port created by the stlink and it should just work
2026-04-15T16:04:47 < Posterdati> I'm taking a look to board schematics :)
2026-04-15T16:05:38 < Posterdati> yes! The T_VCP
2026-04-15T16:07:14 < Posterdati> zyp thanks
2026-04-15T16:33:18 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2026-04-15T17:08:02 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2026-04-15T17:11:49 < ColdKeyboard> So you can swap TX SS with RX SS pair on USB3.x without any performance penalty, right?
2026-04-15T17:12:50 < ColdKeyboard> Or is it just the + and - within the channel?
2026-04-15T17:13:16 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Read error: Connection reset by peer]
2026-04-15T17:16:05 < ColdKeyboard> So just swapping +/=- within the same pair has mandated support by the USB3 spec
2026-04-15T18:28:26 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2026-04-15T18:29:40 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Quit: Client closed]
2026-04-15T18:48:46 < mrec> swapping is okay
2026-04-15T19:25:12 < aandrew> was SS +/- swapping not always allowed? I know LS/HS was never allowed (found out the hard way)
2026-04-15T19:26:09 < aandrew> still kind of fucks me off that there are zero or practically zero SS hubs that can do what's it called, MTT (packaging multiple LS/HS packets into SS frames to the host)
2026-04-15T19:27:39 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-15T19:39:07 < karlp> that's not mtt, 
2026-04-15T19:39:36 < karlp> what you want is packing usb2 into usb3, when they were so separate they went on different pins, they just lied to us and hid them inside the connectors for usb-a
2026-04-15T19:40:14 < karlp> hecking, tried to order what's apparently a fairly obsolete dev kit now, finally found it in stock in germany,  company only does bank transfers, ok, no problem
2026-04-15T19:40:34 < karlp> go to my netbank and foreign transfers have been removed because they're used by fraudsters.
2026-04-15T19:40:40 < karlp> and I have to contact the bank to get access back again
2026-04-15T19:40:43 < karlp> what a fucking fuck around
2026-04-15T19:42:33 < specing> another reason to migrate to crypto
2026-04-15T19:42:55 < karlp> sure, absolutely, I'm 100000% sure the distro will take $doge
2026-04-15T19:43:08 < mrec> it was always allowed
2026-04-15T19:43:15 < specing> they might if their customers start demanding it
2026-04-15T19:43:30 < karlp> they'll put it back on, they've just removed it from the default setup, so I can't get it done today.
2026-04-15T19:43:42 < specing> maybe not doge but maybe stablecoins
2026-04-15T19:44:05 < karlp> kinda demonstrates that using digital id to sign new transactions and the 2fa they use for it, isn't actuallllllllly meeting the claimed security goals :)
2026-04-15T19:52:58 -!- infisd [~infisc@user/infisc] has quit [Read error: Connection reset by peer]
2026-04-15T19:55:06 < karlp> lol, rutronik wants 60 euro handling.
2026-04-15T19:56:50 < specing> TIL rutronik is not in russia (was wondering how they handle euros)
2026-04-15T20:10:36 -!- martinmoene__ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-15T20:29:37 -!- c10ud [~c10ud@user/c10ud] has quit [Read error: Connection reset by peer]
2026-04-15T21:03:09 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 255 seconds]
2026-04-15T21:11:39 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2026-04-15T21:42:45 < qyx> so, nightime innovation begins
2026-04-15T21:43:39 < jbo> same
2026-04-15T21:43:45 < jbo> oh, I read "nightmare"
2026-04-15T21:44:02 < jbo> I am biased as I am doing bq25756 again
2026-04-15T22:02:45 -!- mtoy [~mtoy@user/mtoy] has quit [Ping timeout: 246 seconds]
2026-04-15T22:12:12 -!- mtoy [~mtoy@user/mtoy] has joined ##stm32
2026-04-15T22:16:58 < Posterdati> hi
2026-04-15T22:17:19 < nohit> hi
2026-04-15T22:17:36 < Posterdati> people! Which kind of fft algorithm do you suggest for stm32h723 implementation???? Thanks!
2026-04-15T22:17:59 < jbo> is it homework time again?
2026-04-15T22:18:16 < Posterdati> no
2026-04-15T22:18:23 < Posterdati> I'm not so young
2026-04-15T22:28:58 < fantanYl> we'll start charging your employer consultation fees
2026-04-15T22:31:04 < fantanYl> which is futile, because automotive is broke
2026-04-15T22:32:43 < Posterdati> my employer?
2026-04-15T22:33:17 < Posterdati> automotive?
2026-04-15T22:34:45 < fantanYl> ah, different nick
2026-04-15T22:35:43 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Quit: KVIrc 5.2.6 Quasar http://www.kvirc.net/]
2026-04-15T22:36:10 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2026-04-15T23:05:07 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Read error: Connection reset by peer]
2026-04-15T23:08:31 < specing> fantanYl: Lol
2026-04-15T23:08:49 < specing> posterdati should learn chinese so they can ask for help
2026-04-15T23:09:49 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2026-04-15T23:10:14 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Client Quit]
2026-04-15T23:10:40 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2026-04-15T23:10:57 -!- mtoy [~mtoy@user/mtoy] has quit [Ping timeout: 255 seconds]
2026-04-15T23:18:52 -!- mtoy [~mtoy@user/mtoy] has joined ##stm32
2026-04-15T23:41:07 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Read error: Connection reset by peer]
2026-04-15T23:49:04 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
--- Day changed Thu Apr 16 2026
2026-04-16T00:14:17 -!- martinmoene__ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 248 seconds]
2026-04-16T00:23:54 < catphish> ColdKeyboard: you can only swap +/- not TX/RX, and only on the SS lines, not D+ and D-
2026-04-16T00:24:50 < catphish> or to be more clear, you can only swap TX+ with TX- and swap RX+ with RX-
2026-04-16T00:25:04 < catphish> no other combinations
2026-04-16T00:31:53 < qyx> can I swap but not swap? or to be more clear, can i swap without swapping?
2026-04-16T00:33:29 < catphish> qyx: you can swap talking for not talking
2026-04-16T00:33:46 < qyx> :( that was rude
2026-04-16T00:33:50 < qyx> much hurt
2026-04-16T01:03:19 < karlp> (unless you're using hub chips, in which case you _may_ be able to swap more...)
2026-04-16T01:04:19 < karlp> yeah, newark had it in stock, allegedly, and is shipping product, usps, for less total than rutroniks handling :)
2026-04-16T01:04:33 < karlp> let's see if it's actually in stock before we cancel the hitex.de order...
2026-04-16T02:18:01 -!- qyx [~qyx@84.245.120.133] has quit [Ping timeout: 248 seconds]
2026-04-16T02:19:46 -!- qyx [~qyx@84.245.120.9] has joined ##stm32
2026-04-16T02:28:50 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 256 seconds]
2026-04-16T02:40:10 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Read error: Connection reset by peer]
2026-04-16T02:46:15 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2026-04-16T03:31:16 < ColdKeyboard> Thanks catphish. I found that USB3 phy requires that the receiver supports RX SS +/- detection
2026-04-16T03:32:17 < ColdKeyboard> I'm sure if this wasn't the case, Mr Andrew Rogers might have already patented that... :)
2026-04-16T03:32:30 < ColdKeyboard> *from Microchip
2026-04-16T03:33:37 < ColdKeyboard> Still can't believe that they got granted a patent on "If channel A and channel B are available and you don't know which one to use. Try channel A, if it does not work, try channel B"... and that "there is no prior art" for this. What a joke of a patent system :)
2026-04-16T03:51:34 < om3ga> ColdKeyboard: is this a joke?
2026-04-16T03:51:56 < ColdKeyboard> [21:00] <ColdKeyboard> https://patentimages.storage.googleapis.com/ed/d0/0a/bc36c5a7eb0973/WO2023164109A1.pdf
2026-04-16T03:54:58 < om3ga> that's not only about this "method" of selecting the port :)
2026-04-16T03:55:09 < om3ga> port == channel
2026-04-16T03:55:29 < om3ga> othervise it would be a comedy
2026-04-16T04:03:49 < ColdKeyboard> Still, I think patent system is OG slop playpen :)
2026-04-16T06:42:35 -!- specing [~specing@user/specing] has quit [Read error: Connection reset by peer]
2026-04-16T06:43:58 -!- specing [~specing@user/specing] has joined ##stm32
2026-04-16T07:20:12 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2026-04-16T07:32:32 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Quit: bitmask]
2026-04-16T07:33:21 -!- haritzondo [~hrtz@140.228.70.141] has joined ##stm32
2026-04-16T07:33:45 -!- haritz [~hrtz@user/haritz] has quit [Ping timeout: 248 seconds]
2026-04-16T07:53:38 -!- martinmoene_ [~martinmoe@132.229.46.129] has quit [Read error: Connection reset by peer]
2026-04-16T08:20:05 -!- martinmoene__ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-16T09:13:42 -!- krish2487 [~krishi@cpe.ge-8-1-4-100.henqe12.dk.customer.tdc.net] has joined ##stm32
2026-04-16T09:41:32 -!- c10ud [~c10ud@host-95-233-182-170.retail.telecomitalia.it] has joined ##stm32
2026-04-16T09:41:32 -!- c10ud [~c10ud@user/c10ud] has changed host
2026-04-16T09:45:44 -!- infisd [~infisc@user/infisc] has joined ##stm32
2026-04-16T09:57:06 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2026-04-16T10:15:06 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2026-04-16T11:11:12 < catphish> ColdKeyboard: yeah it was the lack of prior art that baffled me the most - it seems like much the same thing 100Base-T ethernet does for crossover
2026-04-16T11:46:59 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 245 seconds]
2026-04-16T12:16:03 < karlp> which was also patented wasn't it?
2026-04-16T12:16:25 < karlp> https://patentimages.storage.googleapis.com/45/a8/46/08d2b33ab8aa2a/US6175865.pdf
2026-04-16T12:39:27 -!- infisd [~infisc@user/infisc] has joined ##stm32
2026-04-16T14:21:17 < karlp> heh, had a problem with my zephyr tests yesterday, was getting an interrupt setup failure on the button sample test.
2026-04-16T14:21:37 < karlp> turns out we connected the button to a pin that doesn't have input interrupt capability.
2026-04-16T14:21:49 < karlp> infineon really makes some weird ass shit.
2026-04-16T14:50:06 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2026-04-16T14:53:16 -!- infisc [uid692580@user/infisc] has joined ##stm32
2026-04-16T15:26:22 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Quit: Client closed]
2026-04-16T15:28:47 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2026-04-16T15:54:41 < Posterdati> karlp: no more nice input pins with their interrupt of some time ago... :(
2026-04-16T16:00:18 < karlp> sorry, what?
2026-04-16T16:24:06 < qyx> oh mouser not free above 50 anymore?
2026-04-16T16:27:20 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2026-04-16T16:35:45 -!- krish2487 [~krishi@cpe.ge-8-1-4-100.henqe12.dk.customer.tdc.net] has quit [Ping timeout: 246 seconds]
2026-04-16T16:40:51 < karlp> hrm, if you have three ethernet ports on a board, why would you have one of them a magjack, and the other two with descrete magnetics?
2026-04-16T16:41:15 < karlp> like, one of them is connected to an rmii phy, and the other two to two mii phys, but.. why the different magnetics?
2026-04-16T16:41:30 < karlp> is that just going to be "copy paste, yolo, who cares!" ?
2026-04-16T16:42:57 < qyx> is it the 1x wan + 2x lan scenario?
2026-04-16T16:44:03 < qyx> I can't see anything, maybe the magjack wasn't cheap enough with the right magnetics so they went with discrete
2026-04-16T16:45:20 -!- System_Error [~SystemErr@user/systemerror] has quit [Ping timeout: 265 seconds]
2026-04-16T16:46:33 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2026-04-16T16:57:53 < karlp> if it wasn't cheap enough wit hthe right ones, they should have used it for all three?
2026-04-16T16:58:06 < karlp> no, it's this eval board form infineon with ethernet on one and ethercat on the other two.
2026-04-16T16:58:17 < karlp> but it's still just 3x100M ethernet.
2026-04-16T17:07:13 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-16T17:08:56 < qyx> the key here is the two are on an ethernet switch
2026-04-16T17:09:04 < qyx> I have seen many routers like that
2026-04-16T17:09:24 < qyx> maybe just copy&paste of the switch ref sch
2026-04-16T17:13:07 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2026-04-16T17:13:13 < Laurenceb_> arduino ide 2.3 looks kind of nice
2026-04-16T17:16:04 < Laurenceb_> cant get SWO to work tho
2026-04-16T17:19:10 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2026-04-16T17:32:01 -!- artok [~azo@91-153-163-37.elisa-laajakaista.fi] has quit [Read error: Connection reset by peer]
2026-04-16T17:47:26 -!- mujin [~mujin@user/mujin] has joined ##stm32
2026-04-16T17:52:55 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2026-04-16T17:56:59 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2026-04-16T18:06:48 -!- infisc [uid692580@user/infisc] has joined ##stm32
2026-04-16T18:41:34 -!- mujin [~mujin@user/mujin] has quit [Quit: WeeChat 4.9.0]
2026-04-16T19:29:58 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2026-04-16T20:45:42 < zyp> karlp, could be the different ports require different magnetics, but sounds somewhat unlikely in this case
2026-04-16T20:46:22 < zyp> different phys means one could be voltage mode and the other current mode, and those require different center tap termination
2026-04-16T20:46:48 < zyp> but IIRC 100M magjacks usually bring out the center taps, unlike gigabit magjacks, so that shouldn't be an issue here
2026-04-16T20:47:57 < zyp> another reason would be poe vs non-poe, but I assume you would have noticed if that was the case
2026-04-16T21:04:36 -!- hexo__ [~hexo@user/hexo] has joined ##stm32
2026-04-16T21:38:57 < karlp> yeah, they both have centertaps going to vdd33 and cap to ground, it jus tlooks like ze germans being weird, and probablhy different teams and just not caring
2026-04-16T21:39:38 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 252 seconds]
2026-04-16T21:45:00 < karlp> heck, got boards back, vbus and ground are shorted.
2026-04-16T21:45:49 < karlp> on all 5, great
2026-04-16T21:47:18 < karlp> hrmmmm, tempted to power it into a bigger supply and see what it does...
2026-04-16T21:47:42 < fantanYl> *sparks*
2026-04-16T21:48:51 < zyp> that's what I like doing when something is shorted and I can't figure out where
2026-04-16T21:57:10 < karlp> and my fucking hot air is work.
2026-04-16T21:57:18 < karlp> high fucking time they got their own...
2026-04-16T22:17:45 < karlp> kernel: usb 1-4.2: Product: USB JTAG/serial debug unit
2026-04-16T22:17:47 < karlp> whee, fixed it
2026-04-16T22:18:36 < karlp> https://bin.jvnv.net/file/pqRqd/Screenshot%20From%202026-04-16%2019-18-12.png
2026-04-16T22:19:13 < karlp> I presume my solder mask layer for that tiny dfn wasn't right, gnd/vbus were shorted underneath there.
2026-04-16T22:19:37 < karlp> I used the supremely effective "pliers" technique to remove it, instead of waiting to tomorrow for hot air :)
2026-04-16T22:20:28 < karlp> lol, my shared usb trick worked too.
2026-04-16T22:20:30 < karlp> New USB device found, idVendor=1a86, idProduct=55e0, bcdDevice=23.00
2026-04-16T22:20:46 < zyp> shared?
2026-04-16T22:22:45 < karlp> doing dumb shit with a dual test board, https://kicanvas.org/?repo=https%3A%2F%2Fgithub.com%2Fkarlp%2Fktwinkler%2Ftree%2Fmain%2Fhw%2Fktwinkler-multi-r2025-12
2026-04-16T22:22:56 < karlp> just routed to both esp32 and ch584 in parallel
2026-04-16T22:23:01 < karlp> fuck it, usb-fs, yolo
2026-04-16T22:23:22 < karlp> ok, lets make this kids dinner then, hw "works"
2026-04-16T22:25:09 < zyp> yeah, that seems reasonable enough
2026-04-16T22:26:13 < zyp> if you told one of them to be hub class and had it enable the usb port on the other, you could probably run them both at the same time even
2026-04-16T22:27:04 < karlp> yeah, not doing anythign crazy, plan was mostly to just use the board run to try other things out "for free"
2026-04-16T22:28:05 < karlp> hrm, it's a kicad upstream footprint
2026-04-16T22:28:13 < karlp> ok, will have to check that against manuf stuff later.
2026-04-16T22:56:09 -!- hexo__ [~hexo@user/hexo] has quit [Ping timeout: 245 seconds]
2026-04-16T23:15:04 -!- infisd [~infisc@user/infisc] has quit [Read error: Connection reset by peer]
2026-04-16T23:42:55 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2026-04-16T23:45:28 -!- martinmoene__ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 244 seconds]
--- Day changed Fri Apr 17 2026
2026-04-17T01:35:03 < karlp> hah, 
2026-04-17T01:35:08 < karlp> no, nothing wrong with mask....
2026-04-17T01:35:16 < karlp> https://bin.jvnv.net/file/UNhhz.png  is from the part datasheet.
2026-04-17T01:35:24 < karlp> that is not.... what I made into the symbol....
2026-04-17T01:35:32 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 268 seconds]
2026-04-17T01:37:08 < qyx> karlp: thermal camera works for 100 mA, if you have one accessible
2026-04-17T01:37:47 < karlp> I do, but I hate it.
2026-04-17T01:38:01 < karlp> I did suspect the tiny dfn2510 part, but... not for the reason it turned out to be :)
2026-04-17T01:38:13 < karlp> which cam do you have?
2026-04-17T01:38:54 < qyx> a hikmicro one
2026-04-17T01:39:26 < qyx> TP42
2026-04-17T01:40:04 < karlp> man, these littlefuse dfn2510 hav ea totally differentinternal schematic.
2026-04-17T01:45:08 < karlp> fucking lol, I feel so stupid 
2026-04-17T01:45:23 < karlp> I wired it up as bidir, totally missed it, even though I selected uni.
2026-04-17T01:45:37 < karlp> ah well, easy fix, and it's a dev board, so fuck esd protection amirite.
2026-04-17T01:48:30 < qyx> I am using sp3400, half of that
2026-04-17T01:52:28 < karlp> eh, this one I picked, I'm only using half too, I picked it as one of the super cheap ones on jlc parts
2026-04-17T02:28:04 < qyx> hm this is the only board with boot0 unconnected.
2026-04-17T02:28:13 < qyx> should have fixed that in the last revision
2026-04-17T02:28:23 < qyx> s/the/my
2026-04-17T02:42:40 < karlp> zyp: you mean, have a device say it's a hub, _and_ say it's a device, and have one of them tell upstream there's a new device? how... would the other device know? it also thinks it's a device, it will be pulling and trying to do enumeration at the same time as the "hub"
2026-04-17T02:43:35 < zyp> you'd have signals between the devices
2026-04-17T02:43:52 < zyp> the one pretending to be a hub would tell the other device when to enable USB
2026-04-17T02:47:52 < zyp> now I want to try that some time :)
2026-04-17T02:48:01 < karlp> yeah, I think I'll let you do that experiment :)
2026-04-17T02:48:04 < karlp> I have enough on :)
2026-04-17T02:48:50 < zyp> got more useful stuff to do though :p
2026-04-17T02:49:02 < karlp> indeed.
2026-04-17T02:49:11 < karlp> dropping an actaul hub on is like 30-40c
2026-04-17T02:50:13 -!- hexo [~hexo@user/hexo] has quit [Read error: Connection reset by peer]
2026-04-17T02:50:42 -!- hexo [~hexo@user/hexo] has joined ##stm32
2026-04-17T03:59:03 -!- c10ud_ [~c10ud@host-95-233-182-170.retail.telecomitalia.it] has joined ##stm32
2026-04-17T04:02:09 -!- c10ud [~c10ud@user/c10ud] has quit [Ping timeout: 244 seconds]
2026-04-17T05:54:40 -!- jpka_ [~root@176.107.81.139] has quit [Quit: Konversation terminated!]
2026-04-17T06:09:50 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Quit: bitmask]
2026-04-17T06:11:41 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Quit: Client closed]
2026-04-17T06:28:45 -!- infisd [~infisc@user/infisc] has joined ##stm32
2026-04-17T07:41:38 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2026-04-17T08:07:42 -!- nerozero [~nerozero@87.253.63.54] has quit [Read error: Connection reset by peer]
2026-04-17T08:13:48 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-17T08:24:47 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2026-04-17T08:32:47 -!- martinmoene__ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-17T08:44:45 -!- Livio [~livio@user/livio] has quit [Ping timeout: 265 seconds]
2026-04-17T08:46:21 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2026-04-17T09:15:15 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2026-04-17T09:24:55 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-17T09:25:28 -!- krish2487 [~krishi@cpe.ge-8-1-4-100.henqe12.dk.customer.tdc.net] has joined ##stm32
2026-04-17T10:16:27 -!- Livio [~livio@user/livio] has quit [Remote host closed the connection]
2026-04-17T10:16:40 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-17T10:18:19 -!- martinmoene__ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 264 seconds]
2026-04-17T10:33:30 -!- Livio [~livio@user/livio] has quit [Ping timeout: 265 seconds]
2026-04-17T10:51:45 -!- jpka [~root@176.107.81.139] has joined ##stm32
2026-04-17T11:15:01 -!- grindhold [~quassel@2a0a:4cc0:c0:70c9::1] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
2026-04-17T11:40:17 -!- martinmoene [~martinmoe@132.229.46.129] has joined ##stm32
2026-04-17T11:41:16 -!- grindhold [~quassel@2a0a:4cc0:c0:70c9::1] has joined ##stm32
2026-04-17T12:11:08 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-17T12:22:55 < qyx> what was the catch with dfu on h7?
2026-04-17T12:23:02 < qyx> doesit work on both ports?
2026-04-17T12:25:51 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2026-04-17T12:33:25 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2026-04-17T13:15:32 < qyx> of course it doesn't
2026-04-17T13:15:38 < qyx> it works only on the OTG FS port
2026-04-17T13:36:53 < zyp> and of course you've only wired the OTG HS port
2026-04-17T13:38:38 < qyx> sure
2026-04-17T13:39:46 < qyx> do you know of any h7 compatible simple bootloader with dfu or mass storage emulation?
2026-04-17T13:41:11 < zyp> no, but rolling one is easy work
2026-04-17T13:47:36 < zyp> there's embassy-usb-dfu, but it looks overcomplicated, it integrates with embassy-boot to do reset-and-swap which seems kinda pointless when you have a standalone bootloader you can talk to
2026-04-17T14:02:00 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 244 seconds]
2026-04-17T15:00:56 < PhantomWork> The engineers at STM seems to be weird at time... like why the heck does boot0 is canbus receive, which by design is idling to "Boot to DFU mode!" state...
2026-04-17T15:17:46 < qyx> you can disable boot0
2026-04-17T15:17:56 < qyx> and CAN_RX is definitely available on other pis as well
2026-04-17T15:18:01 < qyx> s/pis/pins
2026-04-17T15:25:55 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2026-04-17T16:02:39 < PhantomWork> qyx: sure you can, and I did, but it is annoying
2026-04-17T16:03:19 < PhantomWork> and yes, but no
2026-04-17T16:03:32 < PhantomWork> can_rx alt is usb dm
2026-04-17T16:03:49 < PhantomWork> and usb is non-relocatable
2026-04-17T16:04:06 < PhantomWork> so usb + can = boot0 conflict
2026-04-17T16:11:07 -!- krish2487 [~krishi@cpe.ge-8-1-4-100.henqe12.dk.customer.tdc.net] has quit [Ping timeout: 264 seconds]
2026-04-17T16:12:15 < zyp> personally I find that preferable over having a reserved boot0 pin like older stm32s
2026-04-17T16:13:08 < PhantomWork> oh sure, but put it on a more general gpio than one that will clash by design...
2026-04-17T16:13:36 < zyp> a more general general purpose input/output
2026-04-17T16:14:48 < zyp> pretty much all pins have multiple functions, at least on lower pin count parts
2026-04-17T16:15:46 < PhantomWork> like sure, 2 pin away there is uart1 tx. would have been less of an issue there
2026-04-17T16:16:39 < zyp> why? just because you want to use CAN but not the UART, it doesn't mean it's that way for every other design
2026-04-17T16:16:59 < zyp> I mean, statistically there's more projects using UARTs than there are using CAN :p
2026-04-17T16:18:17 < PhantomWork> sure, but a high level on uart1 would not be much of an issue
2026-04-17T16:18:44 < PhantomWork> and should not cause a fault for whatever is connected to it
2026-04-17T16:18:50 < PhantomWork> beside a framing error
2026-04-17T16:20:30 < zyp> why do you want boot0 anyway? I always just tied it to ground on the parts that had a dedicated pin for it
2026-04-17T16:21:13 < PhantomWork> it just make it annoying at first flash :D
2026-04-17T16:21:32 < zyp> IMO they could just have left out the ROM bootloader
2026-04-17T16:22:52 < zyp> during development you'd rather want to flash via a debugger and for end user upgrades you rather want a custom bootloader with a nicer interface and more safeguards
2026-04-17T16:25:20 < PhantomWork> then the weird power pin layout... makes the bypass cap annoying to place
2026-04-17T16:28:09 < fantanYl> the generic DFU is definitely pain in the ass for use
2026-04-17T16:33:42 < karlp> how so?
2026-04-17T16:34:06 < karlp> dfu-util -D woopwoop.bin && echo "woop, upgraded"
2026-04-17T16:35:28 < fantanYl> with USB, it sometimes doesn't realize it is actually connected to host
2026-04-17T16:35:40 < fantanYl> it is mentioned as errata on H7, IIRC
2026-04-17T16:36:03 < karlp> is taht the issue when you have a really high speed crystal, and it autodetects the wrong divider or something?
2026-04-17T16:36:16 < fantanYl> also, it has literally no other feature besides uploading / downloading firmware. no way of checking if target machine is correct and no way of checking if image is consistent
2026-04-17T16:36:18 < karlp> I thought that was fixed on newer rom bootloads, and also very easy to work around in design time.
2026-04-17T16:36:31 < karlp> sure, you want more, you need more..
2026-04-17T16:36:39 < fantanYl> karlp: yes, IME some 60% of attempts to boot this design into DFU fail
2026-04-17T16:37:00 < karlp> ok, that just sounds like reason 10005 to not use h7,
2026-04-17T16:37:15 < fantanYl> but this design has really high speed crystal
2026-04-17T16:37:16 < karlp> I never hear anyone have a good time, and it sure isn't taht much fail on the rom dfu bootloader on the rest of the lineup
2026-04-17T16:37:49 < karlp> ok, so... that's like "don't do that" 
2026-04-17T16:37:52 < fantanYl> my long-term plan is to remove bootloaders completely, use kernel as immutable component and organize rest of the firmware as "files"
2026-04-17T16:38:19 < fantanYl> bootloader will then be just one of the applications
2026-04-17T16:39:30 < fantanYl> sounds like nonsense, but kernel really is only around 800 lines of code, so it should be possible to stabilize it enough so it doesn't need to be upgraded
2026-04-17T16:40:48 < karlp> I wonder what errata sheet has the "don't use top speed crystals" in it.
2026-04-17T16:45:11 < fantanYl> DFU datasheet, IIRC
2026-04-17T16:45:24 < fantanYl> and it is more like "don't use anything faster than few slowest crystals"
2026-04-17T17:39:49 < jbo> jpa-, qyx, the latest bq25756 design is also working :<
2026-04-17T17:41:36 -!- jpka [~root@176.107.81.139] has quit [Ping timeout: 262 seconds]
2026-04-17T17:58:24 < Steffanx> But did you use GAN?
2026-04-17T18:08:55 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2026-04-17T20:09:35 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-17T20:54:20 -!- martinmoene__ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-17T20:58:39 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 255 seconds]
2026-04-17T21:46:50 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 245 seconds]
2026-04-17T21:59:58 -!- infisd [~infisc@user/infisc] has joined ##stm32
2026-04-17T22:11:28 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
--- Day changed Sat Apr 18 2026
2026-04-18T00:09:46 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2026-04-18T00:29:42 -!- martinmoene__ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 255 seconds]
2026-04-18T01:13:49 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 272 seconds]
2026-04-18T01:26:26 -!- _Posterdati_ [~posterdat@user/Posterdati] has quit [Ping timeout: 248 seconds]
2026-04-18T02:09:06 -!- _Posterdati_ [~posterdat@user/Posterdati] has joined ##stm32
2026-04-18T02:18:09 -!- qyx [~qyx@84.245.120.9] has quit [Ping timeout: 255 seconds]
2026-04-18T02:20:01 -!- qyx [~qyx@84.245.121.218] has joined ##stm32
2026-04-18T02:38:54 < qyx> jbo: you are using boring transistors
2026-04-18T02:40:32 < qyx> PhantomWork: not many projects are using CAN, definitely not in automotive because stm32 is not automotive suitable nor certified afaik
2026-04-18T02:40:58 < qyx> and and if you use can, you most probably doesn't use usb
2026-04-18T02:41:08 < qyx> exceot, well, usb to can adapters
2026-04-18T04:11:19 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Quit: bitmask]
2026-04-18T04:31:57 -!- hexo_ [~hexo@user/hexo] has quit [Remote host closed the connection]
2026-04-18T05:05:34 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2026-04-18T05:13:15 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Quit: bitmask]
2026-04-18T06:04:43 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2026-04-18T06:22:15 -!- splud [~noneya.bi@user/splud] has quit [Ping timeout: 245 seconds]
2026-04-18T06:51:43 -!- splud [~noneya.bi@user/splud] has joined ##stm32
2026-04-18T08:26:38 -!- ferdna [~ferdna@user/ferdna] has quit [Ping timeout: 244 seconds]
2026-04-18T08:31:44 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2026-04-18T08:39:17 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2026-04-18T09:16:27 -!- martinmoene__ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-18T09:29:33 -!- hexo_ [~hexo@user/hexo] has joined ##stm32
2026-04-18T09:35:39 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-18T10:19:30 -!- infisc [uid692580@user/infisc] has joined ##stm32
2026-04-18T10:38:34 < catphish> qyx: oops, i build my whole car on STM32
2026-04-18T10:41:00 < catphish> i wonder when AEC-Q100 is actually required
2026-04-18T10:51:12 < catphish> i'm going against the grain because i rather like using USB and CAN and the ROM bootloader with a BOOT0 button :)
2026-04-18T12:01:03 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2026-04-18T12:53:18 < zyp>   what do you like about it?
2026-04-18T12:55:21 -!- hexo_ [~hexo@user/hexo] has quit [Ping timeout: 255 seconds]
2026-04-18T12:58:56 < mawk> I've never used the BOOT0 bootloader, apart for the stm32wb55 to load the radio coprocessor firmware
2026-04-18T13:29:40 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Read error: Connection reset by peer]
2026-04-18T13:34:04 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-18T14:19:14 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2026-04-18T14:20:23 -!- infisx [~infisc@user/infisc] has joined ##stm32
2026-04-18T14:23:12 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 256 seconds]
2026-04-18T15:19:04 -!- hexo_ [~hexo@user/hexo] has joined ##stm32
2026-04-18T15:42:58 < Steffanx> I did.
2026-04-18T15:43:37 < Steffanx> Not my choice though 
2026-04-18T15:56:07 -!- hexo_ [~hexo@user/hexo] has quit [Ping timeout: 264 seconds]
2026-04-18T16:55:19 < qyx> catphish: no worries, I will do a tractor with them
2026-04-18T16:55:54 < qyx> but no usb
2026-04-18T17:11:03 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 244 seconds]
2026-04-18T17:19:05 -!- infisc [uid692580@user/infisc] has joined ##stm32
2026-04-18T17:30:55 -!- jpka [~root@176.107.81.139] has joined ##stm32
2026-04-18T18:13:50 -!- hexo_ [~hexo@user/hexo] has joined ##stm32
2026-04-18T18:57:36 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-18T18:59:53 -!- System_Error [~SystemErr@user/systemerror] has quit [Ping timeout: 265 seconds]
2026-04-18T19:06:11 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2026-04-18T19:18:59 -!- rajkohaxor [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-18T19:21:53 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 272 seconds]
2026-04-18T19:50:14 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2026-04-18T20:16:39 -!- rajkohaxor [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Quit: Leaving]
2026-04-18T20:18:38 -!- infisd [~infisc@user/infisc] has joined ##stm32
2026-04-18T20:20:04 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has joined ##stm32
2026-04-18T20:21:22 -!- infisx [~infisc@user/infisc] has quit [Ping timeout: 248 seconds]
2026-04-18T21:28:39 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 245 seconds]
2026-04-18T21:30:28 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 256 seconds]
2026-04-18T21:31:39 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2026-04-18T21:38:44 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2026-04-18T22:09:13 < catphish> zyp: i like the ROM bootloader because it provides a simple way for skilled end users to flash a device with no special hardware (using the exisitng USB port), and with no development required and no risk of bricking
2026-04-18T22:10:12 < catphish> the place i've used it has been for automotive stuff. it has CAN for normal operation, and USB for diagnostics and flashing
2026-04-18T22:11:15 < catphish> the target market (or people who would use the USB port) are technical people, the volume has never been sufficient to justify writing my own tooling for flashing
2026-04-18T22:12:56 < Posterdati> hi
2026-04-18T22:24:36 < catphish> hell o
2026-04-18T22:30:23 < Posterdati> hell is trying to make printf() works on stm32h7 :)!
2026-04-18T22:41:21 < Posterdati> anyway seems that my code won't let setvbuf or printf work!
2026-04-18T22:42:19 < Posterdati> I won't the pic16f84 back :)
2026-04-18T22:42:36 < Posterdati> s/won't/want
2026-04-18T22:48:57 < qyx> hm, h7 has 128KB sectors, why
2026-04-18T22:51:17 < Posterdati> yes
2026-04-18T23:20:07 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 264 seconds]
2026-04-18T23:27:11 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 244 seconds]
2026-04-18T23:28:50 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2026-04-18T23:30:15 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-18T23:48:08 -!- martinmoene__ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 252 seconds]
2026-04-18T23:48:45 < karlp> qyx: lol, xmc48 has a 64, 64, 128, then 256 for the rest.
2026-04-18T23:48:55 -!- haritzondo [~hrtz@user/haritz] has changed host
2026-04-18T23:49:11 < karlp> so of your 2MB flash, to try and have a bootloader with A/B, you can have your A/B images be.... 512k each.
2026-04-18T23:49:13 < karlp> out of 2M
2026-04-18T23:49:39 < karlp> there was no way to get two 768k eraseable sequences,
2026-04-18T23:49:46 < karlp> let alone anytihng that smaller sectors would have allowed.
2026-04-18T23:57:01 -!- haritzondo is now known as haritz
--- Day changed Sun Apr 19 2026
2026-04-19T00:08:47 -!- Livio [~livio@user/livio] has quit [Remote host closed the connection]
2026-04-19T00:09:49 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-19T00:13:25 < karlp> hrm, I wanted to do this modern fancy discrete magnetics, but now I need to autism the fucking rj jacks to find what's common/standard...
2026-04-19T00:13:36 < karlp> or... not really, but.. feel like I should
2026-04-19T00:15:40 < qyx> rjhse has the "standard" footprint of chink rjs
2026-04-19T00:15:54 < qyx> I still have a bag of them
2026-04-19T00:24:38 -!- infisd [~infisc@user/infisc] has joined ##stm32
2026-04-19T00:38:25 -!- Livio [~livio@user/livio] has quit [Quit: leaving]
2026-04-19T00:53:31 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2026-04-19T02:24:20 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2026-04-19T02:24:32 < karlp> damnit, added a derived symbol, just a new MPN and LCSC part #, but hoho, you were on 10, so we've upgraded yoru entire library, one way forwards only
2026-04-19T02:24:36 < karlp> cuntish fucking thing
2026-04-19T02:24:40 < karlp> enough of that then.
2026-04-19T02:25:02 < karlp> i suspect C7501824 is close enough to RJHSE to fit, butit's nto actually the same dimensions.
2026-04-19T02:25:22 < karlp> it's almost likesomeone rebuilt it by using calipers on a rjhse...
2026-04-19T02:26:29 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2026-04-19T03:04:34 -!- rajkosto [~rajkosto@2a00:e90:211a:1c00:0:ff:fe00:10] has quit [Ping timeout: 248 seconds]
2026-04-19T03:17:22 -!- haritz [~hrtz@user/haritz] has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
2026-04-19T03:24:06 -!- haritz [~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8] has joined ##stm32
2026-04-19T03:24:06 -!- haritz [~hrtz@user/haritz] has changed host
2026-04-19T04:15:44 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 245 seconds]
2026-04-19T04:43:41 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2026-04-19T04:48:06 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Ping timeout: 246 seconds]
2026-04-19T04:53:24 -!- infisd [~infisc@user/infisc] has joined ##stm32
2026-04-19T05:01:38 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 252 seconds]
2026-04-19T05:29:29 -!- infisd [~infisc@user/infisc] has joined ##stm32
2026-04-19T06:18:16 -!- infisx [~infisc@user/infisc] has joined ##stm32
2026-04-19T06:22:00 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 256 seconds]
2026-04-19T08:07:58 -!- martinmoene__ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has joined ##stm32
2026-04-19T08:24:48 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2026-04-19T08:25:04 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Read error: Connection reset by peer]
2026-04-19T08:39:55 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2026-04-19T08:42:29 < Posterdati> karlp: I did that on an str91xf
2026-04-19T08:59:35 -!- haritz [~hrtz@user/haritz] has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
2026-04-19T09:48:23 -!- teknix [~unknown@user/hsv] has quit [Remote host closed the connection]
2026-04-19T10:04:07 -!- teknix [~unknown@user/hsv] has joined ##stm32
2026-04-19T10:15:37 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-19T10:18:15 -!- specing [~specing@user/specing] has quit [Quit: ZNC - https://znc.in]
2026-04-19T10:18:38 -!- specing [~specing@user/specing] has joined ##stm32
2026-04-19T10:49:47 -!- Livio [~livio@user/livio] has quit [Quit: leaving]
2026-04-19T10:50:08 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-19T11:09:56 -!- Livio [~livio@user/livio] has quit [Ping timeout: 265 seconds]
2026-04-19T11:27:12 -!- hexo_ [~hexo@user/hexo] has quit [Read error: Connection reset by peer]
2026-04-19T11:51:51 -!- hexo_ [~hexo@user/hexo] has joined ##stm32
2026-04-19T12:04:56 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-19T12:08:13 -!- hexo_ [~hexo@user/hexo] has quit [Read error: Connection reset by peer]
2026-04-19T12:15:18 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 255 seconds]
2026-04-19T12:18:34 -!- Livio [~livio@user/livio] has quit [Ping timeout: 265 seconds]
2026-04-19T12:53:00 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2026-04-19T13:37:15 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-19T13:37:24 -!- Livio [~livio@user/livio] has quit [Client Quit]
2026-04-19T14:15:12 < Posterdati> hi
2026-04-19T14:22:37 -!- hexo_ [~hexo@user/hexo] has joined ##stm32
2026-04-19T14:30:30 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2026-04-19T15:19:01 -!- hexo_ [~hexo@user/hexo] has quit [Remote host closed the connection]
2026-04-19T15:21:23 -!- hexo_ [~hexo@user/hexo] has joined ##stm32
2026-04-19T15:23:38 -!- hexo [~hexo@user/hexo] has quit [Ping timeout: 244 seconds]
2026-04-19T15:28:53 -!- hexo_ is now known as hexo
2026-04-19T16:50:30 -!- rajkosto [~rajkosto@2a00:e90:211d:e00:0:ff:fe00:10] has joined ##stm32
2026-04-19T17:31:57 -!- hexo_ [~hexo@user/hexo] has joined ##stm32
2026-04-19T17:34:57 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 246 seconds]
2026-04-19T17:50:06 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2026-04-19T18:20:08 -!- haritz [~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8] has joined ##stm32
2026-04-19T18:20:08 -!- haritz [~hrtz@user/haritz] has changed host
2026-04-19T18:27:46 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 248 seconds]
2026-04-19T18:28:49 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2026-04-19T18:54:39 -!- infisc [uid692580@user/infisc] has joined ##stm32
2026-04-19T19:00:10 -!- hexo_ [~hexo@user/hexo] has quit [Ping timeout: 245 seconds]
2026-04-19T19:17:09 -!- mtoy [~mtoy@user/mtoy] has quit [Ping timeout: 246 seconds]
2026-04-19T19:25:25 -!- mtoy [~mtoy@user/mtoy] has joined ##stm32
2026-04-19T19:47:40 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 245 seconds]
2026-04-19T20:05:42 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2026-04-19T20:45:42 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 246 seconds]
2026-04-19T20:58:47 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2026-04-19T21:04:24 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2026-04-19T21:04:54 -!- infisc [uid692580@user/infisc] has joined ##stm32
2026-04-19T21:25:27 -!- Livio [~livio@user/livio] has joined ##stm32
2026-04-19T22:23:14 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 245 seconds]
2026-04-19T22:23:30 -!- inca [~inca@98.1.80.80] has joined ##stm32
2026-04-19T22:35:51 -!- martinmoene__ [~martinmoe@205-20-132-5.ftth.glasoperator.nl] has quit [Ping timeout: 255 seconds]
2026-04-19T23:06:40 -!- artok [~azo@91-154-240-67.elisa-laajakaista.fi] has joined ##stm32
2026-04-19T23:44:24 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
--- Day changed Mon Apr 20 2026
2026-04-20T00:15:40 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2026-04-20T00:38:13 -!- Livio [~livio@user/livio] has quit [Quit: leaving]
2026-04-20T01:17:34 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2026-04-20T02:18:15 -!- qyx [~qyx@84.245.121.218] has quit [Ping timeout: 244 seconds]
2026-04-20T02:20:05 -!- qyx [~qyx@84.245.120.26] has joined ##stm32