--- Log opened Wed Oct 01 00:00:01 2025
2025-10-01T00:09:53 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-01T00:10:51 < qyx> ../../../../build/reproducible-path/gcc-arm-none-eabi-13.2.rel1/libgcc/config/arm/ieee754-df.S 6296
2025-10-01T00:11:05 < qyx> what te hell is that huge, 6 KB
2025-10-01T00:12:16 < qyx> and I am not aware of any doubles involved
2025-10-01T00:13:24 < mawk> maybe for printf/scanf
2025-10-01T00:13:32 < mawk> are you using reduced newlib?
2025-10-01T00:13:53 < mawk> without the -u _printf_float shit
2025-10-01T00:14:18 < mawk> --specs=nano.specs on the gcc command line
2025-10-01T00:14:44 < qyx> yes I am using nano and yes I am using -u _printf_float
2025-10-01T00:14:59 < qyx> but nobody told it to do doubles
2025-10-01T00:15:19 < mawk> it can't know in advance if you're going to use %lf or not in the format I guess
2025-10-01T00:15:50 < qyx> but that's easy to find out
2025-10-01T00:16:32 < qyx> ok commenting out _printf_float causes the size to decrease from 40K to 25K
2025-10-01T00:16:50 < qyx> but still
2025-10-01T00:16:50 < qyx> ../../../../build/reproducible-path/gcc-arm-none-eabi-13.2.rel1/libgcc/config/arm/ieee754-df.S 5300
2025-10-01T00:17:02 < qyx> some symbols are obviously left out and 5K is still there
2025-10-01T00:19:49 < ds2> btw, regarding the cryptolib hfp/sfp discussion earlier - https://stackoverflow.com/questions/51398676/convert-a-arm-gcc-generated-library-from-one-soft-float-bi-to-hard-float-abi
2025-10-01T00:20:07 < ds2> apparently there is an option to override
2025-10-01T00:20:24 < ds2> had to search as it didn't make sense for unconditionally enforce
2025-10-01T00:22:08 < mawk> ah yeah you can remove the ARM attributes shit from the file
2025-10-01T00:22:10 < mawk> nice
2025-10-01T00:22:37 < mawk> the last answer in the stackoverflow post is shitty
2025-10-01T00:22:56 < qyx> oh wow sqrtf is the only symbol requiring __ieee754_sqrtf
2025-10-01T00:23:11 < qyx> and it is an awfully big 5K shit
2025-10-01T00:23:24 < qyx> gross
2025-10-01T00:23:26 < mawk> yeah I was about to say this file doesn't seem to only contain stuff for doubles
2025-10-01T00:23:37 < mawk> but also plain floats
2025-10-01T00:26:15 < mawk> or maybe sqrtf is internally doing sqrt
2025-10-01T00:28:04 < mawk> the file itself only has 25 functions and they'are all fairly small https://raw.githubusercontent.com/gcc-mirror/gcc/refs/heads/master/libgcc/config/arm/ieee754-df.S
2025-10-01T00:29:06 < mawk> and it's not like including another file inside
2025-10-01T00:29:43 < qyx> replaced with __builtin_arm_sqrtf
2025-10-01T00:29:45 < qyx> let's see
2025-10-01T00:30:14 < mawk> but you're compiling with a FPU?
2025-10-01T00:32:31 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Ping timeout: 240 seconds]
2025-10-01T00:32:46 < qyx> yes
2025-10-01T00:32:54 < qyx> ok sqrtf is not used from libgcc anymore
2025-10-01T00:33:00 < qyx> ut still 5K of shit
2025-10-01T00:34:27 < qyx> not optimizing this today, I wanted to do some documentation
2025-10-01T00:43:05 < ds2> there is a lot of cruft in all the posts but the gcc flags re interesting
2025-10-01T00:44:15 < ds2> looking at libgcc and all the other stuff seems risky with the GPL, etc.
2025-10-01T00:44:37 < qyx> void all risks by making your project gpl
2025-10-01T00:45:00 < ds2> sure, if you must go that route :D
2025-10-01T00:55:43 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 240 seconds]
2025-10-01T00:58:15 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-01T00:59:21 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-01T00:59:45 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-01T01:34:13 -!- Livio [~livio@user/livio] has quit [Quit: leaving]
2025-10-01T01:49:40 -!- remcycles [~remcycles@c-24-19-134-216.hsd1.wa.comcast.net] has quit [Remote host closed the connection]
2025-10-01T01:49:59 -!- remcycles [~remcycles@c-24-19-134-216.hsd1.wa.comcast.net] has joined ##stm32
2025-10-01T01:55:47 < qyx> I want to output some data from my device which I want to hide from the user of the serial terminal
2025-10-01T01:57:07 < qyx> there are some escape sequences like PM or APC which I cannot get working, they are not terminating properly and terminate only when I start monkey typing in a amok
2025-10-01T01:57:30 < qyx> the one which works is OSC which looks a bit generic
2025-10-01T01:57:47 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2025-10-01T01:57:49 < qyx> like "\x1b]data\x9c"
2025-10-01T01:58:15 < qyx> but it looks a bit generic and eg. "\x1b]0;title\x9c" setns the terminal emulator window title and icon
2025-10-01T01:58:53 < qyx> so far it looks like the terminal emulator interprets anything having two parameters with ";" in the middle
2025-10-01T01:59:16 < qyx> I should be fine outputting eg. "\x1b]base64,something\x9c"
2025-10-01T02:15:26 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-01T04:05:29 -!- infisx [~infisc@user/infisc] has joined ##stm32
2025-10-01T04:09:02 -!- infise [~infisc@user/infisc] has quit [Ping timeout: 265 seconds]
2025-10-01T05:10:56 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:509c:9b77:584f:4f74] has quit [Remote host closed the connection]
2025-10-01T05:38:18 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has joined ##stm32
2025-10-01T05:39:58 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-01T07:36:36 -!- haritz [~hrtz@user/haritz] has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
2025-10-01T08:00:04 -!- NEYi_ [~NEYi@195.234.78.187] has joined ##stm32
2025-10-01T08:03:01 -!- NEYi [~NEYi@195.234.78.187] has quit [Ping timeout: 264 seconds]
2025-10-01T08:29:24 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-01T08:55:05 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-01T08:59:56 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-01T09:03:37 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-01T09:10:36 -!- NEYi_ [~NEYi@195.234.78.187] has quit [Quit: Leaving]
2025-10-01T09:24:24 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has quit [Remote host closed the connection]
2025-10-01T09:31:41 -!- catphish [~quassel@user/catphish] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
2025-10-01T09:31:56 -!- catphish [~quassel@user/catphish] has joined ##stm32
2025-10-01T09:33:49 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has joined ##stm32
2025-10-01T09:42:55 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has quit [Remote host closed the connection]
2025-10-01T09:45:52 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-01T09:46:05 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has joined ##stm32
2025-10-01T09:48:39 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has quit [Remote host closed the connection]
2025-10-01T09:52:10 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2025-10-01T09:52:51 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has joined ##stm32
2025-10-01T09:53:01 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-01T09:57:51 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has quit [Max SendQ exceeded]
2025-10-01T09:59:36 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-01T10:00:23 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has joined ##stm32
2025-10-01T10:15:35 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-01T10:18:21 < mawk> MSB/DSB are useless on single core cortex M7 right 
2025-10-01T10:18:42 < mawk> if I change something in an interrupt handler it's immediately visible in the user code and vice versa
2025-10-01T10:18:45 < mawk> isn't it
2025-10-01T10:19:39 < mawk> qyx it interprets even more than that, ] is just one of the opcodes
2025-10-01T10:20:18 < mawk> I think you can just set the cursor offscreen and write normally there no? assuming your serial terminal is an actual vt220 compatible terminal
2025-10-01T10:21:25 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-01T10:23:48 < ventYl> mawk: interrupt enter / leave is an explicit barrier
2025-10-01T10:23:57 < ventYl> you are right
2025-10-01T10:24:13 < mawk> ah nice, thanks
2025-10-01T10:24:21 < ventYl> explicit MSB/DSB is needed on multi-core and/or if you manipulate stack pointer
2025-10-01T10:26:22 < ventYl> whole CMRX kernel only has 6 of them, mostly in places where something nasty is being done to memory
2025-10-01T10:32:31 < mawk> I want to add some synchronization between IRQ handler and user code that doesn't require a critical section, using an atomic data type
2025-10-01T10:33:09 < mawk> but I think I have something that will work
2025-10-01T10:34:42 < mawk> I have a volatile global whose value is set to 0x10 or 0x11 by the IRQ handler to signal that value 0 or value 1 is available to process, and the user code changes 0x10 to 0x00 or 0x11 to 0x01 after processing values 0 or 1 respectively 
2025-10-01T10:34:47 < qyx> mawk: can you leak some secret data and say which lte modules are you gonna use after ublox?
2025-10-01T10:35:10 < mawk> the plan for the foreseeable future is to stockpile on ublox modules and keep using them
2025-10-01T10:35:12 < mawk> lol
2025-10-01T10:35:41 < mawk> there's a new company with the ugliest name ever that bought the ublox cellular activity and it seems they might be continuing to make them
2025-10-01T10:35:45 < mawk> trasna something like this
2025-10-01T10:35:50 < qyx> yes
2025-10-01T10:35:59 < mawk> but their website is atrocious 
2025-10-01T10:36:39 < mawk> personally I'd like to try one of these nordic SoC with the LTE builtin, but it's a complete change of code that will be required with the zephyr stuff
2025-10-01T10:36:59 < mawk> but there's no plan at the company level yet, just stockpile
2025-10-01T10:37:17 < mawk> and maybe sue our ublox distributor into oblivion if they can't find new stock for us
2025-10-01T10:37:41 < qyx> nordic has lte? anything other than nrf9, which is nbiot?
2025-10-01T10:37:42 < Steffanx> I would buy a stockpile too. Considering you guys spend quite a lot of money on certification and shit
2025-10-01T10:38:11 < mawk> I mean LTE-M qyx
2025-10-01T10:38:13 < Steffanx> Don't sue Stefan or Richard, mawk
2025-10-01T10:38:21 < mawk> lol
2025-10-01T10:38:29 < qyx> or lte-m
2025-10-01T10:38:55 < mawk> yeah they have the nRF91 with LTE-M/NB-IoT
2025-10-01T10:39:42 < Steffanx> Didn't you listen to Stefan? LTE-M/NB-IoT is dead
2025-10-01T10:40:07 < mawk> yeah when he wanted to sell the new modules
2025-10-01T10:40:10 < mawk> that never came out
2025-10-01T10:40:37 < Steffanx> He was fine selling us non-ublox modules 
2025-10-01T10:40:56 < Steffanx> meig I recall
2025-10-01T10:41:11 < mawk> he even brought a bottle of booze to do his sales pitch
2025-10-01T10:42:03 < mawk> yeah I spent however many weeks at Kiwa in a hot and humid faraday cage to certify the device 
2025-10-01T10:42:15 < mawk> the only fun part was seeing them zapping it with the cattle fence transformer
2025-10-01T10:42:37 < mawk> seeing them struggling to use their antique GSM simulator wasn't fun
2025-10-01T10:47:26 < qyx> Steffanx: wait what meig?
2025-10-01T10:47:29 < qyx> really?
2025-10-01T10:47:49 < qyx> meig is unisoc based and it actually worked
2025-10-01T10:47:58 < qyx> but it is super-chink price and probably quality too
2025-10-01T10:48:04 < Steffanx> They had ublox and MEIG I recall
2025-10-01T10:48:27 < Steffanx> But they weren't very open about it because ublox...
2025-10-01T10:48:34 < qyx> how could anyone has ublox AND meig in their portfolo
2025-10-01T10:52:05 < mawk> maybe they caught the direction of the wind with ublox stopping cellular and tried to diversify
2025-10-01T10:52:35 < qyx> usually it is at least quacktel you diversify with
2025-10-01T10:53:16 < qyx> it happened twice I ordered some simcoms and the sales guy called me I should order quacktel next time
2025-10-01T11:05:05 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-01T11:09:56 < ventYl> mawk: queue can do this with no synchronization and without atomics as long as it is SPSC
2025-10-01T11:10:19 < mawk> what do you mean queue?
2025-10-01T11:10:28 < mawk> just a regular queue data structure?
2025-10-01T11:10:30 < ventYl> queue data structure
2025-10-01T11:10:31 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has quit [Remote host closed the connection]
2025-10-01T11:10:38 < mawk> by atomic I just mean a plain old data type that happens to be atomic
2025-10-01T11:10:42 < mawk> like uint32_t
2025-10-01T11:10:43 < ventYl> yes, single-producer single-consumer queue is inherently lock-free data structure
2025-10-01T11:10:48 < mawk> not using the fancy atomic functions
2025-10-01T11:11:11 < ventYl> this is the kind of shit I had to deal with while writing operating system kernel
2025-10-01T11:11:18 < mawk> it doesn't need to be a queue, just 1 value at a time
2025-10-01T11:11:28 < mawk> to reflect the state of a pin, with hysteresis 
2025-10-01T11:11:44 < ventYl> you can't disable interrupts while searching thread table because latency will become effectively infinite
2025-10-01T11:12:01 < ventYl> and you can't lock a mutex because with interrupts this translates to instant deadlock
2025-10-01T11:12:52 < ventYl> mawk: yeah, double-buffer that value. so writer is free to modify one value without having a race condition with reader
2025-10-01T11:13:06 < ventYl> its just a couple of bytes of memory and you can use this for more stuff
2025-10-01T11:14:05 < mawk> if the value is written in-between reading and clearing by the consumer it's fine, it will be set back again by the writer at the next DMA interrupt 
2025-10-01T11:14:06 < ventYl> https://github.com/ventZl/cmrx/tree/master/src/extra/queue_server
2025-10-01T11:14:37 < ventYl> do you need to know that the value was written, or you sample it periodically?
2025-10-01T11:14:51 < mawk> it gets sampled periodically 
2025-10-01T11:15:02 < mawk> and if the high bit is set I know it was written 
2025-10-01T11:15:17 < mawk> and then clear it
2025-10-01T11:15:18 < ventYl> no you don't
2025-10-01T11:15:27 < ventYl> because clearing bit is non-atomic RMW operation
2025-10-01T11:15:27 < mawk> why?
2025-10-01T11:15:29 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has joined ##stm32
2025-10-01T11:15:52 < mawk> there's a single instruction to clear a bit
2025-10-01T11:16:06 < mawk> but even then that's not a problem
2025-10-01T11:16:19 < ventYl> check if it is interruptible, some instructions are
2025-10-01T11:16:33 < mawk> if the writer sets the bit just before the reader clears it, at the next tick the writer will set it again 
2025-10-01T11:16:41 < ventYl> and, this instruction can clear a bit in register not in memory location, can it?
2025-10-01T11:16:44 < mawk> so it's acceptable to miss the event
2025-10-01T11:17:33 < mawk> right it's for registers indeed
2025-10-01T11:17:44 < ventYl> then why do you even write this flag?
2025-10-01T11:18:09 < ventYl> i'd expect that mishandling it will break something downstream or it is completely useless
2025-10-01T11:18:12 < mawk> well I don't want to process the same event twice, I want to know when the value changed from 0 to 1 or 1 to 0
2025-10-01T11:18:53 < ventYl> so this is an edge detect algorithm?
2025-10-01T11:19:17 < mawk> yeah
2025-10-01T11:19:33 < ventYl> I'd handle this completely differently
2025-10-01T11:19:43 < mawk> I guess I could just unconditionally write the value from the IRQ handler to a global variable, and the reader keeps internally note of the last value
2025-10-01T11:19:49 < mawk> and when the two are different I do something 
2025-10-01T11:19:59 < ventYl> I'd have an edge counter (effectively a pin change interrupt occurrence counter) and current pin value written by the interrupt
2025-10-01T11:20:28 < ventYl> which would be read-only for reader. reader just needs to check if "processed edge" is different from last edge
2025-10-01T11:20:45 < mawk> yeah
2025-10-01T11:20:47 < ventYl> if yes, then there's something to process, if |difference| is larger than 1 then there's an edge missed
2025-10-01T11:20:52 < ventYl> no synchronization needed
2025-10-01T11:20:56 < ventYl> no edges missed
2025-10-01T11:21:39 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has quit [Max SendQ exceeded]
2025-10-01T11:21:40 < mawk> missing edges is fine, or even desirable, I only want to act on the latest value, so I guess I can skip the counter and only have the last processed value
2025-10-01T11:21:55 < ventYl> no you can't
2025-10-01T11:22:33 < ventYl> unless complete miss of two successive edges is not a failure mode
2025-10-01T11:22:44 < ventYl> what is this? a debounding algorithm?
2025-10-01T11:22:48 < mawk> yes
2025-10-01T11:22:54 < ventYl> k then
2025-10-01T11:22:59 < mawk> yes missing two successive edges is fine
2025-10-01T11:23:07 < mawk> although theoretically it shouldn't happen at all
2025-10-01T11:23:09 < mawk> if the algorithm works
2025-10-01T11:23:30 < mawk> since there's such a large time constant compared to the event loop period 
2025-10-01T11:23:41 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-01T11:23:48 < ventYl> i'd expect it to happen often if your userland task has fixed scheduling
2025-10-01T11:25:16 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has joined ##stm32
2025-10-01T11:25:20 < mawk> it's cooperative round robin, but the time constant is like 1 second
2025-10-01T11:25:33 < mawk> if the code is blocking somewhere for more than 1 second there's a bigger problem elsewhere 
2025-10-01T11:26:04 < mawk> it's denouncing a microswitch that indicates when a panel has been opened
2025-10-01T11:26:09 < mawk> debouncing
2025-10-01T11:26:24 < ventYl> yeah
2025-10-01T11:26:52 < ventYl> last real-time system has a constraint that if motor control was misalidned by 20ms, irrepairable mechanical damage to the appliance has happened
2025-10-01T11:27:08 < ventYl> *had
2025-10-01T11:27:28 < mawk> ah yeah
2025-10-01T11:27:54 < mawk> I wish we had an actual RTOS with queues and semaphores and barriers and all that, instead of that monstrous callback soup
2025-10-01T11:28:12 < mawk> but it's all code ported from BASIC in a time crunch by my boss a decade ago
2025-10-01T11:28:49 < ventYl> use CMRX and you'd wish you didn't have RTOS at all :>
2025-10-01T11:29:59 < ThatDamnRanga> mawk, I thought you were talking about mbed (may it rest in peace) for a second
2025-10-01T11:30:16 < ThatDamnRanga> but also, we must always denounce the microswitches
2025-10-01T11:30:21 < mawk> lol
2025-10-01T11:32:07 < ventYl> actually, I am surprised that it doesn't cause a lot more problems
2025-10-01T11:32:15 < ventYl> considering it is written by a punk
2025-10-01T11:33:06 -!- krish2487 [~krishna@62.135.140.101] has joined ##stm32
2025-10-01T11:34:12 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has quit [Remote host closed the connection]
2025-10-01T11:34:40 < ventYl> mawk: what blocks you from using RTOS?
2025-10-01T11:34:48 < mawk> money
2025-10-01T11:34:52 < mawk> and safety
2025-10-01T11:35:11 < mawk> it's a medical device so a complete rewrite would take a lot of time to verify it doesn't kill patients
2025-10-01T11:35:23 < mawk> and there's like ~150k lines of spaghetti C to rewrite
2025-10-01T11:35:43 < ventYl> safety certification of that stuff must be damn expensive
2025-10-01T11:35:44 < mawk> I proposed a gradual approach where we keep both the event loop and gradually add new tasks but bossman doesn't see the appeal
2025-10-01T11:36:28 < mawk> currently it's not too bad, I don't know the specifics but we have to get audited and the radio part has to be certified in a lab but for the code itself it's self-verification
2025-10-01T11:36:54 < mawk> but I suppose for things that are riskier to patients like pacemakers or surgical robots you have a lot more certification to do
2025-10-01T11:37:12 < ventYl> it still has to be expensive even if it is self-verification, unless you more or less fake it
2025-10-01T11:37:38 < mawk> yeah we used to spend like 2 weeks testing each release, with the full team doing it
2025-10-01T11:37:39 < ventYl> i've seen this process in automotive and for most part it was faked otherwise it would be damn expensive
2025-10-01T11:38:00 < mawk> now we automated most of it with raspberry pis and relays to click the various parts and simulate faults
2025-10-01T11:38:17 < ventYl> no unit tests?
2025-10-01T11:39:15 < qyx> rpis?
2025-10-01T11:39:20 < qyx> no NI and labview?
2025-10-01T11:39:37 < qyx> no pneumatic fingers touching your device?
2025-10-01T11:39:50 < mawk> yeah there are unit tests too but they're not extremely useful 
2025-10-01T11:39:58 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has joined ##stm32
2025-10-01T11:40:10 < ventYl> why not?
2025-10-01T11:40:20 < mawk> it's C, and even worse it's spaghetti C, so we can't test the application like it would actually run
2025-10-01T11:40:26 < ventYl> or, different question: what do you consider an unit test
2025-10-01T11:40:30 < mawk> we can just unit test individual functions in the code, mocking the input and looking at the output
2025-10-01T11:40:41 < mawk> the integration test which actually runs the application gives more info
2025-10-01T11:40:49 < mawk> lol
2025-10-01T11:40:53 < ventYl> this is something that can be managed
2025-10-01T11:41:03 < mawk> all custom python controlling relays
2025-10-01T11:41:07 < mawk> wired to the various knobs
2025-10-01T11:41:12 < ventYl> I personally did that on similar spaghetti code
2025-10-01T11:41:22 < ventYl> and found out that one module wasn't able to detect short on one pin
2025-10-01T11:41:34 < qyx> DI and OOP in your code
2025-10-01T11:41:37 < qyx> shall have, you
2025-10-01T11:41:42 < mawk> taking every function (or translation unit at best) in isolation, faking the inputs and looking at the outputs
2025-10-01T11:41:46 < mawk> ensuring every line is covered
2025-10-01T11:41:58 < mawk> but it's way too complex to test the different TUs together easily 
2025-10-01T11:42:25 < mawk> so technically (in theory) every line of code is covered by tests, but that can't account for every single value that every single variable can take in the real world
2025-10-01T11:42:39 < mawk> so we actually run the code on a real device and monitor the serial port in integration tests
2025-10-01T11:43:01 < ventYl> if you are free to mock inputs and outputs, you can actually achieve all possible states
2025-10-01T11:43:18 < mawk> we use a custom version of unity/cmock I modified, to be able to test individual TUs and mock function calls to other TUs
2025-10-01T11:43:19 < ventYl> even those which don't exist under normal conditions, or even less normal conditions
2025-10-01T11:43:31 < mawk> well yeah, but even an int has 2^32 possible values
2025-10-01T11:43:42 < mawk> and if you have 2 ints now you have 2^64 different values
2025-10-01T11:43:49 < mawk> you can't test them all
2025-10-01T11:44:00 < ventYl> you don't have to test for *ALL* values, you do border condition testing
2025-10-01T11:44:27 < ventYl> you test two-three values around the boundary where behavior changes
2025-10-01T11:45:32 < ventYl> if you test modules small-enough and defined well-enough, this should be sufficient to test for correct behavior
2025-10-01T11:45:38 < mawk> yeah for single values that's what we do, but that gets complex quickly if you have like 30 state variables and only a specific combination ends up in a bug
2025-10-01T11:45:51 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has quit [Max SendQ exceeded]
2025-10-01T11:45:57 < ventYl> yeah, but you don't have 30 state variables in one TU
2025-10-01T11:46:04 < ventYl> you have two or three.
2025-10-01T11:46:10 < mawk> and some stuff like memory bugs are kinda hard to do in unit tests, but I plan to add valgrind and compile with red zones or whatever it's called to detect buffer overflows
2025-10-01T11:46:18 < ventYl> this + input completely determines module state
2025-10-01T11:46:19 < mawk> if the code was written cleanly yeah
2025-10-01T11:47:00 < jpa-> clang sanitizer + fuzzing is nice
2025-10-01T11:47:23 -!- krish2487 [~krishna@62.135.140.101] has quit [Quit: WeeChat 4.7.1]
2025-10-01T11:47:27 < mawk> the component handling part of the LTE-M communication has 66 static variables for instance
2025-10-01T11:47:48 < ventYl> mawk: now I'd expect that not touching the code and working with mess actually becomes more expensive in long term than what refactor would cost you
2025-10-01T11:47:53 < mawk> and 139 static functions
2025-10-01T11:48:06 < ventYl> but static variables are internal behavior
2025-10-01T11:48:07 < mawk> yeah I wish bossman thought like that too
2025-10-01T11:48:27 < ventYl> it is not directly visible from outside, so only subset of that is actually exposed to outside
2025-10-01T11:48:48 < mawk> the tests are on each function, static or not
2025-10-01T11:49:26 < ventYl> yeah, i guess that somewhere you have a unit testing manual which has "unit, for the purpose of unit testing is exclusively and only a function" written in it
2025-10-01T11:49:38 < ventYl> which is kinda stupid
2025-10-01T11:50:15 < mawk> it would be possible to test only the external interface but that's infinitely harder
2025-10-01T11:50:28 < ventYl> no, it isn't :)
2025-10-01T11:50:49 < ventYl> if you test for behavior of each function, then you must have tons of tests failing after each code change
2025-10-01T11:50:57 < mawk> in my current codebase it is
2025-10-01T11:52:06 < mawk> it's not just a collection of pure functions with easily defined input and output, it has a lot of internal state, and an event loop
2025-10-01T11:52:17 < ventYl> that's OK
2025-10-01T11:52:31 < mawk> if you want to bring it to a particular internal state to see what happens it's much harder externally
2025-10-01T11:52:35 < ventYl> the point is that externally visible state space is many *dimensions* smaller than internal state space
2025-10-01T11:52:46 -!- haritz [~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8] has joined ##stm32
2025-10-01T11:52:46 -!- haritz [~hrtz@user/haritz] has changed host
2025-10-01T11:53:21 < ventYl> and the idea is that if module is competely encapsulated then asserting its external interface shall be enough to bring it into every possible internal state
2025-10-01T11:53:40 < jpa-> if you want to access internal state in tests, why not do so?
2025-10-01T11:53:54 < ventYl> because its none of tests business to do so
2025-10-01T11:54:04 < ventYl> it breaks encapsulation
2025-10-01T11:54:12 < jpa-> it's just a different kind of test
2025-10-01T11:54:30 < mawk> testing the whole application without looking at the internal state is done with the integration tests
2025-10-01T11:54:35 < jpa-> not all tests have to be "you can replace the implementation as long as the interface stays the same"
2025-10-01T11:54:38 < mawk> but this is the unit tests to check stuff like NULL pointer checks and all that
2025-10-01T11:54:56 < mawk> and check error handling with invalid values, and so on
2025-10-01T11:55:13 < jpa-> when testing an electronic device, i go inside and measure the supply voltages, even if they are not visible on the user interface or IO ports ;)
2025-10-01T11:55:18 < ventYl> mawk: I'd say that much of that falls into static analysis group rather than unit testing
2025-10-01T11:55:25 < qyx> of course, that you du by providing invalid values and checking the result
2025-10-01T11:55:34 < qyx> *do
2025-10-01T11:55:50 < mawk> unless it crashes the program
2025-10-01T11:56:00 < ventYl> mawk: right, but the question here is: if you can't supply incorrect value from outside, how can it appear inside the module?
2025-10-01T11:56:11 < qyx> then your implementation is wrong and you have nothing to test
2025-10-01T11:56:32 < jpa-> sometimes you can add test-specific APIs like a check_data_structure_invariants()
2025-10-01T11:56:37 < mawk> it could in the future, the tests are also to check regression
2025-10-01T11:56:42 < mawk> or it could in a way we haven't seen
2025-10-01T12:00:49 < mawk> for instance a function that does a fairly complex matrix operation loosely based on input values; you don't know which combination of input values would make the matrix singular, but you can do it easily if you manipulate the internal state
2025-10-01T12:04:04 < ventYl> well, for that purpose you consider the function a module and check if it behaves correctly
2025-10-01T12:04:25 < ventYl> i'd expect that the raw algorithm doesn't work on any static variable, rather is a pure function
2025-10-01T12:04:36 < ventYl> doing it so has multiple benefits
2025-10-01T12:04:42 < jpa-> fat expectation for legacy code
2025-10-01T12:04:57 < jpa-> and if you are adding tests to old code, you don't go refactoring it at the same time
2025-10-01T12:05:50 < ventYl> you first add behavioral tests and *then* refactor
2025-10-01T12:06:10 < ventYl> tests that test for internal behavior are contra-productive
2025-10-01T12:06:18 < ventYl> because they'll break en-masse as you refactor
2025-10-01T12:06:53 < jpa-> except if the modularization has been insufficient before
2025-10-01T12:06:56 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has joined ##stm32
2025-10-01T12:10:45 < qyx> nah, no time for programming today apparently
2025-10-01T12:11:30 < qyx> doing breakfast, kid housekeeping, doing dishes, kid housekeeping, now it is time for doing the lunch, kid is asking for some processing time too
2025-10-01T12:12:39 < ventYl> jpa-: this can always be improved without changing the behavior. dirty way is to encapsulate any inbound read or write to variable into function call
2025-10-01T12:12:48 < ventYl> no functional change but improves encapsulation
2025-10-01T12:13:28 < ventYl> fuck it had to be done on pretty much every project i've been working on in last decade and it was doable
2025-10-01T12:15:20 < mawk> it's a team of 3 with 150k lines of legacy code while we have to fix existing bugs and add requested features, we just can't afford to refactor anything
2025-10-01T12:15:53 < mawk> we have to plead for like a year to get time to refactor a small but important part of the code
2025-10-01T12:16:33 < mawk> if it doesn't increase the next quarterly earnings bossman isn't interested
2025-10-01T12:16:46 < mawk> especially since the perfidious finns bought us and are squeezing all the money they can
2025-10-01T12:18:53 < jpa-> ventYl: sure, there are many ways to access internal state, my point is that sometimes it is a thing you need to do
2025-10-01T12:19:59 < jpa-> it's silly to have hard and fast rules for "don't test internal behavior".. just like it is silly to worry too much about tests breaking in a code that is not seeing much changes, it is very different in a new code base that is being constantly refactored anyway
2025-10-01T12:28:37 < ventYl> jpa-: its not a hard rule. its just a rule that you should try to obey unless it is not possible to work around it.
2025-10-01T12:29:02 < ventYl> i *do* check for internal behavior in unit tests of my kernel due to one simple reason: there's no way to observe it behing changed
2025-10-01T12:29:12 < ventYl> yet still I consider this being a hack
2025-10-01T12:29:50 < ventYl> mawk: wrong. you are at your peak capacity because you don't refactor the code
2025-10-01T12:30:04 < mawk> lol
2025-10-01T12:30:26 < ventYl> if you reserved lets say 10% of your bandwidth to do one small refactor at time, in two months time, your pace would be faster
2025-10-01T12:30:26 < qyx> this is like me programming, EEs should not do programming and yet qyx occasionally does
2025-10-01T12:30:28 < mawk> so you want to halt all bugfixes and new features for a year so we refactor everything
2025-10-01T12:30:32 < qyx> which I consider being a hack
2025-10-01T12:30:34 < mawk> and pay the boss out of our own pocket
2025-10-01T12:30:39 < ventYl> mawk: no, see above
2025-10-01T12:31:04 < ventYl> this is exactly the way how I pulled $automotive project from shit it was in
2025-10-01T12:31:27 < mawk> even that the boss doesn't want to schedule
2025-10-01T12:31:31 < ventYl> in my case, those 10% of my time was time I'd otherwise spend looking at cat pictures on the internet, because I've been waiting for someone or something
2025-10-01T12:31:34 < mawk> and it would be a lot more than 2 months
2025-10-01T12:31:51 < tomeaton17> Why don't you just use AUTOSAR
2025-10-01T12:31:52 < mawk> those 10% are currently allocated to increasing safety
2025-10-01T12:31:58 < mawk> lol tomeaton17 
2025-10-01T12:32:22 < ventYl> well, one small refactor at time would increase velocity since day 1. a bit, but increase would be there
2025-10-01T12:32:28 < ventYl> the rest is compound interest
2025-10-01T12:32:36 < ventYl> tomeaton17: they are medical, not automotive
2025-10-01T12:32:51 < mawk> well yeah it would be great to be able to do that
2025-10-01T12:32:52 < ventYl> we were automotive and we were using autosar. yet in the "good old days way"
2025-10-01T12:33:10 < ventYl> mawk: last time $customer didn't want to hear about small refactors
2025-10-01T12:33:43 < ventYl> so I did one anyway and two weeks later they said they are happy that this time the task was done ahead of schedule rather than behind
2025-10-01T12:33:46 < mawk> but even a small refactor would need lots of testing to make sure it still complies; that's why last time we had to focus entirely on it and halt bugfixes or new features so we could do it properly
2025-10-01T12:33:48 < ventYl> which was a normal on this project
2025-10-01T12:34:14 < ventYl> I told them that I did a small refactor which increased our velocity and this increase will apply on all future tasks in this area
2025-10-01T12:34:57 < ventYl> after back of the napkin math translating this into money we got blank voucher to do any refactor we wish as long as we stick to the schedule
2025-10-01T12:35:22 < ventYl> this one refactor at a time changed estimates for tasks from three weeks to three days in 18 months of time
2025-10-01T12:35:33 < ventYl> on a project roughly ~80k SLOC and team of 2 part-time developers
2025-10-01T12:36:14 < ventYl> this particular codebase was complete shitworks because the goal was changed mid-development
2025-10-01T12:37:19 < tomeaton17> ah right
2025-10-01T12:37:27 < tomeaton17> I have never had a great time with it 
2025-10-01T12:37:41 < ventYl> it was so bad that after one of refactors the debug build became faster than release build of previous version
2025-10-01T12:37:57 < ventYl> AUTOSAR is great but many developers feel the urge to fight it
2025-10-01T12:38:06 < ventYl> then the result is complete clusterfuck
2025-10-01T12:38:19 < ventYl> each and every time when this happens, developers are guilty
2025-10-01T12:39:55 < tomeaton17> The licencing is quite crazy
2025-10-01T12:40:00 < ventYl> licensing is ok
2025-10-01T12:40:35 < ventYl> to my knowledge a basic autosar classic without extras costs around 50k / project
2025-10-01T12:41:00 < ventYl> now tell me how much code you are going to write using those 50k if universal hourly rate in automotive is around 100 eur?
2025-10-01T12:41:07 < ventYl> the answer is: not much
2025-10-01T12:42:32 < ventYl> plus, few know it but ElectroBit has a policy that if you license same product three times, then 4th license is free of charge
2025-10-01T12:42:48 < ventYl> you only pay for support hours
2025-10-01T12:43:12 < tomeaton17> I think they went through Vector last time and every component was an adi
2025-10-01T12:43:22 < tomeaton17> additional cost
2025-10-01T12:44:43 < ventYl> yes it is, 50k is just for Autosar classic BSW, even missing some modules, like DCM and DEM (IIRC)
2025-10-01T12:44:52 < ventYl> still, you won't write those in that amount of money
2025-10-01T12:44:56 < ventYl> impossibru
2025-10-01T12:46:05 < ventYl> moreover, the main advantage of autosar is that you don't have to write a code. you import configuration
2025-10-01T12:46:10 < ventYl> which is a HUGE timesaver
2025-10-01T12:48:41 < mawk> this AUTOSAR sales representative card fell out of your pocket
2025-10-01T12:51:55 < mawk> the only time I heard about it was the copypasta about it on reddit
2025-10-01T12:52:08 < ventYl> that one familiar rant, yeah
2025-10-01T12:52:22 < ventYl> the truth is that most of autosar tooling is real crap
2025-10-01T12:52:23 < mawk> https://www.reddit.com/r/embedded/comments/leq366/comment/gmiq6d0/
2025-10-01T12:52:28 < ventYl> like, total
2025-10-01T12:52:58 < ventYl> we've written our own for this very reason
2025-10-01T12:53:22 < ventYl> another problem with Autosar is that it is mostly German-made and Germans are mostly assholes
2025-10-01T12:53:28 < ventYl> at least those in automotive
2025-10-01T12:53:44 < ventYl> we had hard requirement to use Autosar 4.0 but Vector-supplied module was Autosar 4.2
2025-10-01T12:54:12 < ventYl> when we complained, Vector's response basically was: "fuck you, we are Vector Informatik and we only supply this as Autosar 4.2 module"
2025-10-01T12:54:48 < ventYl> we then confronted OEM with this statement of Vector and they replied: "fuck you, our requirement says you *have* to use Autosar 4.0"
2025-10-01T12:56:33 < ventYl> still, when OEM dropped complete network overhaul at short notice, we managed to integrate it in record time thanks to Autosar
2025-10-01T12:56:49 < ventYl> if we had to integrate those changes manually, it is probably still in-progress today
2025-10-01T13:15:18 < mawk> does DMA not slow down the CPU at all? with a 216MHz core if I take a sample every 1us that should be fine right
2025-10-01T13:23:19 < tomeaton17> Well it will be take up some bus time from the cpu 
2025-10-01T13:23:50 < ventYl> that shouldn't be a concern with cache I guess
2025-10-01T13:23:57 < ventYl> unless there's a lot of pressure on cache
2025-10-01T13:25:21 < tomeaton17> this is true
2025-10-01T13:26:30 < ventYl> DO178C would care
2025-10-01T13:38:18 < mawk> tomeaton17: does it matter if the buffer is in regular SRAM or in DTCM?
2025-10-01T13:38:43 < mawk> DTCM is good for using from the CPU, but idk for being written to from DMA
2025-10-01T13:39:34 < mawk> I put it in DTCM so that the half-transfer interrupt is done as quick as possible
2025-10-01T13:40:01 < mawk> it's counting a bunch of stuff, with a 1KiB buffer
2025-10-01T13:40:07 < mawk> and doing some floating point stuff
2025-10-01T13:41:21 -!- noarb [~noarb@user/noarb] has quit [Ping timeout: 250 seconds]
2025-10-01T13:43:16 < ventYl> is segger really such a piece of shit, or it behaves like so only when used from openocd?
2025-10-01T13:44:02 -!- noarb [~noarb@user/noarb] has joined ##stm32
2025-10-01T13:46:45 < mawk> what issues do you have?
2025-10-01T13:46:50 < mawk> I never had it malfunction
2025-10-01T13:46:52 < mawk> unlike the stlink
2025-10-01T13:49:04 < ventYl> random occurrence of Error: Failed to read memory at 0xe0001004
2025-10-01T13:49:10 < ventYl> with different addresses
2025-10-01T13:49:36 < ventYl> it goes away randomly after reconnecting/disconnecting it from USB or restarting openocd after *A LOT* of attempts
2025-10-01T13:52:08 < mawk> hmm
2025-10-01T13:52:16 < mawk> I suppose you already tried lowering the frequency?
2025-10-01T13:58:06 < tomeaton17> mawk: It really depends on the architecture. I assume M7? I haven't used one of those for a while but its MDMA only into DTCM isn't it?
2025-10-01T13:58:22 < mawk> yeah M7
2025-10-01T13:58:24 < mawk> there's no MDMA
2025-10-01T13:58:53 < mawk> if I look at the somewhat vague memory diagram it seems the DMA has a direct connection to DTCM
2025-10-01T13:59:02 < tomeaton17> can you send a link
2025-10-01T13:59:18 < mawk> or maybe not
2025-10-01T13:59:19 < mawk> idk
2025-10-01T13:59:21 < mawk> https://www.st.com/resource/en/reference_manual/rm0410-stm32f76xxx-and-stm32f77xxx-advanced-armbased-32bit-mcus-stmicroelectronics.pdf
2025-10-01T13:59:24 < mawk> page 72
2025-10-01T13:59:29 < mawk> using DMA2
2025-10-01T14:01:04 < mawk> yeah it's not direct
2025-10-01T14:01:17 < mawk> it goes from DMA to DTCM through the "AHBS slave interface"
2025-10-01T14:06:15 < mawk> https://developer.arm.com/documentation/ddi0489/f/memory-system/ahb-slave-interface this is even more cryptic
2025-10-01T14:09:18 < tomeaton17> I guess you might get some contention then if cpu is hammering dtcm?
2025-10-01T14:10:04 < mawk> the CPU is accessing DTCM directly, and the DMA accesses it through the AHB slave
2025-10-01T14:10:13 < mawk> but the DMA is only writing and the CPU is only reading
2025-10-01T14:10:23 < mawk> and never in the same range of addresses at the same time
2025-10-01T14:10:29 < mawk> so it should be fine
2025-10-01T14:10:56 < mawk> no other peripheral seems to be using AHBS as apparently it's only for accessing the DTCM/ITCM memories, so I should be fine
2025-10-01T14:11:07 < mawk> and the only thing I put in DTCM is the DMA buffer and associated variables
2025-10-01T14:11:09 < ventYl> how many ways are there to DTCM? is it only one-way memory?
2025-10-01T14:11:26 < mawk> it's just regular RAM, but which is close to the CPU so supposedly faster
2025-10-01T14:11:29 < ventYl> *one-way associative
2025-10-01T14:11:44 < ventYl> then read and write cannot coexist at the same time as there is only one bus
2025-10-01T14:13:45 < mawk> the CPU isn't constantly reading and the DMA peripheral isn't constantly writing; the DMA writes a byte every 10us
2025-10-01T14:13:51 < mawk> and the CPU reads every 10ms
2025-10-01T14:14:19 < ventYl> that should be fine
2025-10-01T14:14:24 < qyx> mawk: I remember from the past not to do DMA buffer on stack-allocated resources if stack was put into any kind of "special RAM"
2025-10-01T14:14:46 < qyx> but keep in mind that every single MCU family has that "special RAM" made differently and even for different purposes
2025-10-01T14:14:52 < mawk> and there is an arbitrator that does round robin
2025-10-01T14:15:06 < mawk> yeah qyx 
2025-10-01T14:15:14 < mawk> the "close to CPU for fastness" I read from the ST docs
2025-10-01T14:15:19 < mawk> so I suppose that's the purpose here
2025-10-01T14:15:26 < ventYl> I remember my ex-colleague allocating DMA buffer on stack and then wondering that its content got corrupted :>
2025-10-01T14:15:37 < ventYl> as the function which allocated it returned
2025-10-01T14:16:16 < mawk> I put the stack in regular SRAM, there's nothing in the DTCM apart from the DMA buffer so that should be fine
2025-10-01T14:17:07 < jpa-> sounds a weird choice
2025-10-01T14:17:27 < jpa-> stack in DTCM is nice for fast interrupt entry & exit
2025-10-01T14:18:02 < mawk> well it wasn't used at all until them
2025-10-01T14:18:09 < mawk> maybe I will put more things in it afterwards
2025-10-01T14:18:10 < jpa-> i agree that putting the DMA buffer in DTCM on parts that support it can make sense if it takes long to fill it but you want to process it quickly
2025-10-01T14:18:54 < jpa-> because the single DMA write through the DTCM bridge every now and then won't matter much for the CPU
2025-10-01T14:19:05 < mawk> there's also ITCM for the code but that will cause a nightmare with the MPU
2025-10-01T14:19:26 < mawk> we ran out of regions to describe the memory map so we can't use it unless someone has a stroke of genius about how to organize the memory regions better
2025-10-01T14:19:35 < mawk> only 8 regions on that core
2025-10-01T14:20:05 < ventYl> mawk: I have
2025-10-01T14:20:55 < ventYl> mawk: https://archive.fosdem.org/2025/events/attachments/fosdem-2025-4390-cmrx-microkernel-based-rtos-with-memory-isolation-on-mmu-less-architectures/slides/238183/CMRX_talk_EWQ14kw.pdf
2025-10-01T14:22:04 < mawk> you mean dynamically changing the MPU regions?
2025-10-01T14:22:22 -!- System_Error [~SystemErr@user/systemerror] has quit [Ping timeout: 272 seconds]
2025-10-01T14:22:37 < ventYl> I wouldn't call it dynamically, they are statically allocated per-"process"
2025-10-01T14:23:04 < ventYl> so different "processes" can have different maps which are then changed on thread switch which also changes "process"
2025-10-01T14:23:15 < mawk> I see
2025-10-01T14:23:36 < ventYl> I had another talk on why fully dynamic change is no go for real-time
2025-10-01T14:32:16 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-01T14:59:43 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Ping timeout: 240 seconds]
2025-10-01T15:25:40 < mawk> my code appears to work fine with the rest of the application
2025-10-01T15:25:44 < mawk> I can't see any slowdown
2025-10-01T15:26:54 < ventYl> my seems to be fucked-up due to stray interrupt
2025-10-01T15:30:14 < qyx> I have no code
2025-10-01T15:44:19 < mawk> I thought I had a bug in my maths but the switch is actually even glitchier than I thought
2025-10-01T15:45:41 < mawk> the button toggles about 90 times per second
2025-10-01T15:45:48 < mawk> when I'm just pressing it with my finger
2025-10-01T15:46:30 < mawk> but it doesn't mean it's a 90Hz sine wave, all the toggling could be happening together in a 900μs timespan
2025-10-01T15:46:31 < ventYl> no wonder
2025-10-01T15:47:06 < mawk> but if I do the average value of the state, and then smooth that with exponential moving average, I get the good value of the button
2025-10-01T15:47:10 < mawk> so it's working
2025-10-01T15:47:15 < mawk> I just have to tweak the time constants now
2025-10-01T15:47:21 < ventYl> i'd probably put a small RC filter there to limit switching. having an unexpected interrupt flood is not a nice thing to have
2025-10-01T15:47:50 < mawk> yeah that's why I did it with DMA, I collect the button state for 10ms and then look at the most plausible value
2025-10-01T15:47:59 < mawk> and disabled the interrupt for it
2025-10-01T15:48:03 < mawk> for the GPIO pin I mean
2025-10-01T15:48:07 < ventYl> don't you have any other more important stuff to do with that DMA?
2025-10-01T15:48:20 < mawk> some ADC readouts but it's less frequent than that
2025-10-01T15:48:41 < ventYl> each and every time I post something on linkedins I get shit ton of comments where people all around the planet are so busy doing their stuff using DMA they don't have time to do proper SW engineering
2025-10-01T15:49:50 < ventYl> as if pretty much everyone was calculating FFT on attiny8 in real-time running from cr2302 with expected lifespan of 50 years
2025-10-01T15:51:15 < mawk> I would skipp all the software and put an actual lowpass filter on the PCB if I could
2025-10-01T15:51:29 < mawk> this is a "turn shit into gold using software" order from the boss
2025-10-01T15:52:22 < mawk> but he's kinda right, the product is already in the market and experiencing this issue, making a hardware fix would mean recalling everything
2025-10-01T15:53:25 < ventYl> :)
2025-10-01T15:53:51 < mawk> even a broken boss is right twice a day
2025-10-01T16:00:00 < qyx> customers are returning their shit because the button is broken, so why not replace the button during RMA?
2025-10-01T16:03:51 < mawk> currently we just exchange it with another device whose switch seemingly works and call it a day
2025-10-01T16:04:35 < tomeaton17> The refurbished replacement classic
2025-10-01T16:04:57 < mawk> idk if we're allowed to change the PCB just like that, but if we wanted to we'd have to ask the PCB design company who made the PCB to make a new one
2025-10-01T16:05:08 < mawk> it would be infinitely easier for the employees to swap the PCB rather than swap the button
2025-10-01T16:05:19 < mawk> and once we collected enough PCBs we send them in bulk for rework, if that's cheap enough
2025-10-01T16:07:04 < tomeaton17> I hope it wasn't you who specced the switch initially haha
2025-10-01T16:07:20 < mawk> we can engage a hardware lock remotely and then stop reading the status of the button, so that's the hack we do right now
2025-10-01T16:07:46 < mawk> no it's the PCB design company; but it's a perfectly fine switch, we just didn't expect everything inside the device to get oxidized/get whiskers so fast
2025-10-01T16:07:55 < mawk> supposedly from sulfur outgassing from the rubber parts
2025-10-01T16:08:12 < mawk> it's just the switch is the first thing to fail, but other stuff is failing too like RGB LEDs whose colors get all wrong
2025-10-01T16:08:42 < tomeaton17> Is it a harsh environment?
2025-10-01T16:09:06 < mawk> no, just regular homes of regular people; some of them might be smokers
2025-10-01T16:09:25 < mawk> and sometimes hospitals too which should get even better ventilation than homes, and no smokers there
2025-10-01T16:09:55 < qyx> do you produce insomnia loggers
2025-10-01T16:11:14 < mawk> no
2025-10-01T16:11:29 < tomeaton17> how long in the field before they start getting buggered?
2025-10-01T16:11:37 < mawk> if I give too much info one of you is going to call my boss to tell him I'm gay and I smoke heroin 
2025-10-01T16:12:04 < mawk> that's hard to tell because of the whole refurbishing thing, I have to do some stats
2025-10-01T16:12:04 < tomeaton17> Is it a mossad secret listening device?
2025-10-01T16:12:09 < mawk> lol
2025-10-01T16:12:26 < mawk> also the devices stop misbehaving when they are moved or vibrated
2025-10-01T16:12:45 < mawk> maybe whiskers get broken off during transport
2025-10-01T16:12:58 < mawk> and then they start growing again on the previously broken stems, idk
2025-10-01T16:17:27 < tomeaton17> I am now mandated to wear goggles in the lab 
2025-10-01T16:21:04 < tomeaton17> All of the chemistry wet lab are being applied to me for no reason
2025-10-01T16:32:41 < mawk> I had a clandestine lab at work
2025-10-01T16:32:52 < mawk> with various stuff like lead acetate, THF, HCl
2025-10-01T16:32:57 < mawk> they made me hide it for the audit
2025-10-01T16:47:18 -!- fenugrec_ [~f@192.214.232.39] has left ##stm32 []
2025-10-01T16:57:27 < karlp> somewhat unsurprisingly, dwc2 host mode works _better_ but has different bugs.
2025-10-01T17:02:16 < tomeaton17> mawk: what THF using for?
2025-10-01T17:20:22 < mawk> it was to attempt to dissolve plastic tomeaton17 
2025-10-01T17:20:32 < mawk> to analyze impurities on the plastic, or rubber
2025-10-01T17:20:39 < mawk> but it didn't work it just made a sticky goo
2025-10-01T17:21:14 < tomeaton17> Did you try DCM?
2025-10-01T17:22:34 < tomeaton17> I am actually currently dissolving some plastic just for fun
2025-10-01T17:44:21 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-01T17:49:06 < mercenary> mawk: if your problem is tin whiskers, wouldn't a dab of conformal coating fix the problem?
2025-10-01T17:51:09 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-01T18:03:43 < BrainDamage> not on the switch contacts
2025-10-01T18:04:08 < qyx> but he said snpb solder would fix that
2025-10-01T18:04:12 < qyx> so where are the whiskers?
2025-10-01T18:08:06 < mercenary> hmm. the vendors say it should. https://scscoatings.com/newsroom/blog/updates-on-conformal-coating-and-tin-whiskers/ But then, that's what a vendor would say.
2025-10-01T18:12:26 < ventYl> mawk: in this situation a SW fix is probably the right way to do it with HW fix headling with the issue globally being the logical next step
2025-10-01T18:13:01 < mawk> I mean Pb coating/alloy inside the switch qyx
2025-10-01T18:13:16 < mawk> currently it's gold-plated nickel contacts
2025-10-01T18:13:17 < ventYl> although I'd expect that whatever external button has debouncing implemented by default. even buttons my students implement show bouncing behavior.
2025-10-01T18:13:43 < mawk> yeah idk why the PCB designers didn't add debouncing
2025-10-01T18:13:46 < mawk> just a weak pullup
2025-10-01T18:14:17 < ventYl> no, I mean SW debouncing
2025-10-01T18:14:29 < qyx> mawk: so just replace the pullup with a capacitor?
2025-10-01T18:14:37 < qyx> and use an internal pullup?
2025-10-01T18:14:41 < ventYl> we had one for our buttons automatically. yet cars are noisy environment so you *have* to add it
2025-10-01T18:15:10 < mawk> the capacitor would have to go to ground instead of 3.3V doesn't it?
2025-10-01T18:15:17 < qyx> it doesn't matter
2025-10-01T18:15:24 < qyx> capacitor is ac capaciting in all cases
2025-10-01T18:15:45 < mawk> it's like a 0201 pullup, it wouldn't be easy to replace by our people
2025-10-01T18:16:07 < qyx> looks like a multitude of bad design choices
2025-10-01T18:16:11 < mawk> yeah
2025-10-01T18:16:21 < qyx> starting with ublox modules, bla bla bla, ending with no filter on buttons
2025-10-01T18:16:25 < mawk> lol
2025-10-01T18:16:49 < mawk> ublox isn't that bad, although I have no other point of reference 
2025-10-01T18:16:52 < qyx> and using sand to do electric magic
2025-10-01T18:16:59 < mawk> I just hate AT commands
2025-10-01T18:17:19 < mawk> and the randomly changing sets of features between modules
2025-10-01T18:17:23 < ventYl> considering what I've seen in automotive industry and reading that medical devices have even worse design I guess I want to die before my broken body enters premises of hospitals
2025-10-01T18:17:32 < mawk> like the older gen modules that can change DNS servers but not our LTE-M module
2025-10-01T18:22:17 < ventYl> fuck, I'd welcome the C++ form of the "auto" keyword in C
2025-10-01T18:23:38 < jbo> or namespaces
2025-10-01T18:23:39 < jbo> or templates
2025-10-01T18:23:42 < jbo> or just use C++
2025-10-01T18:25:05 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-01T18:25:30 -!- infisx [~infisc@user/infisc] has quit [Ping timeout: 265 seconds]
2025-10-01T18:27:24 < tomeaton17> Why not just use rust
2025-10-01T18:31:06 < mawk> C23 has auto
2025-10-01T18:31:16 < mawk> which works like in C++
2025-10-01T18:31:39 < mawk> and older C versions with GNU extensions have __auto_type which is a bit more limited but still useful 
2025-10-01T18:32:01 < ventYl> hm, good to know
2025-10-01T18:32:28 < tomeaton17> I thought C23 is also limited like the gcc type
2025-10-01T18:36:30 < tomeaton17> Its just a standardisation of the gcc extension I think
2025-10-01T18:37:22 < ventYl> well, most of C and C++ features is just a standardization of some feature developed somewhere
2025-10-01T18:37:33 < ventYl> like, bulk of C++11 was bringing in features from boost into language
2025-10-01T18:38:19 < ventYl> actually, the rule is that if you want to bring some feature into language as standard feature, at least X compilers must already support it as extension
2025-10-01T18:38:25 < ventYl> X is different for C and C++
2025-10-01T18:38:44 < ventYl> because there is shit ton of major C compilers while there are only three or four C++ compilers out there
2025-10-01T18:38:56 < mawk> in C23 you can do stuff like 'const auto *x = y'
2025-10-01T18:39:13 < mawk> to emphasize constness or having a pointer 
2025-10-01T18:39:16 < ventYl> set(CMAKE_C_STANDARD 23)
2025-10-01T18:39:27 < mawk> while previously you do `__auto_type x = y`
2025-10-01T18:39:35 < ventYl> and automotive folks can go nuts
2025-10-01T18:39:50 < mawk> __auto_type is useful for macros when you might have function calls as arguments and don't want to repeat the call
2025-10-01T18:40:18 < ventYl> its useful with iterators too
2025-10-01T18:40:41 < mawk> I mean in C
2025-10-01T18:40:52 < ventYl> if I have some struct YourMomBomberman bombermanArray[MAX_BOMBERMANS] I don't want to write struct YourMomBomberman * iterator
2025-10-01T18:41:02 < mawk> ah right 
2025-10-01T18:41:08 < ventYl> I want simply write auto iterator = &bombermanArray[q];
2025-10-01T18:43:01 < tomeaton17> Oh I thought pointer type deduction was specifically not allowed
2025-10-01T18:43:07 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-01T18:44:10 < ventYl> I can't find any details so far
2025-10-01T18:44:22 < ventYl> even cppreference is missing any details
2025-10-01T18:44:45 < ventYl> and so far I've been stuck on C11
2025-10-01T18:46:01 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-01T18:47:42 < mawk> there's no wiki page yet for it on cppreference
2025-10-01T18:47:48 < mawk> they just say "type inference"
2025-10-01T18:47:49 < mawk> https://en.cppreference.com/w/c/keyword/auto.html
2025-10-01T18:48:25 < tomeaton17> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3007.htm I assume this is what was accepted. Appears to be straight implementation of GCC __auto_type
2025-10-01T18:49:59 < mawk> the standard is yeah 
2025-10-01T18:50:05 < mawk> but apparently the implementations go further
2025-10-01T18:50:35 < mawk> "Usability experience from C++ might set user expectation to be able to write auto * foo = .... Therefore the text leaves room for extensions;"
2025-10-01T18:50:49 < mawk> but this is the proposal, not the standard, maybe the standard actually went further
2025-10-01T18:51:04 < mawk> at least I know that auto *x works, I tried it in C23
2025-10-01T18:52:37 < tomeaton17> With clang?
2025-10-01T18:54:32 < mawk> just gcc
2025-10-01T18:54:47 < mawk> I did std=gnu23 but it probably works too with std=c23
2025-10-01T18:56:19 < mawk> yeah it works with auto but __auto_type doesn't want extra stuff around it
2025-10-01T18:56:25 < mawk> so it's more powerful 
2025-10-01T18:57:52 < tomeaton17> nice
2025-10-01T18:58:46 < tomeaton17> right home time see you tomorrow
2025-10-01T19:03:51 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2025-10-01T19:10:15 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has quit [Remote host closed the connection]
2025-10-01T19:11:25 < Steffanx> Welcome 
2025-10-01T19:15:00 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has joined ##stm32
2025-10-01T19:23:19 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has quit [Max SendQ exceeded]
2025-10-01T19:25:17 < bitmask> hello
2025-10-01T19:25:56 < Steffanx> Are you behaving yourself a little lately mr bitmask ?
2025-10-01T19:26:13 < bitmask> always
2025-10-01T19:26:39 < Steffanx> Ah good
2025-10-01T19:27:28 < bitmask> did something concern you otherwise?
2025-10-01T19:28:13 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has joined ##stm32
2025-10-01T19:28:18 < Steffanx> You never know what a bitmask is up to when he isn't here
2025-10-01T19:28:38 < bitmask> very true, but alas I am remaining boring 
2025-10-01T19:29:46 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has quit [Remote host closed the connection]
2025-10-01T19:30:10 < Steffanx> Ah I see
2025-10-01T19:30:31 < bitmask> you getting into any trouble? I can live vicariously through you
2025-10-01T19:30:43 < Steffanx> No I never get into trouble 
2025-10-01T19:31:40 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has joined ##stm32
2025-10-01T19:31:40 < bitmask> I figured... One day I'm gonna come on though and you are gonna be real sloppy or something
2025-10-01T19:32:20 < bitmask> bahhh, I gotta get this particle system working
2025-10-01T19:37:33 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has quit [Max SendQ exceeded]
2025-10-01T19:49:59 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has joined ##stm32
2025-10-01T19:54:20 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has quit [Remote host closed the connection]
2025-10-01T20:01:38 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has joined ##stm32
2025-10-01T20:05:55 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has quit [Remote host closed the connection]
2025-10-01T20:06:30 < qyx> I am struggling designing my photovoltaic water heater controller, there are nearly no leaded mosfets with rdson < 2 mR and Vds 100 V
2025-10-01T20:06:53 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has joined ##stm32
2025-10-01T20:07:22 < qyx> but if I do it bottom cooled SMT, I can't mount my thick busbars on the bottom (for ~70 A max)
2025-10-01T20:07:50 < qyx> and if I put them on the top layer, there is no place for connectors
2025-10-01T20:19:51 < jpa-> make your busbars your heatsinks
2025-10-01T20:26:52 < jpa-> meh, i thought i was smart when some wago plastic spacers were unavailable to buy, i downloaded their 3D model and had it printed.. they don't have all the holes in the models! :|
2025-10-01T20:30:02 < karlp> yeah, the "models are for mech fit testing" vs "models are models"
2025-10-01T20:30:06 < karlp> ran into that before :)
2025-10-01T20:33:01 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 264 seconds]
2025-10-01T21:45:05 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-01T21:51:01 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has quit [Remote host closed the connection]
2025-10-01T21:57:37 < mawk> drill them
2025-10-01T22:04:56 < catphish> qyx: wouldn't IGBTs be more appropriate at such voltages?
2025-10-01T22:06:22 < catphish> my experience wiht switching at mains voltages has always been with IGBTs - worth comparing the losses between the two
2025-10-01T22:06:33 < mawk> don't bring that woke gay stuff in here
2025-10-01T22:06:46 < catphish> :D
2025-10-01T22:06:50 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has joined ##stm32
2025-10-01T22:10:10 < specing> lol
2025-10-01T22:11:13 < antto> IGBTQ+ or what was it called
2025-10-01T22:11:35 < antto> no one actually knows, they keep inventing new "kinds"
2025-10-01T22:31:55 < qyx> catphish: I am at 70V, a dual paralleled 1.75 mR mosfet is giving me lower voltage drop than a igbt
2025-10-01T22:32:00 < qyx> sorry at 60 V
2025-10-01T22:51:13 < qyx> https://www.mouser.sk/datasheet/3/70/1/Infineon-IPP023N10N5-DS-v02_03-EN.pdf
2025-10-01T22:51:17 < qyx> page 6, diagram 3
2025-10-01T22:51:58 < qyx> I don't understand this, at Vds = 10 V I can only have like Id = 3 A?
2025-10-01T22:52:43 < qyx> or is that in the conduction state?
2025-10-01T22:53:26 < qyx> which means that if I keep the Vds under 1 V, I can switch > 100 A at DC?
2025-10-01T22:58:41 < jbo> mawk, lol'd
2025-10-01T23:02:12 < Steffanx> Want some Jezus Leeft stickers, mawk?
2025-10-01T23:05:57 < qyx> ok I need top-cooled fets
2025-10-01T23:06:25 < jbo> qyx, there are some (infineon?) packages with exposed metal/silicon on the top
2025-10-01T23:09:44 < qyx> I guess I will go with common PG‑HSOF‑8 packaged FETs and just yolo top-cooling
2025-10-01T23:10:33 < qyx> it has 62 °C/W on a minimal footprint areay, I need to cool about 1 W per mosfet
2025-10-01T23:11:23 < qyx> I will parallel 4 for 0.5 mR
2025-10-01T23:11:31 < qyx> shouldn't be a problem (tm)
2025-10-01T23:48:43 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 244 seconds]
--- Day changed Thu Oct 02 2025
2025-10-02T00:09:05 -!- infisd [~infisc@user/infisc] has quit [Read error: Connection reset by peer]
2025-10-02T00:09:22 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-02T00:16:13 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Ping timeout: 264 seconds]
2025-10-02T00:28:37 < karlp> my evening's output: https://github.com/CherryUSB/chryusb_configurator/pull/5
2025-10-02T00:28:45 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has quit [Remote host closed the connection]
2025-10-02T00:28:46 < karlp> now I can drink and play video games, I've been "useful"
2025-10-02T00:30:12 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has joined ##stm32
2025-10-02T00:41:56 -!- PaulFertser [paul@paulfertser.info] has quit [Ping timeout: 244 seconds]
2025-10-02T00:48:54 -!- PaulFertser [~paul@paulfertser.info] has joined ##stm32
2025-10-02T01:03:14 -!- Laurenceb_ [~Laurenceb@120.200.208.46.dyn.plus.net] has joined ##stm32
2025-10-02T01:04:05 < Laurenceb_> suppppp
2025-10-02T01:04:13 < Laurenceb_> anyone here used the VESC speed controller?
2025-10-02T01:10:28 < karlp> gonna run a train with it?
2025-10-02T01:11:36 < Laurenceb_> yeah
2025-10-02T01:11:46 < Laurenceb_> thats the new masterplan
2025-10-02T01:11:53 < Laurenceb_> crash the train with no survivors
2025-10-02T01:12:23 < Laurenceb_> but so far I cant get sensorless startup to work quite right
2025-10-02T01:12:53 < Laurenceb_> the sensorless tracking once its spinning is insane, seems to be beating an 18bit encoder
2025-10-02T01:13:31 < Laurenceb_> I wanted to take a closer look at the HFI debug but then I found I couldn't get debug datastream out, something is wrong with my config
2025-10-02T01:22:02 < Laurenceb_> one explanation for the odd behaviour: due to the large size of my motor, the HFI is not settling on the correct angle, even tho the angle SNR seems good
2025-10-02T01:22:24 < Laurenceb_> HFI is at 15kHz which is a crazy high frequency for my 500kW motor
2025-10-02T01:22:59 < Laurenceb_> its might be detecting surface eddy currents in the magnets or something weird
2025-10-02T01:23:22 < Laurenceb_> but I need full diagnostics to get the answer
2025-10-02T01:24:10 < Laurenceb_> Comsol says weird stuff starts to happen above a few kHz
2025-10-02T02:12:25 -!- Laurenceb_ [~Laurenceb@120.200.208.46.dyn.plus.net] has quit [Quit: Client closed]
2025-10-02T02:20:58 -!- Laurenceb_ [~Laurenceb@120.200.208.46.dyn.plus.net] has joined ##stm32
2025-10-02T02:21:00 < Laurenceb_> sheet, turns out I had flux linkage wrong
2025-10-02T02:21:17 < Laurenceb_> that would break things as the motor first starts to turn, which is what I see
2025-10-02T02:22:10 < specing> make sure to correctly insert the flux capacitor
2025-10-02T02:23:30 < Laurenceb_> lol
2025-10-02T02:23:56 < Laurenceb_> I should probably try vesc forums or email mr vedder himself, offer to pay...
2025-10-02T02:24:11 < Laurenceb_> unless its against loicense conditions to use in commercial products... sheeet
2025-10-02T02:25:27  * Laurenceb_ zzz
2025-10-02T02:25:32 -!- Laurenceb_ [~Laurenceb@120.200.208.46.dyn.plus.net] has quit [Client Quit]
2025-10-02T02:42:34 < ds2> how much does a 500W motor run thesedays?
2025-10-02T02:46:36 -!- srk_ [~sorki@user/srk] has joined ##stm32
2025-10-02T02:46:40 -!- Alexer- [~alexer@alexer.net] has joined ##stm32
2025-10-02T02:47:57 -!- srk [~sorki@user/srk] has quit [Remote host closed the connection]
2025-10-02T02:47:57 -!- Alexer [~alexer@alexer.net] has quit [Ping timeout: 250 seconds]
2025-10-02T02:48:17 -!- artok [~azo@88-112-154-28.elisa-laajakaista.fi] has quit [Ping timeout: 250 seconds]
2025-10-02T02:49:17 -!- artok [~azo@88-112-154-28.elisa-laajakaista.fi] has joined ##stm32
2025-10-02T02:49:27 -!- srk_ is now known as srk
2025-10-02T03:04:10 -!- akaWolf [~akaWolf@akawolf.org] has quit [Ping timeout: 248 seconds]
2025-10-02T03:04:32 -!- akaWolf [~akaWolf@akawolf.org] has joined ##stm32
2025-10-02T03:52:07 < karlp> I think they were talking about 500 _k_ W
2025-10-02T04:10:10 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-02T04:11:28 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-02T04:11:53 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-02T04:15:00 < ColdKeybo[a]rd> I may have discovered that it's not such a great idea to run traces under a QFN package when you have 2Oz board... Soldering it properly is pain in the but
2025-10-02T05:24:30 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-02T05:24:45 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Read error: Connection reset by peer]
2025-10-02T05:52:55 -!- NEYi [~NEYi@195.234.78.187] has quit [Quit: Leaving]
2025-10-02T05:54:52 < ds2> 500kW?!?! guess not a mains powered equipment
2025-10-02T05:58:54 < qyx> no they have their own transformer at the company
2025-10-02T06:00:09 < ds2> in that power realm, isn't it 3PH?
2025-10-02T06:00:38 < ds2> thought the preferred speed controller for 3PH is a VFD not VESC
2025-10-02T06:45:55 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-02T08:11:42 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Remote host closed the connection]
2025-10-02T08:12:21 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2025-10-02T08:14:55 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Remote host closed the connection]
2025-10-02T08:15:27 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2025-10-02T08:23:27 -!- haritz [~hrtz@user/haritz] has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
2025-10-02T08:32:56 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Ping timeout: 240 seconds]
2025-10-02T08:38:41 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-02T09:00:23 < jpa-> why are SOD-323 diodes so lazy
2025-10-02T09:00:39 < jpa-> they want to plop down lying on their side instead of standing up like a proper diode should
2025-10-02T09:02:51 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-02T09:09:02 -!- tomeaton17 [~tom@user/tomeaton17] has quit [Quit: ZNC 1.9.0+deb2ubuntu0.1~esm2 - https://znc.in]
2025-10-02T09:09:23 -!- tomeaton17 [~tom@user/tomeaton17] has joined ##stm32
2025-10-02T09:10:33 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-02T09:13:01 < infisd> maybe the leadframe is on the top instead of the bottom?
2025-10-02T09:14:03 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-02T09:19:51 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-02T09:30:34 -!- nerozero [~nerozero@87.253.63.54] has quit [Remote host closed the connection]
2025-10-02T09:32:28 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-02T09:35:45 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2025-10-02T09:40:21 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-02T09:46:13 -!- nerozero [~nerozero@87.253.63.54] has quit [Remote host closed the connection]
2025-10-02T09:46:33 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-02T09:47:58 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-02T09:54:13 -!- nerozero [~nerozero@87.253.63.54] has quit [Remote host closed the connection]
2025-10-02T09:55:59 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-02T09:57:26 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-02T10:03:17 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-02T11:02:06 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-02T11:02:56 -!- haritz [~hrtz@137.220.80.141] has joined ##stm32
2025-10-02T11:02:56 -!- haritz [~hrtz@user/haritz] has changed host
2025-10-02T11:11:27 < Posterdati> hi
2025-10-02T11:12:30 < Posterdati> please help, I need to develop for stm32mp157 an app using gtkmm but it is not installed in the default SDK, how can I add gtkmm to the SDK? Thanks!
2025-10-02T11:20:04 < qyx> I would say nobody here ever used gtkmm and maybe 1-2 ever used mp157 sdk
2025-10-02T11:20:32 < qyx> I don't even have a slightest clue how that sdk looks like personally
2025-10-02T11:21:52 < qyx> I touched ST's linux code once and I am not gonna do that again until they manage to upstream it, that is, redo it to be in some minimal required quality
2025-10-02T11:23:47 < jpa-> if you can run normal linux apps on the STM32MP157, i don't see why you'd need their SDK for the app development
2025-10-02T11:24:16 < qyx> probably because the FAE said so
2025-10-02T11:24:31 < qyx> if you are capable enough to do anything on the linux, you probably know how to
2025-10-02T11:26:33 < zyp> qyx, ever is a strong word
2025-10-02T11:26:56 < zyp> I used gtkmm for a project, probably 14 years ago or so
2025-10-02T11:27:01 < qyx> ok.
2025-10-02T11:27:06 < qyx> 14.
2025-10-02T11:27:18 < Posterdati> qyx: what distro do you use for stm32mp157?
2025-10-02T11:28:10 < Posterdati> a distro supporting iio
2025-10-02T11:28:16 < qyx> no distro, I am using imx6, imx8 and imx93
2025-10-02T11:28:47 < jpa-> yeah, i used gtkmm too, it is not bad
2025-10-02T11:28:50 < qyx> I wasn't even able to compile the kernel for mp157 custom board because everything was hardcoded for their boards in their kernel sources
2025-10-02T11:28:53 < jpa-> i don't remember what i used it for :D
2025-10-02T11:29:17 < zyp> anybody know any debug tools that can run the same application with two different inputs and break where execution diverges?
2025-10-02T11:30:50 < Posterdati> qyx: could yocto work on mp157?
2025-10-02T11:31:05 < jpa-> zyp: i assume on linux? or stm32?
2025-10-02T11:31:13 < zyp> yes, linux
2025-10-02T11:31:14 < qyx> and in realtime?
2025-10-02T11:31:28 < qyx> could it be even done?
2025-10-02T11:31:30 < jpa-> zyp: diverges as in instructions executed, or is on the syscall level enough?
2025-10-02T11:31:45 < qyx> yeah some strace comparator could be done
2025-10-02T11:31:46 < jpa-> it certainly could be done by having a script single-step in GDB and compare registers
2025-10-02T11:31:53 < jpa-> but slooow
2025-10-02T11:32:29 < zyp> I'd need branches, I believe
2025-10-02T11:32:54 < qyx> maybe run in on some of the crazy step-locked multicore cpus, they definitely have some NMI for that
2025-10-02T11:33:10 < jpa-> -fprofile-arcs could help, but i'm not aware of anything readymade
2025-10-02T11:33:23 < ventYl> yeah, this could help
2025-10-02T11:34:13 < ventYl> it hooks __gcov_init (?) and __gcov_leave (?) instrumentation to each entry and exit point of function
2025-10-02T11:34:25 < ventYl> or maybe even branches
2025-10-02T11:34:47 < ventYl> just dump these into file and then compare two runs
2025-10-02T11:34:58 < zyp> I have an issue with rust-bindgen, where it generates undesireable code for some particular input, but not other inputs, and I have no idea where in the codebase to start looking
2025-10-02T11:35:22 < ventYl> find out how many of them are identical and then in third run break just before the divertion
2025-10-02T11:35:45 < jpa-> you could also binary search without any special script, start with "step 100000" for each program, if they have diverged, check at "step 50000" etc.
2025-10-02T11:36:49 < jpa-> "rr" could be used to record a trace and compare, but i've never used it
2025-10-02T11:37:15 < ventYl> i see two problems: 1) how do you determine that they have diverged? 2) if it is known they diverge (and their execution is deterministic) then search and break is probably faster
2025-10-02T11:37:58 < jpa-> i'd say that if they are at different code locations, they have diverged.. it is unlikely for the execution paths to join again until end of program
2025-10-02T11:41:33 < zyp> so, here's my issue: https://paste.jvnv.net/view/2ScZT
2025-10-02T11:41:46 < zyp> some of my C consts are turned into rust statics, instead of consts
2025-10-02T11:43:06 < zyp> there's no sane reason this should happen
2025-10-02T11:44:28 < zyp> so I want to figure out why 1 << 63 and 1 << 62 are treated differently
2025-10-02T11:45:34 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-02T11:54:33 < qyx> whats the current statistic of rust solving problems vs rust causing problems?
2025-10-02T11:59:32 < zyp> I'm pretty happy with rust
2025-10-02T12:46:15 < nohit> Posterdati: ST is using yocto as their build system. you take one of their example images and add gtkmm to it and then build it. and then you build the sdk for the image (-c populate_sdk) and then you can use that sdk. i cant remember the details as its been a while since i last did it but it is all explained quite well in their wiki
2025-10-02T12:50:59 < nohit> i havent used gtkmm, but i have altered their existing images by adding packages to them, its quite easy and well documented
2025-10-02T12:51:55 < qyx> did you do it on a custom hardware?
2025-10-02T12:51:59 < nohit> no
2025-10-02T12:52:26 < nohit> mp157c-dk2
2025-10-02T12:52:54 < nohit> but doing it on custom hw is also documented in their wiki
2025-10-02T12:54:12 < qyx> then they either removed all the hardcoded shit or they documented it on 150 pages or they finally rewritten it as people and not monkeys
2025-10-02T12:54:39 < qyx> because eg. doing anything without their PMIC was virtually impossible
2025-10-02T12:54:53 < qyx> also using LPDDR2/3
2025-10-02T12:55:13 < qyx> also running their memory calibration software because it simply didn't work and cube crashed
2025-10-02T12:55:29 < nohit> well im not an expert on this, i just remember that i looked some documentation related to custom hardware as i was interested about it
2025-10-02T13:04:07 < jbo> oh shit are we talking stm32mp?
2025-10-02T13:04:18 < nohit> before i used their yocto-based system, i started with buildroot and this blog https://bootlin.com/blog/building-a-linux-system-for-the-stm32mp1-basic-system/
2025-10-02T13:04:31 < nohit> both methods worked painlessly for a beginner
2025-10-02T13:04:45 < jbo> well at least 2 years ago it was a fucking chaos
2025-10-02T13:04:51 < jbo> not the yocto stuff
2025-10-02T13:04:59 < jbo> but PMIC, undocumented shit, hardcoded I2C interfaces etc.
2025-10-02T13:08:25 < zyp> okay, I've found the issue
2025-10-02T13:08:30 < zyp> https://github.com/rust-lang/rust-bindgen/blob/main/bindgen/ir/var.rs#L343-L346
2025-10-02T13:09:50 < zyp> integer representation is i64, L343 returns None if the value doesn't fit in i64, L345 returns None if it's not a literal
2025-10-02T13:10:35 < zyp> so expressions that fit in i64 are fine, and u64 literals are fine, but u64 expressions doesn't match either and fail
2025-10-02T13:11:14 < zyp> expressions with a result >= 1<<63, that is
2025-10-02T13:11:38 < zyp> now lunch, then figure out how to fix it :p
2025-10-02T14:09:43 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2025-10-02T15:47:42 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-02T16:16:07 < tomeaton17> https://www.raspberrypi.com/news/5-10-price-increases-for-some-4gb-and-8gb-products/
2025-10-02T16:16:34 < tomeaton17> thanks openai for taking 40% of dram supply
2025-10-02T16:31:03 -!- haritz [~hrtz@user/haritz] has quit [Ping timeout: 244 seconds]
2025-10-02T16:35:43 < Posterdati> nohit: yocto is quite confusing, I used to program baremetal stm32 using only the debian arm cross compiling default suite...
2025-10-02T16:35:48 < Posterdati> nohit: thanks
2025-10-02T16:40:00 < ventYl> well, it is more complex as it deals with more complex tasks
2025-10-02T16:41:04 < qyx> yes, like building uboot, and kernel, and maybe rootfs if it is not downloaded in binary form
2025-10-02T16:41:46 -!- haritz [~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8] has joined ##stm32
2025-10-02T16:41:47 -!- haritz [~hrtz@user/haritz] has changed host
2025-10-02T16:42:00 < qyx> easy tasks doable using 2 commands, instead of that you are fetching 20 repos, building 700 packages, taking 20 gb of space or so and 4 hours to build
2025-10-02T16:44:37 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 250 seconds]
2025-10-02T16:48:44 < nohit> yes, i would say that yocto is a bit confusing at first, but in the end its quite easy to use
2025-10-02T16:49:17 < nohit> considering how complex tasks it is doing
2025-10-02T16:54:10 < qyx> that was sarcasm
2025-10-02T17:00:29 < nohit> ah you mean that it is easier to do by hand
2025-10-02T17:03:19 < nohit> well i would rather execute 2 commands and let yocto do all that work, even if it takes 4 hours
2025-10-02T17:05:58 < zyp> assuming it works.
2025-10-02T17:06:50 < nohit> also yocto let's you maintain the versions of all the packages, and a mechanism to apply patches to them automatically etc.
2025-10-02T17:07:13 < nohit> it would be quite a hassle to do it all by hand
2025-10-02T17:08:48 < zyp> one of the things I dislike about yocto is when you get layers fighting each other
2025-10-02T17:09:08 < zyp> e.g. wanting to patch the same package
2025-10-02T17:09:27 < nohit> i think there is a mechanism to handle that as well
2025-10-02T17:10:02 < nohit> layer priority/numbering or whatever it is called
2025-10-02T17:11:00 < zyp> changing who throws the first punch doesn't stop the fight
2025-10-02T17:12:31 < tomeaton17> it could stop the fight quicker though
2025-10-02T17:15:00 < zyp> I think my last annoyance with yocto was that meta-raspberrypi doesn't use UUID for the rootfs kernel argument, and there were apparently no easy way of achieving that
2025-10-02T17:18:52 < zyp> I also got annoyed by the build times, so I went and picked up a 36-core build box :p
2025-10-02T17:22:34 < mawk> I snapped a pic of my switch glitching https://i.imgur.com/EN5wW9P.png
2025-10-02T17:22:40 < mawk> but it's too brief to be relevant here
2025-10-02T17:22:50 < mawk> this happens with the board just laying on a table undisturbed
2025-10-02T17:24:14 < mawk> although it's a 216MHz core, idk how long it takes to register a new GPIO value, maybe it would actually have been registered as a 1
2025-10-02T17:25:31 < mawk> how about buildroot qyx 
2025-10-02T17:25:55 < mawk> one of my former teachers is the author
2025-10-02T17:38:00 < tomeaton17> ah I love the imgur uk ban
2025-10-02T17:41:41 < specing> it is nice that trash takes itself out
2025-10-02T17:46:22 < ventYl> wat ban?
2025-10-02T17:58:12 < Steffanx> Is that why Laurenceb no longer shows up, specing ?
2025-10-02T17:58:33 < Steffanx> And AreTooCommie
2025-10-02T17:58:56 < BrainDamage> r2commie ragequit
2025-10-02T17:59:26 < BrainDamage> laurenceb wrote something yesterday or 2 days ago
2025-10-02T18:00:15 < specing> Steffanx: wdym, he was here just yesterday
2025-10-02T18:00:41 < BrainDamage> tangentially related: https://en.wikipedia.org/wiki/Blaxploitation
2025-10-02T18:00:56 < BrainDamage> specing: wrote something since months of inactivity
2025-10-02T18:01:29 < specing> Blaxternator will be back
2025-10-02T18:01:36 < specing> always
2025-10-02T18:02:13 < Steffanx> Oh he's alive. I missed his presence 
2025-10-02T18:20:48 < qyx> nohit: no, patches are solving a nonexietent problem, if bsps were upstreamed, it is as easy as make defconfig && make build
2025-10-02T18:22:17 < qyx> also, building os for a custom device is really just bulding the bootloader, kernel and grabbing a ready rootfs
2025-10-02T18:22:21 < tomeaton17> ventYl: imgur blocked uk because they don't want to comply with OSA
2025-10-02T18:22:35 < qyx> gentoo is a history
2025-10-02T18:23:43 < mawk> BrainDamage r2com still comes once in a while on the offtopic channel
2025-10-02T18:23:45 < mawk> to tell us about how he "hates niggers and jews" and all that
2025-10-02T18:25:04 < BrainDamage> there's an offtopic channel? I thought this was it
2025-10-02T18:25:35 < mawk> yes there's only me and cracki on it
2025-10-02T18:25:54 < mawk> and jadew but he vanished
2025-10-02T18:26:09 < BrainDamage> maybe he finished the datalogger
2025-10-02T18:32:45 < mawk> I found the immigration identity card of a sudanese guy Steffanx 
2025-10-02T18:32:49 < mawk> who do I give it to
2025-10-02T18:32:55 < mawk> I can't find the guy online
2025-10-02T18:33:03 < mawk> can I sell it behind the train station?
2025-10-02T18:33:07 < jbo> ICE
2025-10-02T18:33:31 < jbo> or rather: IJS
2025-10-02T18:40:18 < Steffanx> Send it to the IND or gemeentehuis mawk. Maybe de politie. 
2025-10-02T18:40:31 < Steffanx> Don't forget to add some of your Jezus Leeft stickers
2025-10-02T18:40:35 < jbo> I was not being helpful :(
2025-10-02T18:41:48 < tomeaton17> jbo thats what I was going to say nice
2025-10-02T18:46:48 < Steffanx> How's cracki nowadays mawk?
2025-10-02T18:47:24 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-02T18:49:21 < mawk> alive
2025-10-02T18:50:05 < Steffanx> I see
2025-10-02T18:50:18 < mawk> there is a "jezus redt" truck always around delft
2025-10-02T18:50:21 < Steffanx> But will you take my advice? 
2025-10-02T18:50:30 < mawk> one time I saw the guy being controlled by the cops
2025-10-02T18:50:35 < Steffanx> Add some Jezus Leeft stickers and hand it in
2025-10-02T18:50:39 < mawk> as I presume he doesn't have the right to do that
2025-10-02T18:51:08 < mawk> sadly I used all my jezus leeft stickers 
2025-10-02T18:51:20 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-02T18:51:35 < mawk> but I have stickers with naked allah
2025-10-02T18:51:48 < mawk> from charlie hebdo
2025-10-02T18:52:32 < Steffanx> Lol
2025-10-02T18:52:40 < Steffanx> That might work too 
2025-10-02T19:03:37 < qyx> wth is jezus, is that somethink like juses was in the past?
2025-10-02T19:11:50 < mawk> it's the dutch jesus
2025-10-02T19:12:30 < BrainDamage> which wears wooden shoes and has been bolted to a city bike instead of a cross
2025-10-02T19:13:49 < qyx> apparently I missed my daily dose of interwebs
2025-10-02T19:47:44 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 240 seconds]
2025-10-02T20:05:42 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-02T20:24:56 -!- noarb [~noarb@user/noarb] has quit [Ping timeout: 240 seconds]
2025-10-02T20:29:56 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2025-10-02T20:30:01 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Remote host closed the connection]
2025-10-02T20:31:00 -!- noarb [~noarb@user/noarb] has joined ##stm32
2025-10-02T20:34:26 < karlp> wonderful, went to a "reliable, dwc, stm32" board and the one at home is h723 nucleo.
2025-10-02T20:34:35 < karlp> tinyusb devices all fail to enumerate on that.
2025-10-02T20:34:42 < karlp> everything is just shit isn't it :)
2025-10-02T20:41:19 < karlp> fuckin st "download as guest" still sends you a download link in an email... not really guest.
2025-10-02T20:43:36 < ventYl> dwc as host?
2025-10-02T20:46:20 < karlp> I'm only trying to get a device at the moment to check it worked.
2025-10-02T20:46:44 < karlp> I was using an f429 nucleo at work, device worekd fine there, and host mostly worked,
2025-10-02T20:47:06 < karlp> but it's at work, and I'm working from home today/tomorrow, thought htis h723 nucleo would be ~equally well supported.
2025-10-02T20:47:12 < karlp> but no.... htat was naiive
2025-10-02T20:48:54 < ventYl> h753 works for me
2025-10-02T20:49:06 < ventYl> in vendor device mode
2025-10-02T20:49:24 < ventYl> from tinyusb point of view they should be identical
2025-10-02T20:50:22 < ventYl> although throughtput is shitty
2025-10-02T20:50:27 < ventYl> 80kB down/40kB up
2025-10-02T20:50:47 < karlp> the demos all fail to enumerate for me, or at least, the four I've tried.
2025-10-02T20:51:13 < karlp> I want to try cherry, but it's all "here's the uvproj" 
2025-10-02T20:51:25 < karlp> I want a repo with a makefile/cmake that I can just build and go.
2025-10-02T20:51:31 < ventYl> did you sync repo head?
2025-10-02T20:51:37 < karlp> yeah.
2025-10-02T20:51:54 < ventYl> it might be rotten, wouldn't be the first time
2025-10-02T20:52:15 < ventYl> 40ddf0628a980a718db8c205c53ab45b595180f2
2025-10-02T20:52:19 < ventYl> this commit works for me
2025-10-02T20:52:57 < ventYl> my code is mostly modified vendor demo
2025-10-02T20:53:34 < ventYl> s/vendor/webusb/
2025-10-02T20:54:53 < karlp> that one doesn't even build with fucking -Werror failures.
2025-10-02T20:55:05 < karlp> sw is the wrost...
2025-10-02T20:59:26 < karlp> fuck me, trying to get cube up and i'm at like 2gig of downloads already before I even know if it is going to do anything
2025-10-02T21:06:46 < karlp> now thisthing is trying to use /usr/bin/cc?!
2025-10-02T21:13:46 -!- soweli_iki [soweli_iki@2600:3c02::f03c:93ff:fe5b:9fc] has joined ##stm32
2025-10-02T21:13:47 -!- soweli_iki [soweli_iki@user/soweli-iki:47461] has changed host
2025-10-02T21:15:40 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2025-10-02T21:19:27 < ventYl> something is broken in the kingdom of karlp
2025-10-02T21:22:26 < karlp> many many many things.
2025-10-02T21:22:43 < karlp> and when I try and put it away for something else "for a refreshing change" it's broken there too :)
2025-10-02T21:23:45 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-02T21:24:41 < karlp> well, cube shit is now stuck in "undefined reference to ExitRun0Mode" which Ive never heard of
2025-10-02T21:26:54 < ventYl> universe is probably trying to tell you you should shut that damn machine down and go grab a beer of whatever
2025-10-02T21:27:03 < karlp> soon :)
2025-10-02T21:27:18 < karlp> I can't let it tell me that everytime something breaks...
2025-10-02T21:29:53 < ventYl> no, usually that's a series of fuckups
2025-10-02T21:30:14 < ventYl> or just one large masterfuckup
2025-10-02T21:30:31 < ventYl> years ago, my work machine decided to play slideshow and degrade its performance to the level of 386
2025-10-02T21:30:58 < ventYl> i tried pretty much everything - rebooting, updates, restore, antivirus, you name it
2025-10-02T21:31:09 < ventYl> nothing helped, 8 hours fucked
2025-10-02T21:31:19 < ventYl> the next day it worked as if nothing happened
2025-10-02T21:31:28 < karlp> been there, done that :)
2025-10-02T21:31:32 < karlp> great times...
2025-10-02T21:31:50 < ventYl> at least i've been paid for fucking with it
2025-10-02T21:32:48 < ventYl> now I should establish a battery of boards running tests after each commit
2025-10-02T21:32:56 < ventYl> things are falling apart despite unit tests
2025-10-02T21:35:22 -!- noarb [~noarb@user/noarb] has quit [Ping timeout: 244 seconds]
2025-10-02T21:36:05 -!- noarb [~noarb@user/noarb] has joined ##stm32
2025-10-02T21:36:48 < ventYl> also, CRA has apparently an interesting loophole
2025-10-02T21:49:27 < qyx> hows our shared test rack setup going
2025-10-02T21:55:55 < ventYl> "server room" exists
2025-10-02T21:56:02 < ventYl> with no electricity and connectivity
2025-10-02T21:57:00 < karlp> well, cherry builds, then asserts.
2025-10-02T21:57:11 < karlp> and the assert implies there's a config I haven't done...  somehwere....
2025-10-02T21:57:21 < karlp> ok, that's enough for the day.
2025-10-02T22:05:43 -!- noarb [~noarb@user/noarb] has quit [Ping timeout: 250 seconds]
2025-10-02T22:12:02 -!- noarb [~noarb@user/noarb] has joined ##stm32
2025-10-02T22:14:16 -!- Livio [~livio@user/livio] has quit [Quit: leaving]
2025-10-02T22:15:23 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-02T22:28:17 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Quit: bitmask]
2025-10-02T22:29:25 -!- qyx [~qyx@84.245.121.119] has quit [Ping timeout: 264 seconds]
2025-10-02T22:29:35 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2025-10-02T22:31:19 -!- qyx [~qyx@84.245.121.209] has joined ##stm32
2025-10-02T23:38:23 < ventYl> karlp: welp, I have accidentally ran clang-tidy over dwc2 codebase and it gave me shit ton of errors. some of them quite fancy
2025-10-02T23:38:59 < ventYl> liek "warning: The left operand of '>>' is a garbage value"
2025-10-02T23:43:13 < karlp> heh, just went over a "wtf now" because I was getting atrocious noise on SCK, when the code is runnign and getting valid spi transaction.
2025-10-02T23:44:51 < karlp> turns out the mounting screw holes here, that I assumed where gnd pads aroudn the wholes: https://www.waveshare.com/media/catalog/product/cache/1/image/800x800/9df78eab33525d08d6e5fb8d27136e95/h/i/high-precision-ad-hat-3.jpg
2025-10-02T23:44:57 < karlp> are not. they're white silk.
2025-10-02T23:56:56 < karlp> cool though, if I run the vendor pythong spi code, it works.
2025-10-02T23:57:11 < karlp> if I run mine, it crashes because it's buggy, but after that, the vendor one doesn't work anymore :)
--- Day changed Fri Oct 03 2025
2025-10-03T00:05:25 < bitmask> https://i.imgur.com/TmZnKZQ.png
2025-10-03T00:05:36 < bitmask> does that look like 2 million particles?
2025-10-03T00:07:15 < antto> it looks like Elton Jonh's latest costume
2025-10-03T00:07:34 < antto> dafuq is this?
2025-10-03T00:14:20 < bitmask> just testing a new particle system implementation that runs entirely on GPU
2025-10-03T00:15:32 < bitmask> brb gym
2025-10-03T00:15:33 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Quit: bitmask]
2025-10-03T00:45:55 -!- szqmpc [~szqmpc@user/szqmpc] has joined ##stm32
2025-10-03T00:56:03 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2025-10-03T01:55:28 < karlp> ok cool. spidev talking to the ads1263 at 8Mhz...
2025-10-03T01:55:58 < karlp> tomorrow might actually connect the load cell faker to it...
2025-10-03T01:56:15 < karlp> success for the day!
2025-10-03T01:58:16 < qyx> did you python the spidev?
2025-10-03T01:58:31 < qyx> I will do spidev next week for ncn26010
2025-10-03T02:01:23 < karlp> yeah: https://github.com/karlp/lin-adc-iio-or-bust
2025-10-03T02:02:09 < karlp> I still want to get back to iio with th ehx711, work out what was up with getting buffered reads.
2025-10-03T02:02:24 < karlp> and then yeah, someother "proper" adc with iio and... and. and.....
2025-10-03T02:11:58 -!- szqmpc [~szqmpc@user/szqmpc] has quit [Remote host closed the connection]
2025-10-03T02:14:14 -!- szqmpc_ [~szqmpc@user/szqmpc] has joined ##stm32
2025-10-03T02:14:43 -!- szqmpc_ [~szqmpc@user/szqmpc] has quit [Max SendQ exceeded]
2025-10-03T02:46:31 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 240 seconds]
2025-10-03T03:31:42 -!- haritz [~hrtz@user/haritz] has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
2025-10-03T04:00:04 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-03T04:07:07 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-03T05:50:24 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-03T05:52:25 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 245 seconds]
2025-10-03T06:15:56 < ColdKeybo[a]rd> Anyone used FUSB302B for negotiating 20V on VBUS? I can't find any examples or drivers... :\
2025-10-03T07:22:02 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-03T07:37:35 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Quit: bitmask]
2025-10-03T07:58:19 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-03T08:51:09 -!- c10ud [~c10ud@user/c10ud] has quit [Read error: Connection reset by peer]
2025-10-03T08:51:32 -!- c10ud [~c10ud@host-87-2-122-85.retail.telecomitalia.it] has joined ##stm32
2025-10-03T08:51:32 -!- c10ud [~c10ud@user/c10ud] has changed host
2025-10-03T09:42:00 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-03T10:12:54 < mawk> I gave the card at the city hall Steffanx 
2025-10-03T10:12:57 < mawk> they didn't even pay me
2025-10-03T10:13:02 < mawk> sad
2025-10-03T10:38:07 < qyx> so, zyp, pdm says version 0.1 dev.1 in a github action
2025-10-03T10:38:13 < qyx> probably because of the shallow clone
2025-10-03T10:43:37 < zyp> yup
2025-10-03T10:44:21 < zyp> you might want something like this: https://github.com/orbcode/orbtrace/blob/main/.github/workflows/build.yml#L14
2025-10-03T10:48:00 < qyx> with: fetch-tags: true fetch-depth: 0
2025-10-03T10:48:05 < qyx> this works too
2025-10-03T10:48:12 < zyp> ah
2025-10-03T10:48:35 < zyp> does it work if the current commit is not tagged?
2025-10-03T10:48:54 < qyx> yes, it generates 1.7.1-dev3+g53416341685
2025-10-03T10:48:59 < qyx> which I am not happy with
2025-10-03T10:49:16 < qyx> the last tag was 1.7.0, I don't know where the patch=1 comes from
2025-10-03T10:49:25 < qyx> also I want -dev.3 to be semver compliant
2025-10-03T10:49:45 < qyx> I can't find an easy way to change the format in [tool.pdm.version]
2025-10-03T10:51:18 < zyp> it is semver compliant
2025-10-03T10:51:34 < zyp> this is «<version core> "-" <pre-release> "+" <build>»
2025-10-03T10:53:14 < zyp> 1.7.1 because newer than 1.7.0, dev3 because it's three commits after the last release and gwhatever because you need to distinguish different commits with the same number of parents since last release
2025-10-03T10:54:29 < zyp> semver will sort this after what you tagged last time, and before whatever you end up tagging next
2025-10-03T10:56:14 < zyp> but you can hook the formatting if you want, e.g: https://github.com/amaranth-lang/amaranth/blob/main/pyproject.toml#L5 https://github.com/amaranth-lang/amaranth/blob/main/pdm_build.py#L7-L13
2025-10-03T10:57:06 < qyx> ok strictly speaking semver section 9 says the prerelease identifier is one or more [0-9A-Za-z-] separated by a dot
2025-10-03T10:57:18 < qyx> so dev3 is a valid identifier
2025-10-03T10:57:34 < qyx> but their examples and me personally always use prerelease type <dot> number
2025-10-03T10:57:42 < qyx> a.1, b.1, dev.5, rc.4
2025-10-03T10:58:44 < qyx> and also I have never seen a prerelease for a patch version, I would bump 1.7.0 to 1.8.0 when a prerelease is made
2025-10-03T10:59:23 < qyx> nah
2025-10-03T10:59:52 < zyp> pdm doesn't know whether the next release will be 1.7.1 or 1.8.0 until you've tagged it, it needs to generate a version that's guaranteed to sort between 1.7.0 and 1.7.1
2025-10-03T11:00:19 < qyx> that's true but I don't like it
2025-10-03T11:01:27 < zyp> why do you even care? every release should be tagged in any case
2025-10-03T11:02:41 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-03T11:03:12 < qyx> there are "releases" downloaded to staging/testing which should probably be generated from the develop branch only
2025-10-03T11:03:41 < qyx> and they are not tagged, the same goes for PR "releases", etc.
2025-10-03T11:03:48 < zyp> in which case what you care about is the git hash at the end
2025-10-03T11:04:39 < qyx> just to understand me, I accept everything you have written, it is just my ocpd hurting
2025-10-03T11:32:33 -!- Livio [~livio@user/livio] has quit [Quit: leaving]
2025-10-03T11:34:34 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-03T12:09:12 -!- c10ud [~c10ud@user/c10ud] has quit [Read error: Connection reset by peer]
2025-10-03T12:09:34 -!- c10ud [~c10ud@host-87-2-122-85.retail.telecomitalia.it] has joined ##stm32
2025-10-03T12:09:34 -!- c10ud [~c10ud@user/c10ud] has changed host
2025-10-03T12:19:38 < tomeaton17> Terrorist in Manchester is/was called Jihad
2025-10-03T12:27:14 -!- haritz [~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8] has joined ##stm32
2025-10-03T12:27:14 -!- haritz [~hrtz@user/haritz] has changed host
2025-10-03T12:37:15 -!- szqmpc_ [~szqmpc@user/szqmpc-:51693] has joined ##stm32
2025-10-03T12:47:40 -!- rdmsr [~szqmpc@user/szqmpc] has joined ##stm32
2025-10-03T12:51:24 -!- szqmpc_ [~szqmpc@user/szqmpc-:51693] has quit [Ping timeout: 260 seconds]
2025-10-03T12:55:29 -!- rdmsr [~szqmpc@user/szqmpc] has quit [Ping timeout: 260 seconds]
2025-10-03T12:56:24 -!- rdmsr [~szqmpc@user/szqmpc] has joined ##stm32
2025-10-03T13:22:10 -!- hexo [~hexo@user/hexo] has quit [Remote host closed the connection]
2025-10-03T13:28:31 -!- hexo [~hexo@user/hexo] has joined ##stm32
2025-10-03T14:51:54 -!- System_Error [~SystemErr@user/systemerror] has quit [Ping timeout: 272 seconds]
2025-10-03T15:10:11 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-03T15:28:29 < mawk> using /dev/gpiochip0 on a raspbery toggling as fast as possible I can only get 405 kHz square wave
2025-10-03T15:28:32 < mawk> lame
2025-10-03T15:28:50 < mawk> maybe using /dev/gpiomem with a preempt-rt kernel it would be better
2025-10-03T15:45:04 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2025-10-03T16:15:51 -!- ferdna_ [~ferdna@user/ferdna] has joined ##stm32
2025-10-03T16:16:07 -!- remcycles [~remcycles@c-24-19-134-216.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer]
2025-10-03T16:16:15 -!- remcycles [~remcycles@c-24-19-134-216.hsd1.wa.comcast.net] has joined ##stm32
2025-10-03T16:17:29 -!- noarb- [~noarb@user/noarb] has joined ##stm32
2025-10-03T16:18:18 -!- srk [~sorki@user/srk] has quit [Ping timeout: 264 seconds]
2025-10-03T16:18:24 -!- srk [~sorki@user/srk] has joined ##stm32
2025-10-03T16:18:35 -!- remcycles_ [~remcycles@c-24-19-134-216.hsd1.wa.comcast.net] has joined ##stm32
2025-10-03T16:18:37 -!- ferdna [~ferdna@user/ferdna] has quit [Ping timeout: 264 seconds]
2025-10-03T16:18:37 -!- noarb [~noarb@user/noarb] has quit [Ping timeout: 264 seconds]
2025-10-03T16:21:01 -!- remcycles [~remcycles@c-24-19-134-216.hsd1.wa.comcast.net] has quit [Ping timeout: 264 seconds]
2025-10-03T16:27:01 -!- remcycles__ [~remcycles@c-24-19-134-216.hsd1.wa.comcast.net] has joined ##stm32
2025-10-03T16:29:25 -!- artok [~azo@88-112-154-28.elisa-laajakaista.fi] has quit [Ping timeout: 264 seconds]
2025-10-03T16:29:42 -!- artok [~azo@88-112-154-28.elisa-laajakaista.fi] has joined ##stm32
2025-10-03T16:30:01 -!- remcycles_ [~remcycles@c-24-19-134-216.hsd1.wa.comcast.net] has quit [Ping timeout: 264 seconds]
2025-10-03T17:00:05 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-03T17:04:39 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-03T17:05:02 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Read error: Connection reset by peer]
2025-10-03T17:35:39 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-03T18:03:54 -!- PaulFertser [~paul@paulfertser.info] has quit [Read error: Connection reset by peer]
2025-10-03T18:08:17 -!- PaulFertser [paul@paulfertser.info] has joined ##stm32
2025-10-03T18:08:21 < mawk> I had written the instruction `UMLAL hi, lo, a, b` instead of `UNLAL lo, hi, a, b` and wondered for hours why the result was off
2025-10-03T18:08:38 < mawk> they do all the maths everything big-endian but decide to write that instruction low-endian
2025-10-03T18:08:43 < mawk> -everything
2025-10-03T18:13:46 < Steffanx> I'm sorry mawk 
2025-10-03T18:14:01 < mawk> I even doubted my maths skillz for a moment
2025-10-03T18:14:03 < mawk> can you imagine
2025-10-03T18:15:24 < Steffanx> Time for some methadone 
2025-10-03T18:15:33 < mawk> I stopped methadone
2025-10-03T18:15:35 < mawk> did you forget
2025-10-03T18:15:53 < mawk> no more needles
2025-10-03T18:37:22 < tomeaton17> I thought you drink that stuff
2025-10-03T18:37:29 < tomeaton17> or eat it
2025-10-03T19:11:34 < qyx> what do mawk do now instead?
2025-10-03T19:11:47 < qyx> does sorry
2025-10-03T19:11:53 -!- rdmsr [~szqmpc@user/szqmpc] has quit [Quit: Leaving]
2025-10-03T19:32:15 < mawk> you're supposed to yes tomeaton17 
2025-10-03T19:32:54 < mawk> unless you crush the pills and boil them in dry ethanol then filter with a micrometric filter and boil down the filtrat to obtain pure methadone that you can load up in a syringe 
2025-10-03T19:33:04 < mawk> subutex qyx
2025-10-03T19:38:40 -!- CygniX [~CygniX@user/CygniX] has quit [Ping timeout: 265 seconds]
2025-10-03T19:39:01 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2025-10-03T19:42:25 -!- CygniX [~CygniX@user/CygniX] has joined ##stm32
2025-10-03T19:46:29 < mawk> saturated methadone solution is actually quite bad for the tissue, as surprising as it sounds
2025-10-03T19:47:24 < mawk> if it leaks out of the vein it does chemical burns all around the area
2025-10-03T19:47:41 < mawk> so my skin on hands and arms and feet is full of hyperpigmented scars from the burns
2025-10-03T19:47:46 < mawk> but it's slowly fading now
2025-10-03T20:04:39 < qyx> can't you just.. do nothing?
2025-10-03T20:37:42 < karlp> well, I fixed some bugs, and wired up my load, but... the values are trash.
2025-10-03T20:39:16 < karlp> at 2400sps it occasionally loses samples, the gpio chardev  repors multiple edges.
2025-10-03T20:39:20 < karlp> good enough..
2025-10-03T20:57:40 < mawk> what do you mean qyx
2025-10-03T20:57:45 < mawk> it's a prescription 
2025-10-03T20:57:50 < mawk> it's all legit
2025-10-03T20:58:08 < mawk> the ultimate goal is to stop everything by slowly decreasing the dose
2025-10-03T20:58:14 < mawk> but obviously you can't do that suddenly 
2025-10-03T20:58:23 < mawk> might take a year or a couple of years to get to 0
2025-10-03T20:59:19 < mawk> you mean /dev/gpiochip0 karlp ?
2025-10-03T20:59:22 < mawk> the new interface 
2025-10-03T21:08:32 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 240 seconds]
2025-10-03T21:13:53 -!- Livio_ [~livio@user/livio] has joined ##stm32
2025-10-03T21:18:14 -!- Livio [~livio@user/livio] has quit [Ping timeout: 272 seconds]
2025-10-03T21:47:16 < qyx> mawk: I know but I am not into such things so idk, it seems easy for me to just stop doing both non-legit ones and legit ones
2025-10-03T21:47:22 < qyx> but apparently life is not that e-z
2025-10-03T21:49:46 < mawk> it's hollywood stuff where they just lock themselves in a room for 2 days and are cured
2025-10-03T21:49:58 < mawk> in reality it's literally just torture, and it's pointless 
2025-10-03T21:50:15 < mawk> doing that has the worst outcomes possible, where people will relapse soon after
2025-10-03T21:50:25 < mawk> the only thing that works is substitution and tapering slowly 
2025-10-03T21:51:13 < mawk> and for me it wouldn't be 2 days it would be least a month with these kind of symptoms https://nida.nih.gov/sites/default/files/ClinicalOpiateWithdrawalScale.pdf
2025-10-03T21:54:57 < qyx> nah
2025-10-03T21:55:50 < mawk> nah what
2025-10-03T21:56:20 < qyx> nah = life is hard && i ingested the knowledge
2025-10-03T22:00:49 -!- Livio_ [~livio@user/livio] has quit [Quit: leaving]
2025-10-03T22:26:56 < mawk> a
2025-10-03T22:37:50 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 245 seconds]
--- Day changed Sat Oct 04 2025
2025-10-04T00:10:05 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-04T00:26:05 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 250 seconds]
2025-10-04T01:31:07 < qyx> https://github.com/mendsley/bsdiff/blob/master/bspatch.c
2025-10-04T01:31:17 < qyx> the bspatch function looks extremely simple
2025-10-04T01:31:25 < qyx> the rest of the file is just file i/o and bzip2
2025-10-04T01:48:14 < qyx> so my firmware has 96 KB and I expect it to grow to about 120K when there is ethernet support
2025-10-04T01:48:35 < qyx> bootloader has about 36 KB but 64 KB is reserved
2025-10-04T01:48:46 < qyx> my mcu has 256 KB of flash
2025-10-04T01:50:09 < qyx> and I want to download the firmware when the application is running over ethernet and then bootloader validates it and flashes
2025-10-04T01:50:35 < qyx> so I need an additional space for the new firmware, either in full or compressed or diff'd against the original firmware
2025-10-04T01:50:57 < qyx> so I could split the flash into 64/128/64 (bl, app, update)
2025-10-04T01:51:28 < qyx> or 64/160/32
2025-10-04T01:51:56 < qyx> or 48/16/160/32, 16 being a configuration partition which I need too
2025-10-04T01:52:31 < qyx> somewhat easier approach is to swap MCUs and get 512K
2025-10-04T01:52:50 < qyx> there is a limited number of test devices manufactured, namely 5
2025-10-04T03:37:59 < karlp> mawk: yweah, the gpio chardev is the /dev/gpiochip shits.
2025-10-04T04:38:16 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-04T04:45:18 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-04T05:02:35 < ColdKeybo[a]rd> Anyone have a FUSB302 library to recommend?
2025-10-04T05:03:05 < ColdKeybo[a]rd> I found the chromebook one and the arduino one but can't but neither of them work for me
2025-10-04T05:05:01 < ColdKeybo[a]rd> Not sure what is the deal with folks taking "broken/incomplete" C library and then rewritting them in C++... or even worse, rust
2025-10-04T05:26:14 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-04T05:27:05 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-04T05:28:31 -!- ferdna_ [~ferdna@user/ferdna] has quit [Quit: Leaving]
2025-10-04T05:47:32 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Quit: bitmask]
2025-10-04T05:50:55 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2025-10-04T05:53:24 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Client Quit]
2025-10-04T06:00:27 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2025-10-04T07:18:04 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Quit: bitmask]
2025-10-04T07:30:49 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2025-10-04T07:46:13 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Ping timeout: 264 seconds]
2025-10-04T08:06:09 -!- hexo [~hexo@user/hexo] has quit [Remote host closed the connection]
2025-10-04T08:14:01 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-04T08:45:13 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-04T10:14:29 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-04T10:26:46 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-04T10:55:17 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Ping timeout: 250 seconds]
2025-10-04T11:10:31 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 240 seconds]
2025-10-04T11:33:48 < mawk> it's a rpi karlp ? if you need blazing fast speeds you can use the gpio memory directly
2025-10-04T11:34:12 < mawk> mmap /dev/gpiomem into the program space and use registers directly
2025-10-04T13:15:40 < Steffanx> How fast is blazing fast?
2025-10-04T13:30:16 < qyx> about 250 moves per furlong
2025-10-04T13:30:27 < qyx> sorry fortnite
2025-10-04T13:37:19 < BrainDamage> you're always limited by the 1.8*10^13 furlong/fortnights speed of light
2025-10-04T14:09:54 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-04T14:43:22 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2025-10-04T15:12:25 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 244 seconds]
2025-10-04T15:35:29 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-04T15:38:34 < mawk> Steffanx as fast as the gpio clock runs
2025-10-04T15:38:41 < mawk> assuming you're not impeded by the kernel
2025-10-04T15:39:11 < mawk> but for that you can use a preempt-rt kernel and set your program to realtime class with priority 1 (or 0 but then you can starve the kernel?
2025-10-04T15:39:12 < mawk> )*
2025-10-04T16:29:09 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-04T17:20:05 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 250 seconds]
2025-10-04T17:29:56 < karlp> mawk: it is, but it's more about how fast you can respond to and edge and make spi transfers.  it's fast enough for me.
2025-10-04T17:43:43 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-04T17:46:46 < karlp> hecking lol, I was just reading the adc word as LE instead of BE.
2025-10-04T17:46:50 < karlp> been working the whole time.
2025-10-04T18:00:42 < karlp> cool.  ~same sigma on readings on this ads1263 hat on a rpi as on the "proper" scale.
2025-10-04T18:02:56 < mawk> nice
2025-10-04T18:04:13 < mawk> if you start the program with: sudo ionice -c1 -n0 nice -n-20 yourprogram
2025-10-04T18:04:38 < mawk> then there's less chance of something happening somewhere else on the OS perturbing the readings
2025-10-04T18:05:13 < karlp> no, shouldn't matter.
2025-10-04T18:05:32 < karlp> the kernel chardev gets the events, I just know I lost an event if I got multiple.
2025-10-04T18:05:56 < karlp> I mean, yes, that sort of thing is useful, but it's also why the end goal is to use IIO to justhave the kernel take care of it entirely.
2025-10-04T18:06:04 < karlp> this python spidev is just to try some different modes out.
2025-10-04T18:28:46 -!- infisd [~infisc@user/infisc] has left ##stm32 [Leaving]
2025-10-04T19:03:16 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-04T19:39:33 < \dev\ice> I want to play with JTAG boundary scan. any recomendation for mcu (or even dev board) which has all bsdl files etc?
2025-10-04T20:04:44 < zyp> idk about mcus, but fpgas tends to have them
2025-10-04T20:04:53 < zyp> I've poked at ecp5 boundary scan before
2025-10-04T20:29:08 < jpa-> \dev\ice: i think most STM32s have bdsl files (e.g. STM32F407 has them at https://www.st.com/en/microcontrollers-microprocessors/stm32f407-417.html#cad-resources )
2025-10-04T21:19:13 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 264 seconds]
2025-10-04T21:42:49 < zyp> jpa-, you say that like most stm32s even have jtag :p
2025-10-04T21:48:40 < jpa-> doesn't pretty much everything except cortex-m0? so 1424 out of 1869?
2025-10-04T22:06:55 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 240 seconds]
2025-10-04T22:28:31 -!- qyx [~qyx@84.245.121.209] has quit [Ping timeout: 240 seconds]
2025-10-04T22:30:35 -!- qyx [~qyx@84.245.121.70] has joined ##stm32
2025-10-04T22:45:34 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Quit: Konversation terminated!]
2025-10-04T22:46:04 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-04T22:46:11 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Read error: Connection reset by peer]
2025-10-04T23:24:59 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
--- Day changed Sun Oct 05 2025
2025-10-05T00:12:01 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Ping timeout: 264 seconds]
2025-10-05T02:49:29 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-05T04:06:36 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2025-10-05T04:26:13 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-05T04:42:16 -!- stgl [~stgl@2a03:b0c0:3:d0::cad:a001] has joined ##stm32
2025-10-05T05:44:57 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-05T07:21:42 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-05T07:28:21 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-05T09:13:00 -!- zChris [~zChris@user/zchris] has quit [Ping timeout: 252 seconds]
2025-10-05T09:47:39 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Ping timeout: 250 seconds]
2025-10-05T09:55:05 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-05T09:57:19 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-05T10:00:26 -!- zChris [~zChris@user/zchris] has joined ##stm32
2025-10-05T10:06:42 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-05T12:10:29 -!- PaulFertser [paul@paulfertser.info] has quit [Ping timeout: 260 seconds]
2025-10-05T12:21:50 -!- PaulFertser [paul@paulfertser.info] has joined ##stm32
2025-10-05T12:35:05 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-05T12:39:30 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-05T15:31:55 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-05T16:51:47 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-05T18:36:36 < LFSveteran> https://paste.debian.net/1399547/
2025-10-05T18:36:54 < LFSveteran> can anyone notice why adc calibration isn't finishing?
2025-10-05T18:37:03 < LFSveteran> using an L010
2025-10-05T18:37:16 < LFSveteran> saw this: http://www.efton.sk/STM32/gotcha/g157.html
2025-10-05T18:37:23 < LFSveteran> but is not applicable
2025-10-05T18:39:18 < jpa-> print out ADC register values
2025-10-05T19:00:06 < mawk> if you use the cube ide you can look at registers when the program is halted, like with a breakpoint
2025-10-05T19:00:12 < mawk> then it's easy
2025-10-05T19:01:22 < jpa-> or any debugger
2025-10-05T19:02:21 < LFSveteran> not using the IDE....using a nucleo board with jlink software flashed in the st-link
2025-10-05T19:02:32 < LFSveteran> maybe some debugger software
2025-10-05T19:02:44 < jpa-> gdb to the rescue
2025-10-05T19:16:07 -!- c10ud_ [~c10ud@host-87-2-122-85.retail.telecomitalia.it] has joined ##stm32
2025-10-05T19:18:21 < LFSveteran> hmm ADDIS = 1...maybe to fast...
2025-10-05T19:19:49 -!- c10ud [~c10ud@user/c10ud] has quit [Ping timeout: 264 seconds]
2025-10-05T19:23:02 < mawk> is ADVREGEN = 1 LFSveteran ?
2025-10-05T19:24:12 < mawk> ah yeah should be
2025-10-05T19:27:44 < mawk> there's a minimal calibration examples in the reference manual page 848
2025-10-05T19:28:07 < mawk> it says ensure ADEN = 0, clear ADEN, set ADCAL = 1, wait until EOCAL = 1, clear EOCAL
2025-10-05T19:33:39 < LFSveteran> it's zero
2025-10-05T19:33:57 < LFSveteran> ADC_CR = 0x00000002
2025-10-05T19:34:26 < LFSveteran> but it will be turned on automagicly when starting the calibration
2025-10-05T19:34:32 < mawk> but you also set it manually
2025-10-05T19:34:33 < LFSveteran> page 252
2025-10-05T19:34:36 < mawk> so it shouldn't be zero
2025-10-05T19:35:21 < LFSveteran> I'm not setting it?
2025-10-05T19:35:43 < mawk> yes you call LL_ADC_EnableInternalRegulator(ADC1);
2025-10-05T19:36:47 < LFSveteran> ah yeah
2025-10-05T19:36:52 < LFSveteran> overlooked it
2025-10-05T19:37:15 < mawk> but there's a startup time for it, so you might just remove that line and let the calibration enable it
2025-10-05T19:37:16 < LFSveteran> so why is ADC_CR 2?
2025-10-05T19:37:52 < LFSveteran> indeed unnecessary
2025-10-05T19:38:00 < LFSveteran> removing it
2025-10-05T19:38:43 < qyx> which stm3?2
2025-10-05T19:40:39 < LFSveteran> stm32l010rb
2025-10-05T19:43:38 < LFSveteran> I do 	ADC_REG_InitStruct.TriggerSource = LL_ADC_REG_TRIG_EXT_TIM2_TRGO;
2025-10-05T19:43:48 < LFSveteran> but EXTSEL=2?
2025-10-05T19:44:11 < LFSveteran> ADC_CFGR1=0x00001480
2025-10-05T19:44:13 < mawk> CR = 0x00000002 means the ADC is currently disabling
2025-10-05T19:44:19 < mawk> and it should go back to 0 after a while
2025-10-05T19:45:22 < LFSveteran> indeed, I just added an wait loop for it and seems it also stops there
2025-10-05T19:45:47 < LFSveteran> while (LL_ADC_IsDisableOngoing(ADC1));
2025-10-05T19:46:06 < mawk> you're not supposed to disable it if it's already disabled
2025-10-05T19:46:33 < mawk> even though it probably doesn't hurt, you can try to remove the disable
2025-10-05T19:48:18 < LFSveteran> removing is a good move
2025-10-05T19:48:37 < LFSveteran> now while (LL_ADC_IsDisableOngoing(ADC1)); is continuing
2025-10-05T19:49:51 < LFSveteran> while (LL_ADC_IsDisableOngoing(ADC1)); can be removed now
2025-10-05T19:50:18 < LFSveteran> calibration seems to finish too!
2025-10-05T19:50:28 < mawk> nice
2025-10-05T19:50:34 < LFSveteran> was it really this fuckup?
2025-10-05T19:50:48 < mawk> maybe, the doc isn't extremely clear about it
2025-10-05T19:51:20 < mawk> they make it seem it's just useless to disable a disabled ADC, but it might actually be a problem
2025-10-05T19:52:41 < mawk> the calibration might be faster if you check for calibration end with EOCAL = 1 instead of ADCAL = 0
2025-10-05T19:52:42 < LFSveteran> however it is still strange that ADC_CFGR1 is showing 0x00001480
2025-10-05T19:52:54 < mawk> although nvm you probably need to have both
2025-10-05T19:53:07 < mawk> is it still showing that after the calibration?
2025-10-05T19:53:21 < LFSveteran> hmm didn't check after calib
2025-10-05T19:55:48 < LFSveteran> yes also after calibration
2025-10-05T19:55:54 < mawk> 0x00001480 seems correct to me
2025-10-05T19:56:03 < mawk> that's EXTSEL = 010
2025-10-05T19:56:09 < mawk> which corresponds to TIM2_TRGO
2025-10-05T19:56:21 < mawk> in the table page 281
2025-10-05T19:56:36 < mawk> that's what you set it to
2025-10-05T20:00:06 < mawk> this is your CFGR1 https://bpa.st/raw/MFZQ
2025-10-05T20:01:06 < LFSveteran> correct
2025-10-05T20:07:58 < mawk> you can save the calibration in EEPROM and then set it back yourself after powering back up, if it takes too long
2025-10-05T20:08:03 < mawk> but idk how long it stays valid
2025-10-05T20:08:15 < mawk> especially if you're on battery
2025-10-05T20:08:26 < LFSveteran> I was confused by TRG2 thinking it must be TRG0 
2025-10-05T20:08:40 < LFSveteran> but TRG2 refers to TIM2_TRGO
2025-10-05T20:10:40 < mawk> yeah
2025-10-05T20:10:46 < mawk> it's in the table of page 281
2025-10-05T20:12:05 < LFSveteran> which document are you using? seems I have the wrong one
2025-10-05T20:12:13 < LFSveteran> https://www.st.com/resource/en/reference_manual/rm0451-ultralowpower-stm32l0x0-advanced-armbased-32bit-mcus-stmicroelectronics.pdf
2025-10-05T20:13:26 < mawk> ah yeah I had the wrong one
2025-10-05T20:13:29 < mawk> page 255 then
2025-10-05T20:27:44 < LFSveteran> thx so far
2025-10-05T20:34:00 < mawk> for your irq you want to differentiate between the different interrupts, it's not always EOC
2025-10-05T21:28:07 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 240 seconds]
2025-10-05T21:32:05 < mawk> why is it so convoluted to get started with nordic shit
2025-10-05T21:32:08 < mawk> it's cloning like 50 repositories
2025-10-05T21:34:19 < specing> it's the modern way, like node or rust
2025-10-05T21:40:17 < mawk> and it downloaded the exact same stuff twice
2025-10-05T21:40:22 < mawk> https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/installation/install_ncs.html
2025-10-05T21:40:26 < mawk> their AI-enhanced docs are suspicious
2025-10-05T21:41:00 < specing> just run away
2025-10-05T21:41:03 < mawk> first it tells to run `nrfutil sdk-manager install v3.1.1` which installs everything, and then again `west init blah` which fetches again the exact same thing in a different directory
2025-10-05T21:41:08 < mawk> but I want to use this board
2025-10-05T22:14:25 < qyx> 3.11?
2025-10-05T22:14:32 < qyx> are we there again?
2025-10-05T22:45:05 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-05T23:10:25 -!- tabemann_ [~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net] has quit [Remote host closed the connection]
2025-10-05T23:11:54 -!- tabemann_ [~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net] has joined ##stm32
2025-10-05T23:33:04 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Remote host closed the connection]
2025-10-05T23:33:26 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-05T23:43:20 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 256 seconds]
2025-10-05T23:54:07 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Ping timeout: 240 seconds]
2025-10-05T23:57:04 < karlp> so, using the IDAC on ads1263 to power the bridge, instead of the "raw" avdd on the test board results in much worse perf than I expected.
2025-10-05T23:57:17 < karlp> signals are smaller, of course, but sigma is like 5 times worse.
--- Day changed Mon Oct 06 2025
2025-10-06T00:02:42 < karlp> and at low current, you get this fun oddly periodic thing: https://bin.jvnv.net/file/bEbFs.png
2025-10-06T00:03:12 < qyx> of course noise goes up when the excitation voltage goes up
2025-10-06T00:03:45 < karlp> https://bin.jvnv.net/file/y5AvF.png
2025-10-06T00:03:50 < karlp> no, it's gone _down_
2025-10-06T00:04:10 < qyx> 20:57 < karlp> signals are smaller, of course, but sigma is like 5 times worse.
2025-10-06T00:04:18 < qyx> worse sigma means higher noise, doesn't it?
2025-10-06T00:04:28 < karlp> higher sigma, higher noise, yah.
2025-10-06T00:06:06 -!- Livio [~livio@user/livio] has quit [Quit: leaving]
2025-10-06T00:56:37 < karlp> yeah, gouiing from 5V excitation to ~700mV excitation is just not 
2025-10-06T00:57:15 < karlp> current excitation might be "nicer" and noise free compared to the voltage supply, but with ratiometric ref anyway, the gains frrom bigger signal are wayyyy bigger than the gains from less voltage noise.
2025-10-06T01:02:12 < karlp> so I think,if I realllly wanted better perf, ac excitation on one of the other ones would be next best step.
2025-10-06T01:02:21 < karlp> allows the higher excitation voltage for more signal up front.
2025-10-06T01:29:29 < mawk> v3.1.1 qyx 
2025-10-06T01:29:31 < mawk> it's the nRF SDK version
2025-10-06T01:29:34 < mawk> why
2025-10-06T01:29:52 < qyx> nrf for workgroups
2025-10-06T01:30:05 < qyx> karlp: I am using voltage exc at 2.5 V for my shit
2025-10-06T01:30:38 < mawk> lol
2025-10-06T01:30:49 < qyx> and will probably do 1 V in the future because I am constantly hitting current consumption limits with longer cable runs
2025-10-06T01:31:03 < mawk> the "toolchain shell" of the nRF SDK is using a bundled python, but they're also messing with bash's "command not found" function which calls a script using the system python but with nRF's python libraries and it's all broken
2025-10-06T01:31:07 < mawk> it's like they didn't even test it
2025-10-06T01:31:19 < mawk> I had to patch the system's command-not-found to remove LD_LIBRARY_PATH reset the PATH
2025-10-06T03:37:59 -!- jfsimon1981a [~jfsimon19@2a01:cb14:b9b:2000:15ca:6be8:ce67:7a24] has joined ##stm32
2025-10-06T03:38:12 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:c010:666e:d7e:d7b6] has quit [Ping timeout: 256 seconds]
2025-10-06T04:05:31 -!- hexo [~hexo@user/hexo] has joined ##stm32
2025-10-06T04:29:43 -!- duude__ [~duude__@user/duude/x-4676560] has quit [Ping timeout: 240 seconds]
2025-10-06T04:49:29 -!- duude__ [~duude__@user/duude/x-4676560] has joined ##stm32
2025-10-06T04:53:21 -!- duude__- [~duude__@user/duude/x-4676560] has joined ##stm32
2025-10-06T04:54:25 -!- duude__ [~duude__@user/duude/x-4676560] has quit [Ping timeout: 256 seconds]
2025-10-06T04:55:06 -!- duude__- is now known as duude__
2025-10-06T05:48:51 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-06T07:50:05 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-06T07:52:52 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Ping timeout: 246 seconds]
2025-10-06T07:53:17 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-06T08:01:58 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Ping timeout: 246 seconds]
2025-10-06T08:34:11 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-06T08:47:01 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-06T08:51:49 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 246 seconds]
2025-10-06T08:53:25 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 246 seconds]
2025-10-06T08:53:45 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-06T09:06:46 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-06T09:16:59 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2025-10-06T09:18:30 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-06T09:21:53 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 256 seconds]
2025-10-06T09:49:25 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 246 seconds]
2025-10-06T09:58:30 -!- Netsplit *.net <-> *.split quits: jfsimon1981a
2025-10-06T10:01:14 -!- jfsimon1981a [~jfsimon19@2a01:cb14:b9b:2000:15ca:6be8:ce67:7a24] has joined ##stm32
2025-10-06T11:44:58 < tomeaton17> another week another dollar
2025-10-06T12:12:55 -!- Netsplit *.net <-> *.split quits: veverak, flatmush, noarb-, ds2, Sadale, phryk_
2025-10-06T12:14:23 -!- Netsplit over, joins: phryk_, Sadale, noarb-, ds2, veverak, flatmush
2025-10-06T12:14:23 -!- phryk_ [~totallyno@user/phryk] has quit [Max SendQ exceeded]
2025-10-06T12:14:38 < mawk> zyp let a[n] the sequence defined by a[0] = 5/2, a[n+1] = a[n]² - 2, compute Π (1-1/a[k]), product from k = 0 to k = +∞
2025-10-06T12:14:41 -!- phryk [~totallyno@user/phryk] has joined ##stm32
2025-10-06T12:21:53 < c10ud_> copilot is absolutely sure it's 3/7, is it right
2025-10-06T12:27:56 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-06T12:28:12 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Read error: Connection reset by peer]
2025-10-06T12:30:13 < karlp> qyx: you're probably doing a bunch of other things better though :)
2025-10-06T12:32:14 < tomeaton17> anyone procured an openrtos licence before? Curious about pricing
2025-10-06T12:32:49 < karlp> curious about the motivations :)
2025-10-06T12:34:08 < tomeaton17> ip paranoid company
2025-10-06T12:42:46 < karlp> openrtos just looks like "do you _want_ to pay money? ok, sure... "
2025-10-06T12:43:01 < karlp> ip infringment protection from what?
2025-10-06T12:43:13 < karlp> ok, cool. every compnay has it's own wonk
2025-10-06T12:43:47 < tomeaton17> haha pretty much. who knows, none of our ip is related to the electronics, but ip is the main value of the company really
2025-10-06T12:45:49 -!- infisx [~infisc@user/infisc] has joined ##stm32
2025-10-06T12:47:03 < tomeaton17> considering we are not revenue generating yet
2025-10-06T12:47:38 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 248 seconds]
2025-10-06T12:48:33 < karlp> assuming that IP can be turned into value without sales is optimistic, but sure, I've seen that thinking :)
2025-10-06T12:49:16 < tomeaton17> oh yes I totally agree on that front
2025-10-06T12:55:18 < mawk> yes c10ud_ 
2025-10-06T12:55:30 < mawk> but it's part of its training set
2025-10-06T12:55:33 < mawk> it's a famous problem
2025-10-06T12:55:37 < mawk> from Putnam
2025-10-06T12:58:06 < c10ud_> 1st answer was wrong tho (1/2)
2025-10-06T13:29:48 -!- splud [~noneya.bi@user/splud] has quit [Ping timeout: 256 seconds]
2025-10-06T13:29:55 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-06T13:30:16 -!- splud [~noneya.bi@user/splud] has joined ##stm32
2025-10-06T13:32:02 -!- infisx [~infisc@user/infisc] has quit [Ping timeout: 260 seconds]
2025-10-06T13:35:28 -!- akaWolf [~akaWolf@akawolf.org] has quit [Ping timeout: 256 seconds]
2025-10-06T13:35:44 -!- akaWolf [~akaWolf@akawolf.org] has joined ##stm32
2025-10-06T13:36:35 -!- dudv2 [~dudv2@user/DudV2] has quit [Ping timeout: 245 seconds]
2025-10-06T13:36:50 -!- dudv2 [~dudv2@222-155-163-204-fibre.sparkbb.co.nz] has joined ##stm32
2025-10-06T13:38:37 -!- rkta [~rkta@user/rkta] has quit [Ping timeout: 265 seconds]
2025-10-06T13:38:46 -!- rkta [~rkta@user/rkta] has joined ##stm32
2025-10-06T13:47:19 -!- antto [~pewpew@antonsavov.net] has quit [Ping timeout: 265 seconds]
2025-10-06T13:48:12 -!- antto [~pewpew@antonsavov.net] has joined ##stm32
2025-10-06T13:56:35 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Ping timeout: 245 seconds]
2025-10-06T13:56:55 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2025-10-06T13:59:30 -!- zChris [~zChris@user/zchris] has quit [Ping timeout: 245 seconds]
2025-10-06T14:00:50 -!- zChris [~zChris@user/zchris] has joined ##stm32
2025-10-06T14:01:50 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 256 seconds]
2025-10-06T14:52:18 < mawk> in the MemManage IRQ I want to do some logging and then resume program execution, in case I detect a memory access to address 0
2025-10-06T14:52:29 < mawk> but the return address of the IRQ is the offending instruction, not the next instruction
2025-10-06T14:52:45 < mawk> can I just read the instruction and determine the size and then jump 2 or 4 bytes ahead?
2025-10-06T14:52:54 < mawk> it's thumb2 encoding on cortex M7
2025-10-06T14:53:35 < mawk> so if the first 5 most significant bits of the first half-word are 11101, 11110 or 11111 then it's a 32-bit instruction otherwise it's a 16-bit instruction
2025-10-06T14:54:45 < zyp> what are you trying to achieve with this?
2025-10-06T14:55:19 < mawk> finding NULL pointer dereferences in the code without breaking it
2025-10-06T14:55:45 < mawk> I know there's a bunch but we can't find them all at once, and the code still works with them for now, so I want to know where they are but keep doing the same thing as before
2025-10-06T14:56:18 < mawk> address 0 is the first byte of ITCM RAM so it doesn't crash, it's an actual RAM address; but now we've enabled the MPU and marked that sector as forbidden
2025-10-06T14:56:24 < mawk> and the firmware crashes
2025-10-06T15:05:14 < ventYl> mawk: well, return address is the offending instruction because it wasn't executed
2025-10-06T15:05:55 < mawk> yeah
2025-10-06T15:06:01 < mawk> and I want the next one
2025-10-06T15:06:06 < mawk> just skip over the bad instruction
2025-10-06T15:06:25 < mawk> or emulate it idk but that's too complicated
2025-10-06T15:06:39 < ventYl> though it is possible that due to the relaxed memory model of Cortex-M, memmanage can actually happen at different point in time than the instruction was executed
2025-10-06T15:07:03 < ventYl> so the offending instruction may not necessary be the same which is being executed
2025-10-06T15:07:09 < ventYl> or maybe this applies to hardfault only
2025-10-06T15:07:14 < ventYl> but I definitely seen that happening
2025-10-06T15:08:23 < mawk> well hardfault is different I suppose since it can come from the escalation of a double-fault which can happen away from the initial bad instruction
2025-10-06T15:09:22 < ventYl> I still don't see the value of skipping instruction reading address 0
2025-10-06T15:09:42 < ventYl> unless there was some well-known constant there, your program will misbehave if you skip that instruction
2025-10-06T15:10:34 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-06T15:12:47 < zyp> ventYl, the flags will tell you whether it's a precise or imprecise fault
2025-10-06T15:13:00 < zyp> if it's precise, the return addr is the faulting instruction
2025-10-06T15:13:29 < ventYl> zyp: yeah, but imprecise case won't be of any use for mawk as the $PC is already elsewhere
2025-10-06T15:13:36 < ventYl> so the damage has been done
2025-10-06T15:13:58 < zyp> I suspect in the imprecise case, you can just return and continue without skipping 
2025-10-06T15:25:32 < mercenary> mawk: are you trying to implement 'ON ERROR RESUME NEXT' here?
2025-10-06T15:26:19 < mawk> maybe? idk what that is
2025-10-06T15:26:22 < mawk> SQL stuff?
2025-10-06T15:28:19 < BrainDamage> a terrible policy in programming languages, vb has/had that option, to ignore errors and carry on, think bash where one command failing just carries ahead the control flow
2025-10-06T15:28:57 < qyx> python has that too
2025-10-06T15:29:01 < qyx> just import fukit
2025-10-06T15:29:33 < qyx> oh it is actually named fuckit
2025-10-06T15:31:46 -!- Livio [~livio@user/livio] has quit [Ping timeout: 272 seconds]
2025-10-06T15:34:22 < c10ud_> lol
2025-10-06T15:37:05 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-06T15:40:23 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-06T16:01:07 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2025-10-06T16:04:34 < qyx> mawk: are null pointer dereferences that common? how could that even happen? on one hand you are strictly conforming to the rule "initialize before use", on the other you fail to "always check returned pointers"
2025-10-06T16:23:04 -!- Livio [~livio@user/livio] has quit [Ping timeout: 272 seconds]
2025-10-06T16:30:01 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-06T16:40:48 -!- Livio [~livio@user/livio] has quit [Ping timeout: 272 seconds]
2025-10-06T17:48:00 < jpa-> mawk: have you considered using a watchpoint in debugger?
2025-10-06T17:48:30 < jpa-> though that only catches NULL exactly, not NULL[index]
2025-10-06T17:51:30 < mawk> yeah jpa- or just a breakpoint on MemManage which catches writing to the first sectoral 
2025-10-06T17:51:32 < mawk> sector
2025-10-06T17:52:01 < mawk> but there could be more in other places and it's annoying to test extensively the whole application there's like a thousand features
2025-10-06T17:52:19 < mawk> yeah qyx both things aren't always done in the codebase
2025-10-06T17:52:47 < mawk> BrainDamage in bash it's by default
2025-10-06T17:53:00 < mawk> but bash pros don't recommend using errexit
2025-10-06T17:53:10 < mawk> and to check the return code of everything instead 
2025-10-06T17:54:02 < jpa-> mawk: if they are rare enough, you could log on first MemManage ISR, then disable the area in MPU, continue, and after some time re-enable it
2025-10-06T17:54:25 < jpa-> that also avoids making things slow to a crawl if someone happens to do memcpy() from NULL
2025-10-06T18:16:09 < tomeaton17> has anyone tried out the ST extension for VS code
2025-10-06T18:16:46 < qyx> is there any minimum MPU region size?
2025-10-06T18:17:00 < qyx> can't you map only a few starting words?
2025-10-06T18:22:14 < karlp> tomeaton17: I installed it on friday?
2025-10-06T18:22:33 < karlp> but got as far it launching cubmex and that was sufficent for what I was trying then at least.
2025-10-06T18:22:58 < karlp> you have to dowload separately like a 2gig "command line toolchain" bullshit on the side.
2025-10-06T18:25:55 < tomeaton17> karlp: yeah I just installed the CLT thing
2025-10-06T18:26:19 < tomeaton17> You've got further than me then, when I launch cubemx through it crashes immediately
2025-10-06T18:26:21 < mawk> qyx mostly the whole ITCM area has to be forbidden if you want to forbid address 0
2025-10-06T18:26:56 < mawk> on cores with 16 regions you might be able to use the smallest possible sector for it, but we have only 8 and none left
2025-10-06T18:26:58 < ventYl> 32 bytes is the smallest area that can be exluded
2025-10-06T18:27:21 < mawk> if you make the size 256 bytes yeah
2025-10-06T18:28:04 < mawk> but there's no region slot left for that, with all the different things that should be configured
2025-10-06T18:28:22 < mawk> right jpa- 
2025-10-06T18:28:42 < ventYl> I still think you are trying to achieve something useless. go and fix those places. it won't take you that long
2025-10-06T18:28:53 < mawk> we don't know where they are
2025-10-06T18:29:38 < mawk> "having bug reports in an application is useless, go and fix the bugs" same idea
2025-10-06T18:30:01 < tomeaton17> kind of based
2025-10-06T18:30:37 < ventYl> your problem is not that you want to report the bug
2025-10-06T18:30:49 < ventYl> your problem is that you want the application to continue
2025-10-06T18:31:03 < mawk> well yeah of course
2025-10-06T18:31:10 < ventYl> and that you are not using RTOS
2025-10-06T18:31:16 < mawk> the customers need to keep using what they paid for
2025-10-06T18:31:41 < mawk> suddenly breaking where it used to work is not progress 
2025-10-06T18:32:39 < mawk> "your problem is that you have a legacy codebase" that's both true and a bit pointless, it's not something you fix like that
2025-10-06T18:32:54 < mawk> the decisions were made long before I arrived
2025-10-06T18:33:54 < ventYl> the sooner you start fixing it the sooner it is done
2025-10-06T18:34:15 < ventYl> moreover, being in a regulated industry, there's a valid question: how long will someone go to jail if this fucks up
2025-10-06T18:34:42 < mawk> you don't go to jail for bugs
2025-10-06T18:34:49 < mawk> there's a high bar for gross negligence 
2025-10-06T18:35:51 < tomeaton17> yeah even the therac 25 programmer didn't end up behind bars
2025-10-06T18:35:56 < mawk> and I'm not the one who takes the decisions, I repeatedly asked them to add a RTOS but that's not on the planning 
2025-10-06T18:39:48 -!- tomeaton17 [~tom@user/tomeaton17] has quit [Quit: ZNC 1.9.0+deb2ubuntu0.1~esm2 - https://znc.in]
2025-10-06T18:40:37 -!- tomeaton17 [~tom@user/tomeaton17] has joined ##stm32
2025-10-06T18:43:24 < ventYl> i don't know how medical works but automotive works in a way that communication is archived for 10 years by law
2025-10-06T18:43:51 < ventYl> and in case of massive fuckup it is examined and whoever cooperated without complaint is guilty
2025-10-06T18:44:34 < ventYl> my e-mails will be stored for 5 more years
2025-10-06T18:54:01 < mawk> nobody is storing our emails or git or teams or anything like that
2025-10-06T18:54:23 < mawk> but it's not like a surgical robot or an insulin pump, there's no immediate risk of debt
2025-10-06T18:54:35 < mawk> but the device could definitely kill a stupid patient
2025-10-06T18:54:39 < mawk> or one with dementia
2025-10-06T18:54:53 < mawk> risk of death*
2025-10-06T19:06:29 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-06T19:07:09 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-06T19:07:51 < ventYl> and that's why embedded is one huge pile of shit
2025-10-06T20:23:48 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-06T20:34:13 < qyx> s/embedded/whatever/
2025-10-06T20:53:50 -!- jfsimon1981a [~jfsimon19@2a01:cb14:b9b:2000:15ca:6be8:ce67:7a24] has quit [Remote host closed the connection]
2025-10-06T20:56:13 -!- jfsimon1981a [~jfsimon19@2a01:cb14:b9b:2000:15ca:6be8:ce67:7a24] has joined ##stm32
2025-10-06T20:56:58 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-06T21:00:01 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 256 seconds]
2025-10-06T21:36:51 < qyx> what do pros think about using huffman coding for ARM code?
2025-10-06T21:46:13 -!- mercenar- [~mercenary@2001:19f0:7400:85c3:5400:ff:fe03:dad9] has joined ##stm32
2025-10-06T21:46:40 -!- mercenary [~mercenary@user/mercenary] has quit [Killed (NickServ (GHOST command used by mercenar-!~mercenary@2001:19f0:7400:85c3:5400:ff:fe03:dad9))]
2025-10-06T21:46:46 -!- aandrew_ [~aandrew@vps-2437c00c.vps.ovh.ca] has joined ##stm32
2025-10-06T21:46:47 -!- esden_ [sid32455@id-32455.hampstead.irccloud.com] has joined ##stm32
2025-10-06T21:47:04 -!- soweli_iki_ [~soweli_ik@170-187-203-43.ip.linodeusercontent.com] has joined ##stm32
2025-10-06T21:47:04 -!- soweli_iki [soweli_iki@user/soweli-iki:47461] has quit [Read error: Connection reset by peer]
2025-10-06T21:47:10 -!- aandrew [~aandrew@vps-2437c00c.vps.ovh.ca] has quit [Read error: Connection reset by peer]
2025-10-06T21:47:11 -!- aandrew_ is now known as aandrew
2025-10-06T21:47:15 -!- CygniX_ [~CygniX@2a01:8740:1:727:4e:80:7f:2d] has joined ##stm32
2025-10-06T21:47:19 -!- mercenar- is now known as mercenary
2025-10-06T21:47:23 -!- esden [sid32455@id-32455.hampstead.irccloud.com] has quit [Ping timeout: 248 seconds]
2025-10-06T21:47:23 -!- invzim [~perole@vv.kirurg.org] has quit [Ping timeout: 248 seconds]
2025-10-06T21:47:23 -!- esden_ is now known as esden
2025-10-06T21:47:31 -!- mercenary [~mercenary@user/mercenary] has changed host
2025-10-06T21:47:32 -!- invzim [~perole@vv.kirurg.org] has joined ##stm32
2025-10-06T21:47:55 -!- BrainDamage [~m-t6k752@user/BrainDamage] has quit [Ping timeout: 248 seconds]
2025-10-06T21:47:55 -!- chiptuner [~bobby@user/chiptuner] has quit [Ping timeout: 248 seconds]
2025-10-06T21:48:09 -!- chiptuner [~bobby@user/chiptuner] has joined ##stm32
2025-10-06T21:48:14 -!- CygniX [~CygniX@user/CygniX] has quit [Read error: Connection reset by peer]
2025-10-06T21:49:29 -!- BrainDamage [~m-t6k752@user/BrainDamage] has joined ##stm32
2025-10-06T21:50:02 < qyx> ok no worky, .text contains 23680 32bit symbols
2025-10-06T21:50:07 < qyx> 17176 unique
2025-10-06T21:50:10 < qyx> oh wait, it is thumb
2025-10-06T21:50:35 < qyx> ok 47360 16bit symbols
2025-10-06T21:50:40 < qyx> 10045 unique
2025-10-06T21:50:46 < qyx> that's something
2025-10-06T21:51:23 < qyx> so out of 94720 bytes, 20090 bytes would be the dictionary
2025-10-06T21:51:51 < qyx> the question is, how much is the huffman encoded position
2025-10-06T21:58:44 -!- soweli_iki_ is now known as soweli_iki
2025-10-06T21:58:44 -!- soweli_iki [~soweli_ik@user/soweli-iki:47461] has changed host
2025-10-06T22:01:58 < qyx> not much, most of the symbols are 15 bit
2025-10-06T22:02:00 < qyx> so no gain
2025-10-06T22:06:29 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-06T22:24:35 < mawk> there are 32-bit thumb instructions
2025-10-06T22:25:12 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 260 seconds]
2025-10-06T22:29:25 -!- qyx [~qyx@84.245.121.70] has quit [Ping timeout: 264 seconds]
2025-10-06T22:33:33 -!- qyx [~qyx@84.245.120.46] has joined ##stm32
2025-10-06T22:34:34 < mawk> there's weird SMD antenna on my board, for BLE and wifi, they look like regular resistors
2025-10-06T22:34:35 < mawk> weird
2025-10-06T22:48:46 < ColdKeybo[a]rd> Am I crazy to expect that there should be a simple FUSB302 library that allows you to simply trigger higher voltage on the source if it's available and that's it...
2025-10-06T22:49:59 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2025-10-06T23:26:27 -!- sculptor [~sculptor@user/sculptor] has joined ##stm32
2025-10-06T23:27:04 -!- remcycles [~remcycles@c-24-19-134-216.hsd1.wa.comcast.net] has joined ##stm32
2025-10-06T23:27:19 -!- remcycles__ [~remcycles@c-24-19-134-216.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds]
2025-10-06T23:36:57 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 260 seconds]
2025-10-06T23:38:06 < mawk> USB is always complicated
2025-10-06T23:39:07 < qyx> ColdKeybo[a]rd: kinda crazy because MCUs have their own usb-c negotiation built in nowadays
2025-10-06T23:39:23 < qyx> basically only linux devices use fusb302 and there is a driver for that
2025-10-06T23:39:29 < qyx> no point in making your own
2025-10-06T23:39:58 < mawk> why is devicetree so convoluted
2025-10-06T23:40:01 < qyx> (and windows)
2025-10-06T23:40:01 < mawk> I'm missing cube now
2025-10-06T23:40:04 < mawk> it was easy
2025-10-06T23:40:25 < ColdKeybo[a]rd> qyx I know, but fusb302 is really cheap...
2025-10-06T23:40:40 < ColdKeybo[a]rd> And I understand that you can use it for source and sink, it has all the bells and whistles.
2025-10-06T23:41:05 < qyx> so just poke some registers and you are done
2025-10-06T23:41:29 < ColdKeybo[a]rd> But for example Linux implements every possible PD feature under the sun... so if you want to rip just the driver part and set the voltage... might as well write your own crappy driver
2025-10-06T23:42:07 < ColdKeybo[a]rd> But yeah, I guess long story short; I was expecting there would be a simple way of triggering a voltage level if it's available. But you are right... it's USB so why make it simple :)
2025-10-06T23:49:50 < mawk> you can load the module i2c-dev on linux and do your own i2c driver in userspace
2025-10-06T23:52:18 -!- sculptor [~sculptor@user/sculptor] has quit [Ping timeout: 256 seconds]
--- Day changed Tue Oct 07 2025
2025-10-07T00:04:27 -!- hexo [~hexo@user/hexo] has quit [Remote host closed the connection]
2025-10-07T00:13:47 < ColdKeybo[a]rd> But I'm not on linux and I'm using fusb302 on a MCU
2025-10-07T00:50:05 < mawk> why did you talk about ripping the driver out of linux then
2025-10-07T00:50:09 < mawk> if you're on a mcu it's even easier
2025-10-07T00:50:13 < mawk> it's just I²C
2025-10-07T01:10:47  * qyx starting Cube
2025-10-07T01:33:09 -!- jfsimon1981a [~jfsimon19@2a01:cb14:b9b:2000:15ca:6be8:ce67:7a24] has quit [Remote host closed the connection]
2025-10-07T01:34:25 -!- jfsimon1981a [~jfsimon19@2a01:cb14:b9b:2000:15ca:6be8:ce67:7a24] has joined ##stm32
2025-10-07T01:44:23 < ColdKeybo[a]rd> It's easier if you want to write your own driver from scratch
2025-10-07T01:46:38 < zyp> AIUI FUSB302 is just a PHY, so you still need a full PD stack hooked up to it
2025-10-07T01:47:04 < zyp> if you want something easier to use, maybe pick a chip with a built in PD stack
2025-10-07T01:47:25 < ColdKeybo[a]rd> Yeap, that's the annoying part. I can't find one that is "plug&play" enough that I can just trigger higher voltage and be done with it
2025-10-07T01:47:38 < ColdKeybo[a]rd> I'm kind of stuck with FUSB302 for now
2025-10-07T01:50:52 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2025-10-07T01:53:03 < zyp> how so?
2025-10-07T01:56:53 < zyp> FWIW I poked at this recently: https://github.com/elagil/usbpd, ran one of the stm32 examples
2025-10-07T01:57:08 < zyp> probably wouldn't be too hard to hook up to a FUSB302
2025-10-07T01:58:02 < zyp> alternatively you could just stick a stm32g071 in your project and let it be a self-contained USB-PD controller
2025-10-07T01:59:04 < zyp> I'm planning to use that for an upcoming work project
2025-10-07T02:00:58 < mawk> do you really need another component with FUSB302 if all you want is power?
2025-10-07T02:01:06 < mawk> I don't see any in their typical application block diagram
2025-10-07T02:01:15 -!- noarb- [~noarb@user/noarb] has quit [Ping timeout: 244 seconds]
2025-10-07T02:01:17 < mawk> just the mcu to talk to it using I²C
2025-10-07T02:01:20 < zyp> product is designed to be chainable, will have two USB-C ports, accept power on one port, peel of 10W for its own use and offer the remaining power on the other port
2025-10-07T02:01:32 < zyp> so that you can chain up like ten of them on a 100W PD brick
2025-10-07T02:02:54 -!- noarb [~noarb@user/noarb] has joined ##stm32
2025-10-07T02:06:00 < ColdKeybo[a]rd> This is great, except it's in rust...
2025-10-07T02:09:31 < zyp> you could give it a chance ;)
2025-10-07T02:14:29 < ColdKeybo[a]rd> Maybe one day I'll be at a gunpoint and won't have an option... but until then :)
2025-10-07T03:07:48 -!- duude__ [~duude__@user/duude/x-4676560] has quit [Ping timeout: 256 seconds]
2025-10-07T03:10:04 -!- duude__ [~duude__@user/duude/x-4676560] has joined ##stm32
2025-10-07T04:04:58 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-07T05:14:20 -!- infisx [~infisc@user/infisc] has joined ##stm32
2025-10-07T05:15:47 -!- tabemann__ [~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net] has joined ##stm32
2025-10-07T05:21:29 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:9c41:11c5:dedb:5a0] has joined ##stm32
2025-10-07T05:23:05 -!- remcycles_ [~remcycles@c-24-19-134-216.hsd1.wa.comcast.net] has joined ##stm32
2025-10-07T05:25:14 -!- Netsplit *.net <-> *.split quits: splud, remcycles, infisc, infisd, jfsimon1981a, tabemann_
2025-10-07T05:25:58 -!- Netsplit over, joins: infisc
2025-10-07T05:26:09 -!- infisx [~infisc@user/infisc] has quit [Remote host closed the connection]
2025-10-07T05:26:28 -!- infisx [~infisc@user/infisc] has joined ##stm32
2025-10-07T05:29:44 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:9c41:11c5:dedb:5a0] has quit [Ping timeout: 256 seconds]
2025-10-07T05:32:18 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Ping timeout: 256 seconds]
2025-10-07T05:32:19 -!- antto [~pewpew@antonsavov.net] has quit [Ping timeout: 256 seconds]
2025-10-07T05:32:41 -!- antto [~pewpew@antonsavov.net] has joined ##stm32
2025-10-07T05:33:09 -!- infise [~infisc@user/infisc] has joined ##stm32
2025-10-07T05:33:48 -!- splud [~noneya.bi@user/splud] has joined ##stm32
2025-10-07T05:34:01 -!- splud is now known as Guest3188
2025-10-07T05:34:19 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:9c41:11c5:dedb:5a0] has joined ##stm32
2025-10-07T05:35:34 -!- infisx [~infisc@user/infisc] has quit [Ping timeout: 246 seconds]
2025-10-07T05:38:43 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:9c41:11c5:dedb:5a0] has quit [Max SendQ exceeded]
2025-10-07T05:42:30 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:9c41:11c5:dedb:5a0] has joined ##stm32
2025-10-07T05:44:50 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2025-10-07T05:46:48 -!- jfsimon1981a [~jfsimon19@2a01:cb14:b9b:2000:9c41:11c5:dedb:5a0] has joined ##stm32
2025-10-07T05:50:17 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:9c41:11c5:dedb:5a0] has quit [Ping timeout: 260 seconds]
2025-10-07T06:26:49 -!- dudv2 [~dudv2@222-155-163-204-fibre.sparkbb.co.nz] has quit [Ping timeout: 256 seconds]
2025-10-07T06:26:49 -!- akaWolf [~akaWolf@akawolf.org] has quit [Ping timeout: 256 seconds]
2025-10-07T06:26:52 -!- akaWolf1 [~akaWolf@akawolf.org] has joined ##stm32
2025-10-07T06:27:36 -!- dudv2 [~dudv2@222-155-163-204-fibre.sparkbb.co.nz] has joined ##stm32
2025-10-07T07:43:04 -!- remcycles_ is now known as remcycles
2025-10-07T08:17:55 -!- aandrew_ [~aandrew@vps-2437c00c.vps.ovh.ca] has joined ##stm32
2025-10-07T08:18:26 -!- duude__ [~duude__@user/duude/x-4676560] has quit [Ping timeout: 256 seconds]
2025-10-07T08:18:31 -!- aandrew [~aandrew@vps-2437c00c.vps.ovh.ca] has quit [Read error: Connection reset by peer]
2025-10-07T08:18:31 -!- aandrew_ is now known as aandrew
2025-10-07T08:18:49 -!- duude__ [~duude__@user/duude/x-4676560] has joined ##stm32
2025-10-07T08:22:34 -!- jfsimon1981a [~jfsimon19@2a01:cb14:b9b:2000:9c41:11c5:dedb:5a0] has quit [Ping timeout: 248 seconds]
2025-10-07T08:24:22 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-07T08:25:39 -!- jfsimon1981a [~jfsimon19@2a01:cb14:b9b:2000:9c41:11c5:dedb:5a0] has joined ##stm32
2025-10-07T08:28:31 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-07T08:57:25 -!- zChris [~zChris@user/zchris] has quit [Ping timeout: 256 seconds]
2025-10-07T08:58:05 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2025-10-07T08:59:12 -!- dudv2 [~dudv2@user/DudV2] has changed host
2025-10-07T08:59:27 -!- zChris [~zChris@user/zchris] has joined ##stm32
2025-10-07T09:01:13 -!- rkta_ [~rkta@user/rkta] has joined ##stm32
2025-10-07T09:01:24 -!- rkta [~rkta@user/rkta] has quit [Killed (uranium.libera.chat (Nickname regained by services))]
2025-10-07T09:01:24 -!- rkta_ is now known as rkta
2025-10-07T09:04:10 -!- BrainDamage [~m-t6k752@user/BrainDamage] has quit [Ping timeout: 256 seconds]
2025-10-07T09:04:18 -!- BrainDamage [~m-t6k752@user/BrainDamage] has joined ##stm32
2025-10-07T09:20:15 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-07T09:20:58 -!- zChris [~zChris@user/zchris] has quit [Ping timeout: 246 seconds]
2025-10-07T09:21:30 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:9c41:11c5:dedb:5a0] has joined ##stm32
2025-10-07T09:22:01 -!- infise [~infisc@user/infisc] has quit [Ping timeout: 246 seconds]
2025-10-07T09:23:25 -!- jfsimon1981a [~jfsimon19@2a01:cb14:b9b:2000:9c41:11c5:dedb:5a0] has quit [Ping timeout: 246 seconds]
2025-10-07T09:24:10 -!- zChris [~zChris@user/zchris] has joined ##stm32
2025-10-07T09:25:34 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-07T09:46:06 -!- tom17 [~tom@user/tomeaton17] has joined ##stm32
2025-10-07T09:47:07 -!- tomeaton17 [~tom@user/tomeaton17] has quit [Ping timeout: 260 seconds]
2025-10-07T10:20:30 -!- BrainDamage [~m-t6k752@user/BrainDamage] has quit [Ping timeout: 256 seconds]
2025-10-07T10:20:31 -!- Guest3188 [~noneya.bi@user/splud] has quit [Ping timeout: 256 seconds]
2025-10-07T10:20:40 -!- splud_ [~noneya.bi@user/splud] has joined ##stm32
2025-10-07T10:20:54 -!- PaulFertser [paul@paulfertser.info] has quit [Read error: Connection reset by peer]
2025-10-07T10:21:24 -!- BrainDamage [~m-t6k752@user/BrainDamage] has joined ##stm32
2025-10-07T10:25:20 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 245 seconds]
2025-10-07T10:25:24 -!- PaulFertser [paul@paulfertser.info] has joined ##stm32
2025-10-07T10:58:15 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Ping timeout: 245 seconds]
2025-10-07T10:59:06 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-07T11:02:22 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Ping timeout: 256 seconds]
2025-10-07T11:03:50 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2025-10-07T11:51:53 -!- tom17 is now known as tomeaton17
2025-10-07T12:00:53 < mawk> can I use a timer as a comparator? I see you can use DMA to write into timer registers, so what happens if you write a value in the counter that's higher than the ARR, does it make an interrupt?
2025-10-07T12:14:38 < ventYl> I'd guess it wraps around, maybe generates overflow interrupt and then generates compare match interrupt once it counts to that value again
2025-10-07T12:41:19 < mawk> hmm
2025-10-07T12:41:32 < mawk> so if you stop the timer it won't do the compare
2025-10-07T12:41:56 < mawk> even if you set the "Capture/Compare n generation" bit?
2025-10-07T12:43:25 < mawk> nevermind there is something in the ADC directly to do comparison
2025-10-07T12:44:14 < mawk> so no need for a timer
2025-10-07T14:01:49 -!- srk [~sorki@user/srk] has quit [Ping timeout: 264 seconds]
2025-10-07T14:02:31 -!- srk [~sorki@user/srk] has joined ##stm32
2025-10-07T15:27:49 < mawk> zephyr is nice actually, the USB serial port works first try
2025-10-07T15:28:00 < mawk> it was worth messing with device tree for 2h
2025-10-07T15:36:09 -!- PhantomWork [~PhantomWo@user/phantom] has joined ##stm32
2025-10-07T15:37:01 < PhantomWork> Hihi, do you have a guide for the equivalent of an atomic_block on avr?
2025-10-07T15:47:32 < mawk> disabling IRQs and enabling them back afterwards
2025-10-07T15:48:21 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2025-10-07T15:48:52 < PhantomWork> so not much better thing than save primask, disable, do stuff, restore primask
2025-10-07T15:49:51 < mawk> well it's doing exactly that yes
2025-10-07T15:49:55 < mawk> why would that not be good
2025-10-07T15:50:18 < PhantomWork> I mean nothing better than doing it manually
2025-10-07T15:51:24 < mawk> you have __disable_irq() and __enable_irq in the CMSIS headers
2025-10-07T15:51:31 < mawk> or you can define your own macros
2025-10-07T15:52:24 < mawk> https://developer.arm.com/documentation/107706/0100/Exceptions-and-interrupts-overview/Special-registers-for-exception-masking/PRIMASK
2025-10-07T15:52:52 < PhantomWork> yeah   not a big deal, just sad that there is not one like in AVR, it make the code easier to read imo, and less errorprone
2025-10-07T15:54:53 < specing> PhantomWork: copy the implementation (macro?) from avr libs?
2025-10-07T16:00:41 < mawk> https://www.nongnu.org/avr-libc/user-manual/atomic_8h_source.html
2025-10-07T16:01:09 < tomeaton17> mawk: have you finally got an rtos then
2025-10-07T16:01:16 < mawk> not for work
2025-10-07T16:01:36 < mawk> I'm trying to use a nrf52 board I had laying around
2025-10-07T16:01:40 < mawk> to try stuff with 6LoWPAN
2025-10-07T16:07:06 < mawk> I remember trying to get 6LoWPAN running on a raspberry pi for a school project but there was a kind of bug in the linux driver
2025-10-07T16:07:10 < mawk> and I tried to fix it but gave up
2025-10-07T16:07:13 < mawk> I hope it's fixed now
2025-10-07T16:07:50 < mawk> using these modules on the pi https://ww1.microchip.com/downloads/en/devicedoc/70329b.pdf
2025-10-07T16:14:26 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2025-10-07T16:16:18 < PhantomWork> well thanks, I just made 2 functions
2025-10-07T16:22:38 -!- PhantomWork [~PhantomWo@user/phantom] has quit [Quit: Leaving]
2025-10-07T16:23:18 < tomeaton17> just fork it
2025-10-07T16:24:11 < karlp> it's wow, mrf24j40ma, blast from the past
2025-10-07T16:24:39 < karlp> my most starred github repo :)
2025-10-07T16:25:31 < tomeaton17> Right I have got the STM32 VS code extension working. Seems okay so far but a bit clunky. Haven't tried debugging yet but flashing works OTB with ST-LINK
2025-10-07T16:27:01 < bitmask> good morning
2025-10-07T16:43:22 < bitmask> https://imgur.com/a/Vb30o9y
2025-10-07T16:43:27 < bitmask> second or third better?
2025-10-07T16:43:59 < mawk> second but right pad the log levels so they have the same size
2025-10-07T16:44:28 < mawk> like [CRITICAL] [ERROR   ]
2025-10-07T16:44:30 < mawk> maybe
2025-10-07T16:44:47 < qyx> for me, trace is gray, debug is always green
2025-10-07T16:44:49 < qyx> info blue
2025-10-07T16:45:05 < qyx> warning error the same, critical is purple (to avoid background)
2025-10-07T16:45:16 < bitmask> yea I agree, I had them set but then realized they had default colors so I used them thinking they knew better
2025-10-07T16:45:41 < qyx> also for time field I am using iso8601
2025-10-07T16:45:55 < qyx> it has no spaces and is parsable by many tools
2025-10-07T16:45:55 < bitmask> which is?
2025-10-07T16:46:06 < bitmask> gonna make me look it up? :P
2025-10-07T16:46:36 < bitmask> I see
2025-10-07T16:46:39 < qyx> 2025-08-25T05:32:33Z
2025-10-07T16:46:44 < qyx> 2025-08-25T05:32:33+00:00
2025-10-07T16:46:57 < bitmask> yea ok I like that
2025-10-07T16:47:02 < bitmask> and the colors
2025-10-07T16:47:04 < mawk> I don't like the ugly T
2025-10-07T16:47:05 < bitmask> still not sure about the alignment
2025-10-07T16:47:18 < qyx> yeah I would align left and pad right
2025-10-07T16:47:33 < bitmask> what ugly T?
2025-10-07T16:47:37 < bitmask> oh in the date/time
2025-10-07T16:47:39 < bitmask> ?
2025-10-07T16:47:40 < mawk> yeah
2025-10-07T16:49:53 < bitmask> I also gotta figure out why the filename and line number stopped working
2025-10-07T16:51:14 < bitmask> oh, you gotta use the macros
2025-10-07T16:51:21 < bitmask> why did I change that
2025-10-07T16:53:55 < bitmask> oh right... trace and info weren't working for some reason
2025-10-07T16:54:01 < bitmask> trace and debug I mean
2025-10-07T16:54:04 < bitmask> buh
2025-10-07T16:54:44 < mawk> which macro are you using?
2025-10-07T16:54:56 < bitmask> well I'm using the spdlog library
2025-10-07T16:55:19 < bitmask> so SPDLOG_LOGGER_ERROR
2025-10-07T16:55:23 < bitmask> and the like
2025-10-07T16:55:55 < bitmask> but for some reason the trace and debug don't work
2025-10-07T16:56:30 < bitmask> ahh I think I see why
2025-10-07T16:57:28 < bitmask> default is to set minimum logging level to info, I was setting it incorrectly
2025-10-07T17:01:27 < bitmask> all fixed, now I gotta go back and add a million log commands
2025-10-07T17:01:43 < bitmask> maybe I'll get AI to do that :/
2025-10-07T17:09:10 < tomeaton17> bitmask: really nice image I really enjoyed that from the UK
2025-10-07T17:09:48 < bitmask> huh?
2025-10-07T17:10:07 < tomeaton17> https://help.imgur.com/hc/en-us/articles/41592665292443-Imgur-access-in-the-United-Kingdom
2025-10-07T17:11:15 < bitmask> haha wtf why?
2025-10-07T17:13:05 < tomeaton17> bitmask: online safety act bullshit
2025-10-07T17:13:25 < bitmask> is there an alternative to imgur that works everywhere?
2025-10-07T17:14:25 < tomeaton17> no idea, should get a vpn but don't think they like them at work
2025-10-07T17:17:51 -!- jerrycash3 [~jerrycash@user/jerrycash] has joined ##stm32
2025-10-07T17:18:50 < karlp> YYYYMMDDTHHMMSS.ssss
2025-10-07T17:21:19 -!- jerrycash2 [~jerrycash@user/jerrycash] has quit [Ping timeout: 240 seconds]
2025-10-07T17:38:13 -!- tomeaton17 [~tom@user/tomeaton17] has quit [Quit: ZNC 1.9.0+deb2ubuntu0.1~esm2 - https://znc.in]
2025-10-07T17:38:59 -!- tomeaton17 [~tom@user/tomeaton17] has joined ##stm32
2025-10-07T17:54:09 < mawk> the docs on the nordic HAL are worse than that of cube
2025-10-07T17:54:14 < mawk> idk how that's possible 
2025-10-07T17:54:46 -!- mid-kid1 is now known as mid-kid
2025-10-07T17:54:56 < bitmask> https://i.imgur.com/JiR85Zw.png
2025-10-07T17:54:59 -!- mid-kid [~mid-kid@2a01:7c8:aac8:1e8:5054:ff:fe5e:cd48] has quit [Quit: WeeChat 3.3]
2025-10-07T17:55:01 < bitmask> I think thats the final version
2025-10-07T17:55:08 -!- mid-kid [~mid-kid@2a01:7c8:aac8:1e8:5054:ff:fe5e:cd48] has joined ##stm32
2025-10-07T17:55:42 < bitmask> not 100% on the critical yet
2025-10-07T17:57:02 < bitmask> https://www.dropbox.com/scl/fi/hqn5d76jzl7lfogw0g7ti/Screenshot-2025-10-07-at-10.53.49-AM.png?rlkey=s1sgt5ue4cj4qbymxpl57mz8h&dl=0
2025-10-07T17:57:04 < bitmask> :P
2025-10-07T17:57:12 < bitmask> for UKers
2025-10-07T18:03:47 < karlp> fecking, can't get swo on f4 to work. tedddioussss.
2025-10-07T18:03:51 < karlp> i thought I understood this shit.
2025-10-07T18:05:51 < karlp> goddamn fifo ready bit never sets.
2025-10-07T18:07:25 -!- splud_ [~noneya.bi@user/splud] has quit [Quit: Leaving]
2025-10-07T18:07:50 -!- splud [~noneya.bi@user/splud] has joined ##stm32
2025-10-07T18:14:01 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Ping timeout: 246 seconds]
2025-10-07T18:21:40 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2025-10-07T18:27:01 < tomeaton17> bitmask looks very nice. What did you use for the colouring?
2025-10-07T18:31:58 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Ping timeout: 246 seconds]
2025-10-07T18:32:52 -!- asdasfsafag [~asdasfsaf@195.99.174.130] has joined ##stm32
2025-10-07T18:33:10 -!- asdasfsafag [~asdasfsaf@195.99.174.130] has quit [Client Quit]
2025-10-07T18:41:03 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2025-10-07T18:42:38 < bitmask> tomeaton17 its part of the spdlog library, it can use ansi color codes
2025-10-07T18:44:40 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-07T18:44:44 < tomeaton17> nice
2025-10-07T18:47:04 < bitmask> the annoying part is determining where it can and cant show colors. So for now since all I have is a mac to test on I check #ifdef __APPLE__ and found this to test if running in xcode: bool isXcode = getenv("__XCODE_BUILT_PRODUCTS_DIR_PATHS") != nullptr; and set it to use colors if not running in xcode because if it doesn't support colors then it will display the annoying few characters instead of actually setting colors
2025-10-07T18:48:50 < bitmask> im pretty sure all OS terminals (for windows as long as win10+) show color, so its the IDEs im not sure about
2025-10-07T18:49:36 < tomeaton17> is terminfo not useful for that?
2025-10-07T18:54:59 < qyx> bitmask: ask the terminal whether it supports color
2025-10-07T18:55:37 < qyx> first thing coming to my mind is ask for terminal size but I am sure there is some detection escape defined
2025-10-07T18:59:18 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-07T19:00:07 < ventYl> aren't dumb terminals at least dropping escape sequences if they don't implement colors?
2025-10-07T19:02:04 < qyx> no
2025-10-07T19:04:10 < qyx> echo -e "\x1b[19t" returns terminal size for example, you can read that response
2025-10-07T19:05:25 < qyx> or "\x1b[c" is get terminal attributes
2025-10-07T19:05:32 < qyx> which spits out some cryptic string
2025-10-07T19:33:12 < qyx> ventYl: dumb terminal may be redirect to a file, you don't want color escapes in your redirected log file (later opened in a text exitor and being surprised)
2025-10-07T19:36:14 -!- tabemann__ [~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net] has quit [Read error: Connection reset by peer]
2025-10-07T19:36:35 -!- splud [~noneya.bi@user/splud] has quit [Ping timeout: 245 seconds]
2025-10-07T19:37:31 < ventYl> qyx: detection if output is a terminal or not is simple: isatty()
2025-10-07T19:38:20 < qyx> doesn't look applicable on embedded
2025-10-07T19:41:51 < jpa-> error: not a typewriter
2025-10-07T19:49:30 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-07T19:57:43 < jpa-> lol, qualcomm buys arduino
2025-10-07T19:58:36 < ventYl> i hope they buy it to kill it
2025-10-07T20:09:46 < qyx> no, they are gonna replace broadcom with qca*
2025-10-07T20:10:03 < karlp> s/broadcom/renesas/
2025-10-07T20:10:05 < karlp> you're thinking of rpi
2025-10-07T20:12:02 < qyx> oho lol
2025-10-07T20:12:35 < ventYl> renesas on arduino?
2025-10-07T20:12:37 < qyx> yeah I didn't notice this detail
2025-10-07T20:12:43 < karlp> duh, where have you been the last two years?
2025-10-07T20:12:47 < qyx> so they are converting arduino to rpi
2025-10-07T20:13:09 < karlp> current arduino uno (r4) is renesas ra4m or something.
2025-10-07T20:13:24 < karlp> it's all the same for them, they properly got the HAl right, they actually have portable code...
2025-10-07T20:13:32 < ventYl> do you have to sign the NDA using your blood to get the datasheet for that thing?
2025-10-07T20:13:38 < ventYl> because that's my experience with renesas
2025-10-07T20:14:04 < karlp> all the current renesas mcus anc mpus seems to ahve readily available proper docs as far as I'v efound so far
2025-10-07T20:14:32 < ventYl> som they are not idiots, they just do what others do in the automotive business
2025-10-07T20:15:31 < ventYl> our copy of reference manual for RH850V was watermarked by my colleague's name and I guess I read it illegally
2025-10-07T20:15:40 < ventYl> company probably should have obtained another copy with my name watermarked on it
2025-10-07T20:23:49 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-07T20:25:17 -!- BrainDamage_ [~m-t6k752@user/BrainDamage] has joined ##stm32
2025-10-07T20:27:07 -!- BrainDamage [~m-t6k752@user/BrainDamage] has quit [Ping timeout: 246 seconds]
2025-10-07T20:27:08 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 246 seconds]
2025-10-07T20:27:09 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-07T20:29:32 -!- jerrycash2 [~jerrycash@user/jerrycash] has joined ##stm32
2025-10-07T20:30:09 -!- BrainDamage_ is now known as BrainDamage
2025-10-07T20:32:43 -!- jerrycash3 [~jerrycash@user/jerrycash] has quit [Ping timeout: 256 seconds]
2025-10-07T20:45:25 -!- dudv2_ [~dudv2@222-155-163-204-fibre.sparkbb.co.nz] has joined ##stm32
2025-10-07T20:51:06 -!- Netsplit *.net <-> *.split quits: dudv2
2025-10-07T20:51:08 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Ping timeout: 256 seconds]
2025-10-07T20:51:57 -!- Livio [~livio@user/livio] has quit [Quit: leaving]
2025-10-07T22:18:06 < qyx> what would be the most user-friendly unbrick feature for a wifi router?
2025-10-07T22:23:51 < mercenary> an acceleration sensor. vigorously shaking the router resets to factory defaults.
2025-10-07T22:26:32 < ventYl> my internet banking has this feature. their "mascot" is an owl. violently shaking smartphone while an owl is displayed feels like I am trying to kill it :>
2025-10-07T22:26:51 < ventYl> and it in fact is as doing so will turn the application off
2025-10-07T22:29:10 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 246 seconds]
2025-10-07T22:31:50 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2025-10-07T22:47:25 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Ping timeout: 264 seconds]
2025-10-07T23:15:37 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Ping timeout: 264 seconds]
2025-10-07T23:17:25 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 264 seconds]
--- Day changed Wed Oct 08 2025
2025-10-08T00:04:40 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-08T00:14:13 < catphish> is it possible to force a value into a DAC that is running in DMA mode?
2025-10-08T00:15:34 < catphish> i want to initialize a DAC, set it to the centre voltage, then some time later, start a DMA stream
2025-10-08T00:15:45 < catphish> but i can't figure out how to do this with HAL
2025-10-08T00:16:15 < catphish> maybe if i just set the register manually it'll work
2025-10-08T00:20:08 < catphish> (it doesnt) :(
2025-10-08T00:25:06 -!- srk [~sorki@user/srk] has quit [Ping timeout: 256 seconds]
2025-10-08T00:25:06 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Ping timeout: 256 seconds]
2025-10-08T00:25:22 -!- srk [~sorki@user/srk] has joined ##stm32
2025-10-08T00:25:23 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2025-10-08T00:38:33 -!- soweli_iki_ [~soweli_ik@170-187-203-43.ip.linodeusercontent.com] has joined ##stm32
2025-10-08T00:39:04 -!- soweli_iki [~soweli_ik@user/soweli-iki:47461] has quit [Read error: Connection reset by peer]
2025-10-08T00:48:49 < zyp> catphish, no reason (beyond stupid libs) that shouldn't be possible
2025-10-08T00:49:02 < zyp> DMA is just automated register writes
2025-10-08T00:50:05 < catphish> that was my thought too, clearly i'm missing something dumb
2025-10-08T01:05:27 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2025-10-08T01:10:49 < karlp> qyx: what sort of cap are you using on diff inputs? a lot of old stuff i've got lying around has  jsut got 100nF x7r with 1k5 resistors, which is ~2k cutoff, but I'm reading I _realllly_ should be using c0g for the diff cap, and 100nF c0g et al is like 1206 and "no longer free" ?
2025-10-08T01:11:31 < karlp> I'm looking at using 10nf and 10k, for a ~3khz cuttoff, but "more resistah, moah bad" ...
2025-10-08T01:11:43 < karlp> I wonder if I should place both versions on different hcannel pairs....
2025-10-08T01:14:00 -!- CygniX_ [~CygniX@2a01:8740:1:727:4e:80:7f:2d] has left ##stm32 [Konversation terminated!]
2025-10-08T01:24:27 < tomeaton17> cannot wait for all arduino docs to be behind 2000s NDAs
2025-10-08T01:24:34 < tomeaton17> massive win for open source hardware
2025-10-08T01:25:29 < tomeaton17> fucking poe2 servers are dogshit
2025-10-08T01:29:33 < qyx> karlp: foil 1u
2025-10-08T01:29:48 < qyx> sorry 220n
2025-10-08T01:31:21 < ventYl> tomeaton17: I wouldn't mind if Arduino was killed
2025-10-08T01:31:25 < ventYl> we can do better
2025-10-08T01:44:14 < karlp> yeah, no wonder you're stomping on noise so well :)
2025-10-08T01:44:52 < karlp> fecking, 0603 are feeling too big again.
2025-10-08T01:54:13 < tomeaton17> sure lets remake it with a bluepill
2025-10-08T02:21:39 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 250 seconds]
2025-10-08T03:06:59 < qyx> also, mercenary, that would not work as the router is intended for vibrating environments
2025-10-08T03:37:33 -!- tabemann__ [~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net] has joined ##stm32
2025-10-08T03:37:33 -!- tabemann__ is now known as tabemann
2025-10-08T03:42:14 < ColdKeybo[a]rd> What Arduino and Qualcomm have in common? Lol, such unexpected move
2025-10-08T04:39:32 -!- soweli_iki_ is now known as soweli_iki
2025-10-08T04:39:33 -!- soweli_iki [~soweli_ik@user/soweli-iki:47461] has changed host
2025-10-08T05:03:24 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-08T05:13:42 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-08T05:14:50 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-08T05:15:15 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-08T05:24:37 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Ping timeout: 264 seconds]
2025-10-08T05:40:24 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 260 seconds]
2025-10-08T05:40:32 -!- infisx [~infisc@user/infisc] has joined ##stm32
2025-10-08T05:49:11 -!- infise [~infisc@user/infisc] has joined ##stm32
2025-10-08T05:52:04 -!- infisx [~infisc@user/infisc] has quit [Ping timeout: 260 seconds]
2025-10-08T06:01:23 -!- infisx [~infisc@user/infisc] has joined ##stm32
2025-10-08T06:04:19 -!- infise [~infisc@user/infisc] has quit [Ping timeout: 260 seconds]
2025-10-08T06:07:40 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-08T06:08:44 -!- infise [~infisc@user/infisc] has joined ##stm32
2025-10-08T06:09:34 -!- infisx [~infisc@user/infisc] has quit [Ping timeout: 260 seconds]
2025-10-08T06:12:29 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 260 seconds]
2025-10-08T06:12:34 -!- CygniX [~CygniX@user/CygniX] has joined ##stm32
2025-10-08T06:28:27 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-08T06:30:50 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-08T06:34:04 -!- infise [~infisc@user/infisc] has quit [Ping timeout: 260 seconds]
2025-10-08T06:39:55 -!- infisx [~infisc@user/infisc] has joined ##stm32
2025-10-08T06:40:12 -!- infisx [~infisc@user/infisc] has quit [Remote host closed the connection]
2025-10-08T06:41:39 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 260 seconds]
2025-10-08T06:42:16 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-08T06:49:23 -!- infisx [~infisc@user/infisc] has joined ##stm32
2025-10-08T06:50:56 -!- infise [~infisc@user/infisc] has joined ##stm32
2025-10-08T06:51:34 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 260 seconds]
2025-10-08T06:53:54 -!- infisx [~infisc@user/infisc] has quit [Ping timeout: 260 seconds]
2025-10-08T06:55:39 -!- infise [~infisc@user/infisc] has quit [Ping timeout: 260 seconds]
2025-10-08T07:19:16 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-08T07:19:30 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Read error: Connection reset by peer]
2025-10-08T07:47:53 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-08T08:56:12 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-08T08:56:15 -!- dudv2_ [~dudv2@user/DudV2] has changed host
2025-10-08T08:58:06 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-08T09:15:44 < mercenary> qyx: ah. that wasn't mentioned in the spec. Anyway, most useful is what 'people' expect. I expect "power-up while holding down one or more buttons, with a clear indication in LEDs that 'yeah, I got it, factory reset' that brings the thing into a known state"
2025-10-08T09:16:21 < mercenary> And enough information printed on the box to connect to it in that known state without having to find manuals.
2025-10-08T09:28:27 < qyx> https://github.com/pts/muxzcat/blob/master/README.txt#L102
2025-10-08T09:28:33 < qyx> > containing the entire uncompressed data
2025-10-08T09:28:35 < qyx> pls.
2025-10-08T09:29:01 < qyx> mercenary: yeah although it is a corruptive recovery
2025-10-08T09:29:58 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-08T09:33:29 < mercenary> qyx: once something gets into a state where it needs 'hit it with a hammer' type recovery, it is necessarily corruptive
2025-10-08T09:34:39 < qyx> it doesn't have to be, usually the cause for unbricking is a lost or damaged configuration
2025-10-08T09:34:46 < mercenary> iirc it was 'tik that had two levels of 'Reset!', one full factory reset, one that left configured address and passwords intact.
2025-10-08T09:34:58 < qyx> or corrupted firmware on update, etc.
2025-10-08T09:35:43 < qyx> you don't need to erase the full config, just to enable a way to get in
2025-10-08T09:36:17 < qyx> obviously doing full reset erases the password, but also the keys (if any) and configuration
2025-10-08T09:38:05 < mercenary> 90% of the times I have used 'unbrick' was because 'somebody set this thing up for us, no we don't know what the passwords are'. Firmware corruption on update is rare compared to that
2025-10-08T09:39:27 < mercenary> So if there is more than one reset mode, 'full factory reset' and 'password reset only' would be my choices.
2025-10-08T09:40:19 < qyx> you can't reset password without doing full factory reset
2025-10-08T09:41:15 < qyx> my use case here is "the thing doesn't work, is not remotely accessible and I am in field trying to find out why"
2025-10-08T09:42:10 < qyx> so the best option in this case is to enable some sort of wifi/bluetooth/other interface with known credentials
2025-10-08T09:42:22 < qyx> if this doesn't work, the thing is SAFU
2025-10-08T09:42:41 < mercenary> I was just thinking 'and this is what leads to back-doors'
2025-10-08T09:42:48 < qyx> and the second level is full reset or recovery of "last known configuration" and firmware version
2025-10-08T09:44:31 < qyx> ok I am stopping whining now and just go find a place for a console connector
2025-10-08T09:45:39 < mercenary> gl. last note on resets, my use case is often 'I am remote, there is a device in the field, not reachable, and whoever is physically near the device can only understand very simple instructions'
2025-10-08T09:46:24 < qyx> oh I understand this
2025-10-08T09:46:32 < qyx> "hey the device doesn't even blink"
2025-10-08T09:46:42 < qyx> "no it does nothing, isn't the battery dead?"
2025-10-08T09:46:52 < qyx> idk what did monitoring say before it happened?
2025-10-08T09:47:00 < qyx> "yeah it was reaching 0%"
2025-10-08T09:47:19 < qyx> "I forgot to bring a new one, can I buy it in a grocery store?"
2025-10-08T09:47:36 < mercenary> (grumble to Sierra for having modems where 'light green' and 'dark green' on the LEDs mean different things. Know how difficult it is to see that from a potato-phone video-clip?)
2025-10-08T09:47:46 -!- dudv2_ is now known as DudV2
2025-10-08T09:50:10 < qyx> speaking of mikrotiks, any experience with rbm33g?
2025-10-08T09:50:42 < mercenary> nope, only the older stuff
2025-10-08T09:51:16 < qyx> 2018 is already old :P
2025-10-08T09:52:14 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2025-10-08T09:52:23 < mercenary> true. but it was 2013-2016 that I was heavily into mikrotik/ubiquiti gear
2025-10-08T09:52:48 < qyx> good times of 4xx stuff?
2025-10-08T09:53:44 < mercenary> yup. and lots of passive PoE
2025-10-08T10:02:54 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-08T11:41:04 < tomeaton17> ColdKeybo[a]rd: they want to push AI on the edge stuff. Will be locked into Qualcomm toolchain I expect, subscriptions probably not too far away
2025-10-08T13:27:38 -!- qyx [~qyx@84.245.120.46] has quit [Ping timeout: 248 seconds]
2025-10-08T13:29:42 -!- qyx [~qyx@84.245.121.205] has joined ##stm32
2025-10-08T14:53:27 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2025-10-08T15:08:26 < karlp> heh, for giggles, I tried a different usb hub i have, it's only 2 port and bit fragile, so I don't normally use it,
2025-10-08T15:08:30 < karlp> but some stuff started working.
2025-10-08T15:09:02 < karlp> turns out a few places have limits on total downstream ports, and it's not _checked_ at anypoint, it just determiines array sizes that are indexed into. so... too many ports? memory corrption!
2025-10-08T15:12:42 < zyp> fun
2025-10-08T15:36:28 < karlp> not really...
2025-10-08T15:37:00 < karlp> it's been a lot of spinning wheels and chasing ghosts, "is this host stack? is this HCD layer? what can I compare with?"
2025-10-08T16:36:19 < ColdKeybo[a]rd> tomeaton17 That's going to be fun... We need more AI stuff and more vibe coders
2025-10-08T16:37:09 < ColdKeybo[a]rd> Can't wait for the AI and vibe coding to enter the nuclear rector space. Then there will finally be a hard-reset for the whole world xD
2025-10-08T16:40:07 < qyx> vibeweeno?
2025-10-08T16:40:29 < ColdKeybo[a]rd> qyx What security level are you looking to have?
2025-10-08T16:41:23 < ColdKeybo[a]rd> In a couple of situations we considered that if someone has a physical access to the device (and can open it), then it's no longer considered "secure"
2025-10-08T16:42:33 < qyx> thread model is prevent unauthorized remote access, prevent local unauthorized access by a unskilled attacker, prevent local key compromise by a skilled attacker
2025-10-08T16:42:37 < qyx> *threat
2025-10-08T16:42:38 < ColdKeybo[a]rd> It does not mean that the device will spill unsecure data or that you can just "read back" stuff from it. But it's considered as broken
2025-10-08T16:43:07 < qyx> of course if anyone grabs the device physically, they can do virtually anything in a lab
2025-10-08T16:44:00 < qyx> I am dealing with the use case "allow authorized local access to a misconfigured device"
2025-10-08T16:44:19 < ColdKeybo[a]rd> Do you have BT/WiFi/USB connection to the device and does the device have a "time source"?
2025-10-08T16:44:24 < qyx> and "allow safe access when credentials is lost"
2025-10-08T16:44:37 < qyx> totp?
2025-10-08T16:45:12 < ColdKeybo[a]rd> Well you don't want all devices to have same totp? I mean you could do that
2025-10-08T16:45:15 < qyx> yes, there is bt/wifi and a precise time source, either ntp or a  out-of-band one (gnss/vlf)
2025-10-08T16:46:16 < qyx> I don't have usb exposed, but if I did I could do what I do on other devices - cdc acm + cdc ecm for console and ssh access over usb
2025-10-08T16:46:54 < ColdKeybo[a]rd> If you need higher level of security. You could have a "phone app" of sorts that can authenticate itself over WiFi/BT to your device. The device would need to be able to verify the certificate and also the certificate can be valid for a couple of hours or a day.
2025-10-08T16:47:24 < ColdKeybo[a]rd> So you would issue a certificate to someone, it's valid for a day, for their device only. They can do whatever they want
2025-10-08T16:47:40 < qyx> oh but I am dealing with a broken device
2025-10-08T16:47:42 < ColdKeybo[a]rd> But even if they lose it or publish it somewhere, after the x date, it no longer works
2025-10-08T16:48:05 < qyx> which is not functioning properly because of a broken connection or misconfiguration
2025-10-08T16:48:09 < ColdKeybo[a]rd> Ah, sorry I'm used to you designign stuff and didn't read the whole chat :)
2025-10-08T16:48:46 < ColdKeybo[a]rd> Wait, but you could still put it in "recovery" mode?
2025-10-08T16:49:08 < qyx> I am designing a device with a "unbrick" feature
2025-10-08T16:49:25 < jpa-> so, what is the problem with just a button to reset all config and password?
2025-10-08T16:49:49 < qyx> jpa-: an unskilled operator will be fukd if the config is lost
2025-10-08T16:50:01 < qyx> but most probably is able to use some sort of credentials
2025-10-08T16:50:21 < qyx> however, the device is not responding in the usual way, he has a computer or a mobile phone
2025-10-08T16:50:30 < ColdKeybo[a]rd> I also hate this... my ISP router has a feature where you can read the WiFi password _and_ admin password ON THE SCREEN!
2025-10-08T16:51:37 < jpa-> qyx: hmm.. so maybe boot into some temporary environment which lets you login to old config, or reset all config via web ui
2025-10-08T16:52:19 < ColdKeybo[a]rd> qyx Does the config contain any sensitive information or is it just device related?
2025-10-08T16:52:24 < jpa-> or you could have a "store default configuration" feature when the device is setup for first time
2025-10-08T16:52:41 < qyx> for example, quite common thing is LTE modem dies
2025-10-08T16:52:51 < qyx> the device won't connect anymore
2025-10-08T16:53:02 < qyx> the unskilled operator doesn't know what's wrong
2025-10-08T16:53:12 < qyx> "I can't clicky clicky in my cloud web ui"
2025-10-08T16:53:24 < qyx> so he goes on site, tries restart, doesn't work
2025-10-08T16:53:30 < jpa-> easy button reset to a *working* configuration would be nice
2025-10-08T16:53:47 < qyx> but that doesn't help either
2025-10-08T16:54:02 < qyx> I need some button to enable some side channel for temporary maintenance
2025-10-08T16:54:23 < ColdKeybo[a]rd> qyx So you need some diagnostic output without leaking sensitive info or allowing access?
2025-10-08T16:54:54 < qyx> that's probably one way, yeah
2025-10-08T16:55:01 < ColdKeybo[a]rd> You could give them an app that will connect over BT/WiFi, download diagnostics and then parse it
2025-10-08T16:55:20 < ColdKeybo[a]rd> If you just want to solve "What is going on" part
2025-10-08T16:55:25 < qyx> not a bad idea, mikrotik can download a dignaostic report too
2025-10-08T16:56:08 < ColdKeybo[a]rd> You still need some way of handling a more sever fault, ie if BT/WiFi is dead...
2025-10-08T16:56:33 < jpa-> if this is centrally managed, you could have signed configurations that you can upload without credentials
2025-10-08T16:56:34 < qyx> so in either case it boils down to having a button or two available
2025-10-08T16:56:34 < ColdKeybo[a]rd> Then you have to use some LEDs, blink patterns or something like that
2025-10-08T16:56:48 < jpa-> you always need buttons and leds
2025-10-08T16:57:16 < qyx> with BLE, can I spit out a diagnostic report without pairing and shit?
2025-10-08T16:57:18 < ColdKeybo[a]rd> If you want to be really annoying and have a budget... piezo and beep like crazy
2025-10-08T16:57:21 < ColdKeybo[a]rd> Or play a melody
2025-10-08T16:57:41 < ColdKeybo[a]rd> "Is it playing Death march or the Simpsons theme?"
2025-10-08T16:58:01 < jpa-> qyx: sure, just have a characteristic that anyone can read
2025-10-08T16:59:46 < ColdKeybo[a]rd> You could even have the device name contain the flag ie "qyx-33:0x40"... if you are lazy. But characteristics are a nicer approach
2025-10-08T17:00:19 < qyx> in the past, we used to have ping sequences or "port knocking" on servers to enable diagnostics (ssh)
2025-10-08T17:00:31 < qyx> and serial console for cases network is down
2025-10-08T17:02:42 < ColdKeybo[a]rd> I found that the "simpler"/lower on the stack the debug feature is, it ends up saving me a lot of time later down the line
2025-10-08T17:03:25 < ColdKeybo[a]rd> A simple blinking LED, number of beeps, or serial output is helpful if the thing is completely broken
2025-10-08T17:04:28 < ColdKeybo[a]rd> So you don't have to "break" your own device, you already know something dumb is f-ed up like it failed to init flash or wifi module is not responding
2025-10-08T17:09:18 < karlp> (i'm on the side of just nuke everything, and make it easier to reconfigure.....)
2025-10-08T17:09:37 < karlp> that makes the "debrick" simpler, and make the general "how to config" better as well...
2025-10-08T17:10:08 < karlp> I know how much you love clouds, you can even offer to hvae configs cloud saved, to be re-applied on to a fresh config....
2025-10-08T17:14:13 < qyx> can you imagine instructing someone to freshly configure LTE and VPN?
2025-10-08T17:16:33 < ColdKeybo[a]rd> You should also account that the "unskilled" operator is probably also very frustrated at this point because this thing should just work...
2025-10-08T17:16:50 < ColdKeybo[a]rd> So the simpler you can make it and at the same time get as much diagnostic information as possible... the better
2025-10-08T17:17:03 < mercenary> There are ZTP provisioning schemes for that. As long as it has _some_ form of connectivity
2025-10-08T17:26:02 < ColdKeybo[a]rd> In case anyone is wondering... I'm still stuck with FUSB302
2025-10-08T17:26:26 < ColdKeybo[a]rd> Still can't trigger any PD profile :\
2025-10-08T17:30:34 -!- hexo [~hexo@user/hexo] has joined ##stm32
2025-10-08T17:50:05 < karlp> qyx: I kinda can yeah.
2025-10-08T17:50:16 < karlp> qyx you need to make sure that some of the normal cases work with prebaked options.
2025-10-08T17:50:38 < karlp> have the "you need to configure shit" options available, but you gotta make it easier to setup.
2025-10-08T17:50:55 < karlp> then you woulnd't be in this world of "maybe I can sort of do part of a factory reset" which sounds super confusing and error prone.
2025-10-08T17:56:55 < karlp> zyp: today's weird thing: plugging in orbtrace makes my music stutter for a second or two.
2025-10-08T17:57:35 < zyp> haha
2025-10-08T17:57:52 < karlp> I've never noticed it with any other usb device :|
2025-10-08T17:58:14 < karlp> hrm, I wonder if I just need to blacklist modemmanager from it's cdcacm....
2025-10-08T17:58:35 < zyp> modemmangler should be blacklisted from everything
2025-10-08T17:58:52 < karlp> except until you're trying to get a lte modem to work and can't figure out why nothing works... ;)
2025-10-08T18:00:49 < karlp> nope, not modemmanager
2025-10-08T18:02:45 < karlp> https://paste.jvnv.net/view/7lCJ2
2025-10-08T18:02:55 < karlp> (this is not a huge issue for me, the other one bothers me more)
2025-10-08T18:03:16 < karlp> and even that's worked around for the time being :)
2025-10-08T18:08:21 < karlp> well, no dyn debug in this fedora kernel, so gonna pretend that just isn't happening :)
2025-10-08T18:08:51 < zyp> just leave it plugged in ;)
2025-10-08T18:10:35 < karlp> that's what I normally do. just have to pretend it isn't happening for a bit.
2025-10-08T18:10:40 < karlp> go back to my matrix of testing shit.
2025-10-08T18:22:46 < tomeaton17> karlp: did you get any further with the STM32 VS Code extension? I can't seem to get it to gen intellisense config for me
2025-10-08T18:32:45 < tomeaton17> Seems like they provide a specific clangd extension which seems to work out of the box
2025-10-08T18:35:25 -!- specing [~specing@user/specing] has quit [Ping timeout: 264 seconds]
2025-10-08T19:02:51 < karlp> no, I only needed stm32 to generate some tests for comparison.
2025-10-08T19:03:02 < karlp> I got cube to splat out the bits I needed and it's gone again.
2025-10-08T19:07:12 < karlp> look a tthis fun with 8/16/32bit writes :) https://github.com/hathach/tinyusb/issues/3010
2025-10-08T20:29:13 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 256 seconds]
2025-10-08T20:55:45 < qyx> so, did any of you pros do lzma on embedded?
2025-10-08T21:01:33 < qyx> https://github.com/WangXuan95/TinyZZZ/blob/main/src/lzmaD.c
2025-10-08T21:01:45 < qyx> this looks good although not streaming
2025-10-08T21:10:45 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2025-10-08T21:14:44 < qyx> ok quality code https://github.com/WangXuan95/TinyZZZ/issues/2
2025-10-08T21:25:53 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Ping timeout: 256 seconds]
2025-10-08T22:17:55 -!- specing [~specing@user/specing] has joined ##stm32
2025-10-08T22:26:22 -!- nomorekaki [~nomorekak@37-219-75-75.nat.bb.dnainternet.fi] has joined ##stm32
2025-10-08T22:26:29 < nomorekaki> early crew
2025-10-08T22:28:31 < nomorekaki> how is innovation?
2025-10-08T22:31:11 < nomorekaki> what is busy crew up to
2025-10-08T22:34:22 < qyx> testing some inherently insecure and buggy decompressors
2025-10-08T22:35:13 < nomorekaki> for amusement?
2025-10-08T22:35:29 < qyx> for workz pls
2025-10-08T22:36:40 < nomorekaki> sounds workable
2025-10-08T22:37:03 < nomorekaki> what is the benefit?
2025-10-08T22:37:24 < qyx> to make my code smaller
2025-10-08T22:37:37 < qyx> that is, more effective, less buggy, faster to load, faster to fail
2025-10-08T22:38:06 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-08T22:39:14 < nomorekaki> tighter cycle
2025-10-08T22:44:44 -!- specing [~specing@user/specing] has quit [Read error: Connection reset by peer]
2025-10-08T22:47:14 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2025-10-08T22:52:40 -!- specing [~specing@user/specing] has joined ##stm32
2025-10-08T23:03:04 < nomorekaki> how about the rest of busy crew?
2025-10-08T23:03:31 < nomorekaki> have the exceeded themselfs and all the expectations continuously?
2025-10-08T23:04:46 < Steffanx> Yes
2025-10-08T23:05:52 < nomorekaki> I'm proud
2025-10-08T23:06:03 < Steffanx> For some reason I read your nick as Nomo Rekaki. While I know it's No More Kaki
2025-10-08T23:06:40 < nomorekaki> I'm japanese now
2025-10-08T23:10:57 < nomorekaki> cant you tell
2025-10-08T23:33:54 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Quit: bitmask]
2025-10-08T23:35:10 < karlp> innovation for kaki: https://bin.jvnv.net/file/1SqHq.png
2025-10-08T23:35:55 < nomorekaki> vevy tasteful
2025-10-08T23:36:08 < karlp> very botched up so far, just kinda rough placed to see how it might go.
2025-10-08T23:36:19 < karlp> trying to resist adding too many "options"
2025-10-08T23:36:25 < nomorekaki> for scales I assume
2025-10-08T23:36:29 < karlp> yar
2025-10-08T23:36:51 < karlp> well, anything you want a 24bit ratiometric dual adc on a pi compatible hat thingy...
2025-10-08T23:37:29 < karlp> on an ADC that has kernel IIO support https://www.kernel.org/doc/Documentation/devicetree/bindings/iio/adc/ti-ads124s08.txt
2025-10-08T23:37:33 < karlp> allegedly....
2025-10-08T23:37:48 < nomorekaki> why ext5v?
2025-10-08T23:38:23 < ventYl> I have finally admitted I have to include platform support code into my RTOS
2025-10-08T23:38:38 < ventYl> which I'll consider a big pile of shame at least next five years
2025-10-08T23:38:39 < qyx> karlp: LC filter on VDDA supply missing, series resistors on SPI too
2025-10-08T23:38:53 < qyx> what LDO do you use on VDDA?
2025-10-08T23:38:56 < karlp> yeah, series R on spi I was goign to do actually, that's in my schematic notes.
2025-10-08T23:39:18 < karlp> kaki ext5v so you can poower the rpi without having to find the "right" usb micro that can run it all
2025-10-08T23:40:09 < nomorekaki> ah yes
2025-10-08T23:40:25 < nomorekaki> arent there boards for supplying 5v
2025-10-08T23:40:38 < karlp> qyx: vdda is from this: we already spoke about it with... someone else at least? https://kicanvas.org/?github=https%3A%2F%2Fgithub.com%2Fkarlp%2Fexp-iio-ads124s08
2025-10-08T23:40:52 < nomorekaki> Personally I just soldered wires to rpi
2025-10-08T23:40:58 < nomorekaki> wait no
2025-10-08T23:41:14 < nomorekaki> I made buck regulator years back and it had also RTC and battery
2025-10-08T23:41:38 < karlp> that ext5v is just for connecting a bench supply if you don't want to find the right usb micro shits.
2025-10-08T23:42:39 < qyx> karlp: tps7a2 is not magic, most of low noise LDOs can't filter out higher frequencies and you have to do it on your own
2025-10-08T23:44:53 < qyx> but you should be good to almost 10k
2025-10-08T23:45:08 < qyx> I would filter sensing inputs too
2025-10-08T23:45:10 < karlp> that's what the 1R/C filter was for, on peters advice
2025-10-08T23:45:33 < qyx> and I am filtering excitation output too
2025-10-08T23:45:49 < qyx> more like pulse shaping to avoid shit on longer cables
2025-10-08T23:46:00 < qyx> and to avoid noise coming back to my supply
2025-10-08T23:46:11 < karlp> how long runs are you doing?
2025-10-08T23:46:19 < qyx> 2-5 m
2025-10-08T23:46:37 < qyx> but I have a lot of 50 Hz cables all around the sensors
2025-10-08T23:47:21 < qyx> also I was using that particular TPS* on one board
2025-10-08T23:47:41 < qyx> soldering that shit is not easy
2025-10-08T23:47:55 < karlp> I aint soldering shit
2025-10-08T23:48:13 < karlp> I've only got in sot23 anyway, easypezeee
2025-10-08T23:48:25 < qyx> oh didn't notice
2025-10-08T23:48:27 < qyx> i had x2son
2025-10-08T23:49:11 < qyx> and "Way more cap than required", I would check what is the allowable max
2025-10-08T23:49:59 < karlp> well, all that vdda is whats on the current hx711 board, and it's "fine"
2025-10-08T23:50:10 < karlp> pretty sure I did check and it's ok.
2025-10-08T23:50:16 < qyx> ok then
2025-10-08T23:50:32 < karlp> these are not intended to be final, best possible, just "don't do dumb shit, demonstrate that it can all be done on linux"
2025-10-08T23:50:43 < karlp> especially, with 24bit adcs instead of absurd 32bit ones.
2025-10-08T23:50:51 < qyx> are you getting paid for it? :P
2025-10-08T23:51:02 < qyx> or just trying to make the world a better place to live on?
2025-10-08T23:51:03 < karlp> no :)
2025-10-08T23:51:06 < karlp> not yet...
2025-10-08T23:51:17 < karlp> I'm kinda using my work from home days to do this sort of thing
2025-10-08T23:51:30 < karlp> and when the first demo comes up I'ðll probably get work to pay for some baords or something
2025-10-08T23:51:38 < karlp> but I had no other projects of my own anyway, so....
2025-10-08T23:51:38 < qyx> and is your summer house painted and winterized?
2025-10-08T23:51:49 < karlp> painted and closed for the winter, yes,
2025-10-08T23:51:54 < karlp> but hoping to get back there at least once more.
2025-10-08T23:52:07 < qyx> nah, you are one step further
2025-10-08T23:53:42 -!- duude__- [~duude__@user/duude/x-4676560] has joined ##stm32
2025-10-08T23:54:05 -!- duude__ [~duude__@user/duude/x-4676560] has quit [Ping timeout: 265 seconds]
2025-10-08T23:54:05 < nomorekaki> summer house
2025-10-08T23:54:10 < nomorekaki> pix
2025-10-08T23:55:28 -!- duude__- is now known as duude__
--- Day changed Thu Oct 09 2025
2025-10-09T00:09:48 < antto> kakim0r, you wanted some Motivational Music a pile of time ago one night
2025-10-09T00:09:56 < antto> do you still want it? ;P~
2025-10-09T00:20:05 < karlp> qyx: also, doing it at home, means it all gets to be "mine" and open source as I see fit.
2025-10-09T00:20:22 < karlp> one day I'll be a abig ardweenocommpihat vendor or something
2025-10-09T00:20:34 < karlp> ltos of people need this experiments right?!?!
2025-10-09T00:21:01 < karlp> kaki: this is when we bought it, https://tweak.au/pics2/2021/June/summerhouse/
2025-10-09T00:21:08 < karlp> no comprehensive pics since then
2025-10-09T00:22:36 < qyx> karlp: yeah I don't see anything bad there
2025-10-09T00:25:22 < qyx> I like the house but the nature is a bit uh oh.. boring
2025-10-09T00:26:56 < karlp> it's "wild"
2025-10-09T00:27:11 < qyx> I mean, not eild enough
2025-10-09T00:27:29 < qyx> like if it was on a volcanic rock
2025-10-09T00:27:32 < qyx> oh wait
2025-10-09T00:27:36 < karlp> those pictures were taken probably may? early june, so nothing is in flower yet.
2025-10-09T00:29:56 < karlp> zyp: should I take it as reading in the tealeaves that there's not really any planned further work with laks?
2025-10-09T00:30:06 < karlp> (not complaining, just pondering orbz)
2025-10-09T00:30:19 < qyx> "reading in tealeaves" much harry potter
2025-10-09T00:30:26 < qyx> til
2025-10-09T00:30:47 < karlp> I aim to please :)
2025-10-09T00:31:59 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 250 seconds]
2025-10-09T00:33:05 < karlp> if you're doing series R on spi, do you really put miso R at one end and mosi R at teh other end, or does it just not reallllly matter?
2025-10-09T00:33:20 < karlp> gonna go with "8mhz is too slow to matter, just put them down to smooth corners"
2025-10-09T00:34:42 < qyx> they are not (primarily) source terminating resistors for impedance matching
2025-10-09T00:35:01 < qyx> but to make corners smooth
2025-10-09T00:35:25 < qyx> so whatever limits the current is fine, that's how I understand it
2025-10-09T00:35:30 < qyx> so no matter where are they
2025-10-09T00:37:09 < karlp> you say I should be good to 10khz noise, and I have input AA filter at 3800z, so... "good to go!"?
2025-10-09T00:39:35 < qyx> most of these things I am mentioning are empirical knowledge
2025-10-09T00:39:54 < qyx> I remember 220R works, doesn't limit SPI too much, is reliable, field tested and do not cause noise in measurement
2025-10-09T00:40:10 < karlp> I was only going to put 22R down
2025-10-09T00:40:17 < karlp> TI says 47, but...
2025-10-09T00:40:21 < karlp> fuck the designers
2025-10-09T00:40:29 < qyx> you can always redo that
2025-10-09T00:40:49 < qyx> and I had a different ADC
2025-10-09T00:40:54 < qyx> so different capacitance, etc.
2025-10-09T00:48:02 < zyp> karlp, probably
2025-10-09T00:50:03  * antto slaps nomorekaki with https://www.youtube.com/watch?v=U93jZvRsL9Y
2025-10-09T00:52:12 < nomorekaki> could be legit (2018)
2025-10-09T00:52:12 < karlp> zyp: so, liking embassy enough then?
2025-10-09T00:52:26 < nomorekaki> I dont trust new musics
2025-10-09T00:52:38 < antto> eh?
2025-10-09T00:52:46 < antto> you judge by the Year?
2025-10-09T00:53:57 < nomorekaki> yup
2025-10-09T00:54:46 < antto> pls, this is different
2025-10-09T00:56:40 < nomorekaki> by new musics I mean something like couple years old
2025-10-09T00:57:00 < nomorekaki> not yet time tested
2025-10-09T00:57:25 < antto> this is 50% mr gasmask involved, it is outside the box, it's Off The Charts
2025-10-09T00:57:33 < antto> in fact...
2025-10-09T00:57:35 < nomorekaki> it's tight
2025-10-09T00:58:27 < antto> https://www.youtube.com/watch?v=xUiGxnuMHr0
2025-10-09T00:58:28 < nomorekaki> pa p p pa p p party
2025-10-09T01:00:31 < nomorekaki> dont like that compared to pa p p pa p p party jumping
2025-10-09T01:00:58 < antto> subway shamans goes kinda more into Goa
2025-10-09T01:01:03 < antto> or psytrance
2025-10-09T01:01:16 < antto> nah, i think Goa is closer to what it is
2025-10-09T01:01:39 < nomorekaki> yes
2025-10-09T01:02:34 < antto> okay then, here ya go: https://www.youtube.com/watch?v=x9kejzWR9qc
2025-10-09T01:05:05 < nomorekaki> I like the first one most
2025-10-09T01:06:13 < antto> last one, you can discover more if you want: https://www.youtube.com/watch?v=KdLN8DH1-jo
2025-10-09T01:07:40 < nomorekaki> are you mr. gasmask?
2025-10-09T01:07:48 < antto> nope
2025-10-09T01:08:20 < antto> my stuff is... different
2025-10-09T01:08:36 < nomorekaki> https://www.youtube.com/watch?v=tgFN5ohct4k have some finnish psytrance
2025-10-09T01:08:50 < antto> mr gasmask has a very distinct "sound"
2025-10-09T01:09:02 < antto> my sh*t is random every time ;P~
2025-10-09T01:09:31 < antto> https://www.youtube.com/watch?v=wRxTi2qu3T8
2025-10-09T01:09:53 < nomorekaki> title of that song translates to "false sanity"
2025-10-09T01:10:27 < nomorekaki> or "delusion of sanity"
2025-10-09T01:12:41 < karlp> hrm, I wonder if I should use feed through caps...
2025-10-09T01:12:48 < karlp> maybe on one channelll.
2025-10-09T01:15:00 < nomorekaki> you have board space
2025-10-09T01:15:26 < nomorekaki> also sounds like your design problem is not fully constrained
2025-10-09T01:16:09 < karlp> not in the least :) 
2025-10-09T01:16:23 < karlp> this is experiments, but once primary goal has been met, secondary goals should be added :)
2025-10-09T01:16:32 < karlp> this is fun, not work...
2025-10-09T01:18:08 < nomorekaki> adventurous
2025-10-09T01:24:29 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2025-10-09T01:27:31 < nomorekaki> BM
2025-10-09T01:29:02 < nomorekaki> how is life?
2025-10-09T01:38:40 -!- DudV2 [~dudv2@user/DudV2] has quit [Ping timeout: 245 seconds]
2025-10-09T01:40:39 -!- DudV2 [~dudv2@222-155-163-204-fibre.sparkbb.co.nz] has joined ##stm32
2025-10-09T01:54:36 -!- splud [~noneya.bi@user/splud] has joined ##stm32
2025-10-09T02:03:36 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-09T02:09:11 < qyx> I am unable to get at least one lzma2 decoder compile and work
2025-10-09T02:09:26 < qyx> ok there are other requirements too, code size under 10K, etc.
2025-10-09T02:09:38 < qyx> not allocating 6 MB on heap
2025-10-09T02:09:52 < qyx> not requiring target buffer preallocated as a whole
2025-10-09T02:45:38 -!- nomorekaki [~nomorekak@37-219-75-75.nat.bb.dnainternet.fi] has quit [Quit: Client closed]
2025-10-09T02:55:03 < qyx> k managed to make xz-embedded behave, thumb with -Os is 6KB of code
2025-10-09T03:32:52 -!- NEYi [~NEYi@195.234.78.187] has quit [Quit: Leaving]
2025-10-09T04:03:39 -!- hexo [~hexo@user/hexo] has quit [Read error: Connection reset by peer]
2025-10-09T04:03:48 -!- hexo__ [~hexo@user/hexo] has joined ##stm32
2025-10-09T04:15:14 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-09T04:16:28 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-09T04:16:52 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-09T04:45:12 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-09T05:24:18 -!- NEYi [~NEYi@195.234.78.187] has quit [Ping timeout: 260 seconds]
2025-10-09T06:25:32 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Quit: bitmask]
2025-10-09T06:43:51 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2025-10-09T06:58:47 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Ping timeout: 256 seconds]
2025-10-09T07:16:16 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-09T07:18:17 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-09T07:20:05 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-09T07:48:06 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-09T08:22:38 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-09T08:44:32 -!- qyx [~qyx@84.245.121.205] has quit [Ping timeout: 240 seconds]
2025-10-09T08:46:27 -!- qyx [~qyx@84.245.121.38] has joined ##stm32
2025-10-09T09:28:18 -!- DudV2 [~dudv2@222-155-163-204-fibre.sparkbb.co.nz] has quit [Ping timeout: 256 seconds]
2025-10-09T09:29:10 -!- DudV2 [~dudv2@222-155-163-204-fibre.sparkbb.co.nz] has joined ##stm32
2025-10-09T09:45:23 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-09T09:48:22 -!- DudV2 [~dudv2@user/DudV2] has changed host
2025-10-09T09:56:19 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-09T11:46:00 < mawk> I'm trying wifi shit with atmel WINC1500 using zephyr 
2025-10-09T11:46:20 < mawk> I can scan networks, but if I try to connect I get an extremely helpful "connection failed, reason: unknown"
2025-10-09T11:46:38 < mawk> seems like I can actually talk properly to the chip, and all the pins are wired properly
2025-10-09T11:46:56 < mawk> I even tried using an open network with no security but it still fails
2025-10-09T11:47:01 < mawk> so annoying to debug
2025-10-09T11:52:48 < mawk> apparently I might have to do a firmware update of the wifi chip
2025-10-09T11:52:51 < mawk> sounds super annoying 
2025-10-09T12:04:45 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Read error: Connection reset by peer]
2025-10-09T12:17:00 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2025-10-09T12:28:09 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Quit: Client closed]
2025-10-09T12:29:42 < karlp> qyx: hey, how did this greenhouse heater turn out in the end? https://bin.jvnv.net/file/76D8Y/Screenshot_2024-02-03_00-52-32.png
2025-10-09T12:31:56 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2025-10-09T12:54:07 -!- jerrycash2 [~jerrycash@user/jerrycash] has quit [Ping timeout: 240 seconds]
2025-10-09T12:57:45 -!- jerrycash [~jerrycash@user/jerrycash] has joined ##stm32
2025-10-09T13:09:26 < karlp> weoo, tinyusb using ai to make fixes:  https://github.com/hathach/tinyusb/issues/3286
2025-10-09T13:13:34 < ventYl> :>
2025-10-09T13:14:51 < qyx> karlp: used it 2 last springs, esp32, some ds12b20, ov240 camera, works good
2025-10-09T13:19:55 < qyx> ds18b20, ov2640, sorry using androidz with curvy fingers
2025-10-09T13:20:25 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-09T13:27:44 < karlp> cool, I was scrollingthrough the irc logs looking to rip of some of your circuit snips you've pasted, foundmore interesting stuff
2025-10-09T13:27:54 < karlp> so what's the camera for though?
2025-10-09T13:34:08 < Steffanx> Will you try esp hosted next, mawk?
2025-10-09T13:34:16 < Steffanx> Tell me how well it works
2025-10-09T13:53:43 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Ping timeout: 250 seconds]
2025-10-09T14:20:05 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-09T14:25:24 < qyx> karlp: to see the plants grow!
2025-10-09T14:28:11 < zyp> karlp, yeah, I'm quite liking the rust embedded world in general, much of it is similar to the goals I've had for laks
2025-10-09T14:31:41 < qyx> poor soul found a new sect
2025-10-09T14:31:48 < mawk> Steffanx: idk
2025-10-09T14:31:59 < mawk> it's not ARM so I automatically not like it
2025-10-09T14:32:22 < mawk> the atmel docs are abysmal
2025-10-09T14:32:32 < mawk> seems like the actual registers and pin config of the chip are private
2025-10-09T14:32:45 < mawk> and the info is contradictory between different versions of the docs
2025-10-09T14:33:06 < mawk> at least I found the firmware update files somewhere
2025-10-09T14:33:12 < mawk> not like ublox where you have to email richard to get them
2025-10-09T14:33:40 < qyx> how do you like atwinc?
2025-10-09T14:33:49 < qyx> besides not being able to connect
2025-10-09T14:33:54 < qyx> fuk esp hosted
2025-10-09T14:34:07 < qyx> esp hosted had no power management apparently
2025-10-09T14:34:13 < qyx> or has
2025-10-09T14:34:53 < mawk> if it worked out of the box it would be amazing with the readymade HAL thing
2025-10-09T14:34:57 < mawk> but it doesn't
2025-10-09T14:35:19 < mawk> also it doesn't support WPA3 or stuff like that apparently so it's getting a bit old
2025-10-09T14:37:37 < mawk> I guess I'll skip wifi and try 802.15.4 directly
2025-10-09T14:37:48 < mawk> it better work first try or I trash this nordic thing
2025-10-09T14:39:13 < mawk> and use a stm32 with mrfj40ma module
2025-10-09T14:39:28 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-09T14:43:14 < Steffanx> It should work out of the box mawk. After you flash your esp with the right firmware.
2025-10-09T14:43:33 < Steffanx> And configure your lovely zephyr setup to use it over SPI
2025-10-09T14:43:57 < Steffanx> Power manager is not relevant for every use case Mr qyx. 
2025-10-09T14:44:05 < Steffanx> Or am I insulting you now?
2025-10-09T14:44:48 < mawk> I mean the atmel stuff
2025-10-09T14:45:00 < Steffanx> The atmel stuff is ancient as fuck 
2025-10-09T14:49:01 < Steffanx> Qyx: Latest release notes for esp hosted fg say "enhanced throughput and power management". So all must be great now
2025-10-09T15:04:43 < qyx> also lold at throughput 17 mbit/s
2025-10-09T15:04:50 < qyx> iirc
2025-10-09T15:05:24 < qyx> no PM is not needed everywhere but for my intended use case is
2025-10-09T15:05:37 < qyx> ST's wifi should be okay, the standalone one
2025-10-09T15:06:02 < qyx> for hosted I am happy with IW611 for now
2025-10-09T15:06:13 < qyx> 155 or so mbit/s over SDIO
2025-10-09T15:06:14 < mawk> I wanted to try ST's wifi but the devkit is like 50€
2025-10-09T15:06:16 < mawk> I'm too poor
2025-10-09T15:06:26 < mawk> I will have to steal it from somewhere
2025-10-09T15:06:43 < mawk> but I'm just playing around with the wifi, ideally I just want 802.15.4/6LoWPAN or BLE
2025-10-09T15:06:58 < mawk> for something that runs on a supercap that gets periodically recharged
2025-10-09T15:22:26 < karlp> prettuy sure the atmel wifi wasn't from atmel either...
2025-10-09T15:25:07 < karlp> silabs mg2x stuff is 802154+btle, low pwoer shits. can get basic kits for liek 20€
2025-10-09T15:26:34 < karlp> mawk: https://tweak.net.au/pics2/2013/January/miscstream/pichtml/web_2013_01_29-09_48_40--img_5272_jfr.html if you want to go retro.
2025-10-09T15:26:42 < karlp> f100+mrf24j40
2025-10-09T15:26:55 < karlp> but really, fuck mrf24j40 off, it's suppper old, 
2025-10-09T15:27:09 < mawk> lol
2025-10-09T15:27:17 < mawk> professeur tournesol
2025-10-09T15:27:40 < mawk> yeah I guess so, but I have a bunch of them
2025-10-09T15:27:41 < karlp> (from https://github.com/karlp/zypsnips/blob/master/dolls-on-pcbs.txt if anyone has any updates theyd like to share)
2025-10-09T15:27:59 < mawk> when I have money I'll try a ST nucleo board with 802.15.4
2025-10-09T15:28:01 < karlp> they're too much power compared to modern shits
2025-10-09T15:28:19 < karlp> the wb nucleo is not tooo much money,  you get two boards too.
2025-10-09T15:28:31 < karlp> you're employed, it can't be that expensive?
2025-10-09T15:28:44 < mawk> the mrf24j40 would be for the base station on a raspberry pi, for the device it's nrf52840 which has the 802.15.4 builtin
2025-10-09T15:28:52 < mawk> yeah but bailiffs are taking all my money
2025-10-09T15:28:58 < mawk> out of my salary directly
2025-10-09T15:29:20 < karlp> oh, that should work ok, it's got an old skool kernel modure for it iirc, Inever went that far.
2025-10-09T15:29:31 < karlp> I had a usb connected mcu as the "base station"
2025-10-09T15:29:39 < mawk> yeah I tried it years ago and it kinda worked but half of packets were being dropped and I couldn't find the bug in the driver
2025-10-09T15:30:08 < karlp> yeah, well, when you get into mrf24j40 y ou start seeing allllll the magic that they send to undocumented registers to get it to work and just..... nope.
2025-10-09T15:30:14 < mawk> lol
2025-10-09T15:30:36 < karlp> it was _cool_ at the time, it was cheap, it was spi, you could just _do stuff_
2025-10-09T15:30:45 < karlp> but.. no way would I be considering starting something with it today.
2025-10-09T15:32:01 < karlp> I bought a handful of the mrf24xa which was meant to supersede it, but it was when I was just gettingback into hw at all, and making a board for the bare chip seemed a bit much at the time.
2025-10-09T15:34:51 < mawk> they make a kind of module for it apparently
2025-10-09T15:34:56 < mawk> https://www.farnell.com/datasheets/1755822.pdf
2025-10-09T15:34:58 < mawk> with 439208483209423 pins
2025-10-09T16:00:44 -!- infisc is now known as theRealBirb
2025-10-09T16:03:00 -!- theRealBirb is now known as theOriginalBirb
2025-10-09T16:07:51 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-09T16:07:52 -!- theOriginalBirb is now known as infisc
2025-10-09T16:10:12 < qyx> nxp fixed their imx93 shit apparently
2025-10-09T16:10:19 < qyx> ordering more \o/
2025-10-09T16:20:06 < karlp> fixed what part of it?
2025-10-09T16:20:33 < karlp> are resistor networks _always_ better matched? none of the network array datasheets have any matching figures?
2025-10-09T16:29:39 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-09T16:39:41 < qyx> karlp: "voltage overstress" in the 3v3 domain causing MTBF of 128 days
2025-10-09T16:43:57 < mercenary> I'd guess just as well matched as individual resistors from the same spool. But they will be closer thermally.
2025-10-09T17:05:14 < karlp> that is my gut as well, especially when the resistor array datasheets don't even specify any on chip matching
2025-10-09T17:14:48 < mercenary> some do. e.g. https://www.vishay.com/docs/28770/acasat.pdf
2025-10-09T17:15:31 < mercenary> (digikey even has filters on 'Resistor Matching Ratio'
2025-10-09T17:25:55 < karlp> yeah, but those are also 0.1% resistors already, Imean,you're right, thanks, but that's not really what I was trying to figure out :)
2025-10-09T17:26:25 < karlp> I'm trying to decide whether "R should be matched to avoid CM noise" means anything more than "1% is fine, but go wild if you want"
2025-10-09T17:29:35 < mercenary> you only get what the manufacturer guarantees, so 1% means you could get a 99R and a 101R in the same pack. Want it matched, pay more.
2025-10-09T17:31:06 < karlp> right, I get it, but what really happens?
2025-10-09T17:31:28 < karlp> I'm seeing people using generic 1% arrays becuase there's some _belief_ thatthey are intrinsically better matched.
2025-10-09T17:35:27 < mercenary> not necessarily. you _can_ get arrays that are 1%, matched to 0.1% for example, but that falls under 'read the datasheet to make sure'. Tempco and matching temperature is probably a better reason for using arrays
2025-10-09T17:35:54 < karlp> ok, updated https://kicanvas.org/?github=https%3A%2F%2Fgithub.com%2Fkarlp%2Fexp-iio-ads124s08 with two alternate inputs now. will ponder orbz and do the layout later.
2025-10-09T18:07:13 < karlp> hrm, spent a bit more of the day on that than I planned.
2025-10-09T18:55:31 < tomeaton17> I think the connectors might work a bit better if they are on the board
2025-10-09T19:08:42 < karlp> not sure I follow?
2025-10-09T19:42:54 -!- infisd [~infisc@user/infisc] has left ##stm32 [K-Lined]
2025-10-09T21:46:16 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 255 seconds]
2025-10-09T22:11:28 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 265 seconds]
2025-10-09T22:31:14 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-09T22:32:24 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-09T22:32:48 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-09T22:40:45 -!- krjst [~krjst@2a0a:4cc0:2000:789a:b827:c6ff:fed6:bb48] has quit [Quit: bye]
2025-10-09T22:47:55 -!- krjst [~krjst@2a0a:4cc0:2000:789a:b827:c6ff:fed6:bb48] has joined ##stm32
--- Day changed Fri Oct 10 2025
2025-10-10T00:19:07 -!- NEYi [~NEYi@195.234.78.187] has quit [Quit: Leaving]
2025-10-10T00:34:59 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-10T01:44:28 -!- nomorekaki [~nomorekak@37-219-75-75.nat.bb.dnainternet.fi] has joined ##stm32
2025-10-10T02:02:49 -!- aandrew [~aandrew@vps-2437c00c.vps.ovh.ca] has quit [Ping timeout: 246 seconds]
2025-10-10T02:02:49 -!- invzim [~perole@vv.kirurg.org] has quit [Ping timeout: 246 seconds]
2025-10-10T02:02:58 -!- invzim [~perole@vv.kirurg.org] has joined ##stm32
2025-10-10T02:03:45 -!- aandrew [~aandrew@vps-2437c00c.vps.ovh.ca] has joined ##stm32
2025-10-10T03:00:15 -!- nomorekaki [~nomorekak@37-219-75-75.nat.bb.dnainternet.fi] has quit [Quit: Client closed]
2025-10-10T05:43:22 -!- splud [~noneya.bi@user/splud] has quit [Read error: Connection reset by peer]
2025-10-10T05:49:34 -!- infisx [~infisc@user/infisc] has joined ##stm32
2025-10-10T05:58:09 -!- splud [~noneya.bi@user/splud] has joined ##stm32
2025-10-10T06:58:39 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-10T07:06:57 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-10T08:13:21 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-10T08:30:59 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-10T08:44:04 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-10T09:46:41 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2025-10-10T10:13:03 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 256 seconds]
2025-10-10T11:33:06 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Quit: Leaving]
2025-10-10T12:00:23 -!- DemolitionMan [~kvirc@77.39.229.101] has joined ##stm32
2025-10-10T12:09:49 -!- DemolitionMan [~kvirc@77.39.229.101] has quit [Quit: KVIrc 5.2.8 Quasar http://www.kvirc.net/]
2025-10-10T12:10:07 < mawk> what do we think about this https://www.st.com/en/microcontrollers-microprocessors/stm32wl5m-modules.html
2025-10-10T12:10:20 < mawk> "SORRY, PAGE NOT FOUND" that doesn't start very well
2025-10-10T12:10:52 < mawk> there's a builtin antenna so I don't have to mess with that
2025-10-10T12:11:19 < mawk> ah no antenna, just a typo in the page lol
2025-10-10T12:11:27 < mawk> missing the word "filter"
2025-10-10T12:11:45 < jpa-> builtin antenna = you'll inevitably mess it up with enclosure and placement ;)
2025-10-10T12:14:03 < mawk> you can't mess up with the enclosure if there's no enclosure
2025-10-10T12:15:08 < mawk> but seriously is it that hard? remove all copper under the antenna within the specified margin and that's it no
2025-10-10T12:15:31 < mawk> LCSC has the version with the antenna so I don't have to solder it myself
2025-10-10T12:16:29 < jpa-> well that's mostly all you can do, but even the PCB shape can affect it
2025-10-10T12:16:52 < mawk> well maybe I won't reach 1km range but I live in a closet so that should be fine, with the devices being 5m apart
2025-10-10T12:17:00 < jpa-> but it's pretty easy as long as you can have a large enclosure or it is sitting on the table.. but in that case putting in u.fl or SMA connector and external antenna is easy too and gets better range
2025-10-10T12:17:23 < mawk> it's 2.4GHz so I can use any wifi antenna I have laying around right?
2025-10-10T12:17:32 < jpa-> yeah
2025-10-10T12:17:34 < mawk> or even the big SMA connector and reuse the antennas of the other 2.4GHz modules I have
2025-10-10T12:18:07 < jpa-> things get annoying when you want a small device and have to cram everything in :)
2025-10-10T12:18:23 < mawk> yeah
2025-10-10T12:18:50 < mawk> I can't find a ST device that does regular bluetooth audio, it's all BLE audio; apparently android supports it but idk how good it can be
2025-10-10T12:19:25 < mawk> >There is no option to use an external antenna
2025-10-10T12:19:27 < mawk> well there it goes
2025-10-10T12:19:50 < mawk> I have to use the actual chip and hope that I didn't mess up the reference design if I want to be able to have an external antenna
2025-10-10T12:22:59 < zyp> mawk, there's some rule of thumb that states that if the ground plane is smaller than the wavelength of the signal (or some factor of it, don't remember exactly), it should be considered an active element whose shape affects the antenna performance significantly
2025-10-10T12:23:53 < mawk> so 12.5cm
2025-10-10T12:24:14 < zyp> and ground plane aside, *anything* around an antenna will detune it in some way or another
2025-10-10T12:24:18 < mawk> yeah they provide a reference design where the module is in a corner and you have a big ground plane on a right with a bunch of vias
2025-10-10T12:25:06 < mawk> so you're saying I should make a 1m long PCB
2025-10-10T12:26:01 < jpa-> you can run a 5 meter coax cable between your devices, but remember to add an attenuator
2025-10-10T12:26:45 < ventYl> back to '80s
2025-10-10T12:27:49 < zyp> my RF prof at uni was showing off some antenna he'd made for some health device to be mounted close to the body; since it would be detuned by the proximity of the body, it was designed so that different parts of the antenna would be detuned in opposite directions so it evened out
2025-10-10T12:28:52 < tomeaton17> I liked messing around with high energy rf at a previous job
2025-10-10T12:33:50 < tomeaton17> visiting a client anechoic chamber messing around with 70-80 dBm stuff and technician got a a pretty nasty burn
2025-10-10T12:33:58 < zyp> I think this is it: https://patents.google.com/patent/US20100231471A1/
2025-10-10T12:34:10 < zyp> > By tuning the track width and length of the whip antenna to the loop area of the loop antenna, the inductance of the loop antenna is changed to the same degree as the capacitance of the whip antenna, but in the opposite direction, when the antenna is parallel to the surface of the body and the distance to the body is changed. That is to say, the product Ll*Cp remains approximately unchanged, whereby also 
2025-10-10T12:34:16 < zyp> the resonant frequency of the antenna is changed only to an insignificant degree.
2025-10-10T12:35:39 < tomeaton17> we had one at the office as well but it was a lot smaller only room size
2025-10-10T12:36:02 < mawk> I spent 2 weeks in anechoic chambers to RF certify the product
2025-10-10T12:36:07 < mawk> it was super hot and moist inside
2025-10-10T12:36:45 < mawk> but they wouldn't turn the antenna on with me inside
2025-10-10T12:36:48 < mawk> I wanted to see what it felt like
2025-10-10T12:36:58 < tomeaton17> The client one was okay because it was hangar sized. The company one not so much. Even though its not acoustic chamber its still a bit strange with the sound dampening
2025-10-10T12:39:02 < zyp> mawk, and no, what you should do is tune the antenna once you have it in the correct environment
2025-10-10T12:39:15 < mawk> it's inside a module zyp it's not possible
2025-10-10T12:39:22 < zyp> sure it is
2025-10-10T12:40:21 < mawk> how
2025-10-10T12:40:28 < zyp> most modules with integrated antennas that I've used loops the RF signal out of the module and back in so that you can hook up a little tuning network to it
2025-10-10T12:41:03 < zyp> which specific module are you looking at?
2025-10-10T12:41:05 < mawk> well this module does have the antenna pins going out, but they tell you to ground them
2025-10-10T12:41:07 < mawk> https://www.lcsc.com/datasheet/C5184586.pdf
2025-10-10T12:48:19 < zyp> fun
2025-10-10T12:51:02 < mawk> but this is just for having fun, as long as it works a little bit it's fine
2025-10-10T13:18:47 < mawk> another version of the datasheet says it is actually possible to finetune, using the pins the first datasheet says to not touch
2025-10-10T13:56:20 < Steffanx> What does chatgpt say?
2025-10-10T13:57:01 < tomeaton17> yeah nothing wrong with a bit of vibe schematic capturing
2025-10-10T13:57:28 < tomeaton17> recruiter contacted me about a job with an ai pcb layout company
2025-10-10T14:13:22 < Steffanx> Was it a human recruiter or AI?
2025-10-10T14:56:02 < mawk> it needs to be a 4-layer board if I want to use all the gpios
2025-10-10T14:56:04 < mawk> lame
2025-10-10T14:56:15 < mawk> I can skip a few probably
2025-10-10T14:58:28 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-10T15:37:59 < Steffanx> 4 layer is cheap
2025-10-10T15:50:11 < Steffanx> So why is it an issue mawk?
2025-10-10T15:59:30 < mawk> 2 is cheaper
2025-10-10T16:05:13 < tomeaton17> Steffanx: luckily a human
2025-10-10T16:05:37 < tomeaton17> 1 is cheaper
2025-10-10T16:13:28 < Steffanx> 0 is cheapest
2025-10-10T16:42:15 < tomeaton17> Steffanx: true, you can get that from PCBPower actually
2025-10-10T16:52:48 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-10T16:53:41 < jpa-> 2 layers for RF stuff is just asking for trouble
2025-10-10T16:53:48 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-10T16:54:12 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-10T16:55:12 < karlp> 4 layers is the new 2...
2025-10-10T16:55:16 < karlp> has been for years.
2025-10-10T16:56:42 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-10T16:58:21 < Steffanx> Exactly 
2025-10-10T17:00:31 -!- NEYi [~NEYi@195.234.78.187] has quit [Read error: Connection reset by peer]
2025-10-10T17:04:18 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-10T17:05:21 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-10T17:05:45 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-10T17:19:18 < jpa-> though sometimes i've been surprised on how much parasitic capacitance to GND you get with only 0.1 or 0.2 mm between copper layers
2025-10-10T17:47:23 < Steffanx> jpa- try to not have copper on the two inner layers next time
2025-10-10T17:47:46 < Steffanx> Less troubles more sailing
2025-10-10T17:48:57 < qyx> lolsteff
2025-10-10T18:07:38 < tomeaton17> I have the night off tonight nice
2025-10-10T18:09:24 -!- nerozero [~nerozero@87.253.63.54] has quit [Read error: Connection reset by peer]
2025-10-10T18:26:27 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-10T18:28:00 -!- mrec_ [~mrec@sundtek.de] has joined ##stm32
2025-10-10T18:29:11 -!- nerozero [~nerozero@87.253.63.54] has quit [Read error: Connection reset by peer]
2025-10-10T18:35:08 < mrec_> this circular buffer / double buffer normal mode implementation is nothing but nonsense if someone wants to stream out a few hundred k samples no? You cannot just make the transfer stop after a certain amount of samples
2025-10-10T18:35:17 < mrec_> this is about dma / timer sampling
2025-10-10T18:36:02 < mrec_> one way is certainly to count the pulses in an isr which might cause high interrupt load
2025-10-10T18:37:17 < mrec_> I wonder what STM has thought when implementing that, that DMA/timer implementation is pretty much incomplete in my eyes. It has many use cases but they failed to implement a clear way to stop sampling.
2025-10-10T18:38:02 < mrec_> it's good to discuss this topic with AI, not everything is correct but I got everything work - just not fully hardware supported.
2025-10-10T18:44:05 < qyx> 	decoders = ['-D' + k[4:] for k,v in conf.items() if k.startswith('LIB_XZ_DEC') and v == 'y']
2025-10-10T18:44:09 < qyx> enjoy your python
2025-10-10T18:45:20 < karlp> mrec_: are you desiring to be able to transmit N samples and exactly only N samples, where N is not a multiple of a buffer?
2025-10-10T18:46:27 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-10T19:16:05 < mrec_> exactly
2025-10-10T19:16:26 < mrec_> I used circular buffers, I can stop it by counting the pulses manually
2025-10-10T19:16:45 < mrec_> but that is pretty much nonsense because it requires interrupts for it
2025-10-10T19:19:39 < karlp> just drop that absurd requirement :)
2025-10-10T19:19:51 < karlp> have X buffers.
2025-10-10T19:20:18 < karlp> userspace can toss some trailing data if you want to say "lol, only give me 312 samples"
2025-10-10T19:56:00 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-10T20:00:21 < karlp> ok. all my testing is in.  I have the choice of adding kinetis host to cherry, which has a workign host stack, or porting k70 to mcuxpresso, because nxp doesn't care about k70 anymore.
2025-10-10T20:00:32 < karlp> tinyusb can go and fucking die as far as host is concerned.
2025-10-10T20:34:07 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 240 seconds]
2025-10-10T20:40:08 < jpa-> mrec_: the fancier stm32's have MDMA that can make you think you can do that, and take your sanity
2025-10-10T20:49:12 < qyx> hey pros, I need an independent opinion on https://www.frederickscompany.com/products/f225-00t-003-01/
2025-10-10T20:49:23 < qyx> do you think the digital (rs232) output is temperature compensated?
2025-10-10T20:50:30 < jpa-> buy SCL3400 and compensate yourself ;)
2025-10-10T20:50:38 < karlp> fuckin lol
2025-10-10T20:50:56 < karlp> scl3300 or something is whatðs being done with a brain fart at work
2025-10-10T20:51:13 < karlp> qyx: do yuo have any reason to believe it woudl be?
2025-10-10T20:51:18 < karlp> it doesn't say it at all?
2025-10-10T20:51:36 < qyx> karlp: customer says so
2025-10-10T20:51:42 < jpa-> it does say "0.0002° per °C" in datasheet
2025-10-10T20:51:44 < qyx> he may be wrong and most probably is
2025-10-10T20:52:34 < qyx> two hints, specs for the rs232 board with two sensors is the same as specs of the tilt sensor itself
2025-10-10T20:52:53 < qyx> and second one, there is an application note describing what steps do you have to take to compensate the output
2025-10-10T20:53:01 < qyx> and they are using a rs232 board as an example
2025-10-10T20:53:08 < qyx> s/a/the
2025-10-10T20:53:18 < qyx> not the exact one but a similar one they are offering
2025-10-10T20:54:58 < jpa-> yeah, very much looks non-compensated
2025-10-10T20:57:48 < jpa-> so uh.. is that a box with three sticks and water in it? or am i reading the app note wrong?
2025-10-10T20:59:09 < jpa-> ah, youtube video shows it clearly
2025-10-10T20:59:11 < jpa-> kinda cool
2025-10-10T21:15:01 < qyx> yes it is although most probably not water
2025-10-10T21:22:03 < mrec_> the stm32f4 is doing many things in a nonstandard way, I guess the STMicro engineers were drunk when they worked on that chip or it was friday before off time
2025-10-10T21:28:43 < karlp> where by "non standard" you mean, "not what I would have done" ?
2025-10-10T21:29:19 < karlp> qyx: found a rice lake ranger5 in a cupboard at work, and compared it roughly to my cell faker.  it's about 3 times lower z score, when I properly adjust sigma for the actual value...
2025-10-10T21:30:22 < karlp> I still think this is all wayyyy noisier than it should be, but that's probably just the way waveshare did this board.  "mine will be better" he says confidently in his head....
2025-10-10T21:30:43 < mrec_> DMA Start IT shouldn't loop over and over, I would expect it submits one block and done ... no it keeps going here
2025-10-10T21:35:00 < jpa-> ST HAL/Cube is crap, it does crazy things everywhere
2025-10-10T21:35:14 < jpa-> but if you choose to use it, you shouldn't be surprised
2025-10-10T21:37:04 < mrec_> well it's usually okay but I'm surprised that those simple dma transfers are causing issues now
2025-10-10T21:41:41 < qyx> karlp: interesting cupboard
2025-10-10T21:42:51 < karlp> don't go there :)
2025-10-10T21:43:23 < karlp> I kinda want to borrow one of the "real" load cell emulators and see how that behaves with _this_ waveshre adc board, just to see what the baseline really is,
2025-10-10T21:53:25 < qyx> what is a real load cell simulator? the most real one was some pricey HBM/HBK thing and it didn't look very pro
2025-10-10T21:54:35 < qyx> ok the reference blake2s implementation is 1400 B
2025-10-10T21:55:11 < qyx> the size optimized one is 672 bytes
2025-10-10T21:55:29 < qyx> should I hunt for those few bytes
2025-10-10T22:02:10 < karlp> we have some super fancy ones with cal stickers on them. I'll take a closer look on monday
2025-10-10T22:29:13 < ColdKeybo[a]rd> Is there any benefit to having a decoupling capacitor for a PWM/4-PIN fan?
2025-10-10T22:29:31 < ColdKeybo[a]rd> I see some designs use it and most don't... but can't find any app notes saying you should or should not.
2025-10-10T22:30:09 < ColdKeybo[a]rd> I would assume since 4-pin/PWM fan has internal driving circuit, it would also have some decoupling already built in
2025-10-10T22:31:37 < jpa-> it probably has a couple of microfarads, it then depends on your power supply and wire lengths if you need more
2025-10-10T22:38:09 < ColdKeybo[a]rd> But would adding a 1-2uF at the connector really help with anything?
2025-10-10T22:39:04 < ColdKeybo[a]rd> I saw designs putting 100uF or more to (I assume) help with the power rail droop when the fan spins up or if it stalls or something
2025-10-10T22:40:39 < jpa-> 1-2 uF could be for EMI, or it could be useless
2025-10-10T22:43:00 < jpa-> even 100uF won't spin a fan much.. the rotational energy is around 4 J, and the capacitor has some millijoules
2025-10-10T22:47:04 < ColdKeybo[a]rd> My guess was that it was useless... but I can't find any app notes on this
2025-10-10T22:47:27 < ColdKeybo[a]rd> So I guess I'm sticking with my guess for now :)
2025-10-10T23:32:56 -!- infise [~infisc@user/infisc] has joined ##stm32
2025-10-10T23:36:18 -!- infisx [~infisc@user/infisc] has quit [Ping timeout: 256 seconds]
2025-10-10T23:51:07 < mawk> I wired up the UART of the WINC1500 wifi module, and there's clearly data on it, but I tried every combination of baudrate and setting 
2025-10-10T23:51:11 < mawk> it has to be binary shit
2025-10-10T23:51:33 < mawk> the datasheet says it's a debug log and it's 115200 bauds, then another version of the datasheet says it's 460800, and a third version says it's configurable
2025-10-10T23:52:06 < mawk> I found the absolutely awful firmware update "tool" that's supposed to work with linux, I had to disassemble it to know which commandline options it takes
2025-10-10T23:52:36 < mawk> by resetting the WINC1500 at just the right time i was able to get it to recognize the type of chip and start erasing the flash, and then it crashed
2025-10-10T23:52:56 < mawk> but apparently it didn't erase anything important because the chip still runs
2025-10-10T23:53:08 < mawk> I had closed source shit like this
2025-10-10T23:54:16 < mawk> mrec_: what do you mean it loops over and over
2025-10-10T23:54:22 < mawk> did you enable circular mode?
2025-10-10T23:55:13 < mawk> you can have a buffer twice as big and then use the half-transfer interrupt to transmit the first half of the buffer while the DMA continues in the second half
--- Day changed Sat Oct 11 2025
2025-10-11T00:17:31 < mawk> I found a stm32wb55 boars on Aliexpress for 0,80€
2025-10-11T00:17:41 < mawk> just the right price for me
2025-10-11T00:17:53 < mawk> I'll probably receive a piece of cardboard 
2025-10-11T00:19:05 < qyx> in a month or two
2025-10-11T00:20:38 < mawk> they say in 5-10 days 
2025-10-11T00:20:46 < mawk> and if it's late I get 1€ back
2025-10-11T00:26:54 < qyx> TIL -fstack-usage
2025-10-11T00:27:37 < mawk> yeah
2025-10-11T00:27:40 < qyx> mawk: what about scoping your serial shit to precisely know the baudrate and format?
2025-10-11T00:27:51 < mawk> I broke my scope
2025-10-11T00:27:59 < qyx> you better broke a new one
2025-10-11T00:28:01 < qyx> *buy
2025-10-11T00:28:07 < mawk> I'll use the LA at the office monday
2025-10-11T00:28:10 < mawk> the scope is fixable
2025-10-11T00:28:19 < mawk> I need to replace a flatcable connector
2025-10-11T00:28:34 < qyx> of course, when a thing is breakable, it is fixable
2025-10-11T00:28:55 < mawk> what if you burn it so that only CO2 and ash is left
2025-10-11T00:29:33 < mawk> I know the baud rate is 115200 and  settings 8N1 from the shitty flasher tool, so rhe format has to be binary
2025-10-11T00:30:25 < mawk> the chip runs a supervisor immutable ROM and if you stop it you can use the SPI directly as a SPI flash interface and access the wifi module's built-in flash
2025-10-11T00:30:33 < mawk> if I can find out the offsets I can flash the firmware myself 
2025-10-11T00:30:59 < mawk> but it's a bit annoying to do
2025-10-11T00:35:21 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 265 seconds]
2025-10-11T00:38:28 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-11T00:59:26 -!- splud [~noneya.bi@user/splud] has quit [Ping timeout: 256 seconds]
2025-10-11T01:07:35 -!- splud [~noneya.bi@user/splud] has joined ##stm32
2025-10-11T01:15:58 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has joined ##stm32
2025-10-11T01:27:36 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has quit [Quit: Bye]
2025-10-11T02:14:59 -!- infisx [~infisc@user/infisc] has joined ##stm32
2025-10-11T02:16:03 -!- infise [~infisc@user/infisc] has quit [Ping timeout: 252 seconds]
2025-10-11T04:15:58 < ventYl> mawk: just out of curiosity, how many partitions does your firmware have?
2025-10-11T04:40:42 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-11T04:47:57 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-11T06:48:26 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-11T06:49:36 < mrec_> I figured out my DMA circular bug yesterday, it was a bug of stm32cube. I trusted that the generated output was correct but it wasn't it was still set to circular.
2025-10-11T06:50:32 < mrec_> not was.. it is a bug of stm32cube, if there's a second dma involved the second one is not updated appropriately
2025-10-11T07:43:51 < jpa-> use the registers like a pro :)
2025-10-11T07:49:34 < mrec_> no it's a HW bug, I was wrong and looked at the wrong part of the code.
2025-10-11T07:49:42 < mrec_> I'm not the only one with this problem
2025-10-11T07:50:11 < mrec_> the suggested way to go would be to count pulses .. well I did that and it works but it's actually not what I want
2025-10-11T07:50:46 < mrec_> NDTR = 0 .. after that it should turn off the buffer
2025-10-11T07:50:52 < mrec_> anyway I'm still looking into this
2025-10-11T07:51:38 < mrec_> overall I don't like this rubbish STM32F4 timer implementation, maybe I should ditch in my own implementation and add a cheap FPGA
2025-10-11T07:52:43 < mrec_> STMicro engineers should think, someone would expect to solve such a timer application within 10 minutes STM turns this to days of debugging
2025-10-11T07:54:49 < mrec_> https://electronics.stackexchange.com/questions/606233/what-to-do-to-stop-pwm-after-n-pulses-in-stm32
2025-10-11T08:16:35 < jpa-> things aren't always easy :)
2025-10-11T08:17:14 < jpa-> but i don't quite trust you blaming everything on ST bugs
2025-10-11T08:34:49 < mrec_> NDTR = 0 EN = 0 PWM is happily outputting, it's a wrong behaviour
2025-10-11T08:35:26 < mrec_> logically thinking PWM should turn off, if they want to keep it running they should add another register for it
2025-10-11T08:35:58 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-11T08:36:25 < mrec_> output compare works as far as I remember
2025-10-11T08:36:57 < mrec_> who would like to process a dma and then keep PWM running, it makes no sense thus STM fucked it up.
2025-10-11T08:39:09 < mrec_> the only think I haven't tried yet is timer chaining, not sure if that will work the other things I already went through and they all rely on a period elapsed interrupt signal (yes that works, but it's not how it should work)
2025-10-11T08:40:01 < mrec_> I could also add the period elapsed interrupt to the "normal" buffer situation and it will also work but then I'm back to .. it's all the same
2025-10-11T08:41:59 < jpa-> uh, why would the timer stop if you just stop dmaing into its registers?
2025-10-11T08:42:53 < jpa-> if you don't want to change length of each pulse, you can just DMA once at the end (using another timer) or preload and repetition counter
2025-10-11T08:43:27 < mrec_> I want to change each pulse that's the problem
2025-10-11T08:43:47 < jpa-> so at last pulse, change pulse length to zero?
2025-10-11T08:44:31 -!- qyx [~qyx@84.245.121.38] has quit [Ping timeout: 240 seconds]
2025-10-11T08:45:20 < mrec_> it's a pity what STM did here... I know timer 1 and timer 8 have the repetition counter but only 8 bit here.
2025-10-11T08:45:52 < mrec_> it all looks like they wanted to implement something smart but only went half way with it
2025-10-11T08:46:41 -!- qyx [~qyx@84.245.121.164] has joined ##stm32
2025-10-11T08:47:19 < jpa-> advanced timer functions are a bit off mess on everything i've used, but you also need to remember STM32F4 is like 15 years old now.. closer to the beginning of STM32 family than to present time
2025-10-11T08:47:20 < mrec_> naturally I would expect that they add an option to stop the timer as well after processing n dma samples
2025-10-11T08:47:37 < mrec_> you are right
2025-10-11T08:47:50 < jpa-> doesn't it stop if you dma 0 to ARR at the end?
2025-10-11T08:48:14 < mrec_> my H7 board arrived dead on arrival I can just use it as heater :-( so I'm stuck with the old board
2025-10-11T08:48:14 < jpa-> STM32 DMA is very generic, it just writes to registers like CPU does, it doesn't do special stuff like stopping timers
2025-10-11T08:48:54 < jpa-> compare with ESP32 where there is more special stuff but.. you can't DMA to timers at all
2025-10-11T08:49:13 < mrec_> dma 0 to arr will pull the output to 1
2025-10-11T08:50:17 < jpa-> use output invert and negate duty cycle?
2025-10-11T08:51:08 < mrec_> that is an idea, I did not try that yet
2025-10-11T08:52:22 < jpa-> you can also dma 65535 to ARR and have second compare channel give you interrupt at eg. 65000 so you have time to disable the timer in ISR
2025-10-11T08:54:22 < jpa-> on F7/H7 this would be kind-of straightforward by chaining MDMA transfers (write N times to pulse regs, then write to control reg), but i find MDMA somewhat complex itself
2025-10-11T08:56:42 < mrec_> I think your previous idea might be the only workable solution for the stm32f4 and it's a smart one (if it works)
2025-10-11T08:57:25 < jpa-> by no means the only
2025-10-11T08:57:27 < mrec_> I have multiple dma frames to process, I cannot just add random frames at the end of it unless I want to deal with the jitter
2025-10-11T08:57:45 < mrec_> adding 65535 to arr is not viable
2025-10-11T08:58:26 < jpa-> timer chaining can solve this too
2025-10-11T08:59:00 < jpa-> it's just annoying to figure out what combination of timers has the connections you need
2025-10-11T09:00:11 < jpa-> looks like newer stm32's have 16-bit repetition counter
2025-10-11T09:01:28 < mrec_> 8 bit is really too less
2025-10-11T09:01:43 < jpa-> though i guess you could reload RCR in interrupt handler so that you can count pulses in blocks of 256 instead of individually, and then only set the rwmainder on the ISR before last block begins
2025-10-11T09:01:46 < mrec_> 16 bit soso but better than nothing, for sure they will have to bump it up to 32bit
2025-10-11T09:02:41 < mrec_> I have a "jitter free" (of course there's always a small amount of jitter) circular buffer implementation, that's the actual goal.
2025-10-11T09:03:05 < jpa-> why is there jitter?
2025-10-11T09:05:15 < mrec_> small crystal jitter nothing to worry about
2025-10-11T09:05:26 < mrec_> nanoseconds
2025-10-11T09:06:23 < jpa-> ah
2025-10-11T09:06:59 < jpa-> yeah, shouldn't have jitter in terms of clock cycles, but can't escape particle physics :)
2025-10-11T09:07:18 < mrec_> I don't blame STM for that! :-)
2025-10-11T09:20:07 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-11T09:27:11 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-11T09:57:34 < mrec_> inverting the signal is probably the smartest thing that can be done here
2025-10-11T09:58:57 < mrec_> it works, and the last 0 length period will probably trigger an xfer complete signal without much noticeable overhead
2025-10-11T09:59:14 < mrec_> it worked a little bit different than expected but it seems to work (for one buffer so far)
2025-10-11T10:01:05 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-11T10:02:02 < mrec_> it should also solve my problem with circular buffers as long as I clear the buffers to 0
2025-10-11T10:02:37 < mrec_> a second timer could trigger the absolute cut-off
2025-10-11T10:03:58 < mrec_> jpa-: thanks for that excellent idea! feels like using tools from the stone age to make something useful out of it
2025-10-11T10:06:12 < jpa-> i think timer will not trigger any further DMA if ARR is 0
2025-10-11T10:06:36 < jpa-> but yeah, this is life when you need to deal with the peripherals the manufacturer has provided :)
2025-10-11T10:10:11 < mrec_> it's the pwm timer that is running as expected even after the dma is done
2025-10-11T10:10:42 < mrec_> it is still running but it's cheated with the 0 period which will never raise to 1
2025-10-11T10:18:39 < jpa-> i'm not sure what you mean by cheated, but the reference manual specifies for timer ARR that "The counter is blocked while the auto-reload value is null.", which i think also blocks any further DMA requests from being generated
2025-10-11T10:25:49 < mrec_> I just need to feed it a separate table of pulse length, I don't even need to invert it
2025-10-11T10:26:04 < mrec_> pulse length / duty cycles
2025-10-11T10:28:06 < mrec_> cheating.. because it would never reach the active part of the duty cycle. However it seems they do check if CCRx = 0 and don't just output a high cycle in PWM mode 1
2025-10-11T10:28:42 < mrec_> cheating.. because it would never reach the active part of the duty cycle - in inverted mode
2025-10-11T10:29:38 < jpa-> PWM mode 1 is "CNT < CCR1".. but CNT can never be less than 0
2025-10-11T10:30:40 < mrec_> yes inverting is pwm mode 2
2025-10-11T10:31:36 < jpa-> there is a second invert in CCER register, so you can configure what you want to happen when CNT == CCR1
2025-10-11T10:31:52 < mrec_> anyway it's okay now inverted and non inverted. The solution was simple too actually just a bit unexpected
2025-10-11T10:32:01 < jpa-> :)
2025-10-11T10:33:26 < jpa-> maybe one day there will be a good microcontroller timer implementation and other manufacturers will copy it
2025-10-11T10:33:55 < jpa-> so far STM32 timers are "let's slap on more features in every release", which kind-of works but gets confusing and has too much docs to read
2025-10-11T10:33:57 < mrec_> I'm reworking the motion controller of my pick and place machine, controlling two motors on the Y axis. Currently I use to square the Y axis myself, the next version will square it automatically
2025-10-11T10:34:54 < mrec_> the first version was simple, just taking one output for Y it works, as long as I don't touch the axis.
2025-10-11T11:00:33 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 256 seconds]
2025-10-11T11:13:48 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-11T11:18:20 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has joined ##stm32
2025-10-11T12:09:26 -!- NEYi [~NEYi@195.234.78.187] has quit [Quit: Leaving]
2025-10-11T13:14:15 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-11T13:15:19 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-11T14:04:13 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-11T14:05:15 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-11T14:05:38 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-11T14:10:59 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has quit [Ping timeout: 260 seconds]
2025-10-11T14:12:26 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has joined ##stm32
2025-10-11T14:24:43 -!- PaulFertser [paul@paulfertser.info] has quit [Ping timeout: 246 seconds]
2025-10-11T14:32:37 < jpa-> that's cute   https://forum.digikey.com/t/top-mounted-inductor-helps-with-regulator-cooling/61105
2025-10-11T14:33:05 < jpa-> but expensive :)
2025-10-11T14:39:31 < mrec_> well it is not as nice as I thought I am not able to restart the dma
2025-10-11T14:40:00 < mrec_> I'm fed up with this now, I should get another microcontroller
2025-10-11T14:40:09 < mrec_> simple tasks are overcomplicated
2025-10-11T14:43:41 < mrec_> shutting down this garbage dma engine and restarting it will not start it again either. possibly sending 0x0 to it will make it stall
2025-10-11T14:43:52 < mrec_> (the dma engine), the mainloop is still okay
2025-10-11T14:45:05 < jpa-> which microcontroller makes this easier?
2025-10-11T14:45:19 < mrec_> and hal functions are not throwing any errors, they're just fine (the inside low level code overall looks ok for this task)
2025-10-11T14:45:32 < jpa-> you are rewriting the timer ARR to other than 0 manually, right?
2025-10-11T14:45:54 < mrec_> of course, I tried looping over the same data again it doesn't work either.
2025-10-11T14:46:06 < mrec_> the dma just will not trigger anymore
2025-10-11T14:46:10 < jpa-> because like i and refman said, setting ARR to 0 blocks the timer, and won't generate more DMA requests; so you need to write the first entry yourself
2025-10-11T14:47:54 < jpa-> probably the best sequence to start a new sequence is to    1. stop timer with enable bit    2. write first ARR value   3. Force update   4. write second ARR value and start DMA for next ones  5. enable timer
2025-10-11T14:48:17 < jpa-> that way you already have the second value in the preload so even a very short pulse won't cause underrun
2025-10-11T14:49:36 < jpa-> (if you forget to force update, the new ARR value will not do anything either..)
2025-10-11T15:01:30 -!- PaulFertser [~paul@paulfertser.info] has joined ##stm32
2025-10-11T15:07:09 < mrec_> I did not see that this was mentioned, it seems to work now... I was looking at this for hours again
2025-10-11T15:08:23 < jpa-> it's like stm32 timers 101, i don't really know what magical microcontroller would make this easier
2025-10-11T15:21:37 < mrec_> definitely sounds plausible, however when using HAL and if it works the first time I'd expect running it a second time would also trigger it, so the register is probably pre-set to something non zero initially.
2025-10-11T15:22:01 < mrec_> of course it will work the second time after updating it manually
2025-10-11T15:23:25 < jpa-> yeah, i don't know what hal does
2025-10-11T15:23:35 < jpa-> normally you force the update as part of initialization anyway
2025-10-11T15:23:53 < jpa-> http://www.efton.sk/STM32/gotcha/g42.html   maybe it is due to this
2025-10-11T15:25:44 < mrec_> now everything works here
2025-10-11T15:26:10 < mrec_> totally not the way I would ever have expected it, your last hint was the key thanks.
2025-10-11T15:27:03 < jpa-> yeah, common mistakes :)
2025-10-11T15:27:22 < jpa-> i still forget update every now and then
2025-10-11T15:28:59 < jpa-> fortunately it works pretty much the same on every microcontroller (at least stm32, esp32 and rp2xxx)
2025-10-11T15:39:18 < mrec_> the controllers I worked with had the option to trigger an interrupt n items before the end of the buffer was reached
2025-10-11T15:42:33 < mrec_> and it allowed to stitch together other buffers seamlessly
2025-10-11T15:43:56 < mrec_> I think I will go back to my first solution, circular buffer, remove the period counter and use the additional duty cycle dma
2025-10-11T16:28:39 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has quit [Ping timeout: 256 seconds]
2025-10-11T16:30:26 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has joined ##stm32
2025-10-11T16:48:05 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-11T17:21:03 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-11T17:29:06 < mrec_> ok as usual that didn't work out nice ARR=0 seems to be undefined it looked like it was stuck and sometimes it is but it's not a reliable stop
2025-10-11T17:29:51 < mrec_> now I'm with ARR=0xffff and CCRx=0 and that seems to work (but need to do some more testing with it)
2025-10-11T17:30:03 < mrec_> AR=0 + CCRx
2025-10-11T17:30:30 < mrec_> ARR=0 + CCRx=0 sometimes ends up high (depending if I do something else in the interrupt)
2025-10-11T17:41:17 < jpa-> dma buffer stitching is possible at least on mdma, but even with old dma you can fake it by shortly stopping the dma to reconfigure, unless thr datarate is very high
2025-10-11T17:59:13 < mrec_> hmm I see a glitch.. low time is 10us instead of 20us, all the high times around it are at 30us, something truncated the lowtime
2025-10-11T18:00:20 < mrec_> well I need to check I have a few options now to get it done.
2025-10-11T18:18:37 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-11T18:21:41 -!- infisx [~infisc@user/infisc] has quit [Ping timeout: 244 seconds]
2025-10-11T19:05:00 < mawk> I found the right opcodes to write to the flash of the wifi ATWINC1500 module directly, and I found the addresses
2025-10-11T19:05:14 < mawk> the thing doesn't work as it is so I guess I'll just do it and if it's bricked then whatever
2025-10-11T19:33:44 < Steffanx> time to go esp-hosted fg
2025-10-11T19:38:00 < mawk> the esp32 board I have is even bigger than the nrf one
2025-10-11T19:40:00 < mawk> I'll try updating the firmware first
2025-10-11T19:40:14 < mawk> I'm able to query that it's 4MiB, that won't find in the nrf
2025-10-11T19:40:25 < mawk> but there's spi flash on the board so I might store the firmware there first
2025-10-11T19:40:47 < mawk> or send it through uart but that sounds risky
2025-10-11T19:41:38 -!- nerozero [~nerozero@87.253.63.54] has quit [Read error: Connection reset by peer]
2025-10-11T19:57:49 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-11T20:01:28 < mawk> from the PC I can get it to program part of the flash but that's it then it crashes: https://bpa.st/raw/VEDQ
2025-10-11T20:01:32 < mawk> I feel like it's almost there
2025-10-11T20:03:29 < ventYl> mawk: ^^^
2025-10-11T21:09:48 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 260 seconds]
2025-10-11T21:16:36 < mawk> looking up the address of the Atmel CEO to send him a package of dog shit
2025-10-11T21:17:59 < ventYl> there's no Atmel anymore
2025-10-11T21:18:08 < mawk> I'll dig up his body then
2025-10-11T21:18:12 < jpa-> you mean the microchip CEO who is trying to get rid of what atmel legacy remains :)
2025-10-11T21:18:58 < ventYl> TIL that atmel legacy is actually good 30 years younger than microchip legacy
2025-10-11T21:19:07 < ventYl> PIC is actually shit good 5 years older than 8051
2025-10-11T21:19:29 < mawk> it's this guy https://www.crunchbase.com/person/steven-laub
2025-10-11T21:19:38 < mawk> the guy responsible
2025-10-11T21:20:55 < mawk> you can see on his face he knows what he did
2025-10-11T21:21:15 < ventYl> what he did?
2025-10-11T21:22:25 < mawk> he's responsible for all the bullshit I experience with the ATWINC1500
2025-10-11T21:24:10 < jpa-> it's the "blame someone else than yourself" day
2025-10-11T21:25:13 < ventYl> did atmel actually create any radio peripherals while it was still atmel?
2025-10-11T21:27:36 < jpa-> does that radio module count?
2025-10-11T21:30:28 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-11T21:31:50 < ventYl> hm, that merger happened way later than I remembered
2025-10-11T21:36:59 < mawk> I didn't even write any code yet jpa- , I use the zephyr-provided WINC1500 module with the zephyr shell and try to connect like that
2025-10-11T21:37:48 < ventYl> why didn't you dump it into english channel if it is such a shitty hardware?
2025-10-11T21:38:04 < mawk> I had it laying around
2025-10-11T21:38:11 < ventYl> was it chosen by your boss and you rejecting to work with it would be taken as personall offense by him?
2025-10-11T21:38:12 < mawk> and I have no other wifi module, except ESP32
2025-10-11T21:38:20 < mawk> no it's just for personal stuff
2025-10-11T21:38:32 < mawk> but I can't give up now that I've invested enough time
2025-10-11T21:38:45 < ventYl> RPI made their WiFi/BT modules a standalone stuff recently
2025-10-11T21:38:48 < zyp> zephyr supports esp32 as wifi coproc too
2025-10-11T21:39:06 < ventYl> they might not be super but at least there's worky driver for them in pico-sdk
2025-10-11T21:41:32 < ventYl> mawk: I am curious how many partitions your firmware has; the one where you ran out of memory regions in MPU
2025-10-11T21:43:28 < mawk> there are 8 regions in the chip, I don't remember them all but you have to cover the various parts of the bootloader 
2025-10-11T21:44:35 < mawk> then regions to allow the user code, and the user ram, and the peripherals, and the reserved-but-not-really-reserved addresses that contain the calibration constants
2025-10-11T21:45:10 < ventYl> so there's only one partition which gets access to all this?
2025-10-11T21:46:48 < mawk> the bootloader runs in supervisor mode and has access to most of the addresses
2025-10-11T21:46:54 < mawk> then the application runs in user mode and has only access to itself (rx for flash, wr for ram) and peripherals and calibration constants
2025-10-11T21:47:24 < ventYl> noted
2025-10-11T21:47:34 < mawk> the permissions are global to a region so that adds up quickly 
2025-10-11T21:48:05 < ventYl> I know, MPU management is one of core tasks of my RTOS
2025-10-11T21:49:21 < mawk> I proposed that we use the background region to get rid of all the readonly region but my coworkers are afraid that by having access to reserved addresses you could somehow hack the chip or something 
2025-10-11T21:49:29 < ventYl> it probably *could* solve most of your problems
2025-10-11T21:49:51 < ventYl> background region is only accessible in privilege mode, isn't it?
2025-10-11T21:49:54 < qyx> hack the chip by reading its memory?
2025-10-11T21:52:00 < mawk> yeah it's for privileged mode only
2025-10-11T21:52:13 < ventYl> how would that solve your application's memory map?
2025-10-11T21:52:13 < mawk> so it could be used for the bootloader 
2025-10-11T21:52:28 < mawk> and free up one region
2025-10-11T21:52:36 < ventYl> well, yeah
2025-10-11T21:52:43 < ventYl> I am using it, I actually rely on it.
2025-10-11T21:52:55 < mawk> qyx yes 
2025-10-11T21:53:04 < ventYl> so my RTOS is not compatible with NXP MKL chips as they have different MPU implementation which doesn't implement background region
2025-10-11T21:53:17 < mawk> the goal is to not have any part of the code access the encryption keys
2025-10-11T21:54:15 < ventYl> that's reasonable
2025-10-11T21:54:30 < ventYl> yet I guess that at least bootloader has to access it
2025-10-11T21:58:25 < mawk> it's only the secure engine that has access to it, which runs before the MPU is enabled; so the region with the keys is permanently disabled until reboot
2025-10-11T21:58:28 < mawk> if I remember correctly 
2025-10-11T21:58:48 < mawk> the bootloader has two components, the closed source super secret secure engine, and the actual bootloader 
2025-10-11T21:58:50 < ventYl> then how anything running on the chip can get access to it?
2025-10-11T21:58:59 < mawk> the keys are just for firmware updates
2025-10-11T21:59:10 < ventYl> but the chip is M7, right? so no TrustZone
2025-10-11T21:59:14 < mawk> the firmware writes the OTA image to some slot in the flash and then reboots into the secure engine
2025-10-11T21:59:21 < mawk> yeah M7
2025-10-11T21:59:53 < mawk> yeah it's probably not foolproof, but at least just naively trying to access the keys will fail
2025-10-11T22:00:23 < ventYl> that scheme is kind-of gross
2025-10-11T22:00:35 < mawk> yeah it's the ST provided bootloader
2025-10-11T22:00:38 < ventYl> it either misses TrustZone or bootloader is way too powerfull
2025-10-11T22:01:53 < ventYl> crazy idea I am toying with is to entirely kill the concept of bootloader
2025-10-11T22:02:06 < mawk> how do you do that
2025-10-11T22:02:16 < ventYl> kernel is just some 700 SLOC anyway. so why not make it stable enough so that you barely ever need to update it.
2025-10-11T22:02:18 -!- noarb [~noarb@user/noarb] has quit [Ping timeout: 248 seconds]
2025-10-11T22:02:39 < ventYl> then kernel can first start "bootloader" app. if this decides that no software update is needed, it quits and the kernel starts "init" app
2025-10-11T22:03:14 < ventYl> 700 lines of code is trivial amount of code for full formal verification
2025-10-11T22:04:04 < ventYl> so the goal of almost no need to update the kernel is doable
2025-10-11T22:04:54 -!- noarb [~noarb@user/noarb] has joined ##stm32
2025-10-11T22:05:56 < ventYl> this way the bootloader would be just an application running inside the (immutable) RTOS which has right to write into flash and runs with the guarantee no other task is running
2025-10-11T22:06:41 < mawk> I decided to try to add a RTOS to our codebase without asking the boss first
2025-10-11T22:06:54 < mawk> then when he sees that it works and is easy he will have no choice
2025-10-11T22:07:20 -!- Livio [~livio@user/livio] has quit [Ping timeout: 272 seconds]
2025-10-11T22:07:29 < ventYl> I hope your boss is not German
2025-10-11T22:07:31 < mawk> how did FreeRTOS turn out now that it's Amazon
2025-10-11T22:07:37 < mawk> he's dutch 
2025-10-11T22:07:43 < ventYl> otherwise it may take 5+ years before he acknowledges the use of RTOS :>
2025-10-11T22:07:47 < ventYl> been there did that
2025-10-11T22:08:44 < ventYl> I assume that using FreeRTOS with memory isolation will be a major PITA
2025-10-11T22:09:07 < ventYl> their design is that if you turn memory isolation on for any task it is untrusted by default and some 60% of FreeRTOS API is unavailable for it
2025-10-11T22:09:23 < ventYl> + they use partition design which is PITA on its own
2025-10-11T22:10:26 < mawk> the whole userland would run in regular thread mode
2025-10-11T22:10:34 < mawk> but idk how that works with IRQs
2025-10-11T22:10:46 < mawk> maybe have to downgrade to thread mode on all irq entry
2025-10-11T22:10:48 < ventYl> IRQs run in handler mode
2025-10-11T22:10:52 < ventYl> that's not possible
2025-10-11T22:11:26 < ventYl> if stuff is time-critical then process it inside IRQ in statically allocated memory in handler mode
2025-10-11T22:11:47 < ventYl> if it is not time-critical then just read the data out and send it via queue or whatever and notify thread to process it
2025-10-11T22:12:10 < ventYl> "managed IRQs" are just polished fart which does the latter
2025-10-11T22:12:17 < mawk> right
2025-10-11T22:12:39 < ventYl> I spent considerable amount of time inventing way how to confine IRQ handlers
2025-10-11T22:12:53 < mawk> does DMA respect the MPU?
2025-10-11T22:13:01 < ventYl> there's no way to do that unless you are ready to sacrifice kernel performance and/or do crazy shit in HardFault handler
2025-10-11T22:13:21 < ventYl> no, MPU in all cores except of NXP MKL (to my knowledge) only affect CPU
2025-10-11T22:13:31 < ventYl> (MPU is Cortex internal peripheral)
2025-10-11T22:13:34 < mawk> ah
2025-10-11T22:13:49 < mawk> then that's a little security hole we have
2025-10-11T22:13:59 < mawk> we can read the encryption keys with DMA
2025-10-11T22:14:13 < ventYl> MKL MPU has a bit different design, sits on crossbar and has a bitmask which configures which peripheral a MPU region applies to
2025-10-11T22:14:28 < mawk> but we use DMA for ADC and GPIO so we can't forbid it
2025-10-11T22:15:05 < ventYl> for this reason the DMA driver shall be an encapsulated driver with well-defined API and configuration that only allows to configure DMA to memory areas outside of protection keys region
2025-10-11T22:16:58 < ventYl> in case of CMRX, DMA driver would not export any generic API, rather there would be several DMA regions statically configured which would be exported. Applications could only control these using some well-defined API.
2025-10-11T22:17:06 < ventYl> this is almost bulletproof
2025-10-11T22:17:39 < mawk> I guess I can use SVC handler to do the configuration 
2025-10-11T22:18:14 < mawk> or just do it in privileged mode before dropping to thread mode but I also need to stop and start it at some point
2025-10-11T22:18:41 < mawk> but we're running out of regions to disable DMA, it will be a problem
2025-10-11T22:18:58 < ventYl> -> https://cmrxrtos.org/examples/driver/
2025-10-11T22:20:24 < mawk> my boss will probably not agree to use a RTOS which doesn't come from a company but I can always try
2025-10-11T22:20:51 < ventYl> you can implement the general idea
2025-10-11T22:21:23 < ventYl> IIRC, FreeRTOS has ability to swap partition maps when tasks are switched
2025-10-11T22:21:38 < ventYl> so you can create a partition map that has access to DMA configuration and then call it somehow
2025-10-11T22:21:53 < ventYl> e.g. by sending messages via queues
2025-10-11T22:22:09 < ventYl> why not emulate microkernel inside monolithic not-a-kernel, if you can?
2025-10-11T22:26:34 < mawk> lol
2025-10-11T22:27:07 < ventYl> it is funny to watch how people of embedded oppose the idea of using this RTOS based on the fact it comes from mr. nobody
2025-10-11T22:27:20 < ventYl> there's this other company which has super safety-relevant railway code
2025-10-11T22:27:37 < ventYl> which is fugly piece of spaghetti code interwined with assembly
2025-10-11T22:28:26 < ventYl> but they are not ready fro RTOS yet :>
2025-10-11T22:29:42 < ventYl> https://digital-nomad.sk/img/cmrx-ese-summary.png
2025-10-11T22:41:11 < ventYl> you could also try to manage MPU without FreeRTOS knowing it is enabled but I guess FreeRTOS will poop itself in such configuration
2025-10-11T22:43:17 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-11T22:54:35 -!- Livio_ [~livio@user/livio] has joined ##stm32
2025-10-11T22:55:28 -!- Livio [~livio@user/livio] has quit [Ping timeout: 272 seconds]
2025-10-11T23:08:05 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-11T23:16:44 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-11T23:23:20 -!- Livio_ [~livio@user/livio] has quit [Ping timeout: 272 seconds]
2025-10-11T23:35:10 -!- NEYi [~NEYi@195.234.78.187] has quit [Read error: Connection reset by peer]
2025-10-11T23:53:44 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 240 seconds]
--- Day changed Sun Oct 12 2025
2025-10-12T00:30:41 < karlp> winc1500 is frrom newport media, not atmel... directly per say
2025-10-12T00:30:43 < karlp> per se
2025-10-12T01:15:24 -!- teknix [~unknown@user/hsv] has quit [Server closed connection]
2025-10-12T01:15:39 -!- teknix [~unknown@user/hsv] has joined ##stm32
2025-10-12T01:23:15 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has quit [Quit: Bye]
2025-10-12T01:24:30 -!- Alexer- [~alexer@alexer.net] has quit [Ping timeout: 265 seconds]
2025-10-12T01:28:05 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-12T01:41:48 -!- Alexer [~alexer@alexer.net] has joined ##stm32
2025-10-12T01:55:13 -!- nomorekaki [~nomorekak@37-136-166-42.rev.dnainternet.fi] has joined ##stm32
2025-10-12T02:02:12 -!- esden_ [sid32455@id-32455.hampstead.irccloud.com] has joined ##stm32
2025-10-12T02:02:25 -!- phryk_ [~totallyno@user/phryk] has joined ##stm32
2025-10-12T02:03:38 -!- nomorekaki [~nomorekak@37-136-166-42.rev.dnainternet.fi] has quit [Quit: Client closed]
2025-10-12T02:04:00 -!- esden [sid32455@id-32455.hampstead.irccloud.com] has quit [Ping timeout: 260 seconds]
2025-10-12T02:04:01 -!- esden_ is now known as esden
2025-10-12T02:04:02 -!- phryk [~totallyno@user/phryk] has quit [Quit: ZNC 1.9.1 - https://znc.in]
2025-10-12T02:04:34 -!- DudV2 [~dudv2@user/DudV2] has quit [Ping timeout: 255 seconds]
2025-10-12T02:06:08 -!- nomorekaki [~nomorekak@37-136-166-42.rev.dnainternet.fi] has joined ##stm32
2025-10-12T02:06:28 -!- DudV2 [~dudv2@222-155-163-204-fibre.sparkbb.co.nz] has joined ##stm32
2025-10-12T03:05:27 -!- nomorekaki [~nomorekak@37-136-166-42.rev.dnainternet.fi] has quit [Quit: Client closed]
2025-10-12T03:32:54 -!- jhalmen [373aef909d@sourcehut/user/slowjo] has quit [Server closed connection]
2025-10-12T03:33:02 -!- jhalmen [373aef909d@sourcehut/user/slowjo] has joined ##stm32
2025-10-12T03:42:43 < qyx> {'cborconf': 1, 'current-version': '0.7.0', 'flash-version': '0.8.0', 'pad': 'ppppp'}
2025-10-12T03:43:06 < qyx> any better idea of padding CBOR to 8 byte boundary to be flashable to the stm32 internal flash? :P
2025-10-12T03:45:41 < qyx> ok I changed 'pad' to 1 to save some bytes
2025-10-12T03:53:20 -!- DudV2 [~dudv2@user/DudV2] has changed host
2025-10-12T04:26:36 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-12T05:50:24 -!- blathijs [~matthijs@tika.stderr.nl] has quit [Server closed connection]
2025-10-12T05:50:49 -!- blathijs [~matthijs@tika.stderr.nl] has joined ##stm32
2025-10-12T06:36:42 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-12T06:43:50 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-12T07:46:32 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-12T09:16:29 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-12T09:54:16 < jpa-> qyx: i've done the same with protobuf :)
2025-10-12T10:57:04 < zyp> qyx, just pad it with null (or 0xff) bytes after the encoded object itself?
2025-10-12T11:01:22 < zyp> hmm, 0xff in CBOR is the «break» token for indefinite-length collections
2025-10-12T11:02:08 < zyp> so if you use an indefinite length collection for your toplevel element, and store it in a typical flash that erases to 0xff, you can set it up so you can append to it
2025-10-12T11:21:09 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has joined ##stm32
2025-10-12T12:22:04 -!- karlp [karlp@palmtreev6.beeroclock.net] has quit [Server closed connection]
2025-10-12T12:22:23 -!- karlp [karlp@palmtreev6.beeroclock.net] has joined ##stm32
2025-10-12T12:37:44 < qyx> zyp: yeah exactly what I am doing but there can't be multiple 0xff's
2025-10-12T12:38:11 < qyx> so I need to pad the content to exact bytes so exactly no 0xff is left there if I append
2025-10-12T13:03:16 < zyp> shouldn't the encoder stop when it reaches the end of the toplevel object?
2025-10-12T13:19:33 < qyx> yes but I can't overwrite part of the last doubleword later
2025-10-12T13:19:57 < qyx> and if I want to apoend data, I need to 'erase' these 0xff by writing another doubleword
2025-10-12T13:46:15 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-12T13:55:33 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 252 seconds]
2025-10-12T14:07:12 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-12T14:08:58 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-12T14:10:15 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-12T14:10:38 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-12T14:22:54 -!- Shaun [~shaun@user/shaun] has quit [Server closed connection]
2025-10-12T14:23:09 -!- Shaun [~shaun@user/shaun] has joined ##stm32
2025-10-12T14:53:00 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-12T15:11:40 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-12T15:24:34 -!- zyp [zyp@zyp.no] has quit [Server closed connection]
2025-10-12T15:24:42 -!- zyp [zyp@zyp.no] has joined ##stm32
2025-10-12T15:31:14 -!- nohit [sid334887@id-334887.tinside.irccloud.com] has quit [Server closed connection]
2025-10-12T15:31:25 -!- nohit [sid334887@id-334887.tinside.irccloud.com] has joined ##stm32
2025-10-12T15:36:46 -!- Livio [~livio@user/livio] has quit [Ping timeout: 272 seconds]
2025-10-12T16:05:25 -!- NEYi [~NEYi@195.234.78.187] has quit [Quit: Leaving]
2025-10-12T16:42:36 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has quit [Quit: Bye]
2025-10-12T16:45:24 -!- oz4ga [~tim@hator.sunsite.lv] has quit [Server closed connection]
2025-10-12T16:45:36 -!- oz4ga [~tim@hator.sunsite.lv] has joined ##stm32
2025-10-12T16:47:32 < mawk> I extracted PLL parameters and gain parameters of the wifi module to back them up just in case, then I loaded in the nRF flash the firmware to flash on the wifi chip
2025-10-12T16:47:37 < mawk> now I just have to press the big red button
2025-10-12T16:47:55 < mawk> it's supposedly unbrickable so it should be fine
2025-10-12T17:00:46 < ventYl> worst case you will turn it into a piece of e-waste
2025-10-12T17:03:53 < mawk> you can always access the internal flash even if you completely erase the firmware, so it's recoverable
2025-10-12T17:04:10 < mawk> but if you write garbage that somehow occupies the SPI bus without letting you write to it then it's bricked
2025-10-12T17:04:53 < mawk> I'm also trying to find the correct registers to read and write to eFuse but contrary to the flash there's only one try
2025-10-12T17:05:11 < mawk> to be able to set the MAC address which is 00:00:00:00:00:00 currently which is probably kinda illegal to have in a real wifi network
2025-10-12T17:11:59 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-12T17:41:20 < mawk> I found the layout of efuse but not thé 
2025-10-12T17:41:26 < mawk> commands to write to it
2025-10-12T17:41:38 < Steffanx> what hardware is inside that module/
2025-10-12T17:41:39 < mawk> I had to use wayback machine to find the docs
2025-10-12T17:41:46 < mawk> "cortus" whatever that is
2025-10-12T17:42:00 < Steffanx> sounds obscure
2025-10-12T17:42:16 < mawk> RISC-V thing 
2025-10-12T17:44:41 < jpa-> cortus - your choice when you can't afford cortex
2025-10-12T17:50:21 < mawk> lol
2025-10-12T18:00:25 < mawk> my 0,80€ stm32wb55 board is in transit
2025-10-12T18:00:33 < mawk> it exited china
2025-10-12T18:00:49 < qyx> that was fast
2025-10-12T18:00:52 < qyx> aliexpress?
2025-10-12T18:00:55 < mawk> yeah
2025-10-12T18:00:57 < qyx> ioss?
2025-10-12T18:01:09 < mawk> it's more expensive normally but I had a AliExpress coupon for some reason
2025-10-12T18:02:45 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-12T18:03:24 < mawk> https://nl.aliexpress.com/item/1005007792471427.html
2025-10-12T18:03:28 < mawk> it's something like this
2025-10-12T18:05:58 < mawk> I found an adafruit feather m0+ devboard in my drawer with a wifi module, but it's the exact same WINC1500 shit
2025-10-12T18:06:01 < mawk> I'm cursed 
2025-10-12T18:08:25 < Steffanx> What's the problem with them anyway? Why doesn't it work?
2025-10-12T18:08:44 -!- ventYl [~ventyl@adsl-dyn152.78-98-151.t-com.sk] has quit [Server closed connection]
2025-10-12T18:08:48 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-12T18:08:53 < Steffanx> I assume the one who wrote the zephyr driver had a functional one ..
2025-10-12T18:08:53 -!- ventYl [~ventyl@adsl-dyn152.78-98-151.t-com.sk] has joined ##stm32
2025-10-12T18:09:49 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-12T18:10:13 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-12T18:15:06 -!- Livio [~livio@user/livio] has quit [Ping timeout: 272 seconds]
2025-10-12T19:21:58 < Steffanx> I see
2025-10-12T19:38:03 < mawk> Steffanx: idk
2025-10-12T19:38:07 < mawk> it can scan networks but not connect
2025-10-12T19:38:13 < mawk> I'm using the zephyr code and the correct device trees and all that
2025-10-12T19:38:19 < mawk> I assume the one who wrote the zephyr had a newer firmware
2025-10-12T19:38:23 < mawk> or a different revision (there are 3)
2025-10-12T19:38:38 < mawk> my guess is it's just too old for modern wifi APs
2025-10-12T19:38:42 < mawk> some safety feature is missing or something
2025-10-12T19:40:35 < Steffanx> Hm
2025-10-12T19:54:14 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-12T19:54:52 < mawk> I'm writing the new firmware
2025-10-12T19:55:20 < mawk> and verifying by reading back the flash
2025-10-12T19:55:25 < mawk> it's all written now, the moment of truth
2025-10-12T19:57:49 < Steffanx> No official tools to update it?
2025-10-12T19:57:58 < Steffanx> Or also non functional?
2025-10-12T19:58:19 < mawk> I used the official tool to generate the new firmware image
2025-10-12T19:58:40 < mawk> but the official update tool didn't work, it found the chip and was able to upload the loading firmware but then it crashes
2025-10-12T19:59:54 < mawk> woooooooooooooooo it works
2025-10-12T20:00:05 < mawk> I can successfully connect to my wifi access point now
2025-10-12T20:01:15 < mawk> I should maybe document what I did somewhere so the next sucker knows what to do
2025-10-12T20:01:31 < mawk> I found a forum post from a guy who did the same thing but he didn't give any instructions he just said the process sucked
2025-10-12T20:11:36 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-12T20:15:18 < mawk> PING 192.168.0.183 (192.168.0.183) 56(84) bytes of data.
2025-10-12T20:15:20 < mawk> 64 bytes from 192.168.0.183: icmp_seq=1 ttl=64 time=53.0 ms
2025-10-12T20:15:24 < mawk> and I can even ping it, it's beautiful
2025-10-12T20:43:21 -!- NEYi [~NEYi@195.234.78.187] has quit [Quit: Leaving]
2025-10-12T22:24:22 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 260 seconds]
2025-10-12T22:53:46 -!- Livio [~livio@user/livio] has quit [Ping timeout: 272 seconds]
2025-10-12T23:10:41 -!- hexo__ [~hexo@user/hexo] has quit [Quit: Leaving]
2025-10-12T23:24:38 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2025-10-12T23:32:43 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 246 seconds]
2025-10-12T23:53:24 -!- nomorekaki [~nomorekak@37-136-166-42.rev.dnainternet.fi] has joined ##stm32
--- Day changed Mon Oct 13 2025
2025-10-13T00:10:03 < nomorekaki> antto: I already had subscribed to Baptiste
2025-10-13T00:17:07 < Steffanx> 4 - 0 nomorekaki . Such shame
2025-10-13T00:17:22 < nomorekaki> why you know this?
2025-10-13T00:17:46 < nomorekaki> also shame for who?
2025-10-13T00:18:10 < Steffanx> It's on every random dutch news website 
2025-10-13T00:18:16 < Steffanx> Funland 
2025-10-13T00:20:45 < nomorekaki> for winning or losing?
2025-10-13T00:21:03 < nomorekaki> I dont have strong feelings about soccer
2025-10-13T00:21:35 < Steffanx> Not winning 
2025-10-13T00:22:51 < nomorekaki> shame
2025-10-13T00:28:37 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2025-10-13T01:47:52 < qyx> so
2025-10-13T01:48:00 < qyx> 1am and I am starting working today
2025-10-13T01:48:28 < nomorekaki> everything is normal
2025-10-13T01:48:43 < qyx> mawk: so you got your winc1500 working? can you measure its idle power consumption in "connected, no data"?
2025-10-13T02:18:03 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-13T03:47:47 -!- nomorekaki [~nomorekak@37-136-166-42.rev.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2025-10-13T04:14:37 -!- ventYl [~ventyl@adsl-dyn152.78-98-151.t-com.sk] has quit [Ping timeout: 256 seconds]
2025-10-13T04:16:28 -!- tom17 [~tom@user/tomeaton17] has joined ##stm32
2025-10-13T04:17:36 -!- tomeaton17 [~tom@user/tomeaton17] has quit [Ping timeout: 246 seconds]
2025-10-13T04:20:54 -!- ventYl [~ventyl@adsl-dyn152.78-98-151.t-com.sk] has joined ##stm32
2025-10-13T04:52:40 -!- duude__ [~duude__@user/duude/x-4676560] has quit [Ping timeout: 265 seconds]
2025-10-13T04:53:13 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-13T04:53:19 -!- duude__ [~duude__@user/duude/x-4676560] has joined ##stm32
2025-10-13T06:45:22 -!- phryk [~totallyno@user/phryk] has joined ##stm32
2025-10-13T06:46:50 -!- ou5x [~tim@hator.sunsite.lv] has joined ##stm32
2025-10-13T06:49:27 -!- phryk_ [~totallyno@user/phryk] has quit [Ping timeout: 244 seconds]
2025-10-13T06:49:27 -!- oz4ga [~tim@hator.sunsite.lv] has quit [Ping timeout: 244 seconds]
2025-10-13T08:05:05 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-13T08:34:17 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-13T08:35:51 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-13T08:36:53 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-13T08:37:16 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-13T08:44:59 -!- qyx [~qyx@84.245.121.164] has quit [Ping timeout: 244 seconds]
2025-10-13T08:46:51 -!- qyx [~qyx@84.245.121.157] has joined ##stm32
2025-10-13T09:14:36 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-13T09:22:19 -!- NEYi [~NEYi@195.234.78.187] has quit [Quit: Leaving]
2025-10-13T09:28:30 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-13T09:44:04 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2025-10-13T10:03:46 < mawk> yeah it's connected qyx, I'll try to measure but it's soldered onto the board so the easiest thing I can try I measure the whole board's power usage with and without and see the difference
2025-10-13T10:08:13 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 256 seconds]
2025-10-13T10:15:15 < mawk> note that there is a low power idle mode you can enable after connection but it's not implemented in the zephyr driver apparently 
2025-10-13T10:22:31 < mrec_> what a pity the stm32f4 doesn't have enough input blocks for ABZ encoders :-( that finally disqualifies it for my application. The STM32H7 will make it then
2025-10-13T10:25:00 < jpa-> depending on the necessary encoder speed, you can do DMA from GPIO and software processing
2025-10-13T10:25:32 < jpa-> i did that in one work project with STM32F407 when 8 encoders were needed (used 1 MHz samplerate)
2025-10-13T10:26:42 < mrec_> I am driving 3 servos with the stm32f4 already, I'm out of DMA channels on the corresponding inputs I want to monitor the movements too
2025-10-13T10:27:27 < jpa-> heh
2025-10-13T10:28:24 < mrec_> I had this h7 board but it's DOA, so I will just loop back the step pulses for now until the new parts arrive
2025-10-13T10:40:56 -!- c10ud_ [~c10ud@host-87-2-122-85.retail.telecomitalia.it] has quit [Read error: Connection reset by peer]
2025-10-13T10:41:18 -!- c10ud_ [~c10ud@host-87-2-122-85.retail.telecomitalia.it] has joined ##stm32
2025-10-13T10:52:07 -!- c10ud_ [~c10ud@host-87-2-122-85.retail.telecomitalia.it] has quit [Quit: Leaving]
2025-10-13T10:52:26 -!- c10ud [~c10ud@user/c10ud] has joined ##stm32
2025-10-13T10:53:37 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-13T10:55:26 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-13T10:55:51 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-13T11:11:35 < mawk> mrec_ fix it
2025-10-13T11:31:42 < qyx> driving 3 servos is one timer?
2025-10-13T11:44:42 -!- teknix [~unknown@user/hsv] has quit [Ping timeout: 248 seconds]
2025-10-13T11:51:43 -!- teknix [~unknown@user/hsv] has joined ##stm32
2025-10-13T11:53:18 < tom17> moin
2025-10-13T11:58:48 -!- tom17 is now known as tomeaton17
2025-10-13T12:11:10 < Steffanx> Moi!
2025-10-13T12:13:48 < mawk> mooi
2025-10-13T12:28:39 < tomeaton17> today is going to be rough
2025-10-13T12:39:13 < Steffanx> Why sir Eaton?
2025-10-13T12:43:29 < mrec_> I am just driving two servos in one timer, however I need encoder feedback for all 3 servos
2025-10-13T13:06:33 < karlp> I love how cmake just decided to burn old projects down.
2025-10-13T13:09:18 < tomeaton17> Steffanx: burnt the midnight oil
2025-10-13T13:09:45 < tomeaton17> karlp: quite based
2025-10-13T13:10:43 < veverak> karlp: wdym?
2025-10-13T13:18:54 < karlp> perfectly valid projects that haven't changed and declared minimum compatible cmake versions are failing to build because new cmake says they're too old :)
2025-10-13T13:19:21 < karlp> everybody! back on the udpdate treadmill! the churn must continue!
2025-10-13T13:39:40 < mercenary> that could be a good thing, if the fix is trivial. Puts a spanner in the works of the 'No, we cannot use that, the last update on the project was over 2 years ago, it is oooold' crowd
2025-10-13T13:41:54 < tomeaton17> Hopefully they release an update rewriting how to do everything, I have become bored with the current method
2025-10-13T14:10:50 < karlp> mercenary: go fuck yourself.
2025-10-13T14:11:48 < tomeaton17> how pleasant
2025-10-13T14:19:55 < Steffanx> Lol are you annoyed karlp ?
2025-10-13T14:22:39 < karlp> thinking, "yes, everyone shoudl go and update their projectts to keep dumb people happy" is a dumb position to take.
2025-10-13T14:24:08 < karlp> in other news, nxp's mcux's usb host stack refers to a host fix with a CVE number, but the cve number is unknown...
2025-10-13T14:24:10 < tomeaton17> how about just don't use cmake 4
2025-10-13T14:24:37 < mawk> that's not a good thing at all mercenary lol
2025-10-13T14:24:59 < mawk> there's nothing to "fix", the old projects are not broken
2025-10-13T14:25:05 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-13T14:25:12 < tomeaton17> how to revive abandonware with this one simple trick
2025-10-13T14:25:12 < mawk> if cmake forces you to use an old version for old projects that's super dumb
2025-10-13T14:25:35 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-13T14:27:44 -!- NEYi [~NEYi@195.234.78.187] has quit [Quit: Leaving]
2025-10-13T14:48:00 < mercenary> autotools/automake was worse. At one point one needed 4 different versions of autotools on build machines to build all packages for a distribution
2025-10-13T14:49:57 < mercenary> karlp: also welcome to my frustration, dealing with people that refuse to use things because they are solid, tested, and have had all obvious bugs fixed already.
2025-10-13T14:51:29 < BrainDamage> honestly, cmake is simply grossly misunderstanding what min version is for
2025-10-13T14:52:14 < BrainDamage> it's for the script's compatibility with the runner, not vice-versa
2025-10-13T14:52:18 < karlp> yeah, they're apparently using it to mean "this project file expects to be run in cmake <whatgever> compat mode"
2025-10-13T14:52:27 < karlp> not "this is the minimum we need"
2025-10-13T14:52:45 < karlp> but they're saying "well, it's in the cmake file, we decide"
2025-10-13T14:54:40 < mercenary> Most likely cause: they removed some feature, or made it behave in an incompatible way, so just in case a script uses it in the old way, refuse to run it
2025-10-13T14:56:38 < BrainDamage> thing is, that's the responsibility of the user (developer) to check, and set max version or patch the script, and if they don't, the script will break
2025-10-13T14:56:40 < BrainDamage> but it's a conditional break, instead of a preemptive one
2025-10-13T14:59:11 < mawk> another tool being supposedly worse doesn't make it better
2025-10-13T14:59:29 < mawk> and I bet it was an issue of forward compatibility, not backwards compatibility 
2025-10-13T15:00:09 < mawk> newer features not being available on older autotools versions and not the other way around 
2025-10-13T15:01:23 < mercenary> you wish. then one could just keep latest version autotools. But no, old projects broke with that.
2025-10-13T15:18:30 -!- martinmoene [~martinmoe@132.229.46.129] has quit [Read error: Connection reset by peer]
2025-10-13T15:21:51 -!- martinmoene [~martinmoe@132.229.46.129] has joined ##stm32
2025-10-13T15:34:24 < ventYl> karlp: many project simply didn't gave a fuck about cmake_minimum() clause and they used whatever top-level CMakeLists.txt was written with
2025-10-13T15:35:22 < ventYl> then roughly around 3.25 CMake started showing warning that support for pre-3.5 behavior (which was more than 5 years old at that time) is deprecated and will be removed later
2025-10-13T15:35:37 < ventYl> projects still didn't gave fuck about it
2025-10-13T15:35:47 < ventYl> then 4.0 came and it soft-dropped the support
2025-10-13T15:36:20 < ventYl> and somehow now people are bragging that 6+ years-old version of software is not supported anymore
2025-10-13T15:37:06 < mawk> my cardboard stm32wb55 already arrived in the Netherlands 
2025-10-13T15:37:35 < mawk> 6 years old for system software is nothing 
2025-10-13T15:39:40 < ventYl> actually, cmake 3.4 was released in november 2015. cmake 4.0 was released around april / may this year IIRC.
2025-10-13T15:39:50 < ventYl> that's almost 10 years of support of long-deprecated behavior
2025-10-13T15:39:53 < ventYl> that's OK with me
2025-10-13T15:40:18 < qyx> you know your win11 runs win95 binaries!
2025-10-13T15:40:28 < ventYl> moreover, with like 95% of all CMakeLists they didn't become unsupported
2025-10-13T15:40:49 < ventYl> the cmake_minimum() declares what API version that CMakeLists is using
2025-10-13T15:41:33 < ventYl> what that warning says is that if your CMakeLists is still actually relying on behavior of version you declared it is, you should upgrade it
2025-10-13T16:19:15 < karlp> yes, so when you say "please give me cmake api 2.8" it makes more sense.
2025-10-13T16:19:39 < karlp> but when the field is "cmake min version required is 2.8" which is what it's written as..... and what lots of people _did_
2025-10-13T16:23:58 -!- rkta [~rkta@user/rkta] has quit [Remote host closed the connection]
2025-10-13T16:24:07 -!- rkta [~rkta@user/rkta] has joined ##stm32
2025-10-13T16:28:28 < mercenary> 10 years support for tool chain? Hmm. That's short. Plain make still builds my C code from 30 years ago, and (besides a metric ton of warnings because we didn't bother with casts to suppress that in those days), it still compiles and runs.
2025-10-13T16:49:28 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2025-10-13T17:35:46 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-13T17:46:15 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-13T17:46:59 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-13T17:55:05 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-13T18:00:45 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-13T18:05:59 < tomeaton17> nexperia seized by the dutch
2025-10-13T18:18:11 < qyx> looks like exceptional times are coming
2025-10-13T18:20:00 < tomeaton17> nothing ever happens
2025-10-13T18:23:10 < ventYl> karlp: well, there's this little detail of forward compatibility
2025-10-13T18:23:40 < ventYl> cmake is both forward- and backwards-compatible a lot
2025-10-13T18:23:52 < ventYl> as you *will* get that behavior
2025-10-13T18:26:23 < ventYl> which is why the parameter is called minimum required version
2025-10-13T18:26:45 < ventYl> the format of the call is quite stupid. I guess they did it this way to left the door open for API versions but they soon dropped it
2025-10-13T18:32:16 < karlp> yes, they call it minimum, but what it _does_ is tell cmake to behave as that version, so modern cmake dropped it.  when all the authors of the downstreams mean is "this is the minimum"
2025-10-13T18:32:48 < karlp> and yes... adding "2.2..3.25" is the "new" way of saying "yeah, I actaully mean any of those, at least..."
2025-10-13T18:37:52 < ventYl> modern cmake didn't drop the command entirely
2025-10-13T18:38:05 < ventYl> it dropped compatibility with specific behavior of then 10 years old version
2025-10-13T18:38:35 < ventYl> I might be wrong, that the difference is really only in default settings of CMake policies
2025-10-13T18:42:00 < qyx> let's do some vibe coding
2025-10-13T18:42:10 < qyx> I need to parse ELF in php
2025-10-13T18:42:13 < karlp> ventYl: yes, but the result is that downstreams have to modify...
2025-10-13T18:45:00 < ventYl> that's sad that you have to update your product
2025-10-13T18:45:48 < ventYl> there are only two reasonable uses of this
2025-10-13T18:46:00 < ventYl> either you use newest versions and then you keep your toolchain updated
2025-10-13T18:46:27 < ventYl> or you pin versions of your software down at some particular time and then this doesn't matter because you are still using cmake 2.8 anyway
2025-10-13T18:47:06 < ventYl> any mixing of these two strategies means you'll end up in trouble sooner or later
2025-10-13T19:07:34 < veverak> I mean, I don't think it's same to blame cmake for dropping support for past bad decisions after 10 years
2025-10-13T19:07:41 < veverak> And yes, one way or another that means that stuff has to update
2025-10-13T19:12:25 < ventYl> what past bad decisions?
2025-10-13T19:14:45 < veverak> if they drop support for old api that means that that API behaved differently, I don't think they would change it for the lolz so I assume that the changes are due to previous decisions considered bad
2025-10-13T19:15:35 < ventYl> well, the subject matter here is that CMake behavior changes as CMake itself evolves
2025-10-13T19:15:50 < ventYl> if this happens, then a CMake policy is created that can be set to either old or new behavior
2025-10-13T19:16:07 < ventYl> these policies are pre-set depending on cmake version the project declares it is compatible with
2025-10-13T19:16:32 < ventYl> so if you upgrade CMake, no random behavior change of your buildsystem will happen just because CMake changes how things are done (not written)
2025-10-13T19:17:38 < veverak> I can guess you can say that not all those changes are due to previous being bad
2025-10-13T19:17:40 < ventYl> as there were 180 such policies in cmake 3.31, authors decided that old behavior of cmake versions from pre-3.5 era won't be supported anymore
2025-10-13T19:18:02 < veverak> anyway, I still believe that dropping support of old behavior as long as the time window is quite generous is sane behavior
2025-10-13T19:18:06 < veverak> >5y feels generous
2025-10-13T19:18:35 < ventYl> well, cmake 3.4 was released 11/2015, cmake 3.5, which is still supported was released sometime in 2026
2025-10-13T19:18:57 < ventYl> this old behavior was supported for more than 9 years
2025-10-13T19:20:00 < ventYl> fun thing is that for most projects, they actualy *were* compatible with newer versions of cmake. they just never bothered to upgrade the declaration of minimum supported version
2025-10-13T19:20:42 < ventYl> many of these policies changes are like: yeah, something changed but you won't see the new behavior unless you actually use it
2025-10-13T19:23:30 < qyx> the more you discuss the issue the less I want to touch that thing ever
2025-10-13T19:30:04 < ventYl> well, you pretend as if other tools did not remove features
2025-10-13T19:30:09 < ventYl> or change behavior
2025-10-13T19:36:02 < karlp> your accounting is wrong though.
2025-10-13T19:36:22 < karlp> authors were filling in a "minimimum required" field and _rightfully_ putting quite old ones there _when they wrote them_
2025-10-13T19:36:44 < karlp> it's not like you start a new project today and put "min required(lol, latest master only")
2025-10-13T19:43:29 < karlp> look at this glory though: https://github.com/nxp-mcuxpresso/mcux-component/blob/main/osa/fsl_os_abstraction_free_rtos.h#L18
2025-10-13T19:45:06 < ventYl> karlp: that accounting is OK. because if your project is versioned, then you simply go and upgrade that requirement as you develop the project
2025-10-13T19:45:19 < ventYl> if someone wants to get stuck with 20 years old version, nothing prevents him from doing so
2025-10-13T19:45:31 < qyx> nah not in the "it works, do not touch" setup
2025-10-13T19:45:42 < karlp> I think my  biggest obstacle is that you are told to put in the minimum version you need.
2025-10-13T19:45:43 < qyx> exactly like my python "projects"
2025-10-13T19:45:51 < karlp> but what you get is "it must be this old style"
2025-10-13T19:46:01 < karlp> so it deprecates _far_ faster than you expected.
2025-10-13T19:47:17 < ventYl> its the same as when you spec you want to use some ciphersuite and it gets obsoleted
2025-10-13T19:47:44 < ventYl> I think that people whine mostly because CMake used to have decades of backwards compatibility
2025-10-13T19:48:00 < ventYl> they deprecated (not removed) pre cmake-2.8 only in cmake 3.20
2025-10-13T19:48:17 < ventYl> cmake 2.8 is dinosaurs (and german automotive)
2025-10-13T20:00:29 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-13T20:05:31 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-13T20:06:39 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-13T20:07:03 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-13T20:53:13 < qyx> any of you guys ever did bootloader updating?
2025-10-13T20:53:45 < ventYl> $automotive did
2025-10-13T20:53:52 < ventYl> not in the field
2025-10-13T21:06:08 < qyx> thinking about doing a small sram-residih update stub
2025-10-13T21:06:18 < qyx> run right after reset
2025-10-13T21:10:13 < antto> qyx, i've only thought about it
2025-10-13T21:19:08 < qyx> and what's the result of that creative process?
2025-10-13T21:19:17 < zyp> qyx, by design or by «oh shit, I fucked up the bootloader and now have devices in the field»?
2025-10-13T21:19:28 < qyx> yeah by design lol
2025-10-13T21:19:35 < qyx> I am not mawk
2025-10-13T21:19:41 < zyp> then don't pick that approach
2025-10-13T21:19:58 < qyx> well, there are two approaches
2025-10-13T21:20:07 < zyp> if you're gonna design in an upgradable bootloader, you absolutely have to dual-bank it
2025-10-13T21:20:10 < qyx> "update by application" and "use stup to update itself"
2025-10-13T21:20:49 < qyx> ok I know exactly ONE device supporting that
2025-10-13T21:21:00 < qyx> that is a mikrotik with dial boot flash
2025-10-13T21:21:15 < qyx> I have never seen an embedded device with dual bank or dual flash bootloaders
2025-10-13T21:21:40 < zyp> ncs/zephyr does it if you want upgradable bootloader
2025-10-13T21:21:50 < qyx> all consumer devices and routers update the whole flash when updating the app
2025-10-13T21:21:53 < veverak> hu? I thought dual bank is pretty standard
2025-10-13T21:21:57 < veverak> anyway
2025-10-13T21:22:00 < veverak> qyx: we do have such a thing
2025-10-13T21:22:00 < zyp> it has an immutable first stage bootloader and a dual-bank upgradable second stage bootloader
2025-10-13T21:22:18 < veverak> (technically)
2025-10-13T21:22:25 < veverak> nobody has balls to update the bootloader
2025-10-13T21:22:27 < veverak> :)
2025-10-13T21:22:37 < qyx> what does the first stage do? besides chainloading the second stage
2025-10-13T21:22:50 < zyp> pick which bank to chainload or something
2025-10-13T21:23:06 < veverak> with new generation of devices we move to stm32u5 with 2MB flash so I want to go dual-boot with updateable bootloader... but frankly ... I very mcuh want to write it just once
2025-10-13T21:23:25 < zyp> https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader.html#upgradable-bootloader
2025-10-13T21:23:53 < qyx> yeah I am not there yet, I have stm32g4 designs with 512K max
2025-10-13T21:24:19 < qyx> whats wrong with the stub approach besides it eventually failing?
2025-10-13T21:24:25 < zyp> highend g4 has dual bank flash with bank swapping ability
2025-10-13T21:25:06 < zyp> I did a thing for a client some years ago, using g4
2025-10-13T21:25:50 < zyp> simple stub written in first sector of each flash, responsible for auto bank swapping and rollback
2025-10-13T21:25:55 < qyx> I know it can be done but I also know I have 4 days to implement something and I have some devices in field with 256K of flash
2025-10-13T21:25:58 < qyx> and even 128K
2025-10-13T21:25:59 < zyp> then bootloader embedded in application, writes opposite bank
2025-10-13T21:26:47 < qyx> yeah
2025-10-13T21:26:53 < qyx> I mean, yeah, point taken, I understand
2025-10-13T21:27:00 < qyx> but that's on the menu today
2025-10-13T21:27:05 < qyx> *not
2025-10-13T21:27:28 < qyx> I could make the "stub" an actual FSBL residing in the first 2KB of flash
2025-10-13T21:27:48 < qyx> and update the SSBL when the right signature in the ram buffer is found and the buffer is integrity checked
2025-10-13T21:28:18 < zyp> if you don't want to design it properly, you can just ship a bootloader upgrade as an application image
2025-10-13T21:28:38 < qyx> that way I can't lock the flash when entering the application
2025-10-13T21:28:45 < zyp> true
2025-10-13T21:28:49 < qyx> probably I don't have to
2025-10-13T21:28:50 < qyx> nobody knows
2025-10-13T21:29:21 < zyp> I took that approach when I fucked up a bootloader that weren't meant to be upgradeable
2025-10-13T21:29:46 < qyx> I'll probably make an intermediate version and leave the flash unlocked
2025-10-13T21:29:55 < qyx> and to zyp-upgrade when I decide it is time to move on
2025-10-13T21:30:01 < ventYl> zyp: yeah, we did it the same way
2025-10-13T21:30:46 < mawk> it doesn't do a mass erase when you unlock the flash?
2025-10-13T21:30:55 < mawk> or is that just for RDP downgrade
2025-10-13T21:31:08 < qyx> you are not unlocking the flash
2025-10-13T21:31:23 < qyx> when you are upgrading, you are not-locking the flash
2025-10-13T21:31:24 < zyp> you must reset to unlock flash
2025-10-13T21:31:35 < mawk> what do you mean qyx
2025-10-13T21:31:40 < qyx> what zyp says
2025-10-13T21:31:44 < mawk> it's in option bytes 
2025-10-13T21:31:47 < mawk> it's locked from boot
2025-10-13T21:31:48 < qyx> reset and do not lock, upgrade, lock afterwards
2025-10-13T21:31:48 < mawk> no?
2025-10-13T21:31:51 < qyx> no
2025-10-13T21:34:47 < mawk> on the F7 we have it's in the option bytes, nWRPi
2025-10-13T21:39:22 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 244 seconds]
2025-10-13T21:43:34 < antto> qyx, none ;P~
2025-10-13T21:44:06  * antto sneaks out
2025-10-13T21:45:19 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-13T21:45:19 < antto> but basically i think i was thinking in a direction of... writing a Firmware, which contains a binary blob of the new bootloader, and overwrites the boot section with that blob and crosses fingers for nothing wrong to happen
2025-10-13T21:46:25 < antto> but if it has to be "designed" ... then maybe i have a better idea
2025-10-13T21:46:52 < antto> make a boot sector twices as big and a small pre-bootloader which never gets overwritten
2025-10-13T21:47:12 < antto> huh, so that's how you end up with "layers of bootloaders"
2025-10-13T21:47:55 < antto> the pre-bootloader's job would be to find out which of the two places contains a valid bootloader
2025-10-13T21:48:31 < antto> the update procedure will write the new bootloader blob into one of these two places - if it gets interrupted - the other place should hopefully still be valid
2025-10-13T21:49:01 < antto> this begins to smell a lot like my FRAM "Banked memory" idea i talked about some months ago
2025-10-13T21:49:28 < veverak> we do that at work in single-bank device
2025-10-13T21:49:54 < veverak> two layers of bootloaders, app got compressed copy of both, app can execute update if it feels brave enough
2025-10-13T21:50:08 < antto> there may be other ways, i haven't thought about it, but i probably can't do it this way since my bootloader already isn't made like that
2025-10-13T21:50:11 < veverak> but the bottom one is never updated (and given that it has bare minimum functionality it does not need to be)
2025-10-13T21:50:26 < antto> the only way to do it this way is to "upgrade" to this scheme via the "dangerous" way
2025-10-13T21:50:37 < antto> veverak, yeah, exactly
2025-10-13T21:53:42 < antto> unfortunately, this may not be easy to do depending on the chip, the pre-bootloader will be small and you'd probably wanna make it isolated nicely, but i know some chips have *huge* page sizes
2025-10-13T21:54:00 < antto> i mean, it might be very wasteful
2025-10-13T21:54:22 < antto> if you have to sacrifice 8KB for the pre-bootloader just because this is the smallest chunk you can erase
2025-10-13T22:02:12 < ventYl> that's almost enough to fit my whole kernel
2025-10-13T22:02:26 < ventYl> so why don't use that as immutable anchor and let everything else to be upgraded
2025-10-13T22:11:43 -!- ou5x is now known as oz4ga
2025-10-13T22:14:05 < Steffanx> Is it SAFU?
2025-10-13T22:45:45 < englishman> i wonder how CRA will affect diy bootloaders
2025-10-13T22:46:30 < englishman> maybe both updateable and non-updateable bootloaders will be illegal
2025-10-13T22:50:46 < mawk> qyx 730mA when connected and idle
2025-10-13T22:51:05 < mawk> but I haven't tried to enable the low power mode yet, if it's supported by zephyr
2025-10-13T22:51:31 < mawk> uuh
2025-10-13T22:51:38 < mawk> 73mA I mean
2025-10-13T22:52:15 < mawk> more or less
2025-10-13T22:52:32 < mawk> total of the board is 90mA with everything idle in RUN mode
2025-10-13T23:18:37 < qyx> mawk: uhm I expected 0.73 mA or so
2025-10-13T23:21:21 -!- NEYi_ [~NEYi@195.234.78.187] has joined ##stm32
2025-10-13T23:24:15 -!- NEYi [~NEYi@195.234.78.187] has quit [Ping timeout: 244 seconds]
2025-10-13T23:37:55 < karlp> qyx:  lul. you didn't really expect like 20yo wifi module to have good power consumption did you? :)
2025-10-13T23:38:19 < karlp> ok, ~12 year old.
2025-10-13T23:39:55 < qyx> I expected anything better than esp32 which is around 60 mA
2025-10-13T23:49:05 -!- hexo [~hexo@user/hexo] has joined ##stm32
--- Day changed Tue Oct 14 2025
2025-10-14T00:10:37 < mawk> I'll see if I can get that idle low power mode thing going
2025-10-14T00:10:51 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 256 seconds]
2025-10-14T00:12:17 < mawk> you can also decrease the gain parameters to get lower consumption during transmission 
2025-10-14T00:12:38 < mawk> using a weird CSV file that is used to generate the firmware image
2025-10-14T00:12:47 < mawk> but none of that is documented 
2025-10-14T00:23:35 < mawk> it's already in low power mode actually
2025-10-14T00:23:37 < mawk> lol
2025-10-14T00:42:44 -!- nomorekaki [~nomorekak@37-136-166-42.rev.dnainternet.fi] has joined ##stm32
2025-10-14T00:55:01 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-14T01:13:48 < qyx> [] ERROR: flash-updater: xz: was too optimistic about memory usage...
2025-10-14T01:13:53 < qyx> things starting to work
2025-10-14T01:14:41 < qyx> mawk: lol
2025-10-14T01:57:04 < qyx> wow the shit works
2025-10-14T01:57:24 < qyx> transparently decompresses xz compressed elf update image, even my elf parsing library works on top of that
2025-10-14T01:57:59 < qyx> can load elf headers, section headers, find a .comment section
2025-10-14T01:58:15 < qyx> now, parse the comment section to get the firmware version and some compatibility strings and flags
2025-10-14T02:19:47 -!- nomorekaki [~nomorekak@37-136-166-42.rev.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2025-10-14T03:26:22 -!- teknix [~unknown@user/hsv] has quit [Ping timeout: 256 seconds]
2025-10-14T03:39:05 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:9c41:11c5:dedb:5a0] has quit [Ping timeout: 245 seconds]
2025-10-14T03:39:12 -!- jfsimon1981 [~jfsimon19@2a01:cb14:b9b:2000:1de2:1399:afaf:228e] has joined ##stm32
2025-10-14T03:44:47 -!- jfsimon1981 [~jfsimon19@2a01:cb14:b9b:2000:1de2:1399:afaf:228e] has quit [Remote host closed the connection]
2025-10-14T03:51:45 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1de2:1399:afaf:228e] has joined ##stm32
2025-10-14T03:55:30 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1de2:1399:afaf:228e] has quit [Remote host closed the connection]
2025-10-14T03:58:05 -!- teknix [~unknown@user/hsv] has joined ##stm32
2025-10-14T04:02:10 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1de2:1399:afaf:228e] has joined ##stm32
2025-10-14T04:05:42 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1de2:1399:afaf:228e] has quit [Remote host closed the connection]
2025-10-14T04:07:47 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1de2:1399:afaf:228e] has joined ##stm32
2025-10-14T04:17:11 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-14T07:26:53 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-14T08:21:57 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 260 seconds]
2025-10-14T08:43:45 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-14T08:47:27 < antto> huh, .elf?!
2025-10-14T08:47:31 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-14T08:47:40 < antto> isn't that much bigger than the actual binary?
2025-10-14T08:48:08 < antto> my bootloader uses a binary with a small header in front
2025-10-14T08:48:33 < antto> no compression even
2025-10-14T08:48:58 < qyx> it is not
2025-10-14T08:49:21 < qyx> if you strip bs from the resulting elf, it is only a little bit bigger than a binary
2025-10-14T08:49:45 < qyx> lzma2 saves another 50% or so
2025-10-14T08:51:02 < antto> ah, i don't
2025-10-14T08:51:24 < antto> whatever the compiler pukes - i keep it as is, it has debug symbols and what not
2025-10-14T08:51:45 < antto> i've seen like 4MB .elf files, altho i don't even really care what their size is
2025-10-14T08:52:59 < antto> well, in any case, your bootloader sounds more fancy than mine
2025-10-14T08:54:16 < antto> what kind of average "write speed" do you get when you flash the firmware?
2025-10-14T08:54:23 < qyx> not here yet
2025-10-14T08:54:28 < qyx> there
2025-10-14T08:54:55 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-14T08:55:53 < antto> the decompression could maybe not make it any slower if it's done while waiting for the flash erase or whatever the slow flash thing is
2025-10-14T08:56:53 < antto> i have one more possible move to make mine faster than what it currently is, but i don't wanna do it
2025-10-14T08:57:41 < antto> it's actually not in the bootloader side at all i think, it is mostly on the side of the Program that sends the firmware.bin
2025-10-14T08:59:08 < antto> the program sends a packet containing a page, and waits for the bootloader to say "okay" or "f*ck, SomTingWong" .. the bootloader sends "okay" only after the page has been written to flash, which involves waiting
2025-10-14T08:59:56 < antto> the possible move i have is to send 1 next packet with the next page always, so that while the bootloader is waiting for the first page to be written - the next page is already in the buffers
2025-10-14T09:00:29 < antto> not sure how much i'll gain but it'll be slightly faster surely, but it's gonna change the flashing algo and i don't wanna do it ;P~
2025-10-14T09:00:48 < antto> particularly the error logic
2025-10-14T09:02:57 < antto> there's also another strategy i think where you can erase all pages before you even begin to receive the binary, then i think the waiting for writing will be much smaller or almost "none"
2025-10-14T09:07:41 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-14T09:59:57 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2025-10-14T10:17:12 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 256 seconds]
2025-10-14T10:32:23 < c10ud> i do uncompressed with fixed offsets also
2025-10-14T10:37:17 < jpa-> i do uncompressed .bin that also includes the bootloader; the bootloader skips updating itself, but the same binary works for flashing with other methods
2025-10-14T10:41:33 < qyx> interesting approach
2025-10-14T10:42:12 < qyx> actually, if I expose a flash volume/region in my app where the bootloader resides, I could access it over the wire and update it during runtime
2025-10-14T10:42:20 < qyx> if communication fails, uhm, :)
2025-10-14T10:42:48 < qyx> I guess that's what processes are for, I just document it and yolo
2025-10-14T10:55:39 -!- veverak [~veverak@2a01:4f8:1c1c:377c::1] has quit [Ping timeout: 244 seconds]
2025-10-14T11:04:46 -!- veverak [~veverak@2a01:4f8:1c1c:377c::1] has joined ##stm32
2025-10-14T11:32:57 < c10ud> we just did a two stage bootloader
2025-10-14T11:53:53 < zyp> antto, .elf is a binary with a small header in front
2025-10-14T11:55:07 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Remote host closed the connection]
2025-10-14T11:56:35 < zyp> although, if you need to strip debugsyms and other unnecessary metadata from the .elf to get the size down, I'm not sure what the benefit is over just converting the .elf to a bespoke format for an update image
2025-10-14T11:57:14 < jpa-> at least you can use common tools on PC side
2025-10-14T11:58:06 < jpa-> on the other hand, .elf doesn't have checksum built-in
2025-10-14T11:58:55 < zyp> exactly, you'd typically want an update to be checksummed, signed and/or encrypted
2025-10-14T12:00:02 < zyp> then it's a question of whether each of those are checked/handled at flashing time or on every boot
2025-10-14T12:07:34 < c10ud> my boy ewarm checksums the bin
2025-10-14T12:07:42 < c10ud> we only check on flash tho
2025-10-14T12:15:08 -!- NEYi_ [~NEYi@195.234.78.187] has quit [Quit: Leaving]
2025-10-14T12:15:32 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2025-10-14T12:25:37  * karlp merrily continuously checksums, all the time. gotta make sure flash didn't corrupt itself ;)
2025-10-14T12:53:26 < qyx> zyp: the elf is signed, of course
2025-10-14T12:53:42 < qyx> and it has multiple benefits, mainly direct upgrade path to dynamic loading
2025-10-14T12:54:25 < zyp> as in dynamic linking?
2025-10-14T12:54:49 < qyx> yes, sorry
2025-10-14T12:54:55 < qyx> both loading and linking
2025-10-14T12:59:52 < zyp> that's something I've wanted to play with, but I have doubts about the usefulness
2025-10-14T13:00:27 < zyp> and I expect there's a significant complexity difference between dynamic linking of a shared object and loading of an executable
2025-10-14T13:01:21 < qyx> I decided i am not inventing a new format, I am embedding checksum and signature in a elf section, I am just dealing with embedding version metedata in a .note section too
2025-10-14T13:01:26 < zyp> I have doubts about how suitable elf is for the task too
2025-10-14T13:01:40 < qyx> I have a linker script allowing the elf to be XIP'd as-is
2025-10-14T13:02:48 < qyx> and I plan to use a bunch of concatenated elfs as a simple XIP-able filesystem for storing objects
2025-10-14T13:04:35 < zyp> if you're gonna dynamically link code that goes into flash, you need to rewrite it on the fly when writing the flash, and I suspect that's better done with a format optimized for streaming
2025-10-14T13:05:37 < zyp> assuming we're talking about a standard xip from flash MCU
2025-10-14T13:07:03 < zyp> something like a h7s7 executing from xspi ram or something would be a different deal
2025-10-14T13:07:41 < qyx> I am not considering running from flash in the future at all
2025-10-14T13:08:02 < qyx> starting with u5, all MCUs have enough internal SRAM to run the full firmware
2025-10-14T13:59:58 < c10ud> im unsure if such complexity is worth mantaining, after all a simple soc is nowadays very cheap 
2025-10-14T14:00:18 < c10ud> then you can slap linux on it and call it a day, you can use whatever lib and method you want
2025-10-14T14:07:03 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2025-10-14T14:32:15 < karlp> then you can have new complexities ;)
2025-10-14T14:54:11 < ventYl> things are going to be complex. one way or another. or you have to remove features.
2025-10-14T14:58:37 < qyx> I have linux on things where it fits
2025-10-14T15:13:39 -!- infisx [~infisc@user/infisc] has joined ##stm32
2025-10-14T15:16:44 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1de2:1399:afaf:228e] has quit [Remote host closed the connection]
2025-10-14T15:16:55 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 246 seconds]
2025-10-14T15:20:45 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1de2:1399:afaf:228e] has joined ##stm32
2025-10-14T15:27:04 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1de2:1399:afaf:228e] has quit [Remote host closed the connection]
2025-10-14T15:29:00 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1de2:1399:afaf:228e] has joined ##stm32
2025-10-14T15:32:03 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1de2:1399:afaf:228e] has quit [Remote host closed the connection]
2025-10-14T15:41:49 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1de2:1399:afaf:228e] has joined ##stm32
2025-10-14T15:47:08 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1de2:1399:afaf:228e] has quit [Remote host closed the connection]
2025-10-14T15:50:18 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1de2:1399:afaf:228e] has joined ##stm32
2025-10-14T15:58:15 < zyp> IME throwing linux into the mix adds a ton more complexity than it removes
2025-10-14T16:02:51 < qyx> but you can use your nodez and php
2025-10-14T16:04:59 < zyp> or python, yeah
2025-10-14T16:17:40 < mawk> qyx: try this https://www.st.com/content/st_com/en/campaigns/st67w-wifi6-bluetooth-thread-module-z13.html?icmp=tt43486_gl_fp_apr2025
2025-10-14T16:18:06 < qyx> mawk: yeah I have it on my list to check
2025-10-14T16:18:17 < qyx> looks very good
2025-10-14T16:18:23 < mawk> they say 802.15.4 will come with a future firmware update
2025-10-14T16:18:29 < mawk> if that's the case it's pretty cool
2025-10-14T17:15:46 < mawk> AT commands over SPI is certainly a choice though
2025-10-14T17:16:30 < mawk> I'm wondering how that works if you don't know in advance when you'll receive a URC or how many bytes you expect
2025-10-14T17:21:01 -!- remcycles [~remcycles@c-24-19-134-216.hsd1.wa.comcast.net] has quit [Ping timeout: 264 seconds]
2025-10-14T17:21:50 < mawk> seems like the official cube thing to use it requires you to use freertos or maybe threadx
2025-10-14T17:22:03 < mawk> but at least you can use AT commands in your own driver if you want
2025-10-14T17:30:52 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1de2:1399:afaf:228e] has quit [Remote host closed the connection]
2025-10-14T17:33:58 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1de2:1399:afaf:228e] has joined ##stm32
2025-10-14T17:39:20 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1de2:1399:afaf:228e] has quit [Remote host closed the connection]
2025-10-14T17:40:07 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1de2:1399:afaf:228e] has joined ##stm32
2025-10-14T18:11:57 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has joined ##stm32
2025-10-14T18:13:33 < PlasmaHH> Hi, I am currently porting some app on an stm32u585  to zephyr and for whatever reason I get an interrupt 78 (SDMMC1) despite that peripheral and the bit in NVIC_ISER_2 being disabled... anyone has an idea what I am overlooking or where else I could look?
2025-10-14T18:36:33 < mawk> did you look at the interrupt vector PlasmaHH 
2025-10-14T18:37:14 < PlasmaHH> mawk: not quite sure what you mean, it contains the pointer to the handler being called?
2025-10-14T18:39:55 < mawk> yeah, is it really at position 78?
2025-10-14T18:40:43 < PlasmaHH> I use dynamic interrupts, thus looking at ipsr
2025-10-14T18:43:55 < mawk> you looked at pin 14 of NVIC_ISER2 right
2025-10-14T18:44:01 < mawk> bit 14 I mean
2025-10-14T18:44:18 < PlasmaHH> indeed
2025-10-14T18:44:44 < PlasmaHH> just in case of one off errors the surrounding ones are 0 too ;)
2025-10-14T18:45:24 < mawk> interrupts can be pending without actually raising an interrupt, if you see it as pending when it's disabled you can just ignore it
2025-10-14T18:45:39 < mawk> unless the interrupt handler is actually being called then there's a problem
2025-10-14T18:45:48 < PlasmaHH> yes its called
2025-10-14T18:46:12 < mawk> strange
2025-10-14T18:46:30 < PlasmaHH> indeed
2025-10-14T18:46:45 < qyx> I would say the bootloader forgot to disable it?
2025-10-14T18:46:53 < PlasmaHH> no bootloader
2025-10-14T18:46:58 < qyx> idk then
2025-10-14T18:47:09 < mawk> zephyr does a bunch of stuff before getting to your main() though 
2025-10-14T18:47:14 < mawk> it could happen there
2025-10-14T18:47:39 < mawk> you can add zephyr,deferred-init; in the sdmmc peripheral in the device tree, or just mark it as status = "disabled"
2025-10-14T18:48:26 < PlasmaHH> I don't even have sdmmc in the device tree for our hardware, wouldnt the default be disabled?
2025-10-14T18:49:00 < mawk> probably
2025-10-14T18:50:39 < mawk> when do you see the interrupt fire?
2025-10-14T18:50:44 < PlasmaHH> I sometimes can get to the point where I am right before re-enavling interrupts when zephyr wants to switch the task and next is I am in that interrupt handler... but at that point I see no 78 enabled, pending or whatnot... only thing I can imagine is that between enabling interrupts and hitting that handler something else happens that covers its tracks...
2025-10-14T18:51:20 < PlasmaHH> its usually a moment after my main() initialization code is done and switches to the first task running hte application...
2025-10-14T18:51:29 < mawk> before enabling interrupts you can make sure it's disabled and then clear the pending bit, and it won't fire when you re-enable interrupt 
2025-10-14T18:51:34 < mawk> but it doesn't explain why
2025-10-14T18:51:55 < PlasmaHH> the thing is at that point it is disabled and not pending, checked the registers...
2025-10-14T18:52:23 < PlasmaHH> I kinda have some problems single stepping into interrupt handlers thus most likely in between that and the reenabling of the interrupts something happens that I cannot get my hands on
2025-10-14T18:53:02 < mawk> and you see it marked as active when you put a breakpoint inside the handler? because the problem might be something else, like memory errors that make you end up in the handler another way
2025-10-14T18:53:45 < PlasmaHH> I see ipsr set to 78 nothing else indicates it being in any way enabled
2025-10-14T18:58:51 < mawk> I mean active, so IABR
2025-10-14T18:59:11 < mawk> IABR2 & (1 << 14)
2025-10-14T19:03:39 < PlasmaHH> nope, but NVIC_IABR_2 bit30 is set, hmmm
2025-10-14T19:04:36 < mawk> the plot thickens 
2025-10-14T19:04:45 < mawk> that's interrupt 94
2025-10-14T19:04:58 < PlasmaHH> sorry IABR_1 so interrupt 62
2025-10-14T19:05:08 < PlasmaHH> cant copypaste from the company machine, sigh
2025-10-14T19:05:11 < mawk> ah
2025-10-14T19:05:40 < PlasmaHH> so usaart2 which makes sense since the current code communicates on spi
2025-10-14T19:07:56 < mawk> that's almost 16 between the two
2025-10-14T19:08:09 < PlasmaHH> 0x3e vs 0x4e
2025-10-14T19:09:41 < mawk> they should be at offsets 0x138 and 0x178 in the vector table respectively 
2025-10-14T19:09:58 < mawk> the handler addresses 
2025-10-14T19:10:27 < mawk> this feels like an offset error somehow 
2025-10-14T19:11:32 < PlasmaHH> let me check what ipsr is in the old firmware, where we dont use dynamic isrs
2025-10-14T19:13:35 < PlasmaHH> boinc, there we are
2025-10-14T19:13:40 < PlasmaHH> ipsr says 78
2025-10-14T19:13:43 < PlasmaHH> what the actual f
2025-10-14T19:15:18 < PlasmaHH> or am I miunderstanding how ipsr works?
2025-10-14T19:15:27 -!- hexo [~hexo@user/hexo] has quit [Remote host closed the connection]
2025-10-14T19:18:47 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 260 seconds]
2025-10-14T19:26:46 < PlasmaHH> mawk: indeed I am, looking deeper into the zephyr code I find that they subtract 16 from the ipsr value, so that was the point I was overlooking
2025-10-14T19:32:42 < mawk> ah!
2025-10-14T19:38:17 -!- hexo [~hexo@user/hexo] has joined ##stm32
2025-10-14T19:41:10 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has quit [Ping timeout: 245 seconds]
2025-10-14T19:54:22 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has joined ##stm32
2025-10-14T19:56:44 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-14T20:16:40 < mawk> qyx the datasheet of ATWINC1500 says there is a 380μA low power mode
2025-10-14T20:16:47 < mawk> I have to find how to trigger it
2025-10-14T20:17:07 < mawk> sleeping in-between N beacon intervals
2025-10-14T20:18:05 < mawk> but the datasheet is also a bunch of lies and referencing non-existing features or imaginary documents so might not exist 
2025-10-14T20:35:17 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-14T21:10:36 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-14T21:11:42 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-14T21:12:07 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-14T21:34:45 < Steffanx> Time to ask Richard for support mawk
2025-10-14T21:37:46 -!- infisx [~infisc@user/infisc] has quit [Ping timeout: 256 seconds]
2025-10-14T21:42:09 < mawk> he doesn't sell them
2025-10-14T21:50:14 -!- rgz [uid670983@user/rgz] has joined ##stm32
2025-10-14T21:54:17 < PlasmaHH> On bascially any chip you can trigger a low power sleep mode with a widlarizer
2025-10-14T22:04:19 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1de2:1399:afaf:228e] has quit [Quit: Leaving]
2025-10-14T22:08:13 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1de2:1399:afaf:228e] has joined ##stm32
2025-10-14T22:11:40 -!- NEYi [~NEYi@195.234.78.187] has quit [Quit: Leaving]
2025-10-14T22:22:10 < jbo> octorian, ah, you're here too o/
2025-10-14T22:23:51 -!- Livio [~livio@user/livio] has quit [Remote host closed the connection]
2025-10-14T22:49:24 < Steffanx> Is jbo here too?
2025-10-14T22:57:09 < mawk> of course
2025-10-14T22:57:35 < jbo> always
2025-10-14T23:04:10 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 246 seconds]
2025-10-14T23:19:46 -!- DudV2 [~dudv2@user/DudV2] has quit [Ping timeout: 256 seconds]
2025-10-14T23:21:22 -!- DudV2 [~dudv2@222-155-163-204-fibre.sparkbb.co.nz] has joined ##stm32
2025-10-14T23:24:12 < Steffanx> Ok thanks
2025-10-14T23:52:34 < jbo> you're welcome!
--- Day changed Wed Oct 15 2025
2025-10-15T00:09:17 < antto> zyp, my bootloader's .bin file is prepended with a header, it includes a hash checksum
2025-10-15T00:10:08 < mawk> yeah the powersave seems to work qyx 
2025-10-15T00:10:11 < antto> this is the 2nd bootloader i wrote from scratch, i'm kinda proud of myself (but i'm kinda lousy, so it's not too great after all)
2025-10-15T00:10:17 < mawk> I set it to wake up every 5 beacon intervals
2025-10-15T00:10:52 < mawk> and it stays at 3mA most of the time, peaks to 20mA once in a while
2025-10-15T00:11:27 < mawk> and this is for the whole board, not just the module; with the nrf in run mode
2025-10-15T00:15:50 < qyx> yeah that's much better
2025-10-15T00:16:09 < mawk> but then it takes a long time to respond to ping to 5 beacon intervals is a bit too aggressivbe
2025-10-15T00:16:19 < mawk> but it still eventually works
2025-10-15T00:16:53 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-15T00:17:26 < mawk> but it still eventually works
2025-10-15T00:17:28 < mawk> oops
2025-10-15T00:17:37 < mawk> I thought I was in the terminal
2025-10-15T00:18:42 < qyx> but beaconing in wifi is like what, 100/200 ms?
2025-10-15T00:19:38 < mawk> yeah my router is 100ms
2025-10-15T00:20:05 < qyx> so not that bad compared to the power required
2025-10-15T00:20:16 < mawk> you can make it even longer, then a proper router should buffer the frames until the device wakes up
2025-10-15T00:20:24 < qyx> also it doesn't go to power save immediately so downloading a bigger file should work
2025-10-15T00:20:49 < qyx> yes it should be that wmm support
2025-10-15T00:20:57 < qyx> afaik
2025-10-15T00:23:22 < mawk> yeah
2025-10-15T00:30:47 < mawk> the board I'm using is this https://makerdiary.com/products/pitaya-go
2025-10-15T00:30:55 < mawk> I took the device tree of the nrf52840 development kit and modified to have the proper pins and peripherals, and the wifi chip
2025-10-15T00:32:00 < qyx> oh I have seen that one, isn't it pretty old?
2025-10-15T00:32:11 < mawk> nordic's zephyr support got a lot better since the last time I tried, they made a vscode plugin which is pretty useful, with a visual device tree editor (but I didn't know about it so I did it by hand)
2025-10-15T00:32:17 < qyx> or was it red-pitaya?
2025-10-15T00:32:59 < mawk> I got it years ago so I suppose it's a bit old, but nrf52 is still pretty useful
2025-10-15T00:33:19 < mawk> red pitaya seems to be a radio thing
2025-10-15T00:33:56 < mawk> >Red Pitaya GEN 2 Available In 00 Days : 02 Hours : 26 Minutes : 26 Seconds
2025-10-15T00:34:00 < mawk> wow we're lucky
2025-10-15T00:38:47 < mawk> it's USB-C on the board but it's just a regular usb full-speed, and no PD
2025-10-15T00:41:52 < mawk> the PMIC accepts 5-10V to charge the battery, otherwise there is also a buck converter that bypasses the PMIC but idk how high it can go, it's not named on the schematic and it's too small to read the markings
2025-10-15T00:59:14 -!- octorian [octo@2600:3c00::f03c:91ff:fe93:a61c] has quit [Ping timeout: 260 seconds]
2025-10-15T01:00:39 -!- octorian [octo@2600:3c00::f03c:91ff:fe93:a61c] has joined ##stm32
2025-10-15T01:04:37 -!- nomorekaki [~nomorekak@37-136-166-42.rev.dnainternet.fi] has joined ##stm32
2025-10-15T01:04:55 < nomorekaki> dope crew
2025-10-15T01:06:51 < nomorekaki> antto: can't stop listening to Subway Shamans
2025-10-15T01:32:21 < karlp> hrm, anyone heard of m3l capacitors?
2025-10-15T01:32:29 < qyx> nope
2025-10-15T01:32:30 < karlp> seems to be an alternative "np0" type
2025-10-15T01:34:04 < karlp> ok, not _quite_ as flat tempco
2025-10-15T01:34:43 < karlp> 0.05% for m3l vs 30ppm for c0g vs 10/15% for x5r?
2025-10-15T01:34:54 < karlp> I want better curves to look at not half chinese pseudo datasheests
2025-10-15T01:35:11 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has quit [Ping timeout: 256 seconds]
2025-10-15T01:39:02 < nomorekaki> antto:
2025-10-15T01:39:03 < nomorekaki> https://www.youtube.com/watch?v=ZFspOYo8wWQ Stan Christ - Trepidation
2025-10-15T01:39:03 < nomorekaki> https://www.youtube.com/watch?v=i5CM8e6by4w 1992 - Alignment
2025-10-15T01:39:04 < nomorekaki> https://www.youtube.com/watch?v=LJYid2F8iDk Trudge - страсть [10PILLS010]
2025-10-15T01:44:13 < karlp> china upsell is great, cart is at $11 product, 14$ shipping.  "spend$39 more! save $8 on shipping!"
2025-10-15T01:47:29 < karlp> also, TIL about vishay "thermawick" parts. THJP
2025-10-15T01:48:13 < specing> karlp: I haven't opened ali in bloody ages now
2025-10-15T01:48:51 < specing> last time I was so annoyed by their gamefication of everything.. stuff blinking about, pages with truckload of images, search finds what ali wants you to find, ...
2025-10-15T01:49:32 < karlp> this is actually lcsc.com, but yeah, ali tries hard ot be weird as hell.
2025-10-15T01:49:36 < karlp> still no better options :|
2025-10-15T01:49:40 < karlp> it's far worse than it was of course
2025-10-15T01:49:45 < specing> I wish fasttech.com was still around, it was the only normal china shop
2025-10-15T01:53:07 < specing> anyone knows of any normal shop from china?
2025-10-15T02:06:45 -!- noarb [~noarb@user/noarb] has quit [Quit: ZNC 1.9.1+deb2+b3 - https://znc.in]
2025-10-15T02:09:37 -!- noarb [~noarb@user/noarb] has joined ##stm32
2025-10-15T02:53:14 -!- rgz [uid670983@user/rgz] has quit [Quit: Connection closed for inactivity]
2025-10-15T03:06:36 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1de2:1399:afaf:228e] has quit [Remote host closed the connection]
2025-10-15T03:19:18 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T03:23:11 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Remote host closed the connection]
2025-10-15T03:23:54 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T04:51:40 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-15T05:08:43 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Remote host closed the connection]
2025-10-15T05:12:48 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T05:20:27 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Max SendQ exceeded]
2025-10-15T05:27:16 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T06:10:45 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-15T06:44:13 -!- jerrycash [~jerrycash@user/jerrycash] has quit [Read error: Connection reset by peer]
2025-10-15T06:46:53 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Remote host closed the connection]
2025-10-15T06:51:23 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T06:58:26 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Max SendQ exceeded]
2025-10-15T07:02:20 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2025-10-15T07:03:24 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T07:09:46 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Remote host closed the connection]
2025-10-15T07:10:54 < antto> nomorekaki, >:)
2025-10-15T07:12:59 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T07:33:30 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2025-10-15T07:41:19 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Remote host closed the connection]
2025-10-15T07:43:22 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T08:04:49 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-15T08:05:51 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-15T08:06:15 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-15T08:10:28 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2025-10-15T08:16:12 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-15T08:27:06 -!- DudV2 [~dudv2@user/DudV2] has changed host
2025-10-15T08:36:04 -!- tomeaton17 [~tom@user/tomeaton17] has quit [Remote host closed the connection]
2025-10-15T08:36:24 -!- tom17 [~tom@user/tomeaton17] has joined ##stm32
2025-10-15T08:45:17 -!- qyx [~qyx@84.245.121.157] has quit [Ping timeout: 256 seconds]
2025-10-15T08:47:04 -!- qyx [~qyx@84.245.121.36] has joined ##stm32
2025-10-15T09:02:05 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-15T09:13:48 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Remote host closed the connection]
2025-10-15T09:21:18 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-15T09:34:29 < mawk> fasttech had all the good counterfeit ecigarette parts
2025-10-15T09:34:30 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T09:39:29 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Max SendQ exceeded]
2025-10-15T09:46:19 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T09:50:27 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Remote host closed the connection]
2025-10-15T09:52:32 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T09:56:42 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Max SendQ exceeded]
2025-10-15T10:00:55 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T10:10:27 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has joined ##stm32
2025-10-15T11:04:43 -!- nomorekaki [~nomorekak@37-136-166-42.rev.dnainternet.fi] has quit [Quit: Client closed]
2025-10-15T11:23:29 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-15T11:53:50 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Remote host closed the connection]
2025-10-15T11:57:08 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T12:22:12 -!- tom17 is now known as tomeaton17
2025-10-15T12:57:53 -!- c10ud [~c10ud@user/c10ud] has quit [Read error: Connection reset by peer]
2025-10-15T13:04:45 < karlp> fucking gunzip -f doesn't actualyl force it.
2025-10-15T13:04:57 < karlp> it still says " oh noes, file didn't end in .gz, .... nooooo"
2025-10-15T13:06:51 < ventYl> cat $file | gunzip ?
2025-10-15T13:06:57 < ventYl> - 
2025-10-15T13:07:10 < karlp> apparently the right thing is actually "ar -x" even though it says "gzip compressed"
2025-10-15T13:07:21 < karlp> whatever, on winndows or somewhere I used to be ablt ot just right click and open .debs
2025-10-15T13:09:36 < ventYl> yeah, tar is rather smart on figuring out how the shit was compressed and it doesn't care much if content actually is or is not TAR
2025-10-15T13:09:55 < karlp> well, yeah, I tried "tar -xf" first, that normally magically does the right thing, but it just ignored me.
2025-10-15T13:11:12 < karlp> fuckin lol, this deb includes a deb inside that has to run as well.
2025-10-15T13:11:15 < karlp> nonces.
2025-10-15T13:14:04 -!- c10ud [~c10ud@user/c10ud] has joined ##stm32
2025-10-15T13:19:23 < qyx> is karl discovering the world
2025-10-15T13:19:45 < karlp> no, just tried to have "a short little distraction" and install the infineon tools for an upcoming project.
2025-10-15T13:21:12 -!- NEYi_ [~NEYi@195.234.78.187] has joined ##stm32
2025-10-15T13:22:42 < BrainDamage> ah, I too have short tasks to break monotony that span months
2025-10-15T13:24:06 -!- NEYi [~NEYi@195.234.78.187] has quit [Ping timeout: 256 seconds]
2025-10-15T13:35:50 < karlp> it's wow, they've made this virtually impossible to install by hand.
2025-10-15T13:36:04 < karlp> it'ðs just "nope, you're giving us sudo, and we're goign to do "stuff"" 
2025-10-15T13:36:22 < karlp> ok. let's have a different break instead then :)
2025-10-15T13:45:16 < ventYl> infineon smells like super garbage
2025-10-15T13:46:01 < ventYl> i guess that 50+% of their income is automotive, so they *have* to be super garbage
2025-10-15T13:50:42 < qyx> yesterday customer asked "can I update tie firmware using a usb stick?"
2025-10-15T13:51:32 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2025-10-15T14:01:26 < karlp> ventYl: it's great, we bought a commercial ethercat slave stack to use with infineon cpus, and they just got bought by nxp :)
2025-10-15T14:01:41 < karlp> who have precisely one, brand new, cpu with ethercat hw...
2025-10-15T14:21:58 < ventYl> who got bought? stack vendor?
2025-10-15T14:28:49 < karlp> yeh, port gmbh
2025-10-15T14:29:08 < karlp> it was pretty neat, I found the old "decision docs" on choosing a stack,
2025-10-15T14:29:25 < karlp> they listed 2 open source stacks, didn't even evaluate them, just went and bought onee from ze germans.
2025-10-15T14:29:32 < karlp> and now all the emails are bouncing 
2025-10-15T14:30:23 < ventYl> is your $company also german?
2025-10-15T14:32:06 < karlp> no, we're "everywhere" jbtmarel
2025-10-15T14:35:11 -!- NEYi__ [~NEYi@195.234.78.187] has joined ##stm32
2025-10-15T14:37:37 -!- NEYi_ [~NEYi@195.234.78.187] has quit [Ping timeout: 246 seconds]
2025-10-15T16:25:55 -!- duude__- [~duude__@user/duude/x-4676560] has joined ##stm32
2025-10-15T16:26:46 -!- zyp_ [zyp@zyp.no] has joined ##stm32
2025-10-15T16:28:14 -!- Alexer- [~alexer@alexer.net] has joined ##stm32
2025-10-15T16:32:24 -!- Netsplit *.net <-> *.split quits: duude__, Alexer, Shaun, octorian, karlp, nohit, infisc, zyp, infisd
2025-10-15T16:33:05 -!- Shaun [~shaun@mail.oneil.me.uk] has joined ##stm32
2025-10-15T16:33:05 -!- Netsplit over, joins: infisc, octorian, nohit, karlp
2025-10-15T16:33:11 -!- nohit [sid334887@id-334887.tinside.irccloud.com] has quit [Max SendQ exceeded]
2025-10-15T16:33:11 -!- Shaun [~shaun@mail.oneil.me.uk] has quit [Max SendQ exceeded]
2025-10-15T16:33:22 -!- noarb [~noarb@user/noarb] has quit [Ping timeout: 260 seconds]
2025-10-15T16:33:25 -!- duude__- is now known as duude__
2025-10-15T16:33:39 -!- nohit [sid334887@id-334887.tinside.irccloud.com] has joined ##stm32
2025-10-15T16:35:33 -!- Shaun [~shaun@user/shaun] has joined ##stm32
2025-10-15T16:36:03 -!- noarb [~noarb@user/noarb] has joined ##stm32
2025-10-15T16:36:38 -!- grindhold_ [~quassel@mail.skarphed.org] has joined ##stm32
2025-10-15T16:36:48 -!- teknix [~unknown@user/hsv] has quit [Ping timeout: 256 seconds]
2025-10-15T16:36:52 -!- grindhold_ [~quassel@mail.skarphed.org] has quit [Client Quit]
2025-10-15T16:38:24 -!- teknix [~unknown@user/hsv] has joined ##stm32
2025-10-15T16:44:00 < qyx> ok I have a weird issue
2025-10-15T16:44:17 < qyx> I have a piece of code writing and reading from a serial, it is in production for idk 3 years, on various hardware
2025-10-15T16:44:50 < qyx> now it sends the packet over serial correctly, the device responds, I can see it on the scope but select() returns timeout
2025-10-15T16:45:12 < qyx> if I use a serial terminal to check if the device responds, I can see the echo
2025-10-15T16:45:38 < qyx> fuser/lsof shows no other processes accessing /dev/ttyACM0
2025-10-15T16:45:48 < qyx> the software runs with root permissions
2025-10-15T16:46:16 < qyx> I tried setting struct timeval to various values, the issue perists
2025-10-15T16:47:17 < qyx> atm I am using stlinkv3 as a serial terminal
2025-10-15T16:48:01 < qyx> *bridge
2025-10-15T16:54:26 < c10ud> maybe some os-level tty crap is mitm-ing your device
2025-10-15T17:00:15 < qyx> wot I run tio /dev/ttyACM0 -b 115200 in parallel and then quit it, now it works
2025-10-15T17:00:30 < qyx> I guess the port has hw flow control enabled by default or sameshit
2025-10-15T17:03:09 < qyx> flags returned by stty are the same before and after tio is run
2025-10-15T17:09:06 < jpa-> make sure you don't have modemmanager installed, it tends to leave ports in weird states
2025-10-15T17:14:39 < qyx> this is fucking insane, I had half million of different flags to set raw mode and was missing *CS8*
2025-10-15T17:15:13 < qyx> this finally works https://paste.jvnv.net/view/TcFUc
2025-10-15T17:15:13 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Remote host closed the connection]
2025-10-15T17:15:48 < qyx> my AI friend was actually helpful this time
2025-10-15T17:16:12 < qyx> now back to 1 Mbaud
2025-10-15T17:18:32 < c10ud> so, working on various hardware -- by luck :)
2025-10-15T17:18:50 < qyx> apparently now the default is not 8 bit
2025-10-15T17:19:28 < qyx> at least not for stlink bridge
2025-10-15T17:19:44 < qyx> intel, rockchip and imx works
2025-10-15T17:19:47 < qyx> sama5d27 too
2025-10-15T17:20:09 < qyx> ft232, cp2102 bridges too
2025-10-15T17:23:31 < qyx> 2 hours wasted
2025-10-15T17:24:29 < c10ud> btw #define   CS8		0x00000030, how can it work without cs8?
2025-10-15T17:24:53 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T17:26:06 < c10ud> unless your ai friend added the cflag clear and it's not part of your original code
2025-10-15T17:29:09 < qyx> no other cflag, it starts working after adding CS8
2025-10-15T17:29:25 < qyx> also, transmit was working correctly in 8 bit mode
2025-10-15T17:29:43 < qyx> the device received valid data and even decrypted it and responded
2025-10-15T17:29:53 < mawk> you brain will leak out of your skull if you keep using AI
2025-10-15T17:29:55 < mawk> qyx I assume the readymade function cfmakeraw() wasn't raw enough for you?
2025-10-15T17:29:57 < mawk> so you don't have to mess with flags manually 
2025-10-15T17:30:04 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Remote host closed the connection]
2025-10-15T17:30:48 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T17:30:50 < qyx> for some reason I couldn't use termios, I had to use termios2
2025-10-15T17:32:18 < qyx> oh yes custom baud rates
2025-10-15T17:32:52 < qyx> otherwise you would hit this https://stackoverflow.com/questions/37710525/including-termios-h-and-asm-termios-h-in-the-same-project
2025-10-15T17:33:30 < qyx> hm but at the end I implemented the termios/termios2 fix
2025-10-15T17:33:32 < qyx> so idk
2025-10-15T17:35:14 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Remote host closed the connection]
2025-10-15T17:39:41 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T17:41:27 < c10ud> if you dont set cs8 you get cs5 as far as I see... probably <other devices> don't implement cs5 and fallback to cs7
2025-10-15T17:41:29 < c10ud> cs8*
2025-10-15T17:41:36 < c10ud> while stlink really does it
2025-10-15T17:41:57 < c10ud> now, trasmitting working, otoh..
2025-10-15T17:44:34 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Max SendQ exceeded]
2025-10-15T17:45:24 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T17:46:17 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Remote host closed the connection]
2025-10-15T17:53:56 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T17:55:58 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Remote host closed the connection]
2025-10-15T17:59:33 -!- zyp_ is now known as zyp
2025-10-15T18:02:01 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-15T18:02:32 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T18:06:07 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Remote host closed the connection]
2025-10-15T18:06:52 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T18:42:18 -!- System_Error [~SystemErr@user/systemerror] has quit [Ping timeout: 272 seconds]
2025-10-15T19:18:19 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Remote host closed the connection]
2025-10-15T19:19:57 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-15T19:29:31 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T19:29:34 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Remote host closed the connection]
2025-10-15T19:31:09 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T19:35:29 < mawk> the stm32wb55 is in my mailbox 
2025-10-15T19:35:40 < mawk> I'll try to make it talk with the nrf52
2025-10-15T19:36:01 < mawk> last time I tried 802.15.4 it was a huge pain but maybe it was the mrf24j40ma's fault
2025-10-15T19:36:18 < mawk> I even remember reading parts of the 802.15.4 spec
2025-10-15T19:38:04 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Remote host closed the connection]
2025-10-15T19:40:51 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T20:06:00 < mawk> there's nobody in #zephyrproject
2025-10-15T20:06:02 < mawk> concerning 
2025-10-15T20:10:49 < ventYl> nrf52 is on my todo list as well
2025-10-15T20:11:01 < ventYl> i wonder how bad will its hacky SDK work with full memory isolation
2025-10-15T20:11:07 < ventYl> assumption is that it won't work
2025-10-15T20:11:20 < mawk> there's no hacky SDK anymore 
2025-10-15T20:11:26 < mawk> it's all zephyr
2025-10-15T20:11:38 < ventYl> for nrf52 the nrf5 sdk works
2025-10-15T20:11:41 < mawk> the old sdk is deprecated and unmaintained 
2025-10-15T20:11:47 < mawk> yeah it works
2025-10-15T20:11:52 < ventYl> and they released zephyr-free version of their zephyr-based SDK recently
2025-10-15T20:12:00 < ventYl> like, two or three weeks ago
2025-10-15T20:12:13 < ventYl> the SDK is not hacky because they wanted to make it hacky
2025-10-15T20:12:26 < ventYl> they had to make it hacky because the CPU itself is a broken piece of shit
2025-10-15T20:12:32 < mawk> you mean the bare metal thing?
2025-10-15T20:12:47 < ventYl> yeah, I've seen the announcement but didn't study it yet.
2025-10-15T20:12:48 < mawk> it's just a barebones thing for one board for BLE apparently 
2025-10-15T20:12:56 < mawk> without a rtos
2025-10-15T20:13:08 < mawk> so there should be no issue adapting it to memory isolation with your own rtos
2025-10-15T20:13:20 < ventYl> well, with nrf52 there is
2025-10-15T20:13:40 < ventYl> pretty much all peripherals are fundamentally broken, so you have to apply all kind of weird hacks to make them work
2025-10-15T20:13:49 < mawk> >In parallel with Zephyr-RTOS based application development, there is the additional nRF Connect SDK Bare Metal option for developing simple Bluetooth LE applications on the nRF54L Series, that do not benefit from an RTOS or advanced features. This offers developers additional flexibility to choose the software development approach that better fits
2025-10-15T20:13:49 < mawk>  their use case.
2025-10-15T20:13:53 < mawk> why broken
2025-10-15T20:14:03 < ventYl> like, SPI can't clock 1-byte message. if you make it to do so, it will actually clock out two bytes, second being some random garbage
2025-10-15T20:14:06 < mawk> some peripherals have erratas but stm32 do as well
2025-10-15T20:14:14 < ventYl> so you have to use event unit to stop SPI from clocking out the second byt
2025-10-15T20:14:26 < mawk> yeah it's fixed automatically for you in the sdk
2025-10-15T20:14:27 < ventYl> thus, SPI driver is internally issuing calls to event driver
2025-10-15T20:14:32 < mawk> and it's just for SPIM, with DMA
2025-10-15T20:14:45 < mawk> if it's regular SPI there's not that 1-byte issue
2025-10-15T20:14:59 < ventYl> if you give the SPI driver access just to SPI peripherals, it will poop itself at runtime while installing hack into event unit
2025-10-15T20:15:03 < mawk> but like I said ST has lots of them too, and HAL silently fixes them
2025-10-15T20:15:24 < ventYl> there is no regular SPI with nrf52, everything is easydma
2025-10-15T20:15:39 < ventYl> at least not officially. i think unofficially you can still somehow use the nrf51-style APIs
2025-10-15T20:15:50 < ventYl> registers do exist(?) they are just not documented
2025-10-15T20:15:57 < ventYl> or some similar shady kind of business
2025-10-15T20:16:40 < mawk> yes it has a SPI peripheral separate from the SPIM peripheral 
2025-10-15T20:17:05 < mawk> https://docs.nordicsemi.com/bundle/ps_nrf52840/page/spi.html
2025-10-15T20:17:23 < ventYl> there are like 105 such critical issues in the hardware. which is suprisingly large number of erratas for chip which basically only has SPI, I2C, UART, ADC and radio
2025-10-15T20:22:43 -!- DudV2 [~dudv2@user/DudV2] has quit [Ping timeout: 246 seconds]
2025-10-15T20:24:47 -!- DudV2 [~dudv2@222-155-163-204-fibre.sparkbb.co.nz] has joined ##stm32
2025-10-15T21:25:40 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Remote host closed the connection]
2025-10-15T21:39:14 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T21:46:42 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Remote host closed the connection]
2025-10-15T21:49:06 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T21:53:59 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Max SendQ exceeded]
2025-10-15T21:57:19 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-15T22:00:15 -!- specing_ [~specing@user/specing] has joined ##stm32
2025-10-15T22:00:15 -!- specing [~specing@user/specing] has quit [Killed (NickServ (GHOST command used by specing_))]
2025-10-15T22:02:31 -!- specing_ is now known as specing
2025-10-15T22:24:17 -!- esden_ [sid32455@id-32455.hampstead.irccloud.com] has joined ##stm32
2025-10-15T22:25:40 -!- rkta_ [~rkta@user/rkta] has joined ##stm32
2025-10-15T22:28:58 -!- esden [sid32455@id-32455.hampstead.irccloud.com] has quit [Ping timeout: 244 seconds]
2025-10-15T22:28:59 -!- rkta [~rkta@user/rkta] has quit [Remote host closed the connection]
2025-10-15T22:28:59 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 244 seconds]
2025-10-15T22:28:59 -!- esden_ is now known as esden
2025-10-15T22:40:20 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-15T23:08:00 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has quit [Ping timeout: 252 seconds]
2025-10-15T23:10:45 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 252 seconds]
2025-10-15T23:13:11 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-15T23:13:24 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-15T23:15:49 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has joined ##stm32
2025-10-15T23:31:19 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 240 seconds]
--- Day changed Thu Oct 16 2025
2025-10-16T00:20:45 < ColdKeybo[a]rd> What do you guys use for C code linting? If anything?
2025-10-16T00:21:01 < ColdKeybo[a]rd> clang-tidy is such a PITA on Windows for some reason
2025-10-16T00:21:09 < ventYl> clang-tidy
2025-10-16T00:21:21 < ventYl> it ran on windows for us mostly seamlessly
2025-10-16T00:21:49 < ventYl> activating it was like one line of script
2025-10-16T00:26:37 < specing> ColdKeybo[a]rd: use it inside WSL?
2025-10-16T00:27:11 < specing> I heard MS now provides this layer for those whose employers can't provide them with a proper workstation :P
2025-10-16T00:35:39 -!- infisx [~infisc@user/infisc] has joined ##stm32
2025-10-16T00:37:07 < ColdKeybo[a]rd> I used clang-tidy a while ago... now I'm trying to run it and keep getting some error about "error: 'vcruntime.h' file not found [clang-diagnostic-error]"
2025-10-16T00:37:31 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Ping timeout: 244 seconds]
2025-10-16T00:39:52 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 260 seconds]
2025-10-16T00:40:49 < ventYl> that's due to the fact that LLVM is now compatible with Visual C runtime. If you don't pass sufficient arguments to LLVM so that it can figure out you are cross-compiling, it assumes you do native build and it expects to find Visual C runtime headers
2025-10-16T00:46:58 < ColdKeybo[a]rd> I guess that's it... I have to figure out how to configure it for arm-none-eabi
2025-10-16T00:49:44 < ventYl> -target arm-none-eabi
2025-10-16T00:50:11 < ventYl> then it will also need path to C standard library used in the project
2025-10-16T00:50:27 < ventYl> https://github.com/ventZl/cmrx/blob/master/cmake/clang-tidy.cmake#L30
2025-10-16T00:51:36 < ColdKeybo[a]rd> That's perfect! Thanks! Let me give it a try
2025-10-16T00:52:27 < ventYl> although this script does not pass -target anywhere. it works on ubuntu-latest runners if newlib is installed
2025-10-16T00:52:38 < ventYl> fuck windows
2025-10-16T01:01:48 -!- teknix_ [~unknown@user/hsv] has joined ##stm32
2025-10-16T01:01:51 < ColdKeybo[a]rd> I'll give it a go. It's also nice that this example uses it through cmake, very convenient
2025-10-16T01:02:47 < ventYl> you're welcome
2025-10-16T01:04:32 -!- teknix [~unknown@user/hsv] has quit [Ping timeout: 256 seconds]
2025-10-16T01:11:09 < ventYl> xhci_hcd 0000:02:00.0: HC died; cleaning up
2025-10-16T01:11:13 < ventYl> mmmmmkay
2025-10-16T01:14:23 -!- teknix [~unknown@user/hsv] has joined ##stm32
2025-10-16T01:17:15 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Ping timeout: 252 seconds]
2025-10-16T01:17:41 -!- Netsplit *.net <-> *.split quits: PlasmaHH, teknix_
2025-10-16T01:20:13 -!- blathijs [~matthijs@tika.stderr.nl] has quit [Ping timeout: 246 seconds]
2025-10-16T01:20:55 -!- teknix [~unknown@user/hsv] has quit [Ping timeout: 246 seconds]
2025-10-16T01:22:06 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-16T01:26:09 -!- teknix [~unknown@user/hsv] has joined ##stm32
2025-10-16T01:27:41 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Remote host closed the connection]
2025-10-16T01:28:25 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-16T01:34:09 -!- blathijs [~matthijs@tika.stderr.nl] has joined ##stm32
2025-10-16T01:38:20 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Remote host closed the connection]
2025-10-16T01:39:10 < karlp> ok, ads124s08 board sent off.
2025-10-16T01:39:14 < karlp> spend to glory
2025-10-16T01:39:54 < qyx> oh great
2025-10-16T01:39:59 < qyx> that was the one I wanted to use
2025-10-16T01:40:06 < qyx> but then covid hit
2025-10-16T01:41:44 < ventYl> this little fucker has reset command which apparently does nothing
2025-10-16T01:43:57 < karlp> qyx: I still need to get a more rigourous methodology for acually comparing these things :)
2025-10-16T01:44:07 < karlp> but yeah, one step at a time.
2025-10-16T01:44:27 < karlp> next one is ads1235(?) to compare ac excitation 
2025-10-16T01:44:47 < karlp> but I think I will have problems having test gear good enough to compare the difference...
2025-10-16T01:44:53 < qyx> karlp messing with my fu
2025-10-16T01:45:03 < karlp> fu?
2025-10-16T01:45:04 < qyx> we can cross compare later
2025-10-16T01:45:15 < qyx> my bridge-fu
2025-10-16T01:45:28 < karlp> I can send you a couple of these boards if they're interesting?
2025-10-16T01:45:33 < karlp> https://kicanvas.org/?github=https%3A%2F%2Fgithub.com%2Fkarlp%2Fexp-iio-ads124s08
2025-10-16T01:45:50 < qyx> I am interested in results to steer my development a bit :P
2025-10-16T01:46:03 < qyx> I am lazy to measure but you definitely will
2025-10-16T01:46:05 < karlp> I put footprints for 805 and 1206 diff caps, and am combinging an order with lcsc to try some different values.
2025-10-16T01:46:37 < karlp> oh, I haven't been able to use the "fancy" load cell emulator at work yet, as it's away for calibration.
2025-10-16T01:46:48 < karlp> hopefully next week.
2025-10-16T01:46:50 < qyx> but we could at least make some references to compare shit
2025-10-16T01:47:16 < qyx> I have a manually switched bridge simulator too
2025-10-16T01:47:20 < karlp> yeah, my load cell emulator is awesome for whati t is, but it's a pretty shit tool for measuring and ADC.
2025-10-16T01:48:01 < karlp> I have this ranger5, which is quite a bit quieter than my emulator, but ... testing is harddddd :)
2025-10-16T01:48:24 < karlp> fucking c0g 220nF caps are pricy :)
2025-10-16T01:48:35 < karlp> 30c each! crazy!
2025-10-16T01:49:50 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-16T01:50:47 < karlp> was like 15% of bom cost...
2025-10-16T01:53:00 -!- infisx [~infisc@user/infisc] has quit [Ping timeout: 252 seconds]
2025-10-16T01:55:08 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Remote host closed the connection]
2025-10-16T01:55:53 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-16T01:57:55 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-16T02:03:12 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Max SendQ exceeded]
2025-10-16T02:07:52 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has joined ##stm32
2025-10-16T03:36:30 < ColdKeybo[a]rd> Can you in CMake get _all_ the includes that are going to be passed to the compiler?
2025-10-16T03:36:56 < ColdKeybo[a]rd> I know there is "get_target_property(TARGET_INCLUDES ${PROJECT_NAME} INCLUDE_DIRECTORIES)" but I guess can you expand it to... everything that is being built?
2025-10-16T03:37:37 < ventYl> why would you do that?
2025-10-16T03:38:39 < ventYl> that information is not even known at cmake configure time
2025-10-16T03:40:19 < ColdKeybo[a]rd> The clang-tidy is being fussy about not being able to find all the includes
2025-10-16T03:41:00 < ventYl> https://cmake.org/cmake/help/latest/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html
2025-10-16T03:41:19 < ventYl> set this to on, it will create compile_commands.json and silence most of clang-tidy complaints
2025-10-16T03:45:10 < ColdKeybo[a]rd> Huh, that did the trick! Thank you!
2025-10-16T03:45:40 < ventYl> yeah, clang-tidy documentation sucks
2025-10-16T03:45:43 < ColdKeybo[a]rd> I even made a macro to pull all the includes and add them as --extra-arg. Felt so proud :D
2025-10-16T03:46:02 < ColdKeybo[a]rd> The documentation/examples could definitely use some love
2025-10-16T03:46:15 < ventYl> that --extra-arg is even completely undocumented
2025-10-16T03:46:33 < ventYl> I found it somewhere in some SO thread with a comment that someone found that in source code, or something
2025-10-16T03:55:00 < ventYl> you have basically validated that my clang tidy infrastructure will run on windows if anyone ever will be so wild to run it
2025-10-16T04:06:43 -!- infisx [~infisc@user/infisc] has joined ##stm32
2025-10-16T04:06:48 -!- infisd [~infisc@user/infisc] has quit [Remote host closed the connection]
2025-10-16T04:06:49 -!- ventYl [~ventyl@adsl-dyn152.78-98-151.t-com.sk] has quit [Ping timeout: 246 seconds]
2025-10-16T04:07:00 -!- ventYl [~ventyl@adsl-dyn152.78-98-151.t-com.sk] has joined ##stm32
2025-10-16T04:18:03 < ColdKeybo[a]rd> Runs like a charm, at the moment at least :)
2025-10-16T04:25:22 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:d936:7bd6:27c7:630e] has quit [Ping timeout: 246 seconds]
2025-10-16T04:26:21 -!- jfsimon1981 [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has joined ##stm32
2025-10-16T04:32:22 -!- jfsimon1981 [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has quit [Remote host closed the connection]
2025-10-16T04:37:27 -!- jfsimon1981 [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has joined ##stm32
2025-10-16T05:01:43 -!- jfsimon1981 [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has quit [Remote host closed the connection]
2025-10-16T05:05:38 -!- jfsimon1981 [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has joined ##stm32
2025-10-16T05:05:47 -!- jfsimon1981 [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has quit [Remote host closed the connection]
2025-10-16T05:06:32 -!- jfsimon1981 [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has joined ##stm32
2025-10-16T05:44:07 -!- rkta_ [~rkta@user/rkta] has quit [Ping timeout: 246 seconds]
2025-10-16T05:44:16 -!- rkta [~rkta@user/rkta] has joined ##stm32
2025-10-16T05:51:06 < qyx> antto: you were asking about update speeds
2025-10-16T05:51:16 < qyx> Erase: 100%|███████████████████████████████████████████████████████████████████████| 64.0k/64.0k [00:01<00:00, 48.5kB/s]
2025-10-16T05:51:20 < qyx> Upload: 100%|██████████████████████████████████████████████████████████████████████| 31.2k/31.2k [00:04<00:00, 6.72kB/s]
2025-10-16T05:51:34 < qyx> that's over a 250 kBaud serial
2025-10-16T05:52:49 < qyx> also with a pretty complex chain of protocols, it goes from python over ipv6, then encrypted over the serial
2025-10-16T05:53:28 < qyx> not bothering to optimize it more
2025-10-16T05:57:15 < qyx> the real flashing is done afterwards in the bootloader https://paste.jvnv.net/view/xjBlp
2025-10-16T05:58:00 -!- uyyye [~uyyye@2600:4041:5b26:d900:2af3:5f6:7726:9b4d] has joined ##stm32
2025-10-16T06:05:02 -!- jfsimon1981 [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has quit [Remote host closed the connection]
2025-10-16T06:05:50 -!- jfsimon1981 [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has joined ##stm32
2025-10-16T06:11:17 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-16T06:37:10 -!- NEYi__ [~NEYi@195.234.78.187] has quit [Read error: Connection reset by peer]
2025-10-16T07:25:51 -!- jfsimon1981 [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has quit [Remote host closed the connection]
2025-10-16T07:31:24 -!- jfsimon1981 [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has joined ##stm32
2025-10-16T07:43:56 -!- jfsimon1981 [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has quit [Remote host closed the connection]
2025-10-16T08:01:07 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has joined ##stm32
2025-10-16T08:17:31 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-16T08:39:04 -!- DudV2 [~dudv2@user/DudV2] has changed host
2025-10-16T09:07:36 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-16T09:18:52 -!- infisx [~infisc@user/infisc] has quit [Remote host closed the connection]
2025-10-16T09:19:12 -!- infisx [~infisc@user/infisc] has joined ##stm32
2025-10-16T09:26:56 -!- infisc_ [uid692580@user/infisc] has joined ##stm32
2025-10-16T09:28:46 -!- infisc [uid692580@user/infisc] has quit [Ping timeout: 246 seconds]
2025-10-16T09:28:47 -!- infisc_ is now known as infisc
2025-10-16T09:39:45 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has quit [Remote host closed the connection]
2025-10-16T09:42:17 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has joined ##stm32
2025-10-16T09:45:15 -!- martinmoene_ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 256 seconds]
2025-10-16T09:57:21 -!- blathijs [~matthijs@tika.stderr.nl] has quit [Ping timeout: 246 seconds]
2025-10-16T09:58:38 -!- blathijs [~matthijs@tika.stderr.nl] has joined ##stm32
2025-10-16T10:02:47 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-16T10:02:56 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Read error: Connection reset by peer]
2025-10-16T10:13:10 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has joined ##stm32
2025-10-16T10:28:54 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has joined ##stm32
2025-10-16T10:30:15 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has quit [Remote host closed the connection]
2025-10-16T10:31:00 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has joined ##stm32
2025-10-16T11:09:15 < mrec_> I think the packaging devision of the STM group needs some education in how packaging should be done, and they can team up with their software guys to learn the very basics of it.
2025-10-16T11:09:23 < mrec_> chip packaging*
2025-10-16T11:10:25 < mrec_> it's an old annoying topic
2025-10-16T11:15:41 < mrec_> in stm32cube, left top of the text there should be a pin identification circle; in reality no circle there, right top there is an embossed circle and left bottom.
2025-10-16T11:19:08 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has quit [Remote host closed the connection]
2025-10-16T11:20:53 < jpa-> mrec_: it's worse than that, on the chip itself the text is usually different orientation than STM32Cube shows it
2025-10-16T11:22:38 < jpa-> https://jpa.kapsi.fi/stuff/pix/stm32_orientation.png   and often you have three different types of circles to choose between ;)
2025-10-16T11:24:27 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has joined ##stm32
2025-10-16T11:24:36 < ventYl> similar to this: https://memeguy.com/photos/images/choose-wisely-189760.jpg :)
2025-10-16T11:25:14 < ventYl> true circle will bring the function, false will release the spirit of device :)
2025-10-16T11:27:49 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has quit [Max SendQ exceeded]
2025-10-16T11:29:04 < mrec_> ventYl: very well said haha
2025-10-16T11:31:06 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has joined ##stm32
2025-10-16T11:31:28 < mrec_> today is not a happy day... I turned on the CNC and ... all in chinese
2025-10-16T11:31:52 < ventYl> CCP sends you a signal
2025-10-16T11:32:02 < mrec_> sorry japanese
2025-10-16T11:33:00 < mrec_> all looks the same if you only look at it for one second, I switched it off and ripped out the controller now need to drive to Mitsubishi again. I should add a logic analyser to the extension card and check what key they use to unlock the parameters
2025-10-16T11:33:19 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has quit [Remote host closed the connection]
2025-10-16T11:33:38 < mrec_> we just went there a month ago and replaced the batteries, and now the battery is empty again.
2025-10-16T11:34:04 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has joined ##stm32
2025-10-16T11:35:01 < qyx> ventYl: lold
2025-10-16T11:47:14 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has quit [Remote host closed the connection]
2025-10-16T11:58:11 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has joined ##stm32
2025-10-16T11:59:18 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has quit [Remote host closed the connection]
2025-10-16T12:00:05 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has joined ##stm32
2025-10-16T12:35:52 < tomeaton17> the paper is coming today
2025-10-16T12:42:19 < Steffanx> New toilet paper?
2025-10-16T12:42:39 < tomeaton17> the newspaper
2025-10-16T12:42:46 < tomeaton17> I suppose could be the same thing
2025-10-16T13:17:16 < ventYl> mrec_: actually one of japanese scripts is chineese, because japanese didn't have written form of their language for quite some time
2025-10-16T14:04:45 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-16T14:05:54 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-16T14:06:18 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-16T14:14:12 -!- uyyye [~uyyye@2600:4041:5b26:d900:2af3:5f6:7726:9b4d] has quit [Ping timeout: 260 seconds]
2025-10-16T14:24:52 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has quit [Remote host closed the connection]
2025-10-16T14:29:01 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has joined ##stm32
2025-10-16T15:03:43 < infisc> https://x.com/_trish_xD/status/1978440272426975691
2025-10-16T15:04:15 < tomeaton17> infisc: anime profile picture detected, opinion rejected
2025-10-16T15:11:38 < karlp> now who's being a judgemental cunt? :)
2025-10-16T15:12:12 < karlp> in other news, I bought a gd32vw5 eval board last time I was shopping on lcsc, was like $2.  just went and got all the gd docs and examples.
2025-10-16T15:12:37 < karlp> they have an api guide for the wifi and btle, but... I can't find any examples, nor the blobs you're meant to use.
2025-10-16T15:12:49 < karlp> might explain why the chips themselves dont' exist...
2025-10-16T15:20:05 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-16T15:20:09 < tomeaton17> karlp: lol where did that come from
2025-10-16T15:20:20 < tomeaton17> did I say something before
2025-10-16T15:20:27 < karlp> you were calling me names the other day for being as judgemental as you :)
2025-10-16T15:20:57 < tomeaton17> karlp: was I?
2025-10-16T15:22:43 < tomeaton17> karlp: was that in relation to the "how pleasant" comment haha
2025-10-16T15:23:16 < tomeaton17> I can be rather dry
2025-10-16T15:26:17 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-16T16:02:07 -!- infisx [~infisc@user/infisc] has quit [Ping timeout: 260 seconds]
2025-10-16T16:13:24 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-16T16:18:09 -!- infisx [~infisc@user/infisc] has joined ##stm32
2025-10-16T16:19:42 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-16T16:42:26 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has quit [Remote host closed the connection]
2025-10-16T16:45:12 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has joined ##stm32
2025-10-16T16:49:48 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has quit [Max SendQ exceeded]
2025-10-16T16:53:22 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has joined ##stm32
2025-10-16T16:56:01 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has quit [Remote host closed the connection]
2025-10-16T17:03:17 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has joined ##stm32
2025-10-16T17:07:04 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has quit [Remote host closed the connection]
2025-10-16T17:09:20 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has joined ##stm32
2025-10-16T17:59:24 < qyx> hey, anyone played with STM32 update from android?
2025-10-16T18:00:08 < qyx> I know StLinkP works with stlink over swd
2025-10-16T18:00:30 < qyx> but now i am trying to find something with DFU support using a c-c cable
2025-10-16T18:01:03 < karlp> lol you want usb host on android? with "not keyboard/mouse" ?
2025-10-16T18:01:06 < karlp> sounds spicy
2025-10-16T18:01:47 < karlp> well, if otg works otg works I guess...
2025-10-16T18:02:25 < karlp> https://devanlai.github.io/webdfu/dfu-util/ ? :)
2025-10-16T18:02:31 < karlp> allegedly works in chrome on android....
2025-10-16T18:21:12 < qyx> I already used different kinds of serial converters on android, also mass storage works too
2025-10-16T18:21:21 < qyx> oh nice find
2025-10-16T18:22:49 < qyx> thats great, I can add a clicky in my web file list shit with compiled firmwares
2025-10-16T18:22:57 < qyx> to flash the selected one
2025-10-16T18:23:51 < karlp> yeah, having it on a github page means you get functional https so all teh weird webX shits work ok.
2025-10-16T18:24:53 < qyx> customer feature request "allow monkey to unbrick the device" half dun then
2025-10-16T18:26:31 < qyx> yesterday I finished my part of "allow monkey to update firmware using our web admin"
2025-10-16T18:46:35 < englishman> i tried to update a competitor's instrument yesterday using their homebrew dfu written in .NET 4, it never ended up working and all the error messages had spelling errors, made me feel not so bad about our own software
2025-10-16T18:51:15 < ventYl> :>
2025-10-16T18:53:25 < tomeaton17> englishman: is it chinesium?
2025-10-16T18:58:48 < englishman> no
2025-10-16T18:59:31 < englishman> chinese software would have worked, but kept the spelling errors
2025-10-16T19:03:27 < specing> lol
2025-10-16T19:12:25 < karlp> infineon has "DFU" support, but it's.... not usb...
2025-10-16T19:12:30 < karlp> like, ffs guys
2025-10-16T19:14:39 < ventYl> CAN?
2025-10-16T19:16:27 < karlp> can, uart, i2c or something, yeah.
2025-10-16T19:18:13 < ventYl> :))
2025-10-16T19:19:03 < karlp> ffs. nrf connect wasn't showing me updated btle services because I ws "bonded"
2025-10-16T19:19:11 < karlp> so it psun a wheel and reloaded, but... showed me the old shit
2025-10-16T19:25:42 -!- martinmoene__ [~Martin@30-12-98-95.ftth.glasoperator.nl] has quit [Ping timeout: 252 seconds]
2025-10-16T19:29:41 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-16T20:00:31 -!- martinmoene_ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-16T20:19:39 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 244 seconds]
2025-10-16T20:20:08 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-16T20:21:03 -!- martinmoene_ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 256 seconds]
2025-10-16T21:03:14 -!- splud [~noneya.bi@user/splud] has quit [Ping timeout: 265 seconds]
2025-10-16T21:06:22 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has quit [Ping timeout: 246 seconds]
2025-10-16T21:07:06 -!- PaulFertser [~paul@paulfertser.info] has quit [Ping timeout: 265 seconds]
2025-10-16T21:14:53 -!- splud [~noneya.bi@user/splud] has joined ##stm32
2025-10-16T21:20:24 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has joined ##stm32
2025-10-16T22:30:27 -!- martinmoene_ [~martinmoe@132.229.46.129] has joined ##stm32
2025-10-16T22:31:47 -!- phryk_ [~totallyno@user/phryk] has joined ##stm32
2025-10-16T22:32:09 -!- jhalmen_ [373aef909d@sourcehut/user/slowjo] has joined ##stm32
2025-10-16T22:32:16 -!- esden_ [sid32455@id-32455.hampstead.irccloud.com] has joined ##stm32
2025-10-16T22:32:16 -!- ou5x [~tim@hator.sunsite.lv] has joined ##stm32
2025-10-16T22:32:50 -!- duude__- [~duude__@user/duude/x-4676560] has joined ##stm32
2025-10-16T22:33:50 -!- h4x0riz3d [~pewpew@antonsavov.net] has joined ##stm32
2025-10-16T22:35:30 -!- Alexer [~alexer@alexer.net] has joined ##stm32
2025-10-16T22:36:58 -!- duude__ [~duude__@user/duude/x-4676560] has quit [Ping timeout: 248 seconds]
2025-10-16T22:36:58 -!- jhalmen [373aef909d@sourcehut/user/slowjo] has quit [Ping timeout: 248 seconds]
2025-10-16T22:36:59 -!- esden [sid32455@id-32455.hampstead.irccloud.com] has quit [Ping timeout: 248 seconds]
2025-10-16T22:36:59 -!- Alexer- [~alexer@alexer.net] has quit [Ping timeout: 248 seconds]
2025-10-16T22:37:00 -!- martinmoene [~martinmoe@132.229.46.129] has quit [Ping timeout: 248 seconds]
2025-10-16T22:37:00 -!- oz4ga [~tim@hator.sunsite.lv] has quit [Ping timeout: 248 seconds]
2025-10-16T22:37:00 -!- phryk [~totallyno@user/phryk] has quit [Ping timeout: 248 seconds]
2025-10-16T22:37:00 -!- antto [~pewpew@antonsavov.net] has quit [Ping timeout: 248 seconds]
2025-10-16T22:37:01 -!- duude__- is now known as duude__
2025-10-16T22:37:01 -!- jhalmen_ is now known as jhalmen
2025-10-16T22:37:01 -!- esden_ is now known as esden
2025-10-16T22:48:48 -!- PaulFertser [~paul@paulfertser.info] has joined ##stm32
2025-10-16T23:05:57 -!- NEYi [~NEYi@195.234.78.187] has quit [Quit: Leaving]
2025-10-16T23:09:33 -!- mrec_ [~mrec@user/mrec] has changed host
--- Day changed Fri Oct 17 2025
2025-10-17T00:15:00 -!- System_Error [~SystemErr@user/systemerror] has quit [Ping timeout: 272 seconds]
2025-10-17T00:18:33 < mrec_> hmm an idea how output pulses can be safe-gated? eg it must not exceed certain boundaries
2025-10-17T00:19:02 < mrec_> I think I should pass it through an FPGA and handle it there.
2025-10-17T00:21:00 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has quit [Remote host closed the connection]
2025-10-17T00:21:04 < specing> zeners?
2025-10-17T00:21:28 < mrec_> no I mean I can only output a certain amount of pulses via DMA otherwise I will crash my machine
2025-10-17T00:24:39 < mrec_> well I'll figure out a way tomorrow it's late time to go to bed
2025-10-17T00:25:08 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has joined ##stm32
2025-10-17T00:26:16 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-17T00:31:52 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has quit [Remote host closed the connection]
2025-10-17T00:32:37 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has joined ##stm32
2025-10-17T01:03:27 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 265 seconds]
2025-10-17T01:21:37 -!- noarb [~noarb@user/noarb] has quit [Ping timeout: 264 seconds]
2025-10-17T01:24:08 -!- noarb [~noarb@user/noarb] has joined ##stm32
2025-10-17T01:30:18 -!- noarb [~noarb@user/noarb] has quit [Ping timeout: 248 seconds]
2025-10-17T01:32:58 -!- noarb [~noarb@user/noarb] has joined ##stm32
2025-10-17T01:35:51 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has quit [Ping timeout: 244 seconds]
2025-10-17T01:41:27 -!- jfsimon [~jfsimon19@2a01:cb14:b9b:2000:1cd3:4368:6a6e:fd3f] has quit [Read error: Connection reset by peer]
2025-10-17T02:17:11 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Ping timeout: 244 seconds]
2025-10-17T02:57:36 < qyx> my updating fails :/
2025-10-17T02:59:03 < specing> mrec_: what are these pulses?
2025-10-17T04:03:20 -!- uyyye [~uyyye@2600:4041:5b26:d900:d1f0:6efb:b564:7779] has joined ##stm32
2025-10-17T04:53:12 < qyx> FLASH_SR = 0x80
2025-10-17T04:53:20 < qyx> PGSERR: Programming sequence error
2025-10-17T04:53:23 < qyx> uh what
2025-10-17T04:53:36 < qyx> Set by hardware when a write access to the flash memory is performed by the code while PG or FSTPG have not been set previously.
2025-10-17T05:16:01 < qyx> fuk ST, why do you have your RM ordered like category 3 devices, 4, then 2
2025-10-17T05:39:05 < qyx> so I accidentally erased flash at 0x08018000 instead of 0x08030000
2025-10-17T05:39:37 < qyx> I was erasing sector 48, device is category 4 G4, so 4K sectors, that means 0x08030000 which looks correct
2025-10-17T05:40:41 < qyx> but instead it behaved as erasing sector 24 or erasing sector 48 but with a 2K sector size
2025-10-17T06:12:50 < qyx> ok I fixed programming but broke erasing
2025-10-17T06:52:52 -!- infisx [~infisc@user/infisc] has quit [Ping timeout: 260 seconds]
2025-10-17T06:56:11 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-17T07:27:38 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-17T08:19:01 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-17T08:45:24 -!- qyx [~qyx@84.245.121.36] has quit [Ping timeout: 252 seconds]
2025-10-17T08:47:25 -!- qyx [~qyx@84.245.120.181] has joined ##stm32
2025-10-17T08:49:54 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-17T08:50:58 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-17T08:51:29 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-17T08:57:51 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-17T09:19:36 -!- rob_w [~bob@2001:a61:6109:bb01:89ea:f4a3:3b18:ef50] has joined ##stm32
2025-10-17T09:44:11 < zyp> qyx, is that a dual bank G4? IIRC sector size depends on whether you've got bank interleaving enabled or not
2025-10-17T09:45:29 < zyp> (because if you've got interleaving enabled, you're striping data across both banks, so each logical sectors consists of two physical sectors)
2025-10-17T09:47:16 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-17T09:47:22 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Read error: Connection reset by peer]
2025-10-17T09:48:35 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-17T09:52:11 < qyx> zyp: the whole problem was in "there are category 2, 3 and 4 devices"
2025-10-17T09:52:24 < qyx> in dbg id codes "this is for cat 2, 3 and this for 4"
2025-10-17T09:52:37 < qyx> in all listings, it is category 2, 3 and 4
2025-10-17T09:53:12 -!- rob_w [~bob@2001:a61:6109:bb01:89ea:f4a3:3b18:ef50] has quit [Quit: Leaving]
2025-10-17T09:53:30 < qyx> but well, who the fuck came with an idea to order RM sections "category 3, 4, 2"
2025-10-17T09:53:50 < zyp> and where is category 1?
2025-10-17T09:54:22 < qyx> so I had all my detections and bank interleaving right, except the fact i programmed the shit it the wrong order
2025-10-17T09:54:32 < qyx> so cat 3 is dual bank, not can 4
2025-10-17T09:54:44 < qyx> and I was applying interleaving for cat 4, etc.
2025-10-17T09:54:48 < qyx> there is no cat 1
2025-10-17T09:55:09 < qyx> at least not for RM0440
2025-10-17T09:55:41 < qyx> another problem with G4 is you cannot overwrite the same dword twice
2025-10-17T09:56:17 < qyx> yes you are right, not only you cannot assume 1 turns to 0 but not vice versa because of ECC
2025-10-17T09:56:24 < qyx> you can't even write the same value
2025-10-17T09:56:42 < qyx> if the dword is 0xff, you can write anything
2025-10-17T09:56:52 < qyx> but if dword is != 0xff, you can only write 0x00
2025-10-17T09:57:13 < qyx> so I designed my protocol simply, to allow retransmissions of the same block, but that was failing
2025-10-17T09:57:40 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has joined ##stm32
2025-10-17T09:58:04 < qyx> another thing is G4 has FLASH_SR set to 0x80 after reset, fuck knows why
2025-10-17T09:58:26 < qyx> yes, you have to reset error flags *before* programming attempt
2025-10-17T09:58:36 < qyx> not after you have finished and checked for errors
2025-10-17T09:59:08 < qyx> it was a very productive night, thanks ST
2025-10-17T10:15:06 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 248 seconds]
2025-10-17T10:51:03 < mrec_> specing: pwm, I'm jumping onto the timer synchronisation topic now starting two timers at the same time of course it doesn't work :-)
2025-10-17T10:52:54 < mrec_> overall I'm on a good way outputting and looping it back to a counter gives me a nice way to visualise the behaviour on a PC via serial interface
2025-10-17T10:54:25 < mrec_> the movement is not good if the timers don't start exactly at the same time, most of the time they are okay but sometimes one of them starts earlier. The slave mode doesn't work for me yet
2025-10-17T11:12:28 < qyx> you have to configure the slave and *start* it
2025-10-17T11:13:02 < qyx> it then waits for the trigger to actually start or to reset or whatever
2025-10-17T11:13:16 < qyx> iirc, I did that maybe twice in my life
2025-10-17T11:13:59 < mrec_> well I'm using STM32Cube, it's all configured but doesn't work as expected, so I need to go back read manuals
2025-10-17T11:14:46 < mrec_> so far both channels start independently and trigger settings don't do anything
2025-10-17T11:37:20 < mrec_> I think it works but I have another issue
2025-10-17T11:37:45 < mrec_> a glitch when starting up the timer, there's one pulse which should not be there that glitch seems to be in sync on both channels
2025-10-17T11:39:09 < mrec_> hm the glitch has a 38microsecond offset.
2025-10-17T11:39:09 < mawk> mrec_: http://www.efton.sk/STM32/gotcha/g42.html
2025-10-17T11:39:13 < mawk> maybe this
2025-10-17T11:39:43 < mrec_> does syncing two timers work exactly at the same time or will there be some delay?
2025-10-17T11:49:29 < mrec_> AI suggests sub microsecond delay well...
2025-10-17T11:51:29 < mawk> unplug from the matrix, neo
2025-10-17T11:51:44 < mrec_> PWM with stm32f4 is definitely a messy thing and pretty crippled. my observation ARR=0 = undefined behaviour;
2025-10-17T11:52:49 < mrec_> hmm.. maybe I should just drop this my calculation is just fine and I know how to make it better with an FPGA
2025-10-17T11:53:16 < mrec_> stmicro's timer are powerful but yet a joke
2025-10-17T11:55:27 < mawk> the documentation explicitly says ARR can't be zero
2025-10-17T11:55:32 < mawk> that's defined behavior
2025-10-17T11:56:26 < mrec_> they forgot to mention how to turn off a PWM signal :-) that's odd enough
2025-10-17T11:57:07 < mrec_> I need pulse accuracy.
2025-10-17T11:57:29 < mrec_> implementing a simple counter to stop the timer was too much for them
2025-10-17T11:59:03 < mercenary> loop the signal back to a counter input, kill whatever is generating it on counter-compare
2025-10-17T12:06:12 < mawk> did you try to set CCR1 to zero 
2025-10-17T12:06:27 < mawk> with OC1PE disabled
2025-10-17T12:07:11 < mrec_> the glitch is one thing, the other thing is starting two timers at the same time. Honestly I have some doubts that the timers and dma transfer are 100% reliable with the stm32f4 part
2025-10-17T12:08:11 < mawk> there are a coupla erratas for the timer here: https://www.st.com/resource/en/errata_sheet/es0182-stm32f405407xx-and-stm32f415417xx-device-errata-stmicroelectronics.pdf
2025-10-17T12:08:49 < mawk> also in the reference manual >The minimum delay to activate CC1 output when an edge occurs on the trigger input is 5 clock cycles.
2025-10-17T12:09:01 < mawk> which can be reduced to 3 clock cycles by setting OC1FE
2025-10-17T12:16:24 < mrec_> I could just dump the precalculated samples into some FPGA buffer and sample it out, I feel like that's a better idea than with those stm32 timers. They are overly complicated for no obvious reason (possibly the engineers themselves didn't know how to make it better back then and just did their best)
2025-10-17T12:18:00 < mrec_> everytime I look at some timer/dma oddity I'm burning hours
2025-10-17T12:18:53 < mrec_> implementing such a simple PWM timer and counter in HDL is easily done within 1 day, that should be considered
2025-10-17T12:24:05 < ventYl> as if everyone knew HDL
2025-10-17T12:24:10 < ventYl> :)
2025-10-17T12:26:05 < mrec_> I've done more complex HDL designs, but a timer everyone can do that simple thing with the help of AI boiler code
2025-10-17T12:26:18 < mrec_> "code" / "description"
2025-10-17T12:27:32 < ventYl> that's fallacy and you know it
2025-10-17T12:27:52 < mrec_> no it's not.
2025-10-17T12:29:44 < ventYl> yeah, you are definitely commisioning ASIC containing timer/counter with PWM functionality designed by someone who never did HDL before and created one with help of AI
2025-10-17T12:29:48 < ventYl> yeah.
2025-10-17T12:31:49 < mrec_> you should give it a try :-)
2025-10-17T12:34:56 < mawk> it's easy to make something that has only one very narrow task
2025-10-17T12:35:07 < mawk> but the ST timers do not only do PWM
2025-10-17T12:35:15 < mawk> you can answer your own question about why they are complex
2025-10-17T12:36:05 < mrec_> that is the point, the hdl logic gives more freedom to build anything that STM32 timers can do. While you can advance and learn more about HDL with STM32 you have to deal with workarounds in some detailed areas
2025-10-17T12:37:39 < veverak> which is useless?
2025-10-17T12:37:41 < mrec_> I'm fine with some debugging and workarounds but I'm setting here for quite a long time to get those PWM samples out accurately, it works and the simulation tool is also okay but some oddities are still there. And from what I've experience over the last days it takes hours to bail out every single oddity of the dma/stm32 timer engine
2025-10-17T12:38:23 < veverak> the chances that I am on project where FPGA is present is close to none, so bothering with HDL seems liek waste of time :P so it sounds like "niche" solution
2025-10-17T12:40:19 < mrec_> I'm digging along the path blindly with a stick in the STM32 area... what a nonsense.
2025-10-17T12:41:30 < mrec_> I would not know any undefined area when doing that in HDL, no digging in the dark.
2025-10-17T12:43:19 < tomeaton17> https://x.com/1thousandfaces_/status/1979013989142045038
2025-10-17T12:43:54 < mrec_> those timers only need beginner HDL knowledge aside of that, nothing advanced.
2025-10-17T12:46:03 < c10ud> throwing fpgas around for counting a few pulses reminds me of the great MIL industry 
2025-10-17T12:46:47 < mawk> if you're still talking about ARR = 0 that's perfectly defined in the reference manual
2025-10-17T12:46:56 < c10ud> why bother if you can just sell your 3$ board for 3k$
2025-10-17T12:47:13 < mrec_> small fpgas can be obtained for less than 5$
2025-10-17T12:47:42 < mrec_> R&D time for the STM32 Timer crap costs far more
2025-10-17T12:48:08 < mrec_> they're powerful but messy
2025-10-17T12:54:05 < mrec_> > http://www.efton.sk/STM32/gotcha/g42.html
2025-10-17T12:54:25 < mrec_> I wonder if anyone on this planet knows how to fix that reliably, I tried but it's not reliable. I still get the glitches from time to time
2025-10-17T12:58:12 < c10ud> for starters, i'd avoid hal/ll if greater accuracy in control is needed
2025-10-17T13:00:44 < mrec_> HAL is okay since the stack is open I can just dig inside it and adjust
2025-10-17T13:01:03 < mrec_> this glitch eg. it might work for 3-4 times and then it will happen.
2025-10-17T13:02:34 < mrec_> __HAL_TIM_CLEAR_FLAG(&htim3, TIM_FLAG_UPDATE);   
2025-10-17T13:03:12 < c10ud> not sure on what your current plan is, but i'd expect to directly implement stuff in interrupts and not rely in like hal callbacks or w/e
2025-10-17T13:03:14 < mrec_> this is supposed to clear the UIF flag.
2025-10-17T13:04:39 < mrec_> the plan was to sample out a motion profile via DMA but I'm slowly running out of patience with it and the experience I've collected during the week with the STM32/PWM/Timers (I do use timers other ways too which work better but this given topic makes me think that STM32 engineers who worked on the timers don't really understand what they do and why they are doing that)
2025-10-17T13:08:16 < mrec_> the uif flag seems to be impossible to solve, it works a few times and comes back again who knows why
2025-10-17T13:08:28 < mrec_> those STM engineers would be better to write riddle books rather than designing ICs.
2025-10-17T13:08:36 < mawk> lol
2025-10-17T13:08:39 < mawk> yes blame the engineers
2025-10-17T13:09:25 < mrec_> I'm not the one who would accept glitches in a dma/timer and forget to turn off the pwm if a user requests to play out n samples.
2025-10-17T13:11:55 < mrec_> I just figured out I have a cyclone 2 board lying around I'll use that one
2025-10-17T13:12:06 < zyp> sounds like you've just made yourself some race conditions
2025-10-17T13:12:18 < mrec_> STM32 timer engineers need to learn the basics .. engineers want to get things done and not fool around with that shit
2025-10-17T13:13:02 < mrec_> I'll just feed it via spi and sample it out accordingly. Not much different than with broken STM32 timer shit
2025-10-17T13:18:56 < mrec_> sorry for ranting about it, it just feels to 'undefined' to bail out those STM32 Timer issues. That's just not engineering.
2025-10-17T13:19:37 < c10ud> this is what copilot gets you, 50 lines max, super easy to debug: https://paste.jvnv.net/view/MmUWq
2025-10-17T13:20:36 < mrec_> some boiler plate code, it will certainly help but never form a full solution as usual.
2025-10-17T13:21:07 < mrec_> I have a defined amount of PWM samples I want to play out, basically it works just starting both timers at the same time doesn't work and this stupid glitch is there
2025-10-17T13:22:06 < mrec_> I'll marry the Cyclone part with the STM32, I don't see any value in the STM32 timers anymore if they behave so poorly with PWM
2025-10-17T13:22:33 < mrec_> using simple timers is fine, advanced timers will end up too undefined.
2025-10-17T13:26:06 < c10ud> honestly your application does not sound too advanced to me, but maybe i misinterpreted what you are trying to do
2025-10-17T13:26:20 < c10ud> anyway, whatever floats your boat
2025-10-17T13:26:49 < mrec_> it's absolutely not just sampling out a trapezoidal profile for 3 motors X/2xY
2025-10-17T13:27:00 < zyp> mrec_, so, what you want to do is output a stream of PWM pulse length across N channels, where N > 4?
2025-10-17T13:28:23 < mrec_> yes. it works but not absolutely synchronously plus random glitch at the beginning (like that website says, possibly some preloading issue at some point) 
2025-10-17T13:28:43 < zyp> what sort of motors is this?
2025-10-17T13:28:51 < zyp> steppers with step/dir signals?
2025-10-17T13:29:00 < mrec_> yes
2025-10-17T13:29:16 < zyp> oh, so not pwm then, you're not varying duty but period?
2025-10-17T13:29:41 < mrec_> I'm using PWM, with a small fixed duty cycle.
2025-10-17T13:29:54 < mrec_> the dma will take care about the ARR register
2025-10-17T13:30:42 < zyp> yeah, that's not PWM, if you're varying the period and call it PWM you'll just confuse everybody
2025-10-17T13:31:10 < mrec_> well in terms of stm32 it's the PWM path
2025-10-17T13:31:55 < zyp> what's the peak step rate you're targetting?
2025-10-17T13:33:18 < mrec_> for experimenting as high as possible later on, but there are 3 major problems with the STM32 and I don't feel safe about stopping the transfer.
2025-10-17T13:34:40 < mrec_> 1. the random glitch that happens when starting the transfer, 2. stopping the pwm transfer I need to do more testing, 3. starting two timers at the same time master / slave doesn't seem to work properly with that PWM setup (possibly some HAL interference).
2025-10-17T13:37:30 < mrec_> the pulsetrain itself looked perfectly of course :-)
2025-10-17T13:38:29 < mrec_> I am using a pure software solution at the moment on another STM32 it works fine but I want it faster.
2025-10-17T13:39:51 < zyp> how fast is faster?
2025-10-17T13:41:03 < mrec_> after using DMA the main problem is that STM forgot to turn off PWM (after the last sample), they turned PWM + DMA + single shot to useless, someone can workaround by setting CCR to 0 and ARR to something else very likely.
2025-10-17T13:41:23 < mrec_> the servo claims to support a faster input than 500khz
2025-10-17T13:42:20 < mrec_> actually 4mhz but who knows.
2025-10-17T13:42:30 < c10ud> but this is still with a single timer and 4 chan or multiple timers already
2025-10-17T13:42:55 < zyp> one timer per output, ARR is common for all channels
2025-10-17T13:42:59 < mrec_> I have two timers one for X one for Y
2025-10-17T13:43:10 < zyp> so if you vary ARR you need dedicated timers
2025-10-17T13:43:39 < mrec_> again the pulse train itself is fine that's not the problem
2025-10-17T13:44:27 < zyp> do you have preload enabled?
2025-10-17T13:45:59 < mrec_> yes
2025-10-17T13:47:27 < zyp> but yeah, I would also consider going for an FPGA-based solution if you can't do this fast enough in software, doing it with timer+DMA sounds like a bunch of hassle stemming from the fundamental issue that ARR = 1/speed, so there's no way of doing speed = 0
2025-10-17T13:48:17 < mrec_> speed = 0 is not the problem, I used it for stopping the transfer at some point, STM completely forgot about that when implementing PWM/DMA/Timers
2025-10-17T13:48:24 < mrec_> arr=0 is not the problem
2025-10-17T13:48:50 < zyp> I didn't say ARR = 0 was the problem, I said ARR = 1/0 is the problem
2025-10-17T13:49:10 < mrec_> yes, but I have no problem with that.
2025-10-17T13:49:20 < mrec_> that's not my problem. mine are the other ones.
2025-10-17T13:49:34 < zyp> why is stopping a problem then?
2025-10-17T13:52:07 < mrec_> STM never implemented stopping with PWM ;-)
2025-10-17T13:52:28 < mrec_> they will give you an interrupt but until that triggers more samples are sampled out
2025-10-17T13:52:42 < zyp> stopping with PWM is easy, you just set the pulse width to zero, but this doesn't apply since you're not doing PWM
2025-10-17T13:53:28 < mrec_> you mean duty cycle to 0
2025-10-17T13:53:36 < zyp> when you do DMA to PWM, you just put a zero duty at the end of the DMA buffer to stop once the DMA job is complete
2025-10-17T13:53:55 < zyp> but you're not doing DMA to PWM, you're doing DMA to period
2025-10-17T13:53:58 < mrec_> if pulse width is zero you will enter an undefined behaviour (someone wrote 0 is not allowed)
2025-10-17T13:54:18 < zyp> you're confusing pulse width and period
2025-10-17T13:54:36 < mrec_> you are right.
2025-10-17T13:54:38 < zyp> zero pulse width is fine, zero period is nonsensical
2025-10-17T13:55:21 < mrec_> I'm doing that anyway and it seems to work fine but since that glitch is happening at the beginning I don't really trust it also that starting both timers at the same time doesn't work doesn't look trustful.
2025-10-17T13:55:42 < c10ud> still what prevents from hooking interrupts and force duty to 0
2025-10-17T13:55:48 < zyp> like I tried saying before, stopping is not a zero period, it's an infinite period, and you can't put infinity into your DMA buffer and have it written into ARR at the end of the job
2025-10-17T13:56:12 < mrec_> the pulse train looks good and it works I can move around in my simulation application.
2025-10-17T13:56:54 < c10ud> other glitches, i guess just don't do hal so you are sure on what regs you're setting instead of having to go through all the abstractions and callbacks
2025-10-17T13:56:55 < mrec_> I'm looping back the PWM signal to a counter and read the counter via serial
2025-10-17T13:58:46 < zyp> your starting issue is just initialization bullshit, I think that'd be easily fixable, but I think the issues with stopping (or even going very slow) makes the whole approach flawed, even if it performs well when you're going fast
2025-10-17T13:59:36 < mrec_> very slow is no problem.
2025-10-17T13:59:48 < mrec_> again the pulse trains are fine.
2025-10-17T14:00:01 < zyp> very slow is a problem if the period between pulses is larger than what fits in ARR
2025-10-17T14:05:48 < mrec_> that's a job for the planner, it can set ccr=0 and arr accordingly
2025-10-17T14:06:15 < zyp> last time I worked with steppers, I had a trapezoid generator that generated a series of polynomials that effectively gave me pos(time), and a fast interrupt that did pos(now) and for each axis compared it to current pos and generated a step in either direction
2025-10-17T14:06:51 < mrec_> there are a few ways to do that
2025-10-17T14:07:35 < zyp> if I wanted to reach 500kHz stepping rates, I'd probably keep the same approach and do the update loop in HDL
2025-10-17T14:07:43 < mrec_> currently I just read the current position in the mainloop, so even with glitch it performs correctly because it will compare that value
2025-10-17T14:08:04 < zyp> or maybe a dual CPU MCU with a core dedicated to the update loop
2025-10-17T14:09:49 < zyp> alternatively use something more reasonable than step/dir
2025-10-17T14:11:28 -!- martinmoene_ [~martinmoe@132.229.46.129] has quit [Read error: Connection reset by peer]
2025-10-17T14:12:42 -!- uyyye [~uyyye@2600:4041:5b26:d900:d1f0:6efb:b564:7779] has quit [Ping timeout: 260 seconds]
2025-10-17T14:19:41 -!- martinmoene [~martinmoe@132.229.46.129] has joined ##stm32
2025-10-17T15:14:20 < ventYl> mrec_: no thanks, I am mostly successfully avoiding gathering any deep understanding of hardware
2025-10-17T15:49:27 -!- DudV2 [~dudv2@user/DudV2] has quit [Ping timeout: 252 seconds]
2025-10-17T15:51:14 -!- DudV2 [~dudv2@222-155-163-204-fibre.sparkbb.co.nz] has joined ##stm32
2025-10-17T16:32:44 -!- NEYi [~NEYi@195.234.78.187] has quit [Quit: Leaving]
2025-10-17T16:37:45 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Quit: Konversation terminated!]
2025-10-17T16:39:59 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-17T17:03:54 < mawk> why are all the operations like enable dcache or clean dcache taking ages in gdb
2025-10-17T17:03:59 < mawk> like 30s
2025-10-17T17:04:55 < mawk> I'm in MPU debugging hell
2025-10-17T17:14:01 < Steffanx> I'm very sorry mawk
2025-10-17T17:14:07 < Steffanx> Maybe ask Richard
2025-10-17T17:14:19 < mawk> richard only knows how to gift wine bottles to get sales
2025-10-17T17:14:43 < tomeaton17> richard dawkins?
2025-10-17T17:14:49 < mawk> richard the ublox guy
2025-10-17T17:14:58 < mawk> the most famous salesman of the netherlands
2025-10-17T17:15:48 < tomeaton17> does he support PVV?
2025-10-17T17:17:24 < mawk> maybe
2025-10-17T17:17:29 < mawk> the fascists are roaming among us
2025-10-17T17:17:54 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-17T17:18:46 < tomeaton17> fascist hmm
2025-10-17T17:19:00 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-17T17:19:25 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-17T17:33:38 < Steffanx> Who will get your vote mawk?
2025-10-17T17:33:45 < Steffanx> Jetten? D66?
2025-10-17T17:33:49 < Steffanx> Thierry?
2025-10-17T17:34:02 < tomeaton17> Steffanx: are you German?
2025-10-17T17:34:36 < Steffanx> Nein.
2025-10-17T17:34:54 < Steffanx> Mawk and I share a nationality 
2025-10-17T17:35:05 < Steffanx> The only proper one of mawk
2025-10-17T17:35:19 < tomeaton17> oh anne frank land?
2025-10-17T17:35:23 < Steffanx> Yeah
2025-10-17T17:36:32 < tomeaton17> how interesting
2025-10-17T17:36:40 < tomeaton17> I am planning to visit next year
2025-10-17T17:37:36 < Steffanx> Will you go to Amsterdam, do drugs and jump out of a window?
2025-10-17T17:37:50 < Steffanx> ^ average britbong experience
2025-10-17T17:37:52 < tomeaton17> Yeah the main idea was to sample the local produce
2025-10-17T17:38:33 < tomeaton17> a relative is actually studying in holland
2025-10-17T17:39:11 < Steffanx> *The Netherlands 
2025-10-17T17:40:02 < tomeaton17> Apologies, can I not use it to refer to the specific region
2025-10-17T17:40:41 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-17T17:41:39 < Steffanx> I'm sure mawk has a local momo. He can help you around with the local cuisine for the best dutch experience 
2025-10-17T17:41:47 -!- NEYi_ [~NEYi@195.234.78.187] has joined ##stm32
2025-10-17T17:42:08 < tomeaton17> I am quite a big bitterball enjoyer
2025-10-17T17:42:18 < jbo> what
2025-10-17T17:42:22 < jbo> I litreally just got here
2025-10-17T17:42:39 < Steffanx> Kroketten are nice too
2025-10-17T17:42:45 < Steffanx> I ate one today.
2025-10-17T17:42:46 < tomeaton17> Also the relative received xenophobic abuse on the train
2025-10-17T17:43:07 < Steffanx> That happens everywhere. 
2025-10-17T17:43:15 < jbo> that's trains, not netherlands
2025-10-17T17:43:23 < Steffanx> Thank you jbo
2025-10-17T17:43:32 < jbo> you're welcome Steffanx 
2025-10-17T17:43:50 < Steffanx> I had no such experience in swissertrains though.
2025-10-17T17:44:04 < tomeaton17> I am not attacking the country at all
2025-10-17T17:44:08 < jbo> yes, because swiss trains are different than all other trains
2025-10-17T17:44:25 < jbo> is tomeaton17 blaxter's little sane brother or something?
2025-10-17T17:44:30 < Steffanx> Yes
2025-10-17T17:44:34 < jbo> makes sense.
2025-10-17T17:44:43 < tomeaton17> nice I am sane
2025-10-17T17:44:44 < Steffanx> Maybe not sane, but acts more sane
2025-10-17T17:44:50 < Steffanx> ^
2025-10-17T17:45:01 -!- NEYi [~NEYi@195.234.78.187] has quit [Ping timeout: 264 seconds]
2025-10-17T17:45:10 < tomeaton17> that is the downside of a logged channel with my name
2025-10-17T17:45:21 < tomeaton17> actually that didnt stop lolrence
2025-10-17T17:45:33 < Steffanx> Haha
2025-10-17T17:52:58 < jbo> hmm, aisler said they'd ship on monday, but they shipped today :<
2025-10-17T17:54:09 < ventYl> did they say *which* monday they shipped?
2025-10-17T17:55:19 < jbo> -_-
2025-10-17T17:56:28 < Steffanx> Did they ship today or made the label today?
2025-10-17T17:57:01 < jbo> "shipped"
2025-10-17T17:57:13 < Steffanx> For some "I shipped it" means "I dropped it at the department responsible for shipping".
2025-10-17T17:57:28 < Steffanx> And then they do nothing for a week or so
2025-10-17T18:01:25 < jbo> I didn't order parts yet so it hardly matters
2025-10-17T18:01:33 < tomeaton17> people are getting accounts closed by jlc
2025-10-17T18:04:58 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has quit [Ping timeout: 248 seconds]
2025-10-17T18:09:49 < mawk> Steffanx: partij voor de dieren
2025-10-17T18:11:02 < mawk> I am now debugging the MPU in excel
2025-10-17T18:11:09 < mawk> I should write a tool to automatically show the regions and permissions
2025-10-17T18:24:54 < ventYl> mawk: wait a second
2025-10-17T18:25:52 < ventYl> mawk: http://digital-nomad.sk/info_mpu.gdb
2025-10-17T18:25:59 < ventYl> adds `info mpu` command into gdb
2025-10-17T18:27:07 < mawk> thanks
2025-10-17T18:27:20 < mawk> btw chrome thinks this is a virus it says "insecure download blocked"
2025-10-17T18:27:24 < mawk> but I can override
2025-10-17T18:35:44 < Steffanx> I'll have a talk with your ex mawk. She will kill you for voting so leftist
2025-10-17T18:37:08 < ventYl> mawk: sure it is
2025-10-17T19:28:08 < mawk> what do you mean leftist Steffanx 
2025-10-17T19:28:10 < mawk> it's just pets
2025-10-17T19:28:14 < mawk> at the last tweede kamer bullshit thing I just chose a name at random
2025-10-17T19:28:16 < mawk> too many to choose from on the ballot
2025-10-17T19:28:20 < mawk> it's like a size A2 paper
2025-10-17T19:56:49 -!- infisd [~infisc@user/infisc] has quit [Quit: Vive la révolution.]
2025-10-17T19:58:05 < Steffanx> It's no just pets
2025-10-17T20:07:31 < mawk> they should change their name then
2025-10-17T20:10:59 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-17T20:27:40 -!- sculptor [~sculptor@user/sculptor] has joined ##stm32
2025-10-17T20:27:42 < sculptor> yo
2025-10-17T20:27:56 < mawk> hi
2025-10-17T20:28:13 < sculptor> i ran across a sweet programmed/debugger
2025-10-17T20:28:21 < mawk> info on how the radio core of stm32wb actually works is a bit lacking
2025-10-17T20:28:27 < mawk> they just give you the Cube™ and that's it
2025-10-17T20:28:47 < sculptor> it implements stlink2.1 or daplink -depending on uploaded firmware
2025-10-17T20:28:57 < mawk> so like the stlink
2025-10-17T20:29:28 < sculptor> besides swdio and swclk is also has swo and additional serial rx/tx
2025-10-17T20:29:41 < mawk> so like stlink v3
2025-10-17T20:29:49 < mawk> the v3 also has spi and i2c and a lot more good stuff
2025-10-17T20:30:03 < sculptor> maybe. but this one is cheap https://www.aliexpress.com/item/1005009483848473.html
2025-10-17T20:30:31 < sculptor> and you can get extra cables here https://www.aliexpress.com/item/1005007412514598.html sh1.0-10p option
2025-10-17T20:30:40 < sculptor> i ordered 10 cables and 4 devices. have one on stock
2025-10-17T20:30:59 < sculptor> and one cable comes with an each device
2025-10-17T20:32:34 < sculptor> weact has two stores on ali. 1st one is more pricey. 2nd one is much cheaper, with less products tho
2025-10-17T20:32:35 < mawk> that's the same ali seller on which I bought the stm32wb55
2025-10-17T20:32:44 < sculptor> right, this one https://www.aliexpress.com/item/1005009517091331.html
2025-10-17T20:32:51 < sculptor> i hope you got it from the cheaper store
2025-10-17T20:33:09 < sculptor> 3.13eur 0.31eur shipping for me
2025-10-17T20:33:10 < mawk> https://nl.aliexpress.com/item/1005009517091331.html
2025-10-17T20:33:16 < mawk> idk which one I bought
2025-10-17T20:33:20 < sculptor> yep
2025-10-17T20:33:21 < mawk> I had a aliexpress coupon thing so it was cheap
2025-10-17T20:33:40 < mawk> this https://nl.aliexpress.com/item/1005007119406784.html
2025-10-17T20:33:42 < mawk> with the coupon
2025-10-17T20:33:43 < mawk> buy it
2025-10-17T20:34:32 < sculptor> same company, same product, pricier store https://www.aliexpress.com/item/1005007291039616.html
2025-10-17T20:34:45 < mawk> yeah I noticed that
2025-10-17T20:35:14 < mawk> I think I bought the red one
2025-10-17T20:35:17 < mawk> so the pricier one
2025-10-17T20:36:03 < mawk> 0,40€ more expensive
2025-10-17T20:36:04 < sculptor> i ordered 7 stm32 boards the other day from them
2025-10-17T20:36:17 < mawk> not the f103 thing I hope
2025-10-17T20:36:41 < mawk> like half of the "blue pill" stm32f103 boards I bought had a faulty usb connector I had to resolder
2025-10-17T20:36:42 < sculptor> red one is 7eur for me. with free shipping. blue one is 3.13 eur for me, with 0.31eur shipping. so. 50% cheaper
2025-10-17T20:36:55 < mawk> I guess aliexpress does dynamic pricing
2025-10-17T20:37:04 < mawk> which is kinda illegal but nobody cares about it
2025-10-17T20:37:20 < sculptor> mawk, but not from this company, right
2025-10-17T20:37:25 < sculptor> they are reputable
2025-10-17T20:37:29 < mawk> yeah
2025-10-17T20:37:49 < mawk> the board is kinda ugly though, there's no solder mask on top of the pcb antenna
2025-10-17T20:37:56 < sculptor> i got one of each https://www.aliexpress.com/item/1005009651991042.html
2025-10-17T20:37:56 < mawk> I guess it is for RF reasons but that makes it kinda fragile
2025-10-17T20:38:00 < mawk> you can easily scrape off the trace
2025-10-17T20:38:02 < sculptor> those are dirt cheap
2025-10-17T20:39:26 < sculptor> mawk, are you using st's software
2025-10-17T20:39:29 < sculptor> like cube thing
2025-10-17T20:41:33 < mawk> yes
2025-10-17T20:42:14 < mawk> it's kinda mandatory for the WB board, the radio isn't publicly documented you have to use their code
2025-10-17T20:42:38 < sculptor> ah, yes for that wb family
2025-10-17T20:42:55 < sculptor> well i'm working with g03x atm
2025-10-17T20:43:07 < sculptor> my home automation end points
2025-10-17T20:43:27 < mawk> it's perfectly fine even for the other boards
2025-10-17T20:43:53 < mawk> at least to configure the peripherals and clocks and all that easily; then you can tell it to generate code using LL if you don't like HAL 
2025-10-17T20:43:59 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-17T20:44:24 < sculptor> for the relay nodes i went for rp2040/rp2350
2025-10-17T20:44:30 < sculptor> i like PIO engines a lot
2025-10-17T20:44:58 < sculptor> tho there's no FDCAN support on pico, i'm using external controllers
2025-10-17T20:45:00 < sculptor> CANFD, that is
2025-10-17T20:48:13 < mawk> so you're using wires for the home automation? no wireless magic?
2025-10-17T20:48:22 < mawk> I'm trying to use 802.15.4 to make the things talk
2025-10-17T20:48:26 < mawk> between thermometer and thermostat
2025-10-17T20:54:41 < sculptor> no. mostly wires
2025-10-17T20:55:11 < sculptor> canfd for relay nodes, and single wire half duplex from them to end nodes
2025-10-17T20:56:02 < mawk> what are you automating
2025-10-17T21:01:09 -!- hexo [~hexo@user/hexo] has quit [Remote host closed the connection]
2025-10-17T21:07:22 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 248 seconds]
2025-10-17T21:09:41 < mrec_> after watching rambo and calming down I gave it another try... it works now.
2025-10-17T21:10:51 < mrec_> the delay between Timer3/4 is now around 300ns
2025-10-17T21:11:37 < mrec_> I'm triggering both through timer1
2025-10-17T21:22:36 < mawk> seems like there a lot of ways to brick the STM32WB radio coprocessor
2025-10-17T21:22:54 < mawk> the ST engineers are waiting for an apology now
2025-10-17T21:43:59 -!- sculptor_ [~sculptor@user/sculptor] has joined ##stm32
2025-10-17T21:47:22 -!- sculptor [~sculptor@user/sculptor] has quit [Ping timeout: 248 seconds]
2025-10-17T21:52:30 -!- user1__ [~sculptor@user/sculptor] has joined ##stm32
2025-10-17T21:55:52 -!- sculptor_ [~sculptor@user/sculptor] has quit [Ping timeout: 260 seconds]
2025-10-17T21:58:28 -!- hexo [~hexo@user/hexo] has joined ##stm32
2025-10-17T22:00:42 -!- hexo [~hexo@user/hexo] has quit [Remote host closed the connection]
2025-10-17T22:09:56 < mrec_> heh, the stm32f4 doesn't want to make it easy. Timer5 / TI2FP2 ; since I had to move Timer1 (which I used for counting external pulses previously) I would like to use Timer5 now but it's not counting anything. Is there any limitation on that one?
2025-10-17T22:10:37 < mrec_> the pulses are there, the oscilloscope just shows up everything fine.
2025-10-17T22:22:29 -!- sculptor_ [~sculptor@user/sculptor] has joined ##stm32
2025-10-17T22:25:40 -!- user1__ [~sculptor@user/sculptor] has quit [Ping timeout: 244 seconds]
2025-10-17T22:35:29 -!- user1__ [~sculptor@user/sculptor] has joined ##stm32
2025-10-17T22:39:02 -!- sculptor_ [~sculptor@user/sculptor] has quit [Ping timeout: 260 seconds]
2025-10-17T22:50:55 -!- sculptor_ [~sculptor@user/sculptor] has joined ##stm32
2025-10-17T22:53:57 -!- user1__ [~sculptor@user/sculptor] has quit [Ping timeout: 256 seconds]
2025-10-17T22:57:30 -!- user1__ [~sculptor@user/sculptor] has joined ##stm32
2025-10-17T23:01:13 -!- sculptor_ [~sculptor@user/sculptor] has quit [Ping timeout: 264 seconds]
2025-10-17T23:09:26 < mrec_> one more dupont jumper wire dead okay, tim5 is okay
2025-10-17T23:12:10 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 248 seconds]
2025-10-17T23:13:09 < mrec_> next step s-curve support finally
2025-10-17T23:22:29 -!- sculptor_ [~sculptor@user/sculptor] has joined ##stm32
2025-10-17T23:24:58 -!- sculptor [~sculptor@user/sculptor] has joined ##stm32
2025-10-17T23:25:49 -!- user1__ [~sculptor@user/sculptor] has quit [Ping timeout: 264 seconds]
2025-10-17T23:27:09 -!- sculptor_ [~sculptor@user/sculptor] has quit [Ping timeout: 244 seconds]
2025-10-17T23:42:38 -!- sculptor_ [~sculptor@user/sculptor] has joined ##stm32
2025-10-17T23:45:14 -!- sculptor [~sculptor@user/sculptor] has quit [Ping timeout: 244 seconds]
2025-10-17T23:50:07 -!- ou5x is now known as oz4ga
2025-10-17T23:51:00 -!- user1__ [~sculptor@user/sculptor] has joined ##stm32
2025-10-17T23:53:04 -!- Livio [~livio@user/livio] has quit [Quit: leaving]
2025-10-17T23:53:55 -!- sculptor_ [~sculptor@user/sculptor] has quit [Ping timeout: 246 seconds]
--- Day changed Sat Oct 18 2025
2025-10-18T00:07:59 -!- sculptor_ [~sculptor@user/sculptor] has joined ##stm32
2025-10-18T00:11:12 -!- user1__ [~sculptor@user/sculptor] has quit [Ping timeout: 260 seconds]
2025-10-18T00:26:00 -!- user1__ [~sculptor@user/sculptor] has joined ##stm32
2025-10-18T00:29:16 -!- sculptor_ [~sculptor@user/sculptor] has quit [Ping timeout: 246 seconds]
2025-10-18T00:33:46 < zyp> mawk, tell me more
2025-10-18T00:34:07 < zyp> I have a stm32wb here with a bricked radio coproc :)
2025-10-18T00:39:50 < zyp> IIRC engineering silicon had a sequence that'd disable CPU2 security through a full mass erase (unlike a normal mass erase that skips CPU2 reserved area)
2025-10-18T00:40:34 -!- sculptor_ [~sculptor@user/sculptor] has joined ##stm32
2025-10-18T00:41:41 < zyp> when I tried it on my nucleo, it still did the full mass erase, deleting all the CPU2 code, but security is still force-enabled
2025-10-18T00:43:49 -!- user1__ [~sculptor@user/sculptor] has quit [Ping timeout: 264 seconds]
2025-10-18T00:49:30 -!- user1__ [~sculptor@user/sculptor] has joined ##stm32
2025-10-18T00:52:22 -!- sculptor_ [~sculptor@user/sculptor] has quit [Ping timeout: 246 seconds]
2025-10-18T00:57:20 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-18T01:29:19 -!- duude__- [~duude__@user/duude/x-4676560] has joined ##stm32
2025-10-18T01:29:49 -!- duude__ [~duude__@user/duude/x-4676560] has quit [Ping timeout: 246 seconds]
2025-10-18T01:29:59 -!- sculptor_ [~sculptor@user/sculptor] has joined ##stm32
2025-10-18T01:31:09 -!- duude__- is now known as duude__
2025-10-18T01:33:27 -!- user1__ [~sculptor@user/sculptor] has quit [Ping timeout: 260 seconds]
2025-10-18T01:43:39 -!- user1__ [~sculptor@user/sculptor] has joined ##stm32
2025-10-18T01:44:56 -!- user1__ [~sculptor@user/sculptor] has quit [Client Quit]
2025-10-18T01:46:52 -!- sculptor_ [~sculptor@user/sculptor] has quit [Ping timeout: 260 seconds]
2025-10-18T02:37:48 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Ping timeout: 244 seconds]
2025-10-18T02:58:18 -!- DudV2 [~dudv2@222-155-163-204-fibre.sparkbb.co.nz] has quit [Ping timeout: 248 seconds]
2025-10-18T03:39:38 -!- uyyye [~uyyye@2600:4041:5b26:d900:993:a6cc:c44b:5d61] has joined ##stm32
2025-10-18T04:24:07 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-18T05:57:27 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-18T07:17:52 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-18T07:24:41 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-18T08:38:20 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-18T09:15:46 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-18T09:22:25 -!- zChris [~zChris@user/zchris] has quit [Ping timeout: 245 seconds]
2025-10-18T09:24:31 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-18T09:28:18 -!- zChris [~zChris@user/zchris] has joined ##stm32
2025-10-18T09:36:58 -!- Livio [~livio@user/livio] has quit [Ping timeout: 272 seconds]
2025-10-18T09:47:32 -!- zChris [~zChris@user/zchris] has quit [Ping timeout: 260 seconds]
2025-10-18T10:46:30 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-18T10:59:15 < mawk> can I use stm32cubeprogrammer with a jlink
2025-10-18T10:59:18 < mawk> I assume that no
2025-10-18T11:00:50 < mawk> I haven't tried bricking it yet zyp , I'm actually trying to avoid bricking it lol
2025-10-18T11:01:47 < mawk> how did you trigger the full mass erase? 
2025-10-18T11:08:37 < mawk> ooo apparently now cubeprogrammer works with jlink
2025-10-18T11:08:39 < mawk> perfect
2025-10-18T11:13:44 < mawk> without even undocumented mass erase you can brick it easily, like if you upgrade the CPU2 bootloader by skipping versions, or if you enable anti-rollback without a firmware binary loaded
2025-10-18T11:30:57 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2025-10-18T11:35:53 -!- zChris [~zChris@user/zchris] has joined ##stm32
2025-10-18T11:42:55 -!- mercenary [~mercenary@user/mercenary] has quit [Quit: ZNC 1.10.0 - https://znc.in]
2025-10-18T11:44:25 -!- mercenary [~mercenary@user/mercenary] has joined ##stm32
2025-10-18T12:17:40 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 246 seconds]
2025-10-18T12:20:34 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2025-10-18T13:04:55 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 246 seconds]
2025-10-18T13:07:49 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2025-10-18T13:45:52 < mawk> cubemx doesn't support direct 802.15.4 MAC applications, it wants me to use Thread whatever that is
2025-10-18T13:46:01 < mawk> and then it forces to use freertos
2025-10-18T13:46:24 < mawk> I found code examples for 802.15.4 in the cube repos, without a rtos, but then it uses a weird cooperative scheduler sequencer thing
2025-10-18T13:46:36 < mawk> https://github.com/STMicroelectronics/STM32CubeWB/tree/v1.23.0/Utilities/sequencer
2025-10-18T13:48:23 -!- NEYi_ [~NEYi@195.234.78.187] has quit [Quit: Leaving]
2025-10-18T13:51:41 < Steffanx> Will you be ok?
2025-10-18T13:51:48 < mawk> no
2025-10-18T13:51:55 < mawk> I want to do plain 6lowpan
2025-10-18T13:51:59 < mawk> not that thread thing
2025-10-18T13:52:29 < qyx> oh over 802.15.4?
2025-10-18T13:52:32 < qyx> I am in
2025-10-18T13:52:41 < qyx> no zigbee, no matterz, no threadz
2025-10-18T13:56:53 < mawk> yeah
2025-10-18T13:57:00 < mawk> just almost-regular ipv6 networking
2025-10-18T13:57:16 < mawk> with more or less 120 bytes MTU and compressed headers
2025-10-18T14:04:11 < qyx> lora could work for that too
2025-10-18T14:04:27 < qyx> using some weird ass MAC
2025-10-18T14:54:20 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-18T14:55:34 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-18T14:55:59 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-18T15:20:15 -!- kovalevsky [~kovalevsk@fedora/kovalevsky] has joined ##stm32
2025-10-18T15:26:27 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 260 seconds]
2025-10-18T15:40:54 < kovalevsky> Someboy has found ever the following case ? I do have a variable declared globally but the scope is limited to the translation unit Im compiling. This variable is a struct declare in another place, a header file. At the same time, I have a function that accepts a pointer to this struct. My main problem that I can not still decipher is, when the variable is allocated, the total size of it its as is packet which is weird because the declaration of 
2025-10-18T15:40:54 < kovalevsky> the struct, I can see that is having some holes.
2025-10-18T15:42:23 < kovalevsky> How is possible that, when passing the pointer to the struct at a function, the pointer is not taking into consideration the padding, but when checking the variable one level above the function, its not taking into consideration the padding.
2025-10-18T15:49:08 < kovalevsky> If I print on gdb, the address of the global variable: 0x2002b2f8 <file_s>, whereas, if I obtain the address of the pointer passed to the function, 0x2002b2f8 <file_s>. Both are located on the same address. However, when accessing the following member, there is a padding of 3 bytes. 0x2002b30c <file_s+20>, 0x2002b309 <file_s+17>
2025-10-18T15:50:03 < mawk> declare a variable in a header file? do you mean define?
2025-10-18T15:50:47 < kovalevsky> The variable is global, is declared inside a .c file. But is static, limiting the scope to only be seen in that .c file.
2025-10-18T15:50:57 < mawk> ah
2025-10-18T15:51:02 < kovalevsky> static struct my_struct variable;
2025-10-18T15:51:03 < mawk> the compiler is free to add padding within a structure
2025-10-18T15:51:08 < mawk> for memory alignment purposes
2025-10-18T15:51:28 < mawk> you can request to remove all the padding by marking the type definition with __attribute__((__packed__))
2025-10-18T15:51:33 < kovalevsky> @mawk, I got that part, but in this particular case. variable is instantiated with no padding at all.
2025-10-18T15:51:45 < mawk> you used what I just said?
2025-10-18T15:51:54 < kovalevsky> Even though, in the struct definition, the compiler is obviously adding padding.
2025-10-18T15:52:35 < kovalevsky> Its not possible for me to add packed to the structure definition. Also, the main problem I see is that, the variable is already packed.
2025-10-18T15:52:42 < kovalevsky> Its a really weird case.
2025-10-18T15:52:56 < mawk> it's not the variable that you want to pack, which doesn't make a lot of sense, it's the definition of the structure
2025-10-18T15:53:15 < kovalevsky> But I dont want to pack the structure.
2025-10-18T15:53:22 < mawk> well then you will have padding inside
2025-10-18T15:53:51 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-18T15:54:07 < kovalevsky> Even, if I can do that, I wont be able to do it. This struct definition is being used in other parts of the codebase and after applying packed to the structure, I started to see in other parts of the codebase, some unaligned hard faults.
2025-10-18T15:54:30 < mawk> why does it matter that the structure has internal padding anyway
2025-10-18T15:55:00 < kovalevsky> Its hard to convey the message.
2025-10-18T15:55:14 < kovalevsky> Let me try to write it down.
2025-10-18T15:55:19 < mawk> are you sure you are using the exact same structure definition from the header file in your function that takes a pointer
2025-10-18T15:55:38 < kovalevsky> Yes. Im pretty sure.
2025-10-18T15:55:43 < mawk> you can use offsetof(...) to know the offset of each member
2025-10-18T15:55:56 < mawk> like offsetof(struct my_struct, a)
2025-10-18T15:55:59 < kovalevsky> But I already know the offset.
2025-10-18T15:56:45 < mawk> it doesn't matter anyway, you're not supposed to access members by offsets
2025-10-18T15:56:52 < mawk> you just do ptr->a or ptr->b
2025-10-18T15:56:55 < kovalevsky> The problem is that, I have this struct variable. When passing a pointer to this variable, of the same type into a function. The pointer under that function, takes the padding into consideration whereas, one level above calling this function, the structure is not padded.
2025-10-18T15:57:10 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-18T15:57:15 < mawk> can you maybe show the code
2025-10-18T15:57:15 < kovalevsky> This is the case, functioncall(&my_struct)
2025-10-18T15:57:18 < qyx> wat
2025-10-18T15:57:23 < qyx> paste the code
2025-10-18T15:57:40 < kovalevsky> whats the prefer method I guess? Paste bin here?
2025-10-18T15:57:47 < mawk> https://bpa.st/
2025-10-18T16:01:26 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-18T16:05:43 < kovalevsky> https://bpa.st/VTTIA
2025-10-18T16:05:50 < kovalevsky> Hopefully this will make sense.
2025-10-18T16:07:53 < kovalevsky> I can not understand why the variable is not being padded, taking into consideration that the compiler adds the pad when declaring the struct definition. For me, it seems that file_s is hiddenly packet at myfile.c, whereas when seeing from the pointer at file_system, is taking the padded version.
2025-10-18T16:08:20 < qyx> I would say p &p_fs prints the address of the pointer
2025-10-18T16:09:44 < kovalevsky> https://bpa.st/QOXAU
2025-10-18T16:09:55 < kovalevsky> Recheck please, I made a mistake when showing the values from gdb.
2025-10-18T16:10:28 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-18T16:13:13 < karlp> you're not printing the same thing....
2025-10-18T16:17:08 < kovalevsky> https://bpa.st/KFXUK
2025-10-18T16:17:44 < kovalevsky> Sorry about it, I can not use exactly the same code, so Im providing the really bare minimum. I think I already the adjustments to convey my questions.
2025-10-18T16:18:45 < kovalevsky> My solution would be to force the compiler that when declaring file_s, this variable should obey the padding structure.
2025-10-18T16:19:02 < kovalevsky> But I have not found a way to actually do this at variable level, not really sure if this is possible. 
2025-10-18T16:19:58 < kovalevsky> BTW all the codebase is using optimization for size, -Os
2025-10-18T16:27:24 < veverak> so, the whole thing is that in one compile unit it appears to be padded while in other it is not
2025-10-18T16:28:09 < veverak> yeah, any sources of these issues I am aware of are ... environment related... it can be that some of the type inside struct is actually defined differently between units because of some weird header ifdef sorcery
2025-10-18T16:28:24 < veverak> so, can't help without seeing the actual code and rest of the project
2025-10-18T16:41:06 < mawk> yeah without seeing the actual code we can't say
2025-10-18T16:41:45 < mawk> are there #ifdef blocks in the actual definition of the structure?
2025-10-18T16:43:35 < mawk> use offsetof to get the actual offset in the C code, not with gdb
2025-10-18T16:44:03 < mawk> use printf("%zu\n", offsetof(struct file_system, sector)); for instance
2025-10-18T16:44:29 < kovalevsky> @veverak, exactly, thats what I understand from what I seeing, which is really weird.
2025-10-18T16:44:53 < veverak> kovalevsky: usually caused by soemthing somewhere else in the code
2025-10-18T16:45:03 < veverak> to be sure, I would also check sizes of each member
2025-10-18T16:45:55 < kovalevsky> Sadly, I can not share the entire project and I know is hard to detect where the problem relies on without much context.
2025-10-18T16:45:58 < veverak> now that I think of it
2025-10-18T16:46:36 < veverak> doesnt the pragma pack macro require a closing macro or something like that?
2025-10-18T16:46:40 < veverak> this could also occur if that is not closed
2025-10-18T16:46:52 < mawk> it's not done with a macro usually
2025-10-18T16:47:03 < mawk> you just put __attribute__((__packed__)) on the definition
2025-10-18T16:47:16 < kovalevsky> No, there is no #ifdef inside the struct definition.
2025-10-18T16:47:17 < veverak> that would not cause this :P I am just giving kovalevsky ideas
2025-10-18T16:48:07 < mawk> and go look in the definition of struct mutex too
2025-10-18T16:48:20 < kovalevsky> @mawk, I can not place packed to the struct definition since I dont own that structure. Its coming from a module that I can not edit. 
2025-10-18T16:48:34 < qyx> I would rather reconsider the original requirement for the struct to be packed
2025-10-18T16:48:47 < qyx> oh
2025-10-18T16:48:53 < qyx> so you can't rely on anything then
2025-10-18T16:49:43 < qyx> the only thing iirc which is defined by the spec is there is no packing on the beginning on the struct, so the address of the first member is the same as the address of the struct
2025-10-18T16:49:45 < kovalevsky> I mean, I can edit the module but I already did just for the sake of testing, but the program started to have unaligned accesses in other parts of the codebase. So,even, if I can maintain my own version of this third party module, its already generating problems because of the packet addition.
2025-10-18T16:50:08 < qyx> why do you want it to be packed?
2025-10-18T16:50:29 < qyx> s/there is no packing/there is no padding/
2025-10-18T16:50:34 < kovalevsky> I dont want the structure to be packed, this is a suggestion from @mawk 
2025-10-18T16:50:46 < qyx> why do you care about the alignment then?
2025-10-18T16:50:58 < qyx> it should be aligned by default if there are any alignment requirements
2025-10-18T16:51:04 < kovalevsky> well, it should 
2025-10-18T16:51:18 < kovalevsky> but obviously the compiler is doing weird things
2025-10-18T16:51:48 < kovalevsky> because the struct instance is not aligned, well, one of the members of the struct is not naturally aligned.
2025-10-18T16:51:57 < veverak> qyx: eeh, if you read the discussion what happens is that in one compile unit it appears to be packed and in other not and there is no explenation as why that happens yet
2025-10-18T16:52:24 < kovalevsky> @veverak, you are completely right
2025-10-18T16:52:34 < veverak> kovalevsky: have you tried to get the sizeof of all members of the structure in both scenarios?
2025-10-18T16:52:35 < kovalevsky> i just can not believe is happening 
2025-10-18T16:52:46 < veverak> this is not normal C behavior, so there is bug somewhere, keep calm :)
2025-10-18T16:53:16 < kovalevsky> @veverak, would you please define what both scenarios do you mean?
2025-10-18T16:53:39 < veverak> kovalevsky: "here the struct seems padded" ,"here it is not"
2025-10-18T16:54:08 < kovalevsky> well, I can not obtain the sizeof of the pointer because is a pointer.
2025-10-18T16:54:17 < kovalevsky> Unles Im missing something :)
2025-10-18T16:54:40 < kovalevsky> I meant, I can not obtain the actual size of the struct through the pointer.
2025-10-18T16:54:53 < kovalevsky> And the pointer is the only thing that I have within the function.
2025-10-18T16:55:10 < veverak> hu?
2025-10-18T16:55:14 < qyx> are you including the same file_system.h from both c files?
2025-10-18T16:55:53 < qyx> veverak: meybe he is referring to sizeof(p_fs) would be 4?
2025-10-18T16:56:16 < qyx> it is declared as a pointer and not a struct in the parameter list
2025-10-18T16:56:25 < kovalevsky> @qyx, you got it.
2025-10-18T16:56:32 < veverak> struct file_system*p = ...; print("%i %i %i %i %i %i", sizeof(p->offset), sizeof(p->ate), sizeof(p->data), sizeof(p->sector), sizeof(p->ready), sizeof(p->lock));
2025-10-18T16:56:46 < kovalevsky> @veverak, ok thats different.
2025-10-18T17:06:37 < kovalevsky> I found the culprit.
2025-10-18T17:06:48 < veverak> do tell
2025-10-18T17:07:06 < kovalevsky> @veverak, this codebase have some pragmas with not closing...
2025-10-18T17:07:20 < veverak> :D :D 
2025-10-18T17:07:22 < kovalevsky> jaja
2025-10-18T17:07:30 < veverak> do I win a jackpot? that was one of my guesses :D
2025-10-18T17:07:30 < kovalevsky> what a mess...
2025-10-18T17:07:57 < kovalevsky> jaja
2025-10-18T17:08:21 < kovalevsky> @veverak, actually, I know about this in our codebase and I really thought that all those pragmas were supposed to be already delete it...
2025-10-18T17:08:30 < kovalevsky> well, it happens that NOT all of them
2025-10-18T17:08:42 < kovalevsky> @veverak, thanks for the hint
2025-10-18T17:09:15 < veverak> yeah, to be fair these errors are pain in the biscuit
2025-10-18T17:09:33 < kovalevsky> and also want to thank to you all that came with ideas about how to tackle this
2025-10-18T17:09:36 < veverak> because the opened pragma or similar thing can be literally anywhere and manifests throu specific combination of includes and ... jsut good luck finding it
2025-10-18T17:09:52 < kovalevsky> @veverak, indeed...
2025-10-18T17:10:09 < kovalevsky> well, those pragma were introduced when we were not having a lot knowledge of what we were doing
2025-10-18T17:10:35 < kovalevsky> i still believe that i dont know too much but had progress along the way
2025-10-18T17:10:46 < kovalevsky> but yeah, its really difficult to catch these bugs
2025-10-18T17:11:22 < kovalevsky> now, we have moved to use __attribute(packed) instead of pragma to ensure this problem does not happen again.
2025-10-18T17:11:39 < kovalevsky> When required, Im not fan of packing struct due performance.
2025-10-18T17:13:45 < kovalevsky> well, thanks again to everyone
2025-10-18T17:16:29 -!- NEYi [~NEYi@195.234.78.187] has quit [Quit: Leaving]
2025-10-18T17:28:45 < mawk> are you even using gcc kovalevsky ?
2025-10-18T17:28:49 < mawk> why do you use the pragma pack thing
2025-10-18T17:28:55 < mawk> that's a windows thing
2025-10-18T17:29:23 < mawk> and it's prone to errors
2025-10-18T17:30:42 < kovalevsky> @mawk, i never used pragma before, but this codebase was having pragmas all over the place.
2025-10-18T17:31:23 < kovalevsky> and yes, i use gcc.
2025-10-18T17:31:42 < mawk> you should replace the #pragma pack(push, 0) ... #pragma pack(pop) or whatever with the __attribute__((__packed__)) wherever they are
2025-10-18T17:32:12 < kovalevsky> @mawk, thats what we did in other projects, but in this particular one I did noticed that were still some pragmas around.
2025-10-18T17:32:22 < mawk> I see
2025-10-18T17:32:28 < kovalevsky> The common practice is as you suggested, use attribute packet only.
2025-10-18T18:19:25 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2025-10-18T18:46:34 -!- uyyye [~uyyye@2600:4041:5b26:d900:993:a6cc:c44b:5d61] has quit [Remote host closed the connection]
2025-10-18T18:46:43 < mawk> I upgraded the bootloader of the stm32wb55 radio co-processor
2025-10-18T18:47:02 < mawk> the instructions are awful and full of red boxes like "do that in that exact order or you will brick the device"
2025-10-18T18:47:05 < mawk> but seems like it worked
2025-10-18T18:47:10 < mawk> now I can load up the 802.15.4 stack
2025-10-18T18:48:18 < mawk> I have to rename a file named 0x495.stldr to 0x in the cubeprogrammer installation files so that it would correctly talk to the device
2025-10-18T18:49:02 < Steffanx> All this shit and you're not even using the timers yet, mawk
2025-10-18T18:49:16 < mawk> lol
2025-10-18T18:49:31 < mawk> yes the timers of the big bad evil ST engineers
2025-10-18T19:06:13 < mawk> how did you do the mass erase zyp
2025-10-18T19:06:27 < mawk> and what do they expect us to do, just like erase page by page?
2025-10-18T19:06:45 < mawk> and avoiding the pages that are in write protect mode
2025-10-18T19:10:13 < mawk> buy the aliexpress board and try 802.15.4 qyx
2025-10-18T19:10:22 < mawk> we need more people playing with that
2025-10-18T19:10:27 < mawk> given the lack of documentation 
2025-10-18T19:11:27 < mawk> I don't understand what these manufacturers are trying to achieve with all the domotic protocols
2025-10-18T19:12:15 < mawk> now we have matter which is a protocol on top of thread which is 6lowpan on top of 802.15.4, or on top of BLE
2025-10-18T19:12:21 < mawk> how much encapsulation is enough encapsulation 
2025-10-18T19:12:55 < mawk> they say it's for better inter-operability, but meh
2025-10-18T19:45:36 -!- Livio [~livio@user/livio] has quit [Ping timeout: 272 seconds]
2025-10-18T19:49:40 < ventYl> more protocols, more adidas
2025-10-18T19:55:04 < qyx> I still don't know which layer does mac for the 6lowpan+802.15.4 
2025-10-18T19:58:32 < mawk> what do you mean?
2025-10-18T19:58:46 < mawk> 802.15.4 specifies both MAC and PHY
2025-10-18T19:59:29 < mawk> then when sending a 6LoWPAN packet to a specific address you give this address to the 802.15.4 MAC 
2025-10-18T20:00:17 -!- z_ [~user@2601:c6:4100:88b0:3be0:b82e:cb26:f2ba] has joined ##stm32
2025-10-18T20:01:22 -!- z_ is now known as a
2025-10-18T20:01:27 < qyx> oh that's true
2025-10-18T20:01:27 -!- a is now known as Guest6219
2025-10-18T20:01:42 < qyx> I forgot, last time I did anything with 802.15.4 was in the uni in 2008 or so
2025-10-18T20:02:08 < mawk> it was like 11 years ago for me
2025-10-18T20:02:35 < mawk> I was able to ping devices from a linux host with 6lowpan, with an awesome 50% packet drop rate
2025-10-18T20:03:40 -!- Guest6219 [~user@2601:c6:4100:88b0:3be0:b82e:cb26:f2ba] has left ##stm32 []
2025-10-18T20:35:22 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 248 seconds]
2025-10-18T21:25:30 < qyx> I wasn't able to ping anything because I quit after writing half of my msc thesis
2025-10-18T22:07:36 -!- infisx [~infisc@user/infisc] has joined ##stm32
2025-10-18T22:11:17 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 260 seconds]
2025-10-18T22:23:49 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has joined ##stm32
2025-10-18T22:24:24 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-18T22:29:28 < qyx> what the hell, I finally booted openwrt 24.x on my rbm33g
2025-10-18T22:29:33 < qyx> but I still don't have the wifi command
2025-10-18T22:31:25 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-18T22:33:59 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-18T22:39:49 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-18T22:45:58 < qyx> ok the worst openwrt experience ever, literally nothing works, iw list dies with "nl80211 not found"
2025-10-18T22:47:10 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-18T22:48:13 < qyx> OMG I had to install kmod-mac80211 and it pulled wifi-scripts too
2025-10-18T22:48:44 < qyx> wifi-scripts was the package I was desperately trying to get and no google nor AI friend was able to suggest that the "wifi" command is in this package
2025-10-18T23:10:33 < qyx> [ 1080.776468] ath: phy0: Mac Chip Rev 0x00.0 is not supported by this driver
2025-10-18T23:10:55 < qyx> sometimes I think safu
2025-10-18T23:13:08 < qyx> I can't even get AR958x up, which was known to be working
2025-10-18T23:14:18 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 248 seconds]
2025-10-18T23:17:08 < qyx> also I needed to add a slash at the end of the "packages" feed, otherwise it was not seeing the packages because of some shitty bot protection thing on their web
2025-10-18T23:21:47 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Quit: Konversation terminated!]
2025-10-18T23:24:55 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-18T23:25:12 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Read error: Connection reset by peer]
2025-10-18T23:40:46 < kovalevsky> @mawk, which bootloader are you using?
--- Day changed Sun Oct 19 2025
2025-10-19T01:37:06 -!- System_Error [~SystemErr@user/systemerror] has quit [Ping timeout: 272 seconds]
2025-10-19T01:42:51 -!- infise [~infisc@user/infisc] has joined ##stm32
2025-10-19T01:45:22 -!- infisx [~infisc@user/infisc] has quit [Ping timeout: 260 seconds]
2025-10-19T01:45:45 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-19T01:45:46 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2025-10-19T03:12:47 -!- ferdna_ [~ferdna@user/ferdna] has joined ##stm32
2025-10-19T03:15:22 -!- ferdna [~ferdna@user/ferdna] has quit [Ping timeout: 248 seconds]
2025-10-19T03:17:14 -!- ferdna__ [~ferdna@user/ferdna] has joined ##stm32
2025-10-19T03:19:37 -!- ferdna_ [~ferdna@user/ferdna] has quit [Ping timeout: 246 seconds]
2025-10-19T03:25:43 -!- infisx [~infisc@user/infisc] has joined ##stm32
2025-10-19T03:29:04 -!- infise [~infisc@user/infisc] has quit [Ping timeout: 246 seconds]
2025-10-19T03:38:19 < tomeaton17> oh dear
2025-10-19T03:38:23 < tomeaton17> hello there
2025-10-19T04:08:52 -!- kovalevsky [~kovalevsk@fedora/kovalevsky] has quit [Ping timeout: 260 seconds]
2025-10-19T05:32:05 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-19T06:16:42 -!- ferdna__ [~ferdna@user/ferdna] has quit [Ping timeout: 248 seconds]
2025-10-19T06:19:12 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2025-10-19T06:23:43 -!- ferdna [~ferdna@user/ferdna] has quit [Remote host closed the connection]
2025-10-19T07:48:09 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-19T07:51:47 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-19T08:44:26 -!- qyx [~qyx@84.245.120.181] has quit [Ping timeout: 248 seconds]
2025-10-19T08:46:35 -!- qyx [~qyx@84.245.120.150] has joined ##stm32
2025-10-19T09:38:11 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-19T10:06:58 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-19T10:32:16 -!- Livio [~livio@user/livio] has quit [Ping timeout: 272 seconds]
2025-10-19T11:49:20 < mawk> I'm not sure I understand the hardfault lockup thing, when receiving a certain kind of exception when executing at priority "0 or less", does that count for user code too? what's the priority of user code
2025-10-19T12:07:21 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-19T12:13:10 < mawk> maximum value + 1
2025-10-19T13:04:11 < ventYl> isn't that as simple as that if you cause hardfault inside hardfault, or in situation where hardfault cannot be executed due to interrupt priorities, you get lockup?
2025-10-19T13:15:13 < qyx> I am in hardfault now
2025-10-19T13:27:05 < mawk> there's a lot more ways to trigger it ventYl 
2025-10-19T13:27:36 < mawk> but it's mostly all this same kind of thing, triggering a fault inside a fault
2025-10-19T13:28:04 < mawk> and for my case that includes a MPU error while in an IRQ handler (assuming it runs at priority 0)
2025-10-19T13:28:17 < mawk> if you enable the HFNMIE bit in the MPU
2025-10-19T13:29:24 < mawk> I passionately hate websites that redirect you to a local language version instead of English 
2025-10-19T13:29:28 < mawk> like IGN
2025-10-19T14:17:05 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-19T14:33:55 < BrainDamage> you can set the order of preferred locale in your browser, buts some sites still think they know better, geo2ip you, and force the localize version
2025-10-19T14:38:50 -!- kovalevsky [~kovalevsk@181.168.239.174] has joined ##stm32
2025-10-19T14:38:50 -!- kovalevsky [~kovalevsk@fedora/kovalevsky] has changed host
2025-10-19T16:52:36 < mawk> kovalevsky where?
2025-10-19T16:52:50 < mawk> for my job? we use the ST secure bootloader
2025-10-19T16:52:51 < mawk> SBSFU
2025-10-19T16:53:51 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-19T16:59:33 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2025-10-19T17:00:26 -!- ferdna [~ferdna@user/ferdna] has quit [Remote host closed the connection]
2025-10-19T17:00:44 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2025-10-19T17:29:27 < kovalevsky> @mawk, for the project you were mentioning
2025-10-19T17:30:22 < kovalevsky> @mawk, got it... i wonder if you have been using mcuboot, i never have used sbsfu though, dont know what features may bring into the table.
2025-10-19T17:31:18 < kovalevsky> also, some thoughts from someone that already have had well grounded experience debugging applications with trusted firmware enabled?
2025-10-19T18:37:40 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 246 seconds]
2025-10-19T19:29:49 < qyx> BSTFU you meant mawk?
2025-10-19T19:38:23 -!- plainoldcheese [~plainoldc@user/plainoldcheese] has joined ##stm32
2025-10-19T19:59:47 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 256 seconds]
2025-10-19T20:01:09 -!- plainoldcheese [~plainoldc@user/plainoldcheese] has quit [Ping timeout: 252 seconds]
2025-10-19T20:02:43 -!- plainoldcheese [~plainoldc@user/plainoldcheese] has joined ##stm32
2025-10-19T20:05:40 -!- plainoldcheese [~plainoldc@user/plainoldcheese] has quit [Excess Flood]
2025-10-19T20:11:04 -!- plainoldcheese [~plainoldc@user/plainoldcheese] has joined ##stm32
2025-10-19T20:18:35 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2025-10-19T20:26:24 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-19T21:05:00 -!- plainoldcheese [~plainoldc@user/plainoldcheese] has quit [Quit: WeeChat 4.7.1]
2025-10-19T21:05:19 -!- plainoldcheese [~plainoldc@user/plainoldcheese] has joined ##stm32
2025-10-19T21:10:17 -!- specing [~specing@user/specing] has quit [Ping timeout: 260 seconds]
2025-10-19T21:28:41 -!- plainoldcheese is now known as creamcheese
2025-10-19T21:32:21 -!- creamcheese is now known as plainoldcheese
2025-10-19T21:38:03 -!- plainoldcheese [~plainoldc@user/plainoldcheese] has quit [Quit: WeeChat 4.7.1]
2025-10-19T21:38:25 -!- plainoldcheese [~plainoldc@user/plainoldcheese] has joined ##stm32
2025-10-19T21:47:48 -!- plainoldcheese [~plainoldc@user/plainoldcheese] has quit [Read error: Connection reset by peer]
2025-10-19T21:54:04 -!- plainoldcheese [~plainoldc@user/plainoldcheese] has joined ##stm32
2025-10-19T21:57:24 -!- plainoldcheese [~plainoldc@user/plainoldcheese] has quit [Client Quit]
2025-10-19T22:39:29 < mawk> no qyx SBSFU
2025-10-19T22:39:35 < mawk> that's how they call it in the code
2025-10-19T22:39:52 < mawk> kovalevsky SBSFU is something for STM32
2025-10-19T22:40:00 < mawk> for my personal nordic project I don't use a bootloader
2025-10-19T22:40:14 < mawk> it's useless for personal projects I just flash using swd
2025-10-19T22:40:34 < mawk> qyx https://www.st.com/en/embedded-software/x-cube-sbsfu.html
2025-10-19T22:54:59 -!- krabrock_ [~krabrock@about/hackers/krabrock] has joined ##stm32
2025-10-19T22:55:13 -!- krabrock [~krabrock@about/hackers/krabrock] has quit [Ping timeout: 264 seconds]
2025-10-19T23:23:13 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 256 seconds]
2025-10-19T23:36:30 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2025-10-19T23:53:33 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
--- Day changed Mon Oct 20 2025
2025-10-20T00:49:37 -!- specing [~specing@user/specing] has joined ##stm32
2025-10-20T00:52:36 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2025-10-20T00:54:02 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Quit: bitmask]
2025-10-20T01:17:22 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has quit [Ping timeout: 246 seconds]
2025-10-20T01:38:46 -!- nomorekaki [~nomorekak@37-136-166-42.rev.dnainternet.fi] has joined ##stm32
2025-10-20T01:53:07 < nomorekaki> pump crew
2025-10-20T01:54:52 < qyx> pumped out this night
2025-10-20T01:59:12 < nomorekaki> did you get the real estate?
2025-10-20T02:00:14 < nomorekaki> and obvious question how do you get internets?
2025-10-20T02:55:22 -!- kovalevsky [~kovalevsk@fedora/kovalevsky] has quit [Ping timeout: 246 seconds]
2025-10-20T04:20:09 -!- specing [~specing@user/specing] has quit [Ping timeout: 256 seconds]
2025-10-20T04:27:01 -!- specing [~specing@user/specing] has joined ##stm32
2025-10-20T04:40:45 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-20T04:52:52 -!- duude__ [~duude__@user/duude/x-4676560] has quit [Ping timeout: 260 seconds]
2025-10-20T04:53:22 -!- duude__ [~duude__@user/duude/x-4676560] has joined ##stm32
2025-10-20T05:15:00 -!- duude__ [~duude__@user/duude/x-4676560] has quit [Ping timeout: 252 seconds]
2025-10-20T05:15:37 -!- duude__ [~duude__@user/duude/x-4676560] has joined ##stm32
2025-10-20T05:29:04 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2025-10-20T07:00:24 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-20T07:42:55 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-20T08:12:37 -!- nomorekaki [~nomorekak@37-136-166-42.rev.dnainternet.fi] has quit [Quit: Client closed]
2025-10-20T08:20:11 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-20T08:37:24 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-20T09:20:40 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2025-10-20T09:29:14 -!- infisx [~infisc@user/infisc] has quit [Quit: Vive la révolution.]
2025-10-20T09:33:44 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-20T09:59:35 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 256 seconds]
2025-10-20T10:42:43 -!- tabemann [~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net] has quit [Remote host closed the connection]
2025-10-20T10:43:11 -!- tabemann [~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net] has joined ##stm32
2025-10-20T11:03:08 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-20T11:32:35 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-20T11:33:17 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-20T11:39:21 -!- infisd [~infisc@user/infisc] has quit [Read error: Connection reset by peer]
2025-10-20T12:24:34 -!- Livio [~livio@user/livio] has quit [Ping timeout: 272 seconds]
2025-10-20T13:22:11 -!- c10ud [~c10ud@user/c10ud] has quit [Read error: Connection reset by peer]
2025-10-20T13:25:09 -!- c10ud [~c10ud@user/c10ud] has joined ##stm32
2025-10-20T13:42:35 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-20T14:09:21 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-20T14:22:18 -!- kovalevsky [~kovalevsk@190.103.220.71] has joined ##stm32
2025-10-20T14:22:18 -!- kovalevsky [~kovalevsk@fedora/kovalevsky] has changed host
2025-10-20T14:22:51 -!- kovalevsky [~kovalevsk@fedora/kovalevsky] has quit [Remote host closed the connection]
2025-10-20T16:06:47 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has joined ##stm32
2025-10-20T17:12:26 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-20T17:13:07 < karlp> weird. freertos cahngelog has htat from 10.4.4, if you specify a priority higher than configured max it will assert.
2025-10-20T17:13:17 < karlp> I'm on 10.4.6, and it doesn't assert, it just doens't work...
2025-10-20T18:01:49 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2025-10-20T19:35:52 -!- System_Error [~SystemErr@user/systemerror] has quit [Ping timeout: 272 seconds]
2025-10-20T19:44:57 < zyp> has hwat? 
2025-10-20T19:46:31 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-20T20:00:12 < karlp> has that.
2025-10-20T20:00:43 < karlp> doesn't matter too much, just a little odd in my mind that turning down the max priorities it never asserted just... didn't run properly. I can see the assert in the code.
2025-10-20T20:01:36 < zyp> what is that?
2025-10-20T20:03:07 < karlp> some space saving I guess, https://www.freertos.org/Documentation/02-Kernel/03-Supported-devices/02-Customization#configmax_priorities
2025-10-20T20:03:12 < karlp> I had some sample code that set it to 5.
2025-10-20T20:03:28 < karlp> and this nxp code I'm trying to port/hammer into place had it set to 18 for... reasons?
2025-10-20T20:03:59 < karlp> anyway, things didn't work when their code was setting like 6 or 7, with 5 as the max, but the asserts weren't hitting. which is giving me bad spider senses.
2025-10-20T20:04:52 < karlp> I'm now getting enumeration to start, but still doesn't run, with my laks setup around their codebase, and I'm getting a bit wonky trying to figure out what the hell is different now that the clocks are all setup :)
2025-10-20T20:04:57 < karlp> onwards tomorrow...
2025-10-20T20:06:50 < mawk> does it reset the peripherals when I stop their clocks?
2025-10-20T20:16:58 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-20T20:19:26 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-20T20:29:04 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Quit: Konversation terminated!]
2025-10-20T20:29:09 < qyx> karlp: it has queues for each priority level, so runtime memory saving
2025-10-20T20:30:58 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-20T20:31:08 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Read error: Connection reset by peer]
2025-10-20T20:42:35 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-20T20:48:27 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has joined ##stm32
2025-10-20T20:58:31 -!- bitmask [~bitmask@ool-43525d25.dyn.optonline.net] has quit [Ping timeout: 240 seconds]
2025-10-20T21:04:49 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 264 seconds]
2025-10-20T21:19:41 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2025-10-20T21:23:19 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-20T21:25:39 -!- infisd [~infisc@user/infisc] has quit [Read error: Connection reset by peer]
2025-10-20T21:38:19 < mawk> I'm trying the cortex M DEEPSLEEP mode
2025-10-20T21:38:30 < mawk> I'm not entirely sure what's the state of the peripherals at reset
2025-10-20T21:38:54 < mawk> only thing I found is that at wakeup the CPU is clocked from an internal RC oscillator and you have to change it back
2025-10-20T21:39:13 < mawk> but does systick restart, do the ST peripherals need reconfiguring, etc
2025-10-20T21:57:48 < qyx> it is descri ed in the power saving whatever section
2025-10-20T21:58:03 < qyx> how to enter, how to exit, what happens, waht clocks
2025-10-20T21:58:23 < qyx> on stm32, deepsleep enables stop modes
2025-10-20T21:59:09 < qyx> which ranges from peripherals mostly running to mostly not running, memory from mostly preserved in stop0 to mostly not
2025-10-20T21:59:59 < qyx> the first sleep mode not preserving peripheral state is standby afaik, which requires reset to exit it
2025-10-20T22:00:37 < qyx> but this is sort of knowledge I always check because I don't do sleep states often
2025-10-20T22:03:34 < mawk> yeah I read that section 
2025-10-20T22:03:49 < mawk> but it doesn't say what happens to peripherals after exiting the mode
2025-10-20T22:03:54 < mawk> it says the clocks are gated during sleep
2025-10-20T22:04:09 < mawk> but does that automatically imply peripheral register contents are lost?
2025-10-20T22:04:14 < qyx> they definitely do not need reinit
2025-10-20T22:04:19 < mawk> hmmm
2025-10-20T22:04:34 < qyx> maybe some documented things got reset, but otherwise they keep the state
2025-10-20T22:04:49 < qyx> idk about eg. h7 with multiple power domains
2025-10-20T22:04:55 < mawk> nice
2025-10-20T22:05:02 < mawk> it's F7
2025-10-20T22:05:17 < qyx> f7 is just f4 with m7 core, isn't it?
2025-10-20T22:05:25 < mawk> I suppose
2025-10-20T22:05:51 < qyx> I used f7 twice
2025-10-20T22:05:54 < mawk> there's a regulator that you can put in low power mode but I haven't tried that
2025-10-20T22:06:00 < qyx> both "projects" failed
2025-10-20T22:06:20 < qyx> one was a low power li ux board for remote debugging
2025-10-20T22:06:29 < qyx> with uclinux
2025-10-20T22:06:41 < qyx> 32 MB of DRAM and some spi flash
2025-10-20T22:06:44 < mawk> a long time ago then I suppose
2025-10-20T22:07:07 < qyx> the linux shit kept hardfaulting when I ran anything involving the shell
2025-10-20T22:07:21 < qyx> otherwise it ran "okay"
2025-10-20T22:08:06 < qyx> I tracked it down to something not being jncompatible with the uclinux's fork not forking the usual way
2025-10-20T22:08:37 < qyx> yeah maybe 2018 or so
2025-10-20T22:08:37 < mawk> well if there's no MMU you can only vfork() right
2025-10-20T22:09:34 < qyx> yeah
2025-10-20T22:24:07 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 240 seconds]
2025-10-20T22:26:55 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2025-10-20T22:40:48 -!- System_Error [~SystemErr@user/systemerror] has quit [Ping timeout: 272 seconds]
2025-10-20T22:41:25 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 264 seconds]
2025-10-20T22:43:50 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2025-10-20T22:44:11 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-20T23:44:25 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 264 seconds]
2025-10-20T23:51:31 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 246 seconds]
2025-10-20T23:52:35 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-20T23:54:31 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
--- Day changed Tue Oct 21 2025
2025-10-21T00:23:31 < jbo> Steffanx
2025-10-21T00:42:08 < Steffanx> Mr jbo 
2025-10-21T00:44:40 < Steffanx> Pizza time?
2025-10-21T00:56:22 < jbo> Steffanx, you were right
2025-10-21T00:56:35 < jbo> Steffanx, 17th was "created shipping label", actual shipping happened on 20th
2025-10-21T00:59:14 < Steffanx> Lol :)
2025-10-21T00:59:27 < Steffanx> Bastards
2025-10-21T00:59:50 < Steffanx> Giving the jbo false hope 
2025-10-21T01:10:35 -!- remcycles [~remcycles@c-24-19-134-216.hsd1.wa.comcast.net] has joined ##stm32
2025-10-21T01:37:43 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2025-10-21T05:10:04 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has quit [Ping timeout: 244 seconds]
2025-10-21T05:22:36 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has joined ##stm32
2025-10-21T05:37:13 < mrec_> I'm counting pulses via external pin and a timer, as far as I understand it needs a dummy pulse to enable the counter, does anyone know a workaround how to count from the first occuring pulse? or force it to count at a certain time without the need of the external dummy pulse?
2025-10-21T06:13:48 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-21T06:20:08 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-21T07:48:08 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-21T07:54:42 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-21T08:14:15 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-21T08:17:30 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-21T08:21:59 < jpa-> mrec_: have you tried forcing timer update by setting the update bit from software?
2025-10-21T08:22:28 < jpa-> or why would it require a dummy pulse
2025-10-21T08:45:17 -!- qyx [~qyx@84.245.120.150] has quit [Ping timeout: 260 seconds]
2025-10-21T08:46:45 -!- qyx [~qyx@84.245.120.105] has joined ##stm32
2025-10-21T09:08:16 < qyx> so, how do I determine which inputs are seg and com on an arbitrary china segment LCD display?
2025-10-21T09:10:52 < qyx> I guess I can measure duty cycle on the outputs
2025-10-21T09:27:38 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2025-10-21T09:28:46 < jpa-> yeah, scoping is easiest if you have it in device
2025-10-21T09:29:00 < jpa-> otherwise put some small voltage square wave from signal generator and touch pins to see what happens
2025-10-21T09:30:11 < qyx> ok scoping is not an option, they all look the same
2025-10-21T09:31:18 < qyx> like this https://software-dl.ti.com/lprf/sensor_controller_studio/docs/cc13x2_cc26x2_help/html/lcd_controller__1.html
2025-10-21T09:37:26 < qyx> ok multimeter in diode test mode works to illuminate them
2025-10-21T09:47:25 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has quit [Ping timeout: 264 seconds]
2025-10-21T10:02:48 < qyx> ok first four pins are comons, the reast are segments
2025-10-21T10:02:57 < qyx> commons, rest
2025-10-21T10:04:19 < qyx> now I need to grab some L053, a LCD prototype zebra board and do some wonders
2025-10-21T10:05:38 < ventYl> btw, is it possible to get some LCD flex strips? i managed to fuck one up
2025-10-21T10:06:32 < qyx> polarizers?
2025-10-21T10:06:54 < qyx> zebra rubber?
2025-10-21T10:11:23 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 250 seconds]
2025-10-21T10:14:09 < ventYl> not zebra rubber, conductive foil used to connect LCD displays
2025-10-21T10:14:25 < ventYl> no fancy shape, just plain rectangular foil with straight conductors
2025-10-21T10:14:42 < ventYl> like some old calculators had
2025-10-21T10:14:43 < qyx> ffc?
2025-10-21T10:15:52 < ventYl> almost, yet it is glued at both ends rather than having any kind of socket/plug
2025-10-21T10:25:11 -!- PaulFertser_ [~paul@paulfertser.info] has joined ##stm32
2025-10-21T10:25:29 -!- PaulFertser [~paul@paulfertser.info] has quit [Read error: Connection reset by peer]
2025-10-21T10:32:58 -!- PaulFertser_ is now known as PaulFertser
2025-10-21T10:33:34 < mawk> TCM memory does not have DCache right
2025-10-21T10:33:57 < mawk> so I don't have to call SCB_InvalidateDCache_by_Addr before reading from a DMA buffer that is in TCM
2025-10-21T10:35:20 < mawk> >TCMs always behave as Non-cacheable Non-shared Normal memory
2025-10-21T10:35:22 < mawk> seems like so
2025-10-21T10:40:50 < mrec_> jpa-: I tried forcing a timer update too it doesn't change its behaviour
2025-10-21T10:41:20 < mrec_> two timers are configured as Slave mode - external clock mode 1
2025-10-21T10:41:43 < mrec_> two timers behave exactly the same, the first external pulse is skipped
2025-10-21T10:49:22 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-21T11:00:14 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-21T11:06:56 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-21T12:14:08 < mrec_> __HAL_TIM_GET_COUNTER is just not returning an up to date value
2025-10-21T12:14:13 < mrec_> it is counting the pulse
2025-10-21T12:25:32 < mrec_> hmm waiting like 200 milliseconds will sync it.. I wonder if there's a way to force it
2025-10-21T12:44:02 < mrec_> okay seems like I'm getting somewhere here and it's all good
2025-10-21T12:59:10 < mrec_> seems like lazy dma related, I need to send a dummy request first to make it happen quick
2025-10-21T13:35:01 < ventYl> huh, Qt bought IAR
2025-10-21T14:22:11 -!- mercenary [~mercenary@user/mercenary] has quit [Quit: ZNC 1.10.1 - https://znc.in]
2025-10-21T14:23:38 -!- mercenary [~mercenary@user/mercenary] has joined ##stm32
2025-10-21T14:37:09 < karlp> no more qtcreator then I guess.
2025-10-21T14:38:17 < ventYl> other way around
2025-10-21T14:38:32 < ventYl> IAR was absorbed into Qt
2025-10-21T14:41:37 < karlp> yeah, but IAR has surely got a bigger presence as an IDE than qtcreator.
2025-10-21T14:41:56 < ventYl> maybe in embedded industry
2025-10-21T14:42:11 < ventYl> outside it is pretty much non-existent I guess
2025-10-21T15:17:24 < mrec_> qtcreator is clean and lean
2025-10-21T16:01:32 -!- PhantomWork [~PhantomWo@user/phantom] has joined ##stm32
2025-10-21T16:01:36 < c10ud> ewarm ide is the biggest letdown of the suite i'd say
2025-10-21T16:02:17 < c10ud> let's hope they don't employ Qt company commercial tactics
2025-10-21T16:02:24 < PhantomWork> Hi there, in stm32cubeide... I have some code that is common to a few projects. What is the proper way to handle this?
2025-10-21T16:03:36 < qyx> I would say source-only libraries are handled by a source packaging system or VCS
2025-10-21T16:03:48 < qyx> cubeide has probably nothing to do with it
2025-10-21T16:03:58 < qyx> you can use git and submodules if you are brave enough
2025-10-21T16:04:50 < qyx> because, well, you are already using git for your main project, aren't you? AREN'T YOU?
2025-10-21T16:05:53 < PhantomWork> qyx: too busy/lazy to figure out git  :D
2025-10-21T16:08:08 < PhantomWork> what I did is I put the prototype in util.h and the function in util.c, util.c also #include "util.h"          and my main.c... that is where things break... I tried to #include "i:\path\to\util.h"     and it fail spectacularly... 155 build error now  :D
2025-10-21T16:09:09 < PhantomWork> so I guess I did it totally wrong
2025-10-21T16:10:07 < qyx> most probably
2025-10-21T16:10:13 < qyx> also you don't want to include absolute paths
2025-10-21T16:12:03 < qyx> it is hard to say without any specifics
2025-10-21T16:12:14 < PhantomWork> I know, but relative failed too, so I went meh  let's figure that later.... and absolute failed
2025-10-21T16:12:40 < PhantomWork> and that is why I'm here. not sure what I do wrong
2025-10-21T16:24:40 < PhantomWork> any idea?
2025-10-21T16:33:59 < mercenary> no idea about cubeide, but in my projects common code goes into a library, and headers are included as "header.h" with a -Iinclude_path
2025-10-21T16:39:01 < PhantomWork> so I changed things, it load the .h as per my #warning in it proves it   but gcc spit out 155 "function not found" errors....    but the #warning in my .c don't show up
2025-10-21T17:05:51 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2025-10-21T17:16:37 < PhantomWork> I got it!
2025-10-21T17:17:25 < Steffanx> Bingo!
2025-10-21T17:23:32 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-21T17:24:41 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-21T17:25:05 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-21T17:40:57 < PhantomWork> you have to add the path to 2 places, in order. you add it to the first path, then the directory name show up to be added in the second place, in a confusing way
2025-10-21T17:52:54 < ventYl> I guess it would be beneficial to read some primer on structured software development in C
2025-10-21T17:53:07 < ventYl> it'll save you a lot of time in the long run
2025-10-21T18:00:50 < Steffanx> "Structured Software Development using CreepyOS" is a thing yet ventYl ?
2025-10-21T18:02:28 < ventYl> you can do structured software development even without creepyos
2025-10-21T18:02:34 < ventYl> yet, something, somewhere happened
2025-10-21T18:02:36 < Steffanx> But that's no fun
2025-10-21T18:02:45 < ventYl> i get ~50 clones of the repository per week
2025-10-21T18:02:59 < ventYl> that's a solid start of road towards the word dominance
2025-10-21T18:03:06 < ventYl> *world
2025-10-21T18:03:18 < Steffanx> Jia Tan likes your work.
2025-10-21T18:03:53 < ventYl> i don't know where it comes from, website has constantly the same poor visit rate
2025-10-21T18:03:59 < ventYl> mostly us
2025-10-21T18:04:06 < ventYl> and singapore
2025-10-21T18:06:29 < ventYl> germany is third
2025-10-21T18:06:40 < ventYl> that must be a mistake, that country is still running on 20th century
2025-10-21T18:31:16 -!- PhantomWork [~PhantomWo@user/phantom] has quit [Quit: Leaving]
2025-10-21T18:37:24 -!- fenugrec [~f@192.214.232.39] has joined ##stm32
2025-10-21T19:08:55 < qyx> Steffanx: related, I like xz
2025-10-21T19:09:10 < qyx> now I can haz 2 times more hpdates
2025-10-21T19:09:17 < qyx> *updates
2025-10-21T20:00:50 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-21T20:05:53 < jpa-> qyx: next, only do deltas
2025-10-21T20:14:54 < fenugrec> xdelta3
2025-10-21T20:22:07 < qyx> jpa-: yeah
2025-10-21T20:37:15 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 252 seconds]
2025-10-21T20:52:09 < jpa-> meh, esp32c6 has this built-in usb-serial and jtag thing for debugging
2025-10-21T20:52:34 < jpa-> it works when i connect with USB C-A cable.. it doesn't work when i connect with USB C-C cable
2025-10-21T20:53:06 < jpa-> and yes, i have 5.1k on each CC pin, and it actually gets recognized with same USB device info in both cases
2025-10-21T20:53:15 < jpa-> but nothing comes from the serial port when using a C cable
2025-10-21T20:54:58 < ds2> is the host on the correct side?
2025-10-21T20:57:28 < jpa-> what do you mean?
2025-10-21T20:58:09 < ds2> USB is a host/device protocol. One side has to be a host and other has to be a device
2025-10-21T20:58:30 < jpa-> yes, i have the cable between the ESP32 (a device) and my computer (a host)
2025-10-21T20:58:36 < ds2> USB-C allows for some fluidity in how it is determined. USB-A should always be a host side
2025-10-21T20:58:58 < ds2> that what you expect but is that what is happening
2025-10-21T20:58:59 < jpa-> https://jpa.kapsi.fi/stuff/pix/esp32c6_usb_fail.png    in the failing case, it gets through the enumeration fine, but then just keeps NAKing bulk reads
2025-10-21T20:59:22 < jpa-> i'd say because enumeration works the host vs. device roles get assigned correctly
2025-10-21T20:59:53 < ds2> next thing to check is another USB-C cable... USB-C cables seems to be like the wildwild west
2025-10-21T21:00:18 < ds2> are you negotiating USB 1.x or 2.x?
2025-10-21T21:00:26 < jpa-> usb full speed
2025-10-21T21:00:37 < jpa-> that's all esp32c6 supports anyway
2025-10-21T21:00:43 < ds2> 12Mbs?
2025-10-21T21:00:56 < jpa-> yeah
2025-10-21T21:01:27 < ds2> the 1.5M stuff seems to work almost anywiring but fast stuff depends on the cable
2025-10-21T21:01:48 < ds2> if you have another C-C cable, that's the easiest check (preferably not another one of the same pack/type)
2025-10-21T21:02:23 < jpa-> signal quality looks ok on scope and i don't see any retransmissions during the enumeration so it seems like the problems suddenly only start with the bulk transfers
2025-10-21T21:03:44 < ds2> how did you use the C-A cable? with adapters ?
2025-10-21T21:03:44 < jpa-> hmm.. it seems to be something to do with the USB3.0 signals, even though i'm not using those
2025-10-21T21:03:55 < jpa-> A port on host vs. C port on host
2025-10-21T21:03:59 < ds2> USB3.0 is on a different pair
2025-10-21T21:04:26 < jpa-> now i tried with USB3.0 C-A cable, and it doesn't work.. but when i put a USB2.0 A-A extender in between, it again works!
2025-10-21T21:04:31 < ds2> what kind of port is soldered on to the PC side?
2025-10-21T21:04:46 < ds2> or does your PC have both A and C ports?
2025-10-21T21:04:49 < jpa-> motherboard has both A and C ports (all USB3)
2025-10-21T21:05:52 < ds2> is the power negotiations correct? i.e. the esp32 is asking for the correct amount of power and never exceeding it?
2025-10-21T21:06:06 < jpa-> it happens even when externally powered
2025-10-21T21:06:57 < ds2> are you sure it does not draw USB power even if externally powered? i.e. replaced diode with a 0ohm shut
2025-10-21T21:08:42 < jpa-> pretty sure
2025-10-21T21:09:15 < jpa-> besides, it's well below 500mA anyway, and i can see it drawing the expected current from psu
2025-10-21T21:11:52 < jpa-> hmm, the behavior varies between host ports
2025-10-21T21:12:14 < jpa-> definitely smells like signal quality issues, but i wonder why there are no signs of it during enumeration
2025-10-21T21:26:31 < jpa-> rebooted host, tried another C-C cable, no difference
2025-10-21T21:29:03 < jpa-> another host, same C-C cable works
2025-10-21T21:29:48 < jbo> jpa-, 
2025-10-21T21:30:17 < jpa-> and now it looks like my packets from jbo are getting cut off, too!
2025-10-21T21:51:58 < Steffanx> But that is to blame on jbo for sure. 
2025-10-21T21:55:15 < jpa-> this silly esp32 bug seems to *only* occur with my desktop PC, the usb drivers of which are pretty flaky anyway.. but in packet captures it definitely looks like esp32 bug
2025-10-21T21:56:04 < jpa-> fortunately it's just a debug interface.. it's not like i need the debug interface to work on my development system
2025-10-21T21:57:52 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-21T21:58:21 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Client Quit]
2025-10-21T21:58:25 < jpa-> another invention tonight: you can plug USB-C cable to USB-A port and short out VBUS & GND
2025-10-21T21:58:56 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-21T22:08:15 < Steffanx> Don't do that jpa- 
2025-10-21T22:17:46 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2025-10-21T22:35:23 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has joined ##stm32
2025-10-21T22:36:58 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 248 seconds]
2025-10-21T23:21:48 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-21T23:39:32 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 260 seconds]
2025-10-21T23:42:11 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2025-10-21T23:55:42 -!- krabrock_ is now known as krabrock
--- Day changed Wed Oct 22 2025
2025-10-22T00:07:54 -!- kovalevsky [~kovalevsk@181.168.239.174] has joined ##stm32
2025-10-22T00:07:54 -!- kovalevsky [~kovalevsk@fedora/kovalevsky] has changed host
2025-10-22T00:18:54 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Ping timeout: 252 seconds]
2025-10-22T00:49:49 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has quit [Ping timeout: 264 seconds]
2025-10-22T01:10:03 -!- nomorekaki [~nomorekak@37-136-166-42.rev.dnainternet.fi] has joined ##stm32
2025-10-22T01:10:10 < nomorekaki> early
2025-10-22T01:14:37 -!- NEYi [~NEYi@195.234.78.187] has quit [Ping timeout: 260 seconds]
2025-10-22T01:39:21 < kovalevsky> I got another interesting problem. Somebody has ever found a switch to the right in direction when having a function?
2025-10-22T01:39:52 < kovalevsky> I have a function that accepts uint8_t *buf, int16_t *, bool *
2025-10-22T01:40:54 < kovalevsky> I see that when executing the function, the values are stored in r0, r1, r2 respectively. However, at some point during the function these arguments are not pointing anymore to what it is on r0, r1, r2.
2025-10-22T01:42:10 < kovalevsky> buf points to 0x2001feb9, second argument to points to 0x20030f2a, and third argument points to 0x20030fb1. When the arguments addresses are changed, I see that are shifted to the left.
2025-10-22T01:42:39 < kovalevsky> So that, now: buf poitns to 0x0, second arg to 0x2001feb9, and third one 0x20030f2.
2025-10-22T01:43:16 < kovalevsky> And the function itself is not doing anything to change those variables whatsoever. So, Im not really sure what is happening. This function does not have any optimization.
2025-10-22T01:57:43 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2025-10-22T02:22:25 < fenugrec> what
2025-10-22T03:26:28 -!- nomorekaki [~nomorekak@37-136-166-42.rev.dnainternet.fi] has quit [Quit: Client closed]
2025-10-22T04:54:37 -!- kovalevsky [~kovalevsk@fedora/kovalevsky] has quit [Ping timeout: 264 seconds]
2025-10-22T05:47:49 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-22T07:49:00 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-22T08:24:08 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-22T08:29:35 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Read error: Connection reset by peer]
2025-10-22T08:33:56 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2025-10-22T08:42:31 < ventYl> I'd vote for interrupt handler fucking up stack
2025-10-22T08:42:33 < ventYl> or something else
2025-10-22T08:46:24 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2025-10-22T08:48:08 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-22T10:00:32 -!- nerozero [~nerozero@87.253.63.54] has quit [Remote host closed the connection]
2025-10-22T10:02:28 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-22T10:13:31 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-22T10:51:41 < jpa-> nasty thing about enabling stack overflow detection is that you'll find out the code has been overflowing stack successfully for years
2025-10-22T10:52:45 < qyx> I am running freertos with stack overflow detection and it is fine
2025-10-22T10:52:54 < qyx> also I am using memory allocation failed hook
2025-10-22T10:53:08 < qyx> for cases I forge to catch failed attempts
2025-10-22T10:53:23 < qyx> so, last week, my thing began hardfaulting
2025-10-22T10:54:05 < qyx> I was wtf, got the device back to the lab on debugger, ran out of memory
2025-10-22T10:54:14 < qyx> was expecting a log message about that
2025-10-22T10:54:23 < qyx> but no, my allocation failed hook was hardfaulting
2025-10-22T10:54:46 < qyx> so instead of failing gracefuly with if (mem == NULL), it failed badly in the hook
2025-10-22T10:54:56 < qyx> I disabled to hook for greater good
2025-10-22T10:55:56 < ventYl> jpa-: if you never ran without one, you won't be surprised
2025-10-22T11:01:39 < qyx> what do pros think about push-pull SIM sockets?
2025-10-22T11:01:54 < qyx> samesky SIM-14-B for example
2025-10-22T11:05:23 < qyx> or SIM6050
2025-10-22T11:15:38 < qyx> lol fiboxom N510-GL LTE nb1/nb1 is <4 eur
2025-10-22T11:54:43 < tomeaton17> hello
2025-10-22T12:13:34 < zyp> hrm
2025-10-22T12:13:34 < zyp> ERROR os: ***** BUS FAULT *****
2025-10-22T12:13:34 < zyp> ERROR os:   Precise data bus error
2025-10-22T12:13:34 < zyp> ERROR os:   BFAR Address: 0x32
2025-10-22T12:13:42 < zyp> I thought I fixed this on monday
2025-10-22T12:16:42 < zyp> fun part is that this is some race condition, and now it took 40 minutes to occur
2025-10-22T12:19:19 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Ping timeout: 240 seconds]
2025-10-22T12:19:20 < jpa-> zyp: time to buy an orbtrace
2025-10-22T12:20:50 < mawk> why is BLE so complicated with ST
2025-10-22T12:20:54 < mawk> <jpa-> nasty thing about enabling stack overflow detection is that you'll find out the code has been overflowing stack successfully for years
2025-10-22T12:21:03 < mawk> same when I disabled access to the NULL address in our codebase
2025-10-22T12:21:10 < mawk> turns out it was dereferencing NULL left and right
2025-10-22T12:42:47 -!- ilgrim [~ilgrim@xinu.me] has quit [Quit: WeeChat 4.5.2]
2025-10-22T12:57:26 < qyx> mawk: do't you have some real world cat1bis performance figures?
2025-10-22T13:14:27 < mawk> no we just use lte-m
2025-10-22T13:18:58 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-22T13:26:40 -!- George [~George@5.249.149.67] has joined ##stm32
2025-10-22T13:27:12 -!- George [~George@5.249.149.67] has quit [Client Quit]
2025-10-22T13:27:26 < Steffanx> Call Stefan. He knows all about cat1bis and ublox
2025-10-22T13:29:43 < ventYl> you guys should convert to the church of memory protection long ago. you would have completely different problems now.
2025-10-22T13:29:54 < ventYl> can't say they'd be easier though
2025-10-22T13:31:47 < qyx> I am now in the church of broken lte modems
2025-10-22T13:31:51 -!- kovalevsky [~kovalevsk@fedora/kovalevsky] has joined ##stm32
2025-10-22T13:32:33 < qyx> that damned unisoc thing makes 8 virtual serial devices
2025-10-22T13:33:33 < karlp> lol. lte is teh suck.
2025-10-22T13:33:53 < karlp> up there with fuckin you ess bee
2025-10-22T13:34:01 < qyx> Wed Oct 22 10:33:54 2025 local2.info chat[25752]: +CME ERROR
2025-10-22T13:34:14 < qyx> why don't I have the exact error
2025-10-22T13:34:20 < qyx> despite setting AT+CMEE=2
2025-10-22T13:36:48 < zyp> jpa-, I'm even testing this on one of the few trace-capable boards I have (h573 nucleo), so I should really figure out how to run this with orbmortem
2025-10-22T13:41:29 < zyp> this is some use-after-free bug due to a race condition between threads
2025-10-22T13:43:17 < zyp> I've got a zephyr socket service, which is effectively a separate thread that polls sockets and calls callbacks
2025-10-22T13:46:52 < zyp> server disconnects, callback calls MQTT handler, MQTT handler calls event callback with disconnect event, event callback signals this to the main thread, mqtt.recv() returns Disconnected caller destructs MQTT client
2025-10-22T13:48:32 < zyp> and if the MQTT client is destructed by the main thread before the MQTT handler in the socket service thread returns, this happens
2025-10-22T13:50:54 < qyx> you know what misra says
2025-10-22T13:51:02 < qyx> construct once, touch never
2025-10-22T13:51:59 < zyp> https://paste.jvnv.net/view/RefUU
2025-10-22T13:52:08 < qyx> ok trashing this chink abomination, two pieces both don't work in two different routers, it disconnects usb in a cycle
2025-10-22T13:53:52 < zyp> #16 is the socket service callback, #15 is the MQTT handler, #14 is MQTT trying to unlock a mutex that's part of the now destructed client object
2025-10-22T13:58:44 < zyp> and I thought I fixed this on monday by taking a mutex both in the socket service callback and the destructor 
2025-10-22T13:58:45 < karlp> zyp: do you know off the top of your head what the slowest speed orbtrace runs at?
2025-10-22T13:58:57 < zyp> swclk speed?
2025-10-22T13:59:17 < zyp> IIRC we lowered it last time you complained :)
2025-10-22T13:59:20 < karlp> oocd is defaulting to 100k if I don't specify an adaptor speed, and then that seems to be too high, and orbtrace replies with I've got a zephyr socket service, which is effectively a separate thread that polls sockets and calls callbacks mand CMD_DAP_SWJ_CLOCK failed.
2025-10-22T13:59:35 < karlp> not really stressed, just oculdn't work out what I had wrong 
2025-10-22T13:59:59 < karlp> I have other things i'd like before a slower adapter speed....
2025-10-22T14:00:02 -!- tomeaton17 [~tom@user/tomeaton17] has quit [Quit: ZNC 1.9.0+deb2ubuntu0.1~esm2 - https://znc.in]
2025-10-22T14:00:51 -!- tomeaton17 [~tom@user/tomeaton17] has joined ##stm32
2025-10-22T14:01:56 < zyp> https://github.com/orbcode/orbtrace/releases/tag/v1.1.0
2025-10-22T14:01:57 < zyp> > Reduced minimum debug clock, now goes down to 196KHz (was previously 391KHz). Max clock of 25MHz is not changed.
2025-10-22T14:02:23 < karlp> that wasnt for me then, because 100khz is in opencd min for decades.
2025-10-22T14:02:37 < karlp> no biggie
2025-10-22T14:02:49 < zyp> pretty sure it was for your l1
2025-10-22T14:02:59 < karlp> hrm, that was a different problem iirc.
2025-10-22T14:03:08 < karlp> that was some edge alignment thing?
2025-10-22T14:03:15 < zyp> maybe
2025-10-22T14:03:24 < karlp> I ended up sending a board to mubes for it even.
2025-10-22T14:03:36  * karlp shrugs
2025-10-22T14:04:55 < karlp> was getting this crap https://paste.jvnv.net/view/odjb9 and couldn't see the forest for the trees
2025-10-22T14:06:41 -!- quinor [08c0f10716@2a03:6000:1812:100::dad] has quit [Remote host closed the connection]
2025-10-22T14:06:42 -!- jhalmen [373aef909d@sourcehut/user/slowjo] has quit [Remote host closed the connection]
2025-10-22T14:32:24 < mawk> the BLE code generated by cubemx is lacking the interrupt handlers for the inter-processor communication stuff, I had to add them manually
2025-10-22T14:32:32 < mawk> it seems like it's not really production ready yet
2025-10-22T14:41:40 < mawk> what happens when I have SLEEPONEXIT set to 1 for a while and then disable it from within an ISR
2025-10-22T14:41:59 < mawk> do I return to the user code that was originally executing when the ISR first happened?
2025-10-22T14:47:59 < zyp> unless you've changed stacks, yes
2025-10-22T14:55:39 < mawk> so the processor is saving the stack frame on interrupt exit when SLEEPONEXIT=1 and reusing it for the next interrupt
2025-10-22T14:55:40 < mawk> nice
2025-10-22T14:55:41 < mawk> thanks
2025-10-22T15:18:59 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-22T15:19:24 -!- quinor [08c0f10716@2a03:6000:1812:100::dad] has joined ##stm32
2025-10-22T15:19:27 -!- jhalmen [373aef909d@sourcehut/user/slowjo] has joined ##stm32
2025-10-22T15:47:02 < ventYl> mawk: stack is saved always, it is possible that if sleeponexit is set, the stack is never restored if wakeup leads to another interrupt
2025-10-22T15:47:18 < ventYl> if you get event that forces CPU to continue in user mode, it will restore the frame
2025-10-22T15:47:37 < ventYl> i'd expect the CPU to behave as if interrupt handlers were tail-chained
2025-10-22T16:04:40 < mawk> I have the same thread and handler stack
2025-10-22T16:04:52 < mawk> and several interrupts might occur during sleep yeah
2025-10-22T16:04:59 < mawk> but I tried it and it seems to work
2025-10-22T16:05:07 < mawk> next step is SLEEPDEEP
2025-10-22T16:05:26 < mawk> I have to get a wakeup source outside the cpu and set back the clock configuration on wakeup
2025-10-22T16:09:53 < mawk> even the UART in cubemx's radio generated code doesn't work
2025-10-22T16:10:09 < mawk> I explicitly untick the "USART1 DMA mode" and it still generates code that expects DMA
2025-10-22T16:10:45 < mawk> and when I manually fix the code it still doesn't work because there are 372948 wrappers around _write that they made and it somehow breaks somewhere 
2025-10-22T16:10:54 < mawk> why make things simple when they can be complicated 
2025-10-22T16:11:01 < karlp> cute https://patents.google.com/patent/US10025555B2/en
2025-10-22T16:11:07 < karlp> not sure how that got patented, but ok.
2025-10-22T16:11:25 < mawk> and cubemx's memory manager doesn't support the latest CPU2 radio stacks so I have to guess the memory layouts myself
2025-10-22T16:12:03 < mawk> lol karlp
2025-10-22T16:12:12 < mawk> 2016
2025-10-22T16:13:07 < mawk> I'll make a post on ST forums to properly shame them
2025-10-22T17:11:39 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2025-10-22T17:19:11 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-22T17:20:25 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-22T17:20:57 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-22T18:00:20 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-22T18:46:10 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Ping timeout: 245 seconds]
2025-10-22T19:14:48 -!- _Posterdati_ [~posterdat@user/Posterdati] has joined ##stm32
2025-10-22T19:20:37 < karlp> qyx: you love lithionnly right?
2025-10-22T19:20:57 < karlp> mettler has a cable free (it's bluetooth) floor scale with a _2 year_ battery life
2025-10-22T19:21:08 < karlp> uses a an 85Ah lithionly primary :)
2025-10-22T19:22:28 < qyx> 5x D-cell lisocl2?
2025-10-22T19:22:32 < qyx> that would he 5x17 Ah
2025-10-22T19:23:40 < karlp> yeah, just found that a D is ~17-19Ah. htats not as crazy as I thought.
2025-10-22T19:24:09 < qyx> enough socl2 to kill a whole battalion probably
2025-10-22T19:24:13 < karlp> hahaha
2025-10-22T19:25:27 < qyx> highway toll units usually have 14500 or 14250 cell
2025-10-22T19:25:41 < qyx> once I found a paper assessing the safety of those devices
2025-10-22T19:26:00 < karlp> you mean the windscreen mounted tags?
2025-10-22T19:26:03 < qyx> with the conclusion a single vented 14250 is enough to kill everybody in the truck cabin
2025-10-22T19:26:31 < qyx> yes the active ones
2025-10-22T19:45:43 < mawk> at previous job we had a low power application with lisocl2 that we sold as lasting 9 years on battery 
2025-10-22T19:46:01 < mawk> good thing devices broke down before that so we never had to find out the batteries would've died sooner
2025-10-22T19:47:10 < mawk> is it qyx? I was under the impression it's safer than lipo
2025-10-22T19:47:21 < mawk> I was happily shorting the battery packs without much care
2025-10-22T19:47:28 < mawk> you're telling me I could've died
2025-10-22T19:51:13 -!- nerozero [~nerozero@87.253.63.54] has quit [Remote host closed the connection]
2025-10-22T19:53:03 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-22T19:54:58 < karlp> I think it's "safer, by far, until it isn't"
2025-10-22T19:55:45 < karlp> well, ruled out another suspect.  my rtt prints were getting line buffered, so there's no actual difference between the nxp code and mine now.  (well, none left that I can _see_)
2025-10-22T19:55:58 < mawk> I love RTT
2025-10-22T19:56:08 < mawk> and I also love RTT (which is PTO in french)
2025-10-22T19:56:24 < karlp> I preferred swo classically, but I'v ehad to use rtt so much from this m0 I normally work on.
2025-10-22T19:56:34 < karlp> am on  m4f now, but rtt was already setup.
2025-10-22T19:57:19 < mawk> what I don't like about it is the initial setup, at least with openocd
2025-10-22T19:57:33 < mawk> having to put a breakpoint, start the rtt server, continue the application 
2025-10-22T19:57:53 < mawk> and then it doesn't follow through application jumps like from a bootloader
2025-10-22T19:57:55 < karlp> I have a hook on reload that restarts it.
2025-10-22T19:58:14 < karlp> it's more of a pain when you're switching apps and it moves the block.
2025-10-22T19:58:58 < mawk> yeah like for the bootloader
2025-10-22T19:59:09 < mawk> you're using openocd with it? or segger rtt
2025-10-22T19:59:16 < karlp> openocd
2025-10-22T19:59:44 < mawk> ah I see
2025-10-22T20:00:07 < mawk> I can't flash my stm32wb55 from openocd, I have to use the shitty stm32cubeprogrammer; I have to find out why
2025-10-22T20:00:26 < karlp> try st's openocd fork.
2025-10-22T20:00:29 < mawk> probably something about the secure flash/ram that can't be accessed by cpu1
2025-10-22T20:00:31 < karlp> they're way behind at getting shit upstream
2025-10-22T20:00:46 < mawk> yeah I only use the master branch of openocd, the releases are old
2025-10-22T20:00:51 < mawk> ah nice thanks I'll try that
2025-10-22T20:02:25 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 264 seconds]
2025-10-22T20:02:47 < karlp> fuckn, tried the jlink to have swo because the "other" one doesn't ... and it won't even flash the fucking thing.
2025-10-22T20:02:49 < karlp> wth.
2025-10-22T20:26:12 -!- NEYi [~NEYi@195.234.78.187] has quit [Quit: Leaving]
2025-10-22T21:18:47 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-22T21:18:57 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Read error: Connection reset by peer]
2025-10-22T22:03:28 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has joined ##stm32
2025-10-22T22:46:07 -!- BrainDamage [~m-t6k752@user/BrainDamage] has quit [Ping timeout: 240 seconds]
2025-10-22T22:48:54 -!- BrainDamage [~m-t6k752@user/BrainDamage] has joined ##stm32
2025-10-22T23:03:17 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-22T23:05:16 -!- Livio [~livio@user/livio] has quit [Ping timeout: 272 seconds]
2025-10-22T23:16:41 -!- BrainDamage [~m-t6k752@user/BrainDamage] has quit [Ping timeout: 256 seconds]
2025-10-22T23:32:16 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 256 seconds]
2025-10-22T23:33:47 -!- BrainDamage [~m-t6k752@user/BrainDamage] has joined ##stm32
2025-10-22T23:46:13 -!- BrainDamage [~m-t6k752@user/BrainDamage] has quit [Ping timeout: 264 seconds]
2025-10-22T23:47:20 -!- BrainDamage_ [~m-t6k752@user/BrainDamage] has joined ##stm32
--- Day changed Thu Oct 23 2025
2025-10-23T00:18:10 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has quit [Ping timeout: 256 seconds]
2025-10-23T00:57:13 -!- BrainDamage_ is now known as BrainDamage
2025-10-23T03:16:01 < ColdKeybo[a]rd> Did anyone use pico's PIO module for edge/frequency counting?
2025-10-23T03:31:23 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Remote host closed the connection]
2025-10-23T03:31:43 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2025-10-23T04:09:05 -!- kovalevsky [~kovalevsk@fedora/kovalevsky] has quit [Ping timeout: 256 seconds]
2025-10-23T04:26:05 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-23T06:17:41 -!- r2com [~r2com@38.9.242.88] has joined ##stm32
2025-10-23T07:13:06 -!- r2com [~r2com@38.9.242.88] has quit [Quit: Leaving]
2025-10-23T07:20:57 < jpa-> ColdKeybo[a]rd: probably, considering RP2040 doesn't really have input capture on timers
2025-10-23T07:23:21 < ColdKeybo[a]rd> I got it to work eventually... it's precise enough for my monkey business
2025-10-23T07:25:41 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-23T08:03:50 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-23T08:04:26 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-23T08:44:46 -!- qyx [~qyx@84.245.120.105] has quit [Ping timeout: 256 seconds]
2025-10-23T08:46:38 -!- qyx [~qyx@84.245.120.229] has joined ##stm32
2025-10-23T09:21:29 < ventYl> so far I only molest its CPU and SDK
2025-10-23T09:31:36 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2025-10-23T10:07:40 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-23T10:50:36 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-23T12:12:06 < tomeaton17> stm32 vs code extension officially released
2025-10-23T12:12:41 < tomeaton17> oh that happened 10 days ago
2025-10-23T12:49:26 < ventYl> why would anyone need that?
2025-10-23T12:49:44 < ventYl> you can generate cmake-based build system and use vscode straight away with no plugins
2025-10-23T12:53:08 < qyx> vscode? is it that editor with lagging cursor?
2025-10-23T12:54:58 < jpa-> it's the editor that allocates 1400 GB of virtual memory
2025-10-23T12:59:26 < qyx> https://bin.jvnv.net/file/gkscq/Screenshot_2025-10-23_11-59-06.png
2025-10-23T12:59:54 < jpa-> why such weird capacitor size combinations?
2025-10-23T13:00:14 < jpa-> or are there multiple pins that just show up as one in the schematic?
2025-10-23T13:02:49 < qyx> 100n is always one per pin, yeah, pins are aggregated
2025-10-23T13:02:57 < qyx> but others.. idk, just copied the EVB schematic
2025-10-23T13:02:59 < Steffanx> That lagging cursor must be you qyx
2025-10-23T13:03:11 < qyx> some are 10u, some 10n, some 1u, idk wth
2025-10-23T13:03:57 < Steffanx> And at least VS code uses less memory than Teams. 
2025-10-23T13:05:22 < jpa-> the ferrites for digital supplies seem funny
2025-10-23T13:06:59 < BrainDamage> Steffanx: https://media.mbusa.com/releases/mercedes-benz-expands-collaboration-with-microsoft-to-boost-in-car-productivity-with-enhanced-meetings-for-teams-app-intune-integration-and-microsoft-365-copilot
2025-10-23T13:07:38 < BrainDamage> so you can vibe code while you drive and have a teams meeting
2025-10-23T13:09:10 < ventYl> jesus. fucking. christ
2025-10-23T13:09:56 < ventYl> this is just marginally better than when VW announced they'll support Cisco Webex
2025-10-23T13:15:41 < BrainDamage> I wouldn't put past them that you cannot hang the ecu with the right teams message
2025-10-23T13:17:51 < qyx> We have confirmed that Russian mobile operators have recently started to actively and permanently blocking data and SMS services for roaming SIMs. These restrictions are imposed directly by the local operators and 1NCE does not have the ability to technically change or influence this behavior.
2025-10-23T13:17:56 < qyx> To ensure consistency and clarity for our customers, we have proceeded with barring all Russian networks on our side as well. Please note that this action does not represent a change in your contractual service but reflects external restrictions outside 1NCE’s technical or operational control.
2025-10-23T13:18:01 < qyx> oh!
2025-10-23T13:22:00 < Steffanx> Yeah, BrainDamage how wonderful 
2025-10-23T13:22:59 < Steffanx> Luckily I can't buy an mb soon because of the Nexperia issues.
2025-10-23T13:30:38 < tomeaton17> ventYl: I just use the clangd extension which they provide
2025-10-23T13:31:03 < tomeaton17> But in general they will probably phase out the cube ide and just use this extension in the next few years I think
2025-10-23T13:32:24 < ventYl> tomeaton17: afaik, cubeide and cubemx are now two separate things. you can use mx without ide
2025-10-23T13:32:54 < tomeaton17> ventYl: yeah exactly, thats what I mean. I think they will deprecate the ide
2025-10-23T13:33:03 < ventYl> IDE is long dead for me
2025-10-23T13:33:11 < ventYl> actually, I have never used it
2025-10-23T13:33:24 < tomeaton17> not an eclipse enjoyer?
2025-10-23T13:33:40 < ventYl> definitely no
2025-10-23T13:33:47 < tomeaton17> based
2025-10-23T13:34:11 < ventYl> i had my share of use of eclipse infested with IBM Jazz/RTC plugins which were pooping themselves every now and then
2025-10-23T13:34:47 < ventYl> eclipse is wrong enough on its own, this was pure bastard IDE from hell
2025-10-23T13:58:01 < qyx> so, passives https://bin.jvnv.net/file/RCint/Screenshot_2025-10-23_12-57-20.png
2025-10-23T14:24:41 < c10ud> lul
2025-10-23T14:25:02 < Steffanx> What is that qyx?
2025-10-23T14:29:53 < zyp> passives.
2025-10-23T14:34:22 < Steffanx> I mean the IC
2025-10-23T14:34:50 < Steffanx> Thanks zyp 
2025-10-23T14:35:26 < zyp> ah, that's an IC
2025-10-23T14:43:16 < ventYl> we no longer have ICs, only EXs
2025-10-23T14:44:49 < jpa-> Steffanx: probably https://bin.jvnv.net/file/gkscq/Screenshot_2025-10-23_11-59-06.png
2025-10-23T14:48:48 < qyx> Steffanx: lan9370
2025-10-23T14:49:05 < qyx> how could be that thing more complex than an average stm32
2025-10-23T14:50:37 -!- kovalevsky [~kovalevsk@181.168.239.174] has joined ##stm32
2025-10-23T14:50:37 -!- kovalevsky [~kovalevsk@fedora/kovalevsky] has changed host
2025-10-23T14:52:54 < jpa-> it's such a cool chip that you can't even get the datasheet without nda
2025-10-23T14:53:17 < jpa-> hmm.. can from mouser, can't from microchip :D
2025-10-23T14:53:45 < qyx> yes, also EVB user manual is free and it contains a complete schematic
2025-10-23T14:54:00 < jpa-> but way too many caps ;)
2025-10-23T14:54:32 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 256 seconds]
2025-10-23T14:54:52 < qyx> I am not finished yet, so idk how it turns out
2025-10-23T14:55:24 < jpa-> i'm also confused about "Gigabit Ethernet Switch" but "100BASE-T1"
2025-10-23T14:56:04 < qyx> it has rgmii
2025-10-23T14:56:10 < qyx> switching fabric is probably gigabit
2025-10-23T14:56:30 < qyx> so it may deliver 400 mbit/s in both directions
2025-10-23T14:56:36 < jpa-> ok
2025-10-23T14:56:55 < Steffanx> Thanks for being helpful jpa- 
2025-10-23T14:56:58 < qyx> which reminds me I should probably connect it to the SoC using rgmii instead of rmii
2025-10-23T14:57:15 < qyx> I am not sure if I am that adventurous
2025-10-23T14:58:57 < zyp> how so?
2025-10-23T15:00:45 < qyx> I am not prepared to fail
2025-10-23T15:00:54 < zyp> apart from requiring five extra pins or so, RGMII should be easier
2025-10-23T15:02:52 < qyx> is zyp ready to suffer my anger
2025-10-23T15:03:07 < zyp> I mean, RGMII is five times faster than RMII (and twice as wide), so the length matching requirements are also accordingly stricter
2025-10-23T15:03:26 < qyx> what about that delay line?
2025-10-23T15:03:35 < zyp> but RGMII has source synchronous rx/txclk, RMII has common refclk
2025-10-23T15:05:04 < zyp> and if you're using a decent PHY, it'll have clock skew adjustment so you don't need to do any bullshit on the board to add skew
2025-10-23T15:05:20 < zyp> MAC might too
2025-10-23T15:05:47 < zyp> full disclosure: I've only done RGMII with FPGA, where the FPGA always have the option of doing clock skew
2025-10-23T15:06:43 < qyx> ok I can't see strap configuration
2025-10-23T15:06:48 < zyp> only time I've seen people fuck it up was wiring two MACs back to back and then discovering that the MAC in the SoC they had didn't do skew
2025-10-23T15:14:18 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-23T15:33:54 -!- Livio [~livio@user/livio] has quit [Ping timeout: 272 seconds]
2025-10-23T15:39:47 < zyp> jpa-, nah, mouser just has the databrief
2025-10-23T15:45:35 < qyx> I couldn't find a single additional resource
2025-10-23T15:45:48 < qyx> not mentioning the full datasheet
2025-10-23T15:45:54 < qyx> what's the point in hiding that
2025-10-23T15:49:26 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-23T15:49:42 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-23T15:49:52 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Read error: Connection reset by peer]
2025-10-23T16:16:04 < karlp> ok. weird.  btle nordic uart service works well enough for one ofthe android btle serial apps, but _doesn't_ work with any of the web bluetooth pages.
2025-10-23T16:16:13 < karlp> _different_ impl works in both.
2025-10-23T16:16:26 < karlp> guess I'm not as broken on this as I thought, just some extra magic the web needs...
2025-10-23T16:33:41 -!- c10ud_ [~c10ud@host-87-2-122-85.retail.telecomitalia.it] has joined ##stm32
2025-10-23T16:36:52 -!- c10ud [~c10ud@user/c10ud] has quit [Ping timeout: 246 seconds]
2025-10-23T16:38:29 < qyx> do I understand it right RMII_REFCLK is clocking all the time and I can feed it to XIN?
2025-10-23T16:38:38 < qyx> because that's how it works with a common phy
2025-10-23T16:39:13 < qyx> but this switch in phy mode has both XIN/XOUT for the crystal and RX_RXCLK which is connected to RMII_REFCLK in their EVB
2025-10-23T16:40:54 < zyp> both RMII_REFCLK, RGMII_TXC and RGMII_RXC are free running
2025-10-23T16:42:13 < qyx> https://forum.microchip.com/s/topic/a5CV40000002BAfMAM/t398055
2025-10-23T16:42:17 < qyx> this is super confusing
2025-10-23T16:43:54 < zyp> what is confusing?
2025-10-23T16:44:13 < qyx> so I am connecting MAC to MAC
2025-10-23T16:44:25 < qyx> so TXD->RXD and vice versa
2025-10-23T16:44:27 < zyp> what's the other MAC?
2025-10-23T16:44:35 < qyx> imx93 mac
2025-10-23T16:44:46 < zyp> yeah, so you set the LAN9370 to PHY mode
2025-10-23T16:46:14 < qyx> that's not what I want
2025-10-23T16:46:35 < zyp> why not?
2025-10-23T16:46:37 < qyx> I don't want the switch to output refclk, I have imx93 configured to output refclk and it works with my other phys
2025-10-23T16:46:54 < zyp> right
2025-10-23T16:47:17 -!- kovalevsky [~kovalevsk@fedora/kovalevsky] has quit [Remote host closed the connection]
2025-10-23T16:47:34 < qyx> so I probably want the mac mode with refclk going to RXCLK
2025-10-23T16:47:37 -!- kovalevsky [~kovalevsk@fedora/kovalevsky] has joined ##stm32
2025-10-23T16:47:38 < zyp> usually RMII_REFCLK is an input on the MAC
2025-10-23T16:47:54 < qyx> but then you need PHY with a crystal
2025-10-23T16:48:12 < zyp> yup
2025-10-23T16:48:43 < qyx> so they call that a "normal" mode
2025-10-23T16:48:53 < qyx> when the switch expect RMII_REFCLK
2025-10-23T16:49:19 < qyx> hwich corresponds to the schematic, strapping MII_MODE low
2025-10-23T16:49:35 < qyx> also connecting REFCLK to the RXCLK
2025-10-23T16:49:50 < qyx> so, part of the confusion was he is not understanding they are configuring it in a mac mode
2025-10-23T16:50:26 < zyp> beware TX_EN vs CRS_DV semantic differences
2025-10-23T16:50:40 < zyp> I don't remember the details, but IIRC there's a potential gotcha there
2025-10-23T16:50:58 < zyp> unlike RGMII where TX_CTL and RX_CTL are directly compatible
2025-10-23T16:52:30 < qyx> why couldn't everyone just use sgmii?
2025-10-23T16:52:40 < zyp> price?
2025-10-23T16:53:10 < qyx> ok, so they are connecting that cirectly
2025-10-23T17:09:24 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2025-10-23T17:26:22 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-23T17:32:35 -!- infisd [~infisc@user/infisc] has quit [Remote host closed the connection]
2025-10-23T17:32:55 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-23T17:51:16 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-23T19:08:23 -!- Livio [~livio@user/livio] has quit [Remote host closed the connection]
2025-10-23T19:08:36 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-23T20:31:34 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 255 seconds]
2025-10-23T21:45:09 < ColdKeybo[a]rd> Is there a struct/model that is convenient for storing curves on the mcu?
2025-10-23T21:46:33 < ColdKeybo[a]rd> It will always have fixed number of max points, but some curves might use less points and I should be able to insert points anywhere (before/after value) 
2025-10-23T21:46:52 < ColdKeybo[a]rd> I'm thinking double linked list but I'm not sure if there is something better...
2025-10-23T21:48:12 < ColdKeybo[a]rd> I think double linked list will eat up more ram than just raw array of values and then manually juggling insert/remove
2025-10-23T21:50:06 < qyx> depends what you are optimizing for
2025-10-23T21:50:07 -!- h4x0riz3d is now known as antto
2025-10-23T21:50:24 < ventYl> yeah, if insert/remove is rare, then array is good to go
2025-10-23T21:50:26 < qyx> also double linked list may not be faster than si ple shifting
2025-10-23T21:57:18 < ColdKeybo[a]rd> Optimizing for my sanity... there is plenty of ram and I don't think that the insert/remove will be often. Hopefully it will mostly be set and forget and most of the time it's just finding the first left/right value
2025-10-23T21:58:14 < ColdKeybo[a]rd> The curve is basically (temperature, PWM) pair. So at x temperature, apply y duty PWM
2025-10-23T21:58:55 < veverak> array
2025-10-23T21:59:10 < veverak> it's easiest to inspect what the state of it is, and visualize just by seing raw data in debugger
2025-10-23T22:00:15 < ventYl> ColdKeybo[a]rd: that curve probably only has a couple of nodes anyway. no need to invent any strong optimization
2025-10-23T22:00:18 < ColdKeybo[a]rd> That's what I have right now... Since max length is fixed, I just have to keep track of how many points are actually used so I don't waste time searching for points that are not initialized
2025-10-23T22:01:20 < ColdKeybo[a]rd> It will have 10-20 points max
2025-10-23T22:01:50 < ventYl> another way with constant memory consumption would be to approximate the curve using equation and then use least squares to derive coefficients of this equation
2025-10-23T22:02:12 < ventYl> use becomes no-brainer but curve updates will be non-trivial as you have to recompute equation coefficients
2025-10-23T22:02:44 < ColdKeybo[a]rd> The curve is either linear or pure threshold. So nothing fancy
2025-10-23T22:03:14 < ColdKeybo[a]rd> Like if temperature is 20C, apply 30% PWM and that's it
2025-10-23T22:04:01 < ColdKeybo[a]rd> I could also have it if I only have PWM points for 15C and 30C, then to interpolate what the value should be at 20C but that's as fancy as it gets :)
2025-10-23T22:25:34 -!- Livio [~livio@user/livio] has quit [Ping timeout: 272 seconds]
2025-10-23T22:34:02 -!- zChris_ [~zChris@user/zchris] has joined ##stm32
2025-10-23T22:41:37 -!- Netsplit *.net <-> *.split quits: zChris
2025-10-23T22:55:04 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 256 seconds]
2025-10-23T23:38:10 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has joined ##stm32
2025-10-23T23:40:57 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-23T23:43:02 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
--- Day changed Fri Oct 24 2025
2025-10-24T00:01:26 < Posterdati> hi
2025-10-24T00:03:29 < Posterdati> please help, I've got a strange behaviour from _sbrk() on cortex-m7. It is executed with increment = 0 and execution is stuck with _sbrk() execution. Thanks!
2025-10-24T00:04:23 < Posterdati> I'm compiling using gcc version 14.2.1 20241119 (15:14.2.rel1-1) (arm-none-eabi)
2025-10-24T00:04:52 < Posterdati> on previous gcc release the same code worked just fine
2025-10-24T00:06:31 < ventYl> how do you want that execution is stuck in _sbrk() ?
2025-10-24T00:06:39 < ventYl> want -> know
2025-10-24T00:08:17 < Posterdati> ventYl: debugging with gdb on cont, if I interrupt execution it is always in _sbrk() with argument = 0
2025-10-24T00:08:44 < Posterdati> shall I use the newlib version for _sbrk() ?
2025-10-24T00:13:15 < ventYl> the question is if it is hung there or the code around it calls it repeatedly in short loop
2025-10-24T00:14:58 < Posterdati> yes, I'm using the newlib version, it seems to wrk now!
2025-10-24T00:15:01 < Posterdati> work
2025-10-24T00:39:39 < Posterdati> does newlib initialize bss too?
2025-10-24T00:41:03 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has quit [Ping timeout: 260 seconds]
2025-10-24T00:41:04 < ventYl> C standard requires BSS to be zero-initialized
2025-10-24T00:41:23 < ventYl> so, the most probable answer is: yes
2025-10-24T00:42:14 < Posterdati> ok
2025-10-24T00:43:01 < Posterdati> thanks
2025-10-24T02:57:30 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-24T03:08:55 -!- kovalevsky [~kovalevsk@fedora/kovalevsky] has quit [Ping timeout: 256 seconds]
2025-10-24T04:34:34 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-24T04:56:47 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-24T05:05:04 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-24T07:43:17 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-24T08:14:04 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-24T08:37:10 < qyx> so I decided to move my capacitors to the other side
2025-10-24T08:40:04 < jpa-> they're dead now?
2025-10-24T09:07:55 < qyx> hope not, just overcrowded
2025-10-24T09:16:27 < qyx> TIL finnish summer is foggy and gray, really?
2025-10-24T09:17:23 < jpa-> not true at all
2025-10-24T09:53:34 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 246 seconds]
2025-10-24T10:23:56 < mawk> can I get gdb to stop whenever I enter an ISR without having to set 256 breakpoints
2025-10-24T10:41:47 < ventYl> you can compile your ISRs with BKPT instruction as the very first thing ISR does
2025-10-24T10:42:25 < ventYl> trace macrocell can trace ISRs but IDK if it can stop on entering one
2025-10-24T10:44:29 < zyp> nope, there's no non-intrusive way to break on all interrupts, so explicit bkpt instruction in each handler would be the way to go
2025-10-24T10:45:26 < zyp> alternatively have every handler call a dummy noinline function, and set a breakpoint on that
2025-10-24T11:10:10 < Posterdati> hi
2025-10-24T11:10:37 < Posterdati> nice arm-none-eabi with gcc 13 vs 14 broke my projects... Very nice!
2025-10-24T11:12:07 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-24T11:12:30 < zyp> that's usually a sign that your code was broken in the first place, and just happened to work by undefined behavior behaving in a specific way
2025-10-24T11:13:08 < Posterdati> maybe, maybe not
2025-10-24T11:13:54 < zyp> more plausible than a compiler bug :)
2025-10-24T11:14:03 < mawk> I want to just print something and continue with the isr
2025-10-24T11:14:05 < mawk> but there's no trace support for the chip so I do that with the `dprintf` gdb thinmg
2025-10-24T11:15:01 < Posterdati> zyp: seems to be a linker script bad configuration: HardFault during __libc_init_array
2025-10-24T11:17:54 < mawk> maybe, maybe not
2025-10-24T11:18:04 < mawk> __libc_init_array calls all the constructors
2025-10-24T11:18:06 < mawk> are you using C++?}
2025-10-24T11:18:29 < mawk> constructors are functions that run before main(), there's a bunch in the libc and you can also make your own with __attribute__((__constructor__)); or of course C++ constructors
2025-10-24T11:19:27 < mawk> specifically C++ constructors of global instances of classes (including static parameters of other objects)
2025-10-24T11:20:50 < ventYl> and the order in which these constructors run is not defined
2025-10-24T11:21:06 < zyp> unless you set priority
2025-10-24T11:21:28 < mawk> if you don't set a priority the user constructors run after the libc constructors
2025-10-24T11:22:07 < ventYl> yeaah, but if you have global C++ objects with constructors, their order is hard to be defined
2025-10-24T11:22:18 < zyp> you can set priority on those as well
2025-10-24T11:23:23 < ventYl> the real question is: do you want to do it?
2025-10-24T11:23:25 -!- specing [~specing@user/specing] has quit [Ping timeout: 264 seconds]
2025-10-24T11:23:45 < zyp> https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html#index-init_005fpriority-variable-attribute
2025-10-24T11:23:46 < ventYl> having a global is bad enough, hand tuning constructor order is pure hell
2025-10-24T11:24:12 < zyp> personally I'm not a fan of global non-const constructors
2025-10-24T11:24:48 < ventYl> anyway, I found out that pico-sdk API is pretty sparse. blocking access, that's it for some peripherals
2025-10-24T11:29:00 < jpa-> i find that premade non-blocking functions in any HAL rarely fit what i want to do anyway
2025-10-24T11:29:48 < qyx> hals should be either thin or super thick
2025-10-24T11:29:55 < qyx> anything in between never worked for me
2025-10-24T11:30:01 < zyp> agreed
2025-10-24T11:31:44 < Posterdati> for stm32h723zg are these correct? -> CPU=cortex-m7, FPU=fpv5-sp-d16, ARCH=armv7e-m+fp, FLOAT_ABI=hard
2025-10-24T11:31:49 < jpa-> the biggest benefit is always in getting simple stuff working fast so you have more time to spend on difficult stuff
2025-10-24T11:36:23 < zyp> jpa-, this stuff is pretty good though: https://docs.rs/embedded-hal-async/1.0.0/embedded_hal_async/
2025-10-24T11:39:09 < jpa-> with rust everything is good ;)
2025-10-24T11:40:40 < zyp> no :)
2025-10-24T11:47:05 < ventYl> Posterdati: kuba will configure these for you, to my knowledge, it will be correct, if you configured mx right
2025-10-24T11:58:47 < mawk> I used nm to check which ISRs are defined and inserted a call to dingdingdingdingding() in the beginning of each
2025-10-24T11:58:58 < mawk> and then in the dingding I can look at ICSR
2025-10-24T12:08:50 < Posterdati> wow the cpu resets executing __do_global_dtors_aux :)
2025-10-24T12:09:50 < ventYl> it would probably be worth adding -Wall -Wextra to compiler switches and run clang-tidy over the source code
2025-10-24T12:12:32 -!- specing [~specing@user/specing] has joined ##stm32
2025-10-24T12:13:58 -!- Livio [~livio@user/livio] has quit [Ping timeout: 272 seconds]
2025-10-24T12:34:00 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-24T13:18:58 < mawk> Posterdati: that's not supposed to be executed
2025-10-24T13:19:09 < mawk> only if you return from your main function, and even then cubemx and all that doesn't generate the code for it
2025-10-24T13:19:15 < mawk> unless it's a typo and you mean ctor
2025-10-24T13:26:06 < karlp> feck, spinning rust has gotten expensive.
2025-10-24T13:26:12 < karlp> nas is full up
2025-10-24T13:29:15 < Posterdati> mawk: no it won't eneter main, finished __libc_init_array it resets
2025-10-24T13:31:49 < zyp> today's zephyr hate: https://docs.zephyrproject.org/latest/doxygen/html/group__tls__credentials.html#ga640ff6dd3eb4d5017feaab6fab2bb2f7
2025-10-24T13:32:55 < zyp> I hate how it doesn't specify whether the data I pass a pointer to will be copied or stored a reference to
2025-10-24T13:33:11 < zyp> and I hate the answer even more
2025-10-24T13:33:23 < zyp> «it depends on the selected backend»
2025-10-24T13:34:12 < qyx> lol
2025-10-24T13:34:22 < qyx> so what should you do now
2025-10-24T13:35:09 < jpa-> assume that it is stored a reference to
2025-10-24T13:35:51 < zyp> there's two backends; one just stashes the pointer into a list, the other has TF-M store a copy of the data
2025-10-24T13:36:14 < zyp> either seems reasonable on their own, but I hate that they've shoehorned it into the same API
2025-10-24T13:37:00 < zyp> and yeah, for now I'm just gonna assume volatile storage
2025-10-24T13:37:40 < zyp> I wrote a wrapper API for it: https://paste.jvnv.net/view/oglhy
2025-10-24T13:39:01 < jpa-> if you had a choice, would you prefer to live for 'a or for '_?
2025-10-24T13:39:18 < zyp> :)
2025-10-24T13:40:18 < zyp> the lifetimes aren't a big issue, but a nonvolatile API would need an entirely different approach for tag management
2025-10-24T13:43:23 < zyp> anyway, I need to go make some certificates and shit so I can actually test this :p
2025-10-24T13:44:24 < jpa-> it's always good to take a shit before testing the code, to avoid mess if something blows up
2025-10-24T13:48:02 < qyx> I see zyp is doing serious business talking about zephyr and tls and certificates
2025-10-24T13:48:14 < qyx> must be some pro device
2025-10-24T13:49:22 < zyp> I've done a rust wrapper for zephyr's MQTT API, so far just been testing it with unencrypted sockets, now gonna figure out TLS
2025-10-24T13:49:39 < zyp> I've got three projects that's gonna use it
2025-10-24T13:57:03 < qyx> I have maybe 2 more hours, so I'll continue with my capacitor abomination
2025-10-24T13:57:13 < qyx> ok, one more hour
2025-10-24T13:57:34 < qyx> I'll try to flip them
2025-10-24T14:19:18 -!- c10ud_ [~c10ud@host-87-2-122-85.retail.telecomitalia.it] has quit [Ping timeout: 256 seconds]
2025-10-24T14:49:37 < zyp> > PeerIncompatible(NoCipherSuitesInCommon)
2025-10-24T14:49:38 < zyp> fun stuff
2025-10-24T14:56:23 < Posterdati> please, is it possible to use DTCM memory on the stm32h723zg before system initialization (RCC, PWR and SYSCFG configuration)? Thanks!
2025-10-24T14:59:38 -!- c10ud [~c10ud@user/c10ud] has joined ##stm32
2025-10-24T15:13:14 < qyx> I would say yes?
2025-10-24T15:23:57 < ventYl> zyp: that's one hell of a design
2025-10-24T15:26:34 < zyp> zephyr? yeah, it's full of weird APIs
2025-10-24T15:32:37 < ventYl> like it or not, I have to start doing dirty marketing for CreepyOS
2025-10-24T15:35:00 < karlp> you'ðll need dirty marketing, you have a dirty name :)
2025-10-24T15:40:00 < ventYl> its not really called creepyOS
2025-10-24T15:40:03 < ventYl> and it doesn't matter
2025-10-24T15:40:30 < ventYl> i'm constantly coming over people who are like 'dude, Y U NO assembly? dude, waste of resources. dude'
2025-10-24T15:41:03 < karlp> fucking great. got my shit working with the webbluetooth console, now the android app doesn't connect :)
2025-10-24T15:45:55 < Posterdati> ok
2025-10-24T15:46:39 < Posterdati> I found the problem, I had a mix of home made syscalls and newlib, I leave newlib with nano.specs and nosys.specs and it is working!
2025-10-24T15:47:18 < Posterdati> I have warnings on _kill_r, _lseek_r and so on on linking...
2025-10-24T15:49:40 < karlp> those are gcc14 warnings. I
2025-10-24T15:50:04 < karlp> if they're the ones I'm thinking of
2025-10-24T15:50:32 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-24T15:51:49 < qyx> since gcc12 iirc
2025-10-24T15:57:32 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-24T15:57:34 < Steffanx> Nah 13
2025-10-24T16:01:24 < qyx> since recently!
2025-10-24T16:37:37 < jbo> > Thank you for requesting a quotation. Our customer care teams strive to get back to you within 2 business days. 
2025-10-24T16:37:54 < jbo> doesn't look like nvent schroff knows how long 2 days are
2025-10-24T16:45:41 < specing> they strive and fail
2025-10-24T16:49:03 < karlp> ok. figured it.  webbluetooth won't connect if you have ".own_addr_type      = BLE_ADDR_TYPE_PUBLIC," and don't call esp_ble_gap_config_local_privacy(true)
2025-10-24T16:49:18 < karlp> you need own_addr_type == BLE_ADDR_TYPE_RPA_PUBLIC,
2025-10-24T16:53:45 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-24T16:57:06 < karlp> I have no idea where that is potentially documented....:)
2025-10-24T17:14:27 < Steffanx> You're not being helpful jbo
2025-10-24T17:18:56 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 256 seconds]
2025-10-24T17:23:54 < Posterdati> karlp: which are not relevant since now works
2025-10-24T17:28:24 < jbo> Steffanx thanks
2025-10-24T17:29:29 < Steffanx> Pizza?
2025-10-24T17:42:27 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-24T17:53:36 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-24T18:14:47 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-24T18:16:00 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-24T18:16:24 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-24T18:16:36 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-24T18:44:48 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 244 seconds]
2025-10-24T20:11:31 < jbo> no
2025-10-24T20:17:35 < Steffanx> Ok
2025-10-24T20:23:45 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-24T20:58:35 < mawk> ventYl: how do I make the lock-free queue
2025-10-24T20:58:42 < mawk> I can make a stack with STM/LDM instructions
2025-10-24T21:01:05 < mercenary> you don't. ask aws why not.
2025-10-24T21:03:54 < jpa-> with single reader & single writer it is easy
2025-10-24T21:07:33 < mawk> well if it's re-entrant
2025-10-24T21:07:56 < mawk> there's only 1 core on the mcu but a write might be initiated in the middle of a preempted write
2025-10-24T21:09:21 < ventYl> mawk: that doesn't matter
2025-10-24T21:10:04 < ventYl> https://github.com/ventZl/cmrx/blob/master/src/extra/queue_server/queue.c
2025-10-24T21:10:17 < ventYl> for single threaded, this should be SP&SC lock-free
2025-10-24T21:10:42 < ventYl> you need to remove notify_object and wait_for_object for it to not depend on CreepyOS
2025-10-24T21:11:36 < ventYl> the whole point is that write cursor is ever only advanced by producer and read cursor by consumer. so you have to advance both only after data was read/written
2025-10-24T21:11:53 < ventYl> this way you need no synchronization because the value of cursor itself is authoritative
2025-10-24T21:12:24 < ventYl> if it was multicore, you'd have to add some barriers
2025-10-24T21:14:42 < jpa-> when i did similar but needed to reduce copies too, i had "get_read_pointer()" that gave a pointer and count on how much you can read, and then you'd call a separate finish_read() after you're done with it (and same for writes)
2025-10-24T21:18:01 < mawk> hmmm
2025-10-24T21:18:05 < mawk> thanks
2025-10-24T21:19:37 < mawk> I don't see why it's re-entrant, if you get to line 16, get the value of the cursor, then the ISR is suspended and another one reads the cursor which is identical, writes in the queue, finishes; and then the lower priority ISR overwrites the contents; no?
2025-10-24T21:20:21 < ventYl> re-entrant in what sense?
2025-10-24T21:20:30 < jpa-> i don't think that is a multi-writer queue
2025-10-24T21:20:32 < ventYl> this is thread-safe only in case there is one producer and one consumer
2025-10-24T21:21:03 < mawk> well re-entrant in the sense that a write can happen on top of another write, with the other write suspended until the new one finishes
2025-10-24T21:21:13 < mawk> but not concurrently
2025-10-24T21:21:19 < ventYl> you cannot do that, that's not "single producer"
2025-10-24T21:21:56 < ventYl> this could be done, but you have to add some transacting on top
2025-10-24T21:22:22 < ventYl> or, probably interrupt disable as here transactions have little benefits over disabled interrupts and critical sections
2025-10-24T21:22:26 < mawk> I see
2025-10-24T21:22:40 < jpa-> for multi-writer / multi-reader queue, it's usually best to limit the queue to pointer-sized items; then you can atomically exchange them, and have a separate pool of memory buffers for containing the actual data
2025-10-24T21:23:01 < mawk> on x86 I know there's an atomic exchange instruction, but I haven't found one for ARM cortex M
2025-10-24T21:23:28 < jpa-> it's done with the exclusive read/write instructions.. gcc has atomic builtins that you can use
2025-10-24T21:23:36 < mawk> isn'
2025-10-24T21:23:37 < mawk> oops
2025-10-24T21:23:43 < jpa-> LDREX and STREX
2025-10-24T21:23:43 < mawk> isn't that for multi-core systems?
2025-10-24T21:23:50 < mawk> or is that also suspending interrupts
2025-10-24T21:23:50 < jpa-> it works for any
2025-10-24T21:24:16 < jpa-> it doesn't suspend interrupts, it just detects if there was a conflicting access and lets the code retry
2025-10-24T21:25:49 < ventYl> mawk: it works in a way that if there are multiple load -> store conditional attempts to the same location, only first will succeed, subsequent will fail
2025-10-24T21:25:59 < ventYl> until they re-load value
2025-10-24T21:26:13 < ventYl> in practice it has a lot of false negatives, but that doesn't matter much
2025-10-24T21:26:53 < mawk> ah I see, nice
2025-10-24T21:27:51 < mawk> so I check if strex returns 0 and if not I retry
2025-10-24T21:28:48 < ventYl> yes, as jpa said, GCC has abstractions that use it. I'd probably use these
2025-10-24T21:28:57 < jpa-> https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
2025-10-24T21:29:01 < ventYl> ^^
2025-10-24T21:29:28 < jpa-> though C11 has https://en.cppreference.com/w/c/language/atomic.html which i've never used
2025-10-24T21:31:01 < jpa-> a limitation is that the atomicity works only on one word at a time.. so e.g. writing an item to the buffer and updating the count are not mutually synchronous
2025-10-24T21:32:00 -!- akaWolf1 [~akaWolf@akawolf.org] has quit [Ping timeout: 265 seconds]
2025-10-24T21:37:49 < ventYl> isn't this even dependant on hardware?
2025-10-24T21:38:02 < ventYl> so some MCUs might have more slots in exclusive unit?
2025-10-24T21:39:34 < jpa-> maybe, but i think you are not supposed to rely on more than one
2025-10-24T21:46:23 -!- remcycles [~remcycles@c-24-19-134-216.hsd1.wa.comcast.net] has quit [Ping timeout: 256 seconds]
2025-10-24T22:20:55 -!- jerrycash [~jerrycash@user/jerrycash] has joined ##stm32
2025-10-24T22:48:59 -!- akaWolf [~akaWolf@akawolf.org] has joined ##stm32
2025-10-24T23:24:04 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has joined ##stm32
2025-10-24T23:47:40 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 256 seconds]
--- Day changed Sat Oct 25 2025
2025-10-25T00:25:45 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has joined ##stm32
2025-10-25T00:53:36 -!- NEYi [~NEYi@195.234.78.187] has quit [Quit: Leaving]
2025-10-25T01:02:34 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has quit [Quit: Bye]
2025-10-25T01:34:46 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 256 seconds]
2025-10-25T01:52:55 -!- nomorekaki [~nomorekak@37-136-166-42.rev.dnainternet.fi] has joined ##stm32
2025-10-25T02:13:11 -!- nomorekaki [~nomorekak@37-136-166-42.rev.dnainternet.fi] has quit [Quit: Client closed]
2025-10-25T03:33:41 -!- duude__- [~duude__@user/duude/x-4676560] has joined ##stm32
2025-10-25T03:34:49 -!- duude__ [~duude__@user/duude/x-4676560] has quit [Ping timeout: 264 seconds]
2025-10-25T03:37:50 -!- duude__- is now known as duude__
2025-10-25T04:54:21 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-25T05:01:27 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-25T05:49:08 -!- _Posterdati_ [~posterdat@user/Posterdati] has quit [Ping timeout: 244 seconds]
2025-10-25T06:02:11 -!- _Posterdati_ [~posterdat@user/Posterdati] has joined ##stm32
2025-10-25T07:43:24 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-25T08:12:45 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-25T08:46:00 -!- qyx [~qyx@84.245.120.229] has quit [Ping timeout: 256 seconds]
2025-10-25T08:47:34 -!- qyx [~qyx@84.245.121.159] has joined ##stm32
2025-10-25T09:29:52 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-25T10:24:36 -!- Livio [~livio@user/livio] has quit [Ping timeout: 272 seconds]
2025-10-25T10:29:14 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-25T10:46:20 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has joined ##stm32
2025-10-25T10:53:09 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-25T12:25:33 < mawk> if I keep a queue per ISR priority then it's still SPSC
2025-10-25T12:25:39 < mawk> and as a bonus I can process higher priority requests first
2025-10-25T12:25:54 < mawk> and the consumer is the pendsv interrupt at lowest priority
2025-10-25T12:35:21 -!- mercenary [~mercenary@user/mercenary] has quit [Quit: ZNC 1.10.1 - https://znc.in]
2025-10-25T12:36:47 -!- mercenary [~mercenary@user/mercenary] has joined ##stm32
2025-10-25T12:37:31  * mercenary inverts mawks priorities
2025-10-25T14:04:14  * Steffanx interrupts mercenary while doing that
2025-10-25T14:07:50  * mercenary mutters 'I'll be back' and drops the priorities on a random stack
2025-10-25T14:32:44 < mawk> :(
2025-10-25T14:37:37 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-25T14:38:47 < ventYl> mawk: how are you gonna consume multiple queues in pendsv? a bunch of (queue_receive_if_not_empty()) ?
2025-10-25T14:39:10 < mawk> yeah 
2025-10-25T14:39:51 < mawk> or just consume one from each queue and continue at the next tick
2025-10-25T15:37:56 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-25T19:30:59 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-25T19:39:40 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-25T19:40:47 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-25T19:41:19 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-25T20:29:27 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-25T20:36:32 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-25T20:53:18 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 244 seconds]
2025-10-25T22:17:30 -!- Livio_ [~livio@user/livio] has joined ##stm32
2025-10-25T22:21:32 -!- Livio [~livio@user/livio] has quit [Ping timeout: 272 seconds]
2025-10-25T22:24:22 -!- Livio_ [~livio@user/livio] has quit [Quit: leaving]
2025-10-25T22:27:19 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-25T23:17:16 -!- System_Error [~SystemErr@user/systemerror] has quit [Ping timeout: 272 seconds]
2025-10-25T23:34:03 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-25T23:45:39 -!- phryk_ [~totallyno@user/phryk] has quit [Quit: ZNC 1.9.1 - https://znc.in]
2025-10-25T23:46:23 -!- phryk [~totallyno@user/phryk] has joined ##stm32
--- Day changed Sun Oct 26 2025
2025-10-26T00:06:32 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 240 seconds]
2025-10-26T00:18:31 -!- ds2 [~ds2@69.54.141.155] has quit [Ping timeout: 244 seconds]
2025-10-26T00:50:04 -!- NEYi [~NEYi@195.234.78.187] has quit [Quit: Leaving]
2025-10-26T01:28:49 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has quit [Ping timeout: 264 seconds]
2025-10-26T02:07:51 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has quit [Quit: Bye]
2025-10-26T02:49:19 < ColdKeybo[a]rd> Did anyone use ap33772s? It's pretty neat for ofloading USB PD negotiation but for some reason when I request a PDO, status is OK, PD result is 1 (indicating success) but the VBus does not change
2025-10-26T03:41:02 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 240 seconds]
2025-10-26T03:20:07 -!- infisd [~infisc@user/infisc] has joined ##stm32
2025-10-26T03:27:47 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-26T03:31:25 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2025-10-26T03:39:46 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 246 seconds]
2025-10-26T06:07:09 < ColdKeybo[a]rd> I'm confused why READY and STARTED bits in the status register are never set...
2025-10-26T06:07:42 < ColdKeybo[a]rd> I can read all the PDOs correctly though
2025-10-26T07:16:20 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-26T07:38:22 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-26T07:53:52 -!- ds2 [~ds2@user/ds2] has joined ##stm32
2025-10-26T08:08:55 -!- martinmoene_ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-26T08:30:07 -!- infisx [~infisc@user/infisc] has joined ##stm32
2025-10-26T08:33:46 -!- infisd [~infisc@user/infisc] has quit [Ping timeout: 246 seconds]
2025-10-26T09:19:28 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2025-10-26T10:04:04 -!- martinmoene_ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 246 seconds]
2025-10-26T10:49:58 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has joined ##stm32
2025-10-26T10:55:13 < machinehum> Getting pandas working on a 32bit thing in buildroot isn't easy
2025-10-26T10:55:28 < machinehum> I feel like I should just switch to armbian or something
2025-10-26T10:55:39 < machinehum> Has anyone done an armbian port?
2025-10-26T12:35:52 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-26T13:31:58 -!- jerrycash2 [~jerrycash@user/jerrycash] has joined ##stm32
2025-10-26T13:34:06 -!- jerrycash [~jerrycash@user/jerrycash] has quit [Ping timeout: 265 seconds]
2025-10-26T14:14:25 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has quit [Ping timeout: 264 seconds]
2025-10-26T14:16:36 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has joined ##stm32
2025-10-26T14:57:42 < Posterdati> hi
2025-10-26T14:58:53 < Posterdati> please help, is anyone able to explain the flowchart on page 2014 of RM0468 (User Manual for stm32h730)? Thanks!
2025-10-26T15:00:47 -!- martinmoene [~martinmoe@132.229.46.129] has quit [Read error: Connection reset by peer]
2025-10-26T15:25:41 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-26T15:56:37 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has quit [Ping timeout: 256 seconds]
2025-10-26T15:57:00 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has joined ##stm32
2025-10-26T16:33:48 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has quit [Quit: Bye]
2025-10-26T16:36:15 < nohit> Posterdati: what it unclear about it ?
2025-10-26T16:39:07 < nohit> just check those register explanations (starting from page 2040), it is quite straight forward
2025-10-26T16:41:05 < nohit> and it is actually explained in the previous page
2025-10-26T17:28:12 -!- martinmoene_ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-26T17:28:21 < catphish> something bad happened - i've started just using HAL and cubeIDE for everything - it "just works"
2025-10-26T17:31:50 < Posterdati> nohit: yes, I was confused by the two diamonds connected in parallel :)
2025-10-26T17:35:17 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-26T17:44:46 < Posterdati> nohit: thanks
2025-10-26T17:46:28 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-26T17:47:27 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-26T18:17:22 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has joined ##stm32
2025-10-26T18:38:25 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-26T18:45:02 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 240 seconds]
2025-10-26T19:25:20 -!- Ecco [~user@user/Ecco] has quit [Ping timeout: 240 seconds]
2025-10-26T19:41:57 < ColdKeybo[a]rd> jpa- I think you mentioned using ap33772s?
2025-10-26T19:42:12 < ColdKeybo[a]rd> Did you have issues with ready and status bits never getting set in the status register?
2025-10-26T19:42:49 < ColdKeybo[a]rd> For some reason I can list PDOs and request a PDO without any issues. But the VUSB voltage never switches
2025-10-26T19:44:25 < jpa-> i have not used them
2025-10-26T20:01:46 < ColdKeybo[a]rd> Might have been qyx... can't remember anymore
2025-10-26T20:01:55 < ColdKeybo[a]rd> Someone suggested it when I mentioned that I was stuck with FUSB302
2025-10-26T20:07:41 < jpa-> i don't see anyone suggesting it directly
2025-10-26T20:08:08 < jpa-> based on log grep, invzim seems to have used it in 2022
2025-10-26T20:15:44 < ColdKeybo[a]rd> Maybe I'm halucinating then... I thought someone mentioned it when I talked about FUSB302
2025-10-26T20:16:25 < jpa-> http://xob.kapsi.fi/~jpa/stm32/2025-10.log  it's there for you to read :)
2025-10-26T20:23:05 < ColdKeybo[a]rd> I'll go inspect the soldering again...
2025-10-26T20:23:35 < ColdKeybo[a]rd> I'm confused that I can read the PDOs, configure the thing, everythign is "working"...
2025-10-26T20:24:26 < ColdKeybo[a]rd> But `started` bit which indicates that the AP's mcu is running is never set. And alo `ready` bit is never set. The INT pin is never asserted but you can use the chip with polling or int mode so that shouldn't "matter" I guess
2025-10-26T20:48:04 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-26T21:18:22 -!- martinmoene_ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 240 seconds]
2025-10-26T21:53:42 < ventYl> catphish: yeah, it actually works much smoother than I expected
2025-10-26T22:10:54 < mawk> why does cubemx wants to set SysTick priority at minimum
2025-10-26T22:11:21 < mawk> ventYl: for established chips yeah
2025-10-26T22:11:25 < mawk> for the new stuff not so much
2025-10-26T22:11:26 < zyp> to not interrupt more important stuff?
2025-10-26T22:11:47 < mawk> I thought having accurate timekeeping is important
2025-10-26T22:11:53 < mawk> it just increments a variable and does nothing else
2025-10-26T22:12:02 < zyp> systick is not accurate timekeeping
2025-10-26T22:13:28 < mawk> I see
2025-10-26T22:15:13 < ventYl> it is weird it sets systick priority to lower/same value than pendsv
2025-10-26T22:15:17 < ventYl> which basically breaks pendsv
2025-10-26T22:15:52 < ventYl> mawk: plausible, I've only used it on h7 and g4 as the most modern stuff
2025-10-26T22:16:04 < zyp> ventYl, how so?
2025-10-26T22:16:07 < ventYl> there's also one h5 lying around but didn't have time to play with it
2025-10-26T22:16:30 < ventYl> zyp: pendsv is meant to have the lowest priority in the system, so there is nothing else priority-wise running in the system
2025-10-26T22:17:13 < zyp> I know what pendsv is, but I don't see why same priority is a problem
2025-10-26T22:17:19 < zyp> lower, sure
2025-10-26T22:17:28 < ventYl> i think it is even lower than pendsv
2025-10-26T22:17:40 < zyp> but if pendsv is already lowest priority, it's not possible to set it lower
2025-10-26T22:17:44 < ventYl> CMRX depends on the fact that pendsv is not preempting any other interrupt
2025-10-26T22:18:14 < mawk> cubemx sets pendsv at max priority too, but I guess you're supposed to lower it yourself if you want to do context switching
2025-10-26T22:18:20 < ventYl> and with default kuba setup pendsv was preempting "default" clock provider infrastructure running off systick
2025-10-26T22:19:47 < zyp> oh well, people doing stupid shit with priorities is nothing new
2025-10-26T22:19:58 < ventYl> https://github.com/ventZl/cmrx/blob/master/src/os/arch/arm/cortex.c#L152
2025-10-26T22:20:07 < ventYl> I had to add explicit check for it
2025-10-26T22:20:18 -!- duude__- [~duude__@user/duude/x-4676560] has joined ##stm32
2025-10-26T22:20:19 < zyp> nobody understands that the priority field is fixedpoint either
2025-10-26T22:20:30 -!- duude__ [~duude__@user/duude/x-4676560] has quit [Ping timeout: 244 seconds]
2025-10-26T22:22:20 < mawk> what do you mean fixed point, you mean the sub-priority thing?
2025-10-26T22:22:28 < mawk> with group priority and sub-priority
2025-10-26T22:22:31 < zyp> no
2025-10-26T22:23:18 < mawk> ah, then what
2025-10-26T22:23:40 < zyp> I mean that if your processor has two bits of priority, you have priority levels 0, .25, .5 and .75, not 0, 1, 2 and 3
2025-10-26T22:24:28 -!- duude__ [~duude__@user/duude/x-4676560] has joined ##stm32
2025-10-26T22:25:02 < mawk> why is that different from thinking about integer values if the relative order is the same
2025-10-26T22:25:56 -!- duude__- [~duude__@user/duude/x-4676560] has quit [Ping timeout: 256 seconds]
2025-10-26T22:27:05 < zyp> because when you have three bits, you get levels .125, .375, .625 and .875 naturally interleaved between those
2025-10-26T22:27:51 < zyp> remember that the priority field is 8-bits wide, and it's the top N bits that are implemented
2025-10-26T22:28:35 < zyp> so if you have a middle priority interrupt (i.e. 0.5), you can just set the priority to 0x80 regardless of how many bits are actually implemented
2025-10-26T22:29:22 < mawk> I see
2025-10-26T22:30:20 < zyp> in other words, if you just treat it as a 0.8 fixed point field, you'll get correct priority ordering regardless of number of implemented bits
2025-10-26T22:30:46 < zyp> when it gets truncated to the actually implemented number of bits, adjacent priorities just gets merged together
2025-10-26T22:31:57 < mawk> right
2025-10-26T22:32:30 < mawk> ventYl: for the MCUs themselves cubemx surely works fine, but for the stm32wb stuff and all the HAL/radio support stuff it definitely doesn't out of the box
2025-10-26T22:32:32 < zyp> it was designed to work like this, and dumb fucks don't get it and instead insists on shit like priority << (8 - NUM_PRIORITY_BITS)
2025-10-26T22:33:38 < mawk> even the UI is buggy, if you exit and enter the STM32_WPAN peripheral view it duplicates all the setting values somehow
2025-10-26T22:33:58 < mawk> and then when you generate code some interrupt handlers are missing so if you run it you get hardfault
2025-10-26T22:34:29 < mawk> I'll just skip the cube and work from the official example code
2025-10-26T22:55:44 < ventYl> mawk: heh, based on experience with USB stack I guess the wireless stack would be completely useless with CreepyOS
2025-10-26T22:57:31 < qyx> zyp: thats interesting because afaik thats exacrly what freertos is doing
2025-10-26T23:00:46 < zyp> the dumbfuck way?
2025-10-26T23:00:52 < zyp> everybody does that
2025-10-26T23:03:27 < ventYl> I've seen this somewhere too
2025-10-26T23:03:45 < ventYl> isn't kuba itself doing this?
2025-10-26T23:13:18 -!- nomorekaki [~nomorekak@188-67-167-20.bb.dnainternet.fi] has joined ##stm32
2025-10-26T23:26:01 < nomorekaki> night pros
2025-10-26T23:27:53 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2025-10-26T23:55:03 < mawk> wow I finally got BLE advertising running
2025-10-26T23:55:12 < mawk> I had to call a bunch of functions at random that weren't being called
2025-10-26T23:55:51 < mawk> apparently the generated code doesn't bother to start the wireless stack so it gets stuck in the CPU2 secure firmware update bootloader and does nothing
2025-10-26T23:57:14 < mawk> still can't program with openocd, and the commandline STM32CubeProgrammer segfaults when I run it
--- Day changed Mon Oct 27 2025
2025-10-27T00:19:22 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 260 seconds]
2025-10-27T00:21:54 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2025-10-27T00:32:07 -!- teknix_ [~unknown@user/hsv] has joined ##stm32
2025-10-27T00:40:44 < mrec_> implementing a motion controller in the stm32 is very interesting, until the bitter end some things are wrong. now the first/initial motion is not synchronised it seems
2025-10-27T00:41:21 < mrec_> I'll nail that one too for sure but it's so unnecessary and wasting time.
2025-10-27T01:03:15 -!- teknix_ [~unknown@user/hsv] has quit [Ping timeout: 244 seconds]
2025-10-27T01:27:22 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has quit [Ping timeout: 240 seconds]
2025-10-27T01:30:29 -!- kovalevsky [~kovalevsk@fedora/kovalevsky] has joined ##stm32
2025-10-27T01:37:24 < catphish> mrec_: what kind of motion controller?
2025-10-27T01:45:56 < mrec_> for a simple XYY gantry, initially trapezoidal afterwards s-curve;
2025-10-27T01:46:50 < mrec_> I want to replace my software based solution to gain higher speeds
2025-10-27T01:54:42 -!- kovalevsky [~kovalevsk@fedora/kovalevsky] has quit [Ping timeout: 240 seconds]
2025-10-27T01:56:46 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 246 seconds]
2025-10-27T01:59:41 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2025-10-27T02:01:02 < catphish> stepper motor control?
2025-10-27T02:01:48 < mrec_> servo but pulsetrain based input
2025-10-27T02:15:59 < mrec_> timers are a source of evil so many possible issues
2025-10-27T02:22:29 < mrec_> fixed, well need to do all the testing again. time to go to bed.
2025-10-27T02:50:08 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2025-10-27T02:55:48 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-27T02:56:59 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-27T02:57:23 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-27T03:53:14 -!- duude__- [~duude__@user/duude/x-4676560] has joined ##stm32
2025-10-27T03:53:51 -!- duude__ [~duude__@user/duude/x-4676560] has quit [Ping timeout: 244 seconds]
2025-10-27T03:55:10 -!- duude__- is now known as duude__
2025-10-27T04:02:23 -!- hexo_ [~hexo@user/hexo] has joined ##stm32
2025-10-27T04:19:18 -!- NEYi [~NEYi@195.234.78.187] has quit [Quit: Leaving]
2025-10-27T04:38:10 -!- martinmoene_ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-27T04:42:42 -!- mspaghetti [~mpasghett@bras-base-toroon0648w-grc-08-142-198-71-106.dsl.bell.ca] has joined ##stm32
2025-10-27T04:53:02 -!- duude__ [~duude__@user/duude/x-4676560] has quit [Ping timeout: 240 seconds]
2025-10-27T04:53:11 -!- duude__- [~duude__@user/duude/x-4676560] has joined ##stm32
2025-10-27T04:54:22 -!- martinmoene_ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 240 seconds]
2025-10-27T04:55:03 -!- duude__- is now known as duude__
2025-10-27T05:29:32 -!- mspaghetti [~mpasghett@bras-base-toroon0648w-grc-08-142-198-71-106.dsl.bell.ca] has quit [Quit: Leaving]
2025-10-27T06:46:58 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-27T07:09:06 -!- nomorekaki [~nomorekak@188-67-167-20.bb.dnainternet.fi] has quit [Quit: Client closed]
2025-10-27T07:45:48 -!- qyx [~qyx@84.245.121.159] has quit [Ping timeout: 256 seconds]
2025-10-27T07:47:30 -!- qyx [~qyx@84.245.120.252] has joined ##stm32
2025-10-27T08:13:08 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-27T08:19:44 -!- martinmoene_ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-27T08:54:02 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2025-10-27T09:41:32 -!- teknix_ [~unknown@user/hsv] has joined ##stm32
2025-10-27T09:55:13 -!- martinmoene_ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 246 seconds]
2025-10-27T10:03:30 -!- teknix_ [~unknown@user/hsv] has quit [Ping timeout: 256 seconds]
2025-10-27T10:22:45 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-27T10:34:56 -!- teknix_ [~unknown@user/hsv] has joined ##stm32
2025-10-27T10:49:01 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-27T10:54:20 < mrec_> https://streamable.com/mnjz84
2025-10-27T10:54:29 < mrec_> so next step s-curve support :-)
2025-10-27T10:54:48 < mrec_> those servos are just for testing, the final servos are much stronger.
2025-10-27T10:56:16 < mrec_> also they hvae no feedback, the final servos have ABZ feedback
2025-10-27T10:57:09 -!- martinmoene [~martinmoe@132.229.46.129] has joined ##stm32
2025-10-27T12:13:20 < karlp> zyp: that's the first time I've seen an explanation for the priority bits that makes any sort of sense.  I believe ARM docs are to blame for people treating as integeres and shifting.  they might have designed it one way, but it sure isn't documented well to encourage that thinking.
2025-10-27T12:23:31 < zyp> > Register priority value fields are 8 bits wide, and un-implemented low-order bits read as zero and ignore writes.
2025-10-27T12:24:45 < zyp> not super obvious, but you shouldn't have to think too hard to realize why it's the low-order bits that are optional, not the high order bits
2025-10-27T12:27:05 < karlp> except ~everyone got it wrong....
2025-10-27T12:27:18 < karlp> but sure, the docs are perfect, it's the users who are wrong.
2025-10-27T12:27:24 < zyp> it's a matter of portability and binary compatibility, if you're moving to a processor with fewer bits implemented than what you're using and high order bits were truncated, it'd mess up the priority order entirely
2025-10-27T12:27:46 < karlp> it's easy if you get it, it's not at all from what they provide.
2025-10-27T12:27:48 < qyx> yes but the docs should include "it's a matter of portability and binary compatibility,.."
2025-10-27T12:28:43 < zyp> at least users can't fuck it up too hard either way
2025-10-27T12:29:00 < karlp> sure they can, it's usper common for them to not shift the right amount and get everythign at zero
2025-10-27T12:29:16 < zyp> that's «not too hard» in my book
2025-10-27T12:29:52 < karlp> well, I do often envy your skills, but I feel you're being a little bit condescending on this one :)
2025-10-27T12:30:40 < zyp> I mean, better fuck it up and get everything at the same priority than fuck it up and get a higher priority interrupt below a lower priority one
2025-10-27T12:32:06 < zyp> «x is not allowed to be preempted by y» is a much more common requirement than «x must be able to preempt y»
2025-10-27T12:35:20 -!- teknix_ [~unknown@user/hsv] has quit [Ping timeout: 240 seconds]
2025-10-27T12:55:22 < jpa-> i feel the opposite
2025-10-27T12:55:44 < jpa-> i usually have all interrupts at same priority, until i have something that must not be delayed by the others
2025-10-27T12:56:07 < mawk> do all the other GPIO settings stay the same if I put a pin in analog mode and then back to the previous mode?
2025-10-27T12:56:08 < jpa-> but doing that, i'm usually fine with 4 levels or so
2025-10-27T12:56:12 < mawk> like output value, speed, pullup/down, etc
2025-10-27T12:56:23 < jpa-> mawk: yes
2025-10-27T12:56:29 < mawk> ah nice
2025-10-27T12:56:29 < zyp> jpa-, and by doing that, you've already covered the first requirement
2025-10-27T12:56:33 < mawk> thanks
2025-10-27T12:56:58 < zyp> so naturally it's the situations where you have the second that stick out
2025-10-27T12:57:16 < jpa-> true
2025-10-27T12:58:19 < jpa-> now if you can also figure out how i can remember whether 0 is high or low priority in a particular context (interrupts, dma, rtos)
2025-10-27T12:58:33 < zyp> :D
2025-10-27T12:58:37 < mawk> I assume pullup/down is implicitly disabled in analog mode
2025-10-27T12:59:04 < mawk> ah yes
2025-10-27T12:59:09 < mawk> very good
2025-10-27T13:03:13 < zyp> always fun to go into a new part of zephyr and see how they've managed to fuck up the API this time
2025-10-27T13:03:27 < zyp> about to start with the DNS API now
2025-10-27T13:03:41 < jpa-> s/fuck up/innovate/
2025-10-27T13:04:11 < zyp> I spent all friday trying to get TLS to work
2025-10-27T13:12:53 < karlp> getting tls working in a day still sounds like a win :)
2025-10-27T13:15:21 -!- teknix_ [~unknown@user/hsv] has joined ##stm32
2025-10-27T13:16:01 < ventYl> someone on the internets discovered that zephyr does malloc() internally
2025-10-27T13:16:05 < ventYl> and they are much surprised
2025-10-27T13:24:06 -!- teknix_ [~unknown@user/hsv] has quit [Ping timeout: 256 seconds]
2025-10-27T13:30:37 -!- kovalevsky [~kovalevsk@fedora/kovalevsky] has joined ##stm32
2025-10-27T13:31:30 < zyp> karlp, I didn't
2025-10-27T13:32:22 < zyp> I got it working this morning though, last issue was that default connection timeout is 3s, and TLS handshake takes longer
2025-10-27T13:32:50 < qyx> longer?
2025-10-27T13:33:07 < qyx> what mcu is that?
2025-10-27T13:33:21 < qyx> or is it network related
2025-10-27T13:34:17 < zyp> no, tested on lan, stm32h5
2025-10-27T13:34:36 < qyx> and it takes 3 seconds?
2025-10-27T13:35:55 < zyp> 4-ish: https://bin.jvnv.net/file/tHh2a.png
2025-10-27T13:36:16 < jpa-> that's some slow crypto
2025-10-27T13:36:30 < zyp> that's what I thought too
2025-10-27T13:36:47 < zyp> but it's the first time I do TLS on MCU so I'm not sure what to expect
2025-10-27T13:38:16 < jpa-> esp32 seems to do it much faster, but i'm not sure how well it is verifying certs
2025-10-27T13:38:18 < qyx> meh but I suspect there is rsa involved
2025-10-27T13:38:19 < zyp> hmm, I'm also not sure how I've got sysclk configured, might be I'm not running at full speed
2025-10-27T13:38:47 < qyx> also tls 1.2 so no fancy new fast algos
2025-10-27T13:39:20 < zyp> yes, negotiated cipher suite is TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
2025-10-27T13:41:14 < qyx> omg
2025-10-27T13:41:19 < zyp> idk, I'm not performance tuning this now anyway
2025-10-27T13:41:55 < zyp> just making a nice mqtt API on top of this shit
2025-10-27T13:42:11 < qyx> no but it feels weird to use sha2 and rsa in 2026, nearly
2025-10-27T13:42:20 < zyp> hence why I'm doing DNS next
2025-10-27T13:42:23 < zyp> yeah, idk
2025-10-27T13:42:24 < qyx> there is ecdhe+ecdsa
2025-10-27T13:42:43 < zyp> maybe I just need to enable it
2025-10-27T13:43:11 < zyp> GCM was also disabled by default, until I disabled it server and client had no suites in common
2025-10-27T13:44:35 < qyx> I would also use chacha20+poly on a mcu wthout hw GCM support
2025-10-27T13:46:09 < zyp> hmm, enabled ECDSA, server still picks RSA
2025-10-27T13:46:50 < qyx> what's in the cert?
2025-10-27T13:47:34 -!- teknix_ [~unknown@user/hsv] has joined ##stm32
2025-10-27T13:48:09 < qyx> idk how is it related to pki
2025-10-27T13:49:23 < zyp> cert is RSA I think, but that's unrelated to key exchange, isn't it?
2025-10-27T13:49:58 < zyp> but eh, I don't care it's slow, optimizing that shit is for another time
2025-10-27T14:33:23 < zyp> hmm, the DNS API in zephyr might actually be one of the saner things; I also remembered that I already did a laks wrapper for this last year: https://paste.jvnv.net/view/E6Y8E
2025-10-27T14:49:49 -!- teknix_ [~unknown@user/hsv] has quit [Ping timeout: 264 seconds]
2025-10-27T15:11:41 -!- benishor [~benishor@scene.ro] has quit [Quit: tah tah!]
2025-10-27T15:13:54 -!- benishor [~benishor@scene.ro] has joined ##stm32
2025-10-27T15:24:09 < qyx> yes kex is unrelated but authentication is
2025-10-27T15:24:58 < qyx> if you have a rsa cert it must do rsa in order to compute the whole pki path
2025-10-27T15:26:21 < tomeaton17> nice
2025-10-27T15:29:17 < qyx> what is not nice is it is pouring again
2025-10-27T15:29:47 < tomeaton17> Steffanx: what is the smallest amount you would request on a tikkie?
2025-10-27T15:30:03 < tomeaton17> where is it raining?
2025-10-27T15:31:13 < karlp> in spain, on the plains, i'm told...
2025-10-27T15:31:39 < ventYl> in england. since 1983
2025-10-27T15:31:58 < tomeaton17> its nice here actually just quite windy currently
2025-10-27T15:32:30 < tomeaton17> I will start gas
2025-10-27T15:35:05 -!- teknix_ [~unknown@user/hsv] has joined ##stm32
2025-10-27T16:10:52 < Steffanx> What kind of open question is that tomeaton17 ?
2025-10-27T16:11:43 < qyx> just respond with $4
2025-10-27T16:15:35 -!- teknix_ [~unknown@user/hsv] has quit [Remote host closed the connection]
2025-10-27T16:18:23 < tomeaton17> Steffanx: just wanting an insight into dutch culture
2025-10-27T16:32:02 < Steffanx> I'm not your average dutchy I guess. It totally depends on the context and who it is
2025-10-27T16:33:33 < tomeaton17> Steffanx: fair enough. Cracki sent this https://i.4cdn.org/int/1761473878422532.jpg was wondering how accurate it is 
2025-10-27T16:38:54 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-27T16:39:53 < Steffanx> Cracki. Nuff said 😝
2025-10-27T16:45:48 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-27T16:46:51 < Steffanx> Yeah thats bullshit tomeaton17 
2025-10-27T16:47:58 < BrainDamage> I can imagine over the entire population some people are stingy, but that's extreme cherry picking
2025-10-27T16:48:06 < Steffanx> That would maybe happen when you get 5 euro bucks coffee at some shitty place.
2025-10-27T16:51:47 < BrainDamage> here you just agree who pays and how much when you go to a commercial avenue, if you're hosting someone, the implicit social contract is that you're paying for it entirely, so you don't offer anything you're not willing to give away, and also near every place will give you a glass of water from the tap for free if you ask without any strings attache
2025-10-27T16:56:39 < zyp> here all serving places are required by law to provide free tap water
2025-10-27T16:56:57 -!- ThatDamnRanga [~ThatDamnR@UNASSIGNED-218-100-26-71.3cix.nzix.net] has quit [Ping timeout: 265 seconds]
2025-10-27T16:57:54 < qyx> here all serving places are required to provide free toilet
2025-10-27T16:58:03 < zyp> that too
2025-10-27T16:58:13 < qyx> so, tap water is inside :>
2025-10-27T16:58:56 < qyx> zyp: what do you think about doing a simple fpga rmii/rgmii switch?
2025-10-27T16:58:59 < qyx> like SJA1105 is
2025-10-27T16:59:15 < qyx> I mean, I have no fpga experience so idk what the complexity is
2025-10-27T16:59:39 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2025-10-27T17:00:08 < zyp> *mii is easy, complexity depends on feature set and performance goals
2025-10-27T17:00:45 < qyx> https://www.latticesemi.com/products/designsoftwareandip/intellectualproperty/ipcore/flexibiliscores/flexibilisethernetswitch
2025-10-27T17:00:48 < qyx> oh see
2025-10-27T17:02:00 < zyp> e.g. mac learning/lookup
2025-10-27T17:02:47 < qyx> I would say all the "common" features, except avb, tsn, etc.
2025-10-27T17:03:05 < qyx> mac learning is a common feature
2025-10-27T17:03:14 < zyp> I've never done a switch, but I've done other ethernet stuff, ports are just a matter of a block that turns *MII into a stream pair
2025-10-27T17:04:14 < zyp> the core problem of a switch is figuring out what packets to put into which queues
2025-10-27T17:04:37 < qyx> I guess the lookup itself is hard on a fpga?
2025-10-27T17:04:45 < zyp> which requires you to learn and look up MAC addrs
2025-10-27T17:05:10 < zyp> idk, I figure it depends on the size of the table
2025-10-27T17:06:56 < zyp> if you're doing something application specific where you can make assumptions about the network topology (e.g. certain ports only having a single device behind them), you can probably simplify stuff a bunch
2025-10-27T17:07:31 < qyx> that's most probably not possible
2025-10-27T17:09:48 < qyx> I'll try to get SJA1105 working first :P
2025-10-27T17:11:05 < zyp> there's also opensource switch cores, so best case you can just drop some shit into the fpga and call it a day :p
2025-10-27T17:11:09 < zyp> e.g. https://github.com/mcjtag/eth_switch
2025-10-27T17:12:42 < zyp> this also looks a bit cute: https://github.com/the-aerospace-corporation/satcat5
2025-10-27T17:13:58 < qyx> the mcjtag one looks easy
2025-10-27T17:16:54 < zyp> I've been thinking about writing a switch core before (but haven't needed one yet)
2025-10-27T17:19:11 < zyp> I'm picturing ingress queue per port, egress queue per port, observer that does mac learning on each ingress port, observer that does mac lookup on each ingress port, parallel queue with lookup results next to ingress queue with bitmap of target ports
2025-10-27T17:20:07 < zyp> crossbar that looks at the bitmap and forwards the packet into each egress queue
2025-10-27T17:21:12 < zyp> then a mac table block that gets one stream of learned macs, one stream of lookup requests and provides one stream of lookup results, hooked up to the observers through some arbiters
2025-10-27T17:22:06 < zyp> can do multicast as well if you do IGMP snoop
2025-10-27T17:23:57 < zyp> then the question is flow control rules, where/when do you drop packets when there's congestion?
2025-10-27T17:24:44 < qyx> ok sounds much more complex than I though, all are valid points
2025-10-27T17:27:26 < zyp> I think the solution to flow control is to drop at the crossbar when the egress queue is full
2025-10-27T17:42:45 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-27T18:05:43 < tomeaton17> Steffanx: thanks for the cultural insight
2025-10-27T18:27:53 < karlp> meh, same device, same usb host stack (from nxp), but with nxp's freertos and startup code: https://bin.jvnv.net/file/8VWEx.png  then with my own (laks) startup code, i get this for an LS device, where it can' tmake up it's mind: https://bin.jvnv.net/file/kFSia.png
2025-10-27T18:27:59 < karlp> and the FS devices work fine with both.
2025-10-27T18:28:44 < ventYl> karlp: you were compaining on lack of DMA support in tinyusb, did you measure your USB throughput with non-DMA stack?
2025-10-27T18:28:58 < karlp> no, I was complaining about lack of functionality in tinyusb...
2025-10-27T18:29:28 < karlp> cherry doesn't support the dwc_otg_fs cores in stm32 because stm32 doesn't provide DMA for the FS blocks.
2025-10-27T18:29:43 < karlp> and that meant I didn' thave aany stm32 boards I could use with cherry 
2025-10-27T18:29:54 < qyx> 16:28 < karlp> no, I was complaining about lack of functionality in tinyusb...
2025-10-27T18:29:55 < qyx> lold
2025-10-27T18:31:16 < karlp> my tinyusb host tests: https://bin.jvnv.net/file/88xgY.png
2025-10-27T18:31:53 < karlp> the inconsistences in the first two columns made me give up trying to get the third column there...
2025-10-27T18:32:13 < karlp> the nxp stack is all hearts, but only in their example. 
2025-10-27T18:32:17 < tomeaton17> what does the bomb mean
2025-10-27T18:32:30 < karlp> I have not for the fucking life of my been able to make it work without the entire nxp stack behind it.
2025-10-27T18:32:43 < karlp> tomeaton17: any guesses?
2025-10-27T18:33:22 < tomeaton17> magic smoke escape
2025-10-27T18:34:56 < tomeaton17> incompatible or something I guess or didn't test
2025-10-27T18:35:16 < ventYl> yeah, tinyusb contains random bugs
2025-10-27T18:35:22 < ventYl> so random combo of stuff simply doesn't work
2025-10-27T18:35:28 < ventYl> for me it was two vendor endpoints
2025-10-27T18:35:48 < ventYl> while you were talking to the first one, everything was OK. send *one* message to the latter and whole thing locks up
2025-10-27T18:36:25 < ventYl> s/endpoints/interfaces/
2025-10-27T18:36:26 < karlp> tomeaton17: I take it you require green check marks and red crosses then :)
2025-10-27T18:36:57 < tomeaton17> karlp: lol I don't care as long as there is a legend
2025-10-27T18:37:28 < ventYl> also, my integration sucks, so it actually hurts to upgrade tinyusb in the project :/
2025-10-27T18:37:44 < karlp> ventYl: you're doing device though right?
2025-10-27T18:37:57 < ventYl> karlp: device through?
2025-10-27T18:38:27 < karlp> art thou doing device?
2025-10-27T18:38:52 < ventYl> yes
2025-10-27T18:39:04 < karlp> I'm led to believe tinyusb is ~reasonably functional for device.  I've only been looking at host...
2025-10-27T18:39:04 < ventYl> ah, you were doing host side
2025-10-27T18:39:12 < ventYl> now I remember
2025-10-27T18:39:37 < ventYl> I'd limit it further that it works reasonably functional for trivial device setups and/or HIDs
2025-10-27T18:39:47 -!- teknix_ [~unknown@user/hsv] has joined ##stm32
2025-10-27T18:39:55 < karlp> hid and functional and simple is  a fucking joke  though.
2025-10-27T18:40:07 < karlp> anywya, that's a different issue altogether :)
2025-10-27T18:40:20 < ventYl> I'
2025-10-27T18:40:44 < ventYl> ve found that vendor interfaces break in scenarios where HIDs work
2025-10-27T18:40:52 < ventYl> simple device reset was enough to break vendor interface
2025-10-27T18:41:32 < ventYl> this one was at least fixed in the upstream
2025-10-27T18:43:58 -!- teknix_ [~unknown@user/hsv] has quit [Read error: Connection reset by peer]
2025-10-27T19:39:14 -!- infisx [~infisc@user/infisc] has quit [Ping timeout: 256 seconds]
2025-10-27T19:57:14 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 265 seconds]
2025-10-27T20:13:33 -!- martinmoene_ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-27T20:28:38 -!- kovalevsky_ [~kovalevsk@190.103.220.93] has joined ##stm32
2025-10-27T20:28:45 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-27T20:29:05 -!- hexo__ [~hexo@user/hexo] has joined ##stm32
2025-10-27T20:30:34 -!- duude__- [~duude__@user/duude/x-4676560] has joined ##stm32
2025-10-27T20:32:58 -!- qyx_ [~qyx@84.245.120.252] has joined ##stm32
2025-10-27T20:37:36 -!- Netsplit *.net <-> *.split quits: duude__, phryk, hexo_, kovalevsky, ds2, martinmoene_, qyx
2025-10-27T20:38:08 -!- duude__- is now known as duude__
2025-10-27T20:45:42 -!- ds2 [~ds2@69.54.141.155] has joined ##stm32
2025-10-27T20:50:07 -!- teknix_ [~unknown@user/hsv] has joined ##stm32
2025-10-27T21:13:51 -!- phryk [~totallyno@user/phryk] has joined ##stm32
2025-10-27T21:14:27 -!- teknix_ [~unknown@user/hsv] has quit [Read error: Connection reset by peer]
2025-10-27T21:21:04 < mawk> why do you want tls on the device itself zyp
2025-10-27T21:21:17 < mawk> it sounds annoying to update the root certificates
2025-10-27T21:21:38 < mawk> is it on wifi? or cellular
2025-10-27T21:22:04 < mawk> for cellular we gave up on tls and asked the carrier to setup an ipsec tunnel with everything inside that we need
2025-10-27T21:36:14 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-27T21:42:34 -!- qyx_ is now known as qyx
2025-10-27T21:45:34 < qyx> a what?
2025-10-27T21:45:37 < qyx> is it 1990?
2025-10-27T22:32:17 -!- kovalevsky_ [~kovalevsk@190.103.220.93] has quit [Ping timeout: 260 seconds]
2025-10-27T22:37:51 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has joined ##stm32
2025-10-27T22:58:38 < karlp> he dropped a "someone elses problem" field on the it :()
2025-10-27T23:00:19 -!- jerrycash [~jerrycash@user/jerrycash] has joined ##stm32
2025-10-27T23:02:22 -!- jerrycash2 [~jerrycash@user/jerrycash] has quit [Ping timeout: 256 seconds]
2025-10-27T23:24:03 < mawk> that's the telco standard qyx 
2025-10-27T23:24:06 < mawk> what do you expect them to use
2025-10-27T23:45:57 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
--- Day changed Tue Oct 28 2025
2025-10-28T00:08:16 -!- nomorekaki [~nomorekak@188-67-167-20.bb.dnainternet.fi] has joined ##stm32
2025-10-28T00:08:27 < nomorekaki> it's officially night shift
2025-10-28T00:09:09 < ventYl> bakerman is baking bread
2025-10-28T00:11:04 < nomorekaki> is ventYl baking nice bread?
2025-10-28T00:12:54 < ventYl> i only tried that once, result was not-a-bread
2025-10-28T00:13:13 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 264 seconds]
2025-10-28T00:26:18 -!- teknix_ [~unknown@user/hsv] has joined ##stm32
2025-10-28T00:35:14 -!- teknix_ [~unknown@user/hsv] has quit [Read error: Connection reset by peer]
2025-10-28T00:38:56 -!- drew` [~drew@user/drew] has joined ##stm32
2025-10-28T00:39:39 -!- drew` [~drew@user/drew] has quit [Remote host closed the connection]
2025-10-28T00:46:18 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-28T00:47:18 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-28T00:47:43 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-28T00:49:34 -!- drew` [~drew@user/drew] has joined ##stm32
2025-10-28T00:50:20 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has quit [Ping timeout: 256 seconds]
2025-10-28T00:50:58 -!- drew` is now known as drew
2025-10-28T00:52:01 -!- teknix_ [~unknown@user/hsv] has joined ##stm32
2025-10-28T00:59:08 -!- teknix_ [~unknown@user/hsv] has quit [Read error: Connection reset by peer]
2025-10-28T01:06:59 -!- NEYi_ [~NEYi@195.234.78.187] has joined ##stm32
2025-10-28T01:07:33 -!- hackkitten [~hackkitte@94.31.119.144] has quit [Ping timeout: 250 seconds]
2025-10-28T01:09:23 -!- hackkitten [~hackkitte@94.31.119.144] has joined ##stm32
2025-10-28T01:10:31 -!- NEYi [~NEYi@195.234.78.187] has quit [Ping timeout: 264 seconds]
2025-10-28T01:15:01 -!- hackkitten [~hackkitte@94.31.119.144] has quit [Ping timeout: 264 seconds]
2025-10-28T01:35:06 -!- teknix_ [~unknown@user/hsv] has joined ##stm32
2025-10-28T01:36:51 -!- teknix_ [~unknown@user/hsv] has quit [Read error: Connection reset by peer]
2025-10-28T01:42:57 -!- kovalevsky_ [~kovalevsk@181.168.239.174] has joined ##stm32
2025-10-28T01:43:54 -!- nomorekaki [~nomorekak@188-67-167-20.bb.dnainternet.fi] has quit [Quit: Client closed]
2025-10-28T01:45:00 -!- hackkitten [~hackkitte@94.31.119.144] has joined ##stm32
2025-10-28T03:13:08 -!- kovalevsky_ [~kovalevsk@181.168.239.174] has quit [Ping timeout: 256 seconds]
2025-10-28T03:22:12 < zyp> mawk, depends on the project, the code is going into three different projects I'm working on that all call for MQTT comms
2025-10-28T03:22:33 < zyp> two of them are lte, the third is eth/wifi
2025-10-28T03:25:16 < zyp> I don't really care what backend they connect to and whether it's TLS or plain TCP, that's outside my scope, I just need to support both
2025-10-28T03:26:06 < zyp> and I don't care about the cellular operator either
2025-10-28T03:29:11 < zyp> what I do care about is that my MQTT API is reliable and well behaved, in other words easy to use and hard to fuck up
2025-10-28T04:06:55 -!- NEYi_ [~NEYi@195.234.78.187] has quit [Quit: Leaving]
2025-10-28T04:26:44 -!- teknix_ [~unknown@user/hsv] has joined ##stm32
2025-10-28T06:12:41 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-28T07:24:56 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-28T07:25:54 -!- fdarling [~forest@syn-096-033-104-194.biz.spectrum.com] has joined ##stm32
2025-10-28T07:31:47 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-28T07:42:20 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-28T08:07:18 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-28T09:25:49 -!- teknix_ [~unknown@user/hsv] has quit [Ping timeout: 264 seconds]
2025-10-28T09:32:12 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2025-10-28T09:53:43 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 246 seconds]
2025-10-28T10:39:06 < qyx> do you know of any well-written bug reporting guidelines?
2025-10-28T10:39:24 < qyx> so far no good google
2025-10-28T10:52:23 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-28T10:55:15 < zyp> hmm?
2025-10-28T10:57:58 < qyx> there are many good "how to write a proper git commit message" howtos, but I can't find any good "how to write a proper bug report" howto
2025-10-28T10:58:23 < qyx> I am lazy to write one and want to send customer some.. guiding
2025-10-28T10:59:03 < jpa-> just try to get them to give you something that you can repro the problem with
2025-10-28T10:59:45 < zyp> yeah, I was about to say I don't know any specific ones, but whatever it is should talk about submitting a «minimal reproducible example»
2025-10-28T10:59:45 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-28T11:00:26 < zyp> this one might be good: https://matthewrocklin.com/minimal-bug-reports.html
2025-10-28T11:01:05 < zyp> which links to this, which also looks good: https://stackoverflow.com/help/minimal-reproducible-example
2025-10-28T11:41:55 < Steffanx> Lol you expect your customers to write a proper bug report? "It doesn't work" isn't enough? ;)
2025-10-28T11:43:14 < ventYl> in embedded domain, it is good enough if they actually complain about the problem they have rather than ask for some hack to be implemented
2025-10-28T11:48:33 < karlp> oh yeah, I have that a lot.
2025-10-28T11:49:09 < karlp> "we need this weird knob that does this weird thing" "no why! just because we need it!!" "yes, this other thing we've used has it, we need it!!!!!" 
2025-10-28T11:52:18 < qyx> Steffanx: he is a programmer, so yes
2025-10-28T11:52:37 < qyx> he should know to include steps to reproduce or at least a log of his attempt
2025-10-28T11:52:40 < qyx> there is nothing
2025-10-28T11:53:28 < qyx> "oh we think this should work, no it is not a contracted feature, we just assumed it should work, so we tested with the outcome it definitely doesn't work, we need to fix that asap because we rely on this undocumented and uncontracted feature"
2025-10-28T11:53:34 < ventYl> karlp: around here it is more like "can this interface ID field actually be a bitmask?"
2025-10-28T11:54:03 < qyx> the joke is it *is* implemented despite not being requested and I confirmed it actually works
2025-10-28T11:54:30 < ventYl> then after 30 minutes I figure out that the root issue is application side developer is lazy to properly filter out-of-band data and has anecdotal evidence that there are no out of band data before the first command sent to the device
2025-10-28T11:57:38 < zyp> karlp, https://xkcd.com/1172/
2025-10-28T11:59:21 < karlp> yeah, I remember that one :)
2025-10-28T11:59:51 < karlp> in weighing, there's this thing called "multi-range" where a you have different precision in different ranges of weights.
2025-10-28T11:59:54 < karlp> sounds reasonable.
2025-10-28T12:00:13 < karlp> there's also _multi-interval_ which is... the same, but what people would normally think of.
2025-10-28T12:00:35 < karlp> multirange is "classic" and it means that if you go up a range, you can't go down a range until it goes alllll the way back to zero.
2025-10-28T12:00:43 < ventYl> zyp: :D
2025-10-28T12:00:46 < karlp> this is apparently because old load cells had hysterhesis problems....
2025-10-28T12:01:19 < karlp> still, for "tradition" reasons, there's all sorts of behaviour baked into the regs on multi-range, and for "tradition" reasons, lots of scales get approved as multi-range, not multi-interval.
2025-10-28T12:01:19 < ventYl> we are doing it like this for 15 years and we see nothing wrong at it
2025-10-28T12:01:27 < ventYl> ^^
2025-10-28T12:01:56 < karlp> so we have knobs and buttons that are all working around dumb historical regs tied to multi-range, when if we just sent in the papers and said "it'smulti interval" it would all go away.
2025-10-28T12:02:09 < karlp> but then they can't just copy the old papers from the old scales.... so....
2025-10-28T12:02:33 < karlp> in ohter news, I lost count of how many cars I saw abandoned on the side of the road this morning :)
2025-10-28T12:02:42 < karlp> office is verrrrrry empty
2025-10-28T12:02:53 < BrainDamage> sudden  snow storm?
2025-10-28T12:02:58 < karlp> I'm only here because other wise I'd be at home with the kids and wouldn't get anything done...
2025-10-28T12:03:20 < karlp> BrainDamage: not ... sudden, it was well forecasted, but yeah, first one of the season in town, and has given us like 20cm
2025-10-28T12:03:34 < karlp> my MIL waited ~5 hours in line yesterday to get winter tires put on
2025-10-28T12:05:05 < karlp> https://nc.beeroclock.net/s/7MTpqwHWYAR8X36
2025-10-28T12:07:29 < ventYl> this fucking conference registration form is expecting that I am attending the conference for some company
2025-10-28T12:08:40 < ventYl> s/for/in the name/
2025-10-28T12:09:13 < BrainDamage> umbrella corporation
2025-10-28T12:10:22 < karlp> ventYl: I get that all the time for "public" meetings here
2025-10-28T12:10:26 < qyx> karlp: somehow I expected you are using winter tires all year long
2025-10-28T12:10:35 < karlp> not a lot of belief that citizens might actually attend.
2025-10-28T12:10:53 < karlp> qyx: I'm on all year tires, but lots of people switch summer tires and winter tires.
2025-10-28T12:11:06 < ventYl> https://digital-nomad.sk/img/ese_reg_form.png
2025-10-28T12:11:21 < karlp> some insist on studs, "i drive in the countryside once a year! I need studs ripping up the city roads for six months!"
2025-10-28T12:12:06 < qyx> y no preview in your nc
2025-10-28T12:12:14 < zyp> usually I have exactly one day each winter where it'd be nice to have studded tires
2025-10-28T12:12:16 < karlp> probably because nc is dumb and slow.
2025-10-28T12:12:33 < ventYl> BrainDamage: as these are germans I expect an e-mail response that "Es ist nicht gut lachen machen mit Uns"
2025-10-28T12:12:34 < qyx> what about tire chains instead?
2025-10-28T12:12:45 < karlp> qyx: super rare here.
2025-10-28T12:12:47 < qyx> arent they much faster to get on than studdy tires?
2025-10-28T12:12:48 < zyp> and if I actually had studded tires, those would probably be ground down by the time that day rolls around
2025-10-28T12:13:05 < karlp> qyx: "just put on the winter tires, no longer my problem"
2025-10-28T12:13:22 < qyx> if course chains are put on winter tires
2025-10-28T12:13:28 < karlp> qyx: and no, if you don't to it regualrly, chains are a fucking menace.
2025-10-28T12:13:31 < qyx> as an addition
2025-10-28T12:13:32 < ventYl> with reasonably good winter tires any reasonable amount of snow should be OK
2025-10-28T12:13:32 < karlp> and dangerous
2025-10-28T12:13:47 < karlp> ventYl: yeah, problem on a day like today is all the people still on summer tires.
2025-10-28T12:13:50 < zyp> snow is not the issue, ice is
2025-10-28T12:14:00 < ventYl> if amount becomes unreasonable then something else becomes a blocker, such as ground clearance
2025-10-28T12:14:18 < BrainDamage> I have winter tires, but going uphill requires to put chains too
2025-10-28T12:14:49 < BrainDamage> the main road to access the city center is on a 30% slope
2025-10-28T12:14:56 < karlp> youch
2025-10-28T12:15:00 < zyp> studless winter tires are better than studded in snow, the issue is that one day where the road surface is just a smooth sheet of ice and they haven't gotten around to sand the road yet
2025-10-28T12:15:05 -!- teknix_ [~unknown@user/hsv] has joined ##stm32
2025-10-28T12:15:20 < qyx> yeah so just stay home that day
2025-10-28T12:15:23 < zyp> yup
2025-10-28T12:15:56 < ventYl> in one such day I slipped on ice before I could get into car
2025-10-28T12:16:23 < ventYl> I held a bag of wasabi powder which smashed on ground and broke
2025-10-28T12:16:25 < jpa-> studs seem to be the only real option on bikes, i guess the dynamics don't lend well to non-studded winter tires
2025-10-28T12:16:36 < ventYl> wasabi powder sucks as de-icing salt substitute
2025-10-28T12:16:36 < zyp> last time that happened I had guests over that I were driving home, afterwards I couldn't make it up the last hill when going home, so I just left the car in a parking lot and walked the rest of the way
2025-10-28T12:16:49 < zyp> next morning the roads were sanded and there were no more issue
2025-10-28T12:17:49 < BrainDamage> here it hardly ices, then again, snow also doesn't last super long, just a couple of weeks per year
2025-10-28T12:19:33 < karlp> now, how to make caddy serve precompressed and _only_ precompressed.
2025-10-28T12:20:08 < zyp> also I change the tires myself, not just because I don't want to pay for it, but because I don't want to wait to have it done
2025-10-28T12:20:28 < ventYl> which reminds me I should change tires
2025-10-28T12:20:41 < karlp> no, let's just not have this one use compression, fuck it.
2025-10-28T12:21:32 < BrainDamage> I have a tire changing shop literally in front of my home, if you book it a week in advance it's a matter of going in and getting it back within 15 min
2025-10-28T12:22:01 < zyp> when I buy new tires, I always do it before putting them on the car, so I just go to the tire shop in the morning and leave a stack of wheels there, then go back and pick them up with new tires on after work
2025-10-28T12:22:28 < zyp> and there's always a long line of cars waiting to have their tires changed that I just drive right past
2025-10-28T12:24:22 < zyp> with a decent jack and impact driver, switching the tires myself doesn't take long either
2025-10-28T12:25:09 < ventYl> or long-enough bar
2025-10-28T12:25:48 < zyp> you don't need that unless you overtorque the nuts
2025-10-28T12:26:47 < ventYl> nuts on my car have only two modes. they either loosen over (rather short) time, or it is hard to loosen them when it is needed
2025-10-28T12:27:19 < zyp> do you use a torque wrench for tightening?
2025-10-28T12:27:33 < zyp> if not, that's why
2025-10-28T12:27:44 < ventYl> initialy I thought that the problem is nut head shape so I bought another set with correct shape
2025-10-28T12:28:09 < tomeaton17> just use an impact driver it should be alright
2025-10-28T12:28:13 < ventYl> I might try if the one I have has sufficient range
2025-10-28T12:29:26 < qyx> idk works here, no torque wrench
2025-10-28T12:29:40 < qyx> but I grease the bolts every year
2025-10-28T12:31:20 < qyx> I have a pneu service with an old guy nearby, so sometimes I go there
2025-10-28T12:32:16 < zyp> I used to just use the impact with «torque rods» or whatever they're called in english, usually that's fairly accurate, but after one of my friends bought a nice torque wrench for the workshop I just spend a minute to go over with that afterwards
2025-10-28T12:32:23 < qyx> he also offered to replace the oil and brake discs and stuff but once I saw he wrote "2019 richter" on his wall to remember what car I have, I went to my usual place instead
2025-10-28T12:32:32 < tomeaton17> My car is being scrapped so I get to rag it around
2025-10-28T12:33:11 < zyp> I replaced a pair of brake discs on my car to get it to pass inspection a few weeks ago
2025-10-28T12:34:01 < tomeaton17> my emissions are fucked and will probably cost more to fix than to get rid
2025-10-28T12:34:15 < qyx> which reminds me my timing belt needs some love too
2025-10-28T12:34:27 < qyx> that's an item zyp doesn't have
2025-10-28T12:34:29 < zyp> common issue on EVs is that they don't put so much wear on the brakes that the discs rust
2025-10-28T12:34:32 < tomeaton17> I hope its not wet
2025-10-28T12:35:02 < qyx> nope, 1.2L gasoline has wet belt
2025-10-28T12:35:05 < qyx> this one has a chain
2025-10-28T12:35:12 < tomeaton17> lovely
2025-10-28T12:35:15 < zyp> but in this case the back brakes were all worn out, and the sound I've been hearing for a while but haven't bothered to check out yet was the «brake pad wear warning» thing
2025-10-28T12:35:29 < zyp> never seen that on an EV; was really surprised
2025-10-28T12:35:55 < qyx> I would be surprised if you had a oil change warning thing instead
2025-10-28T12:36:31 < zyp> I wonder if the front brakes are also almost worn out, but I don't bother checking before I'm getting the tires off to switch to winter tires soon anyway
2025-10-28T12:37:04 < zyp> if so I'll probably plan to change them while I'm doing the switch back to summer tires next year
2025-10-28T12:37:21 < tomeaton17> thankfully we don't have snow here
2025-10-28T12:37:53 < zyp> qyx, as for timing belt, I've had one break on me while driving
2025-10-28T12:38:48 < qyx> O_o
2025-10-28T12:38:53 < qyx> was it fixable?
2025-10-28T12:39:13 < qyx> youtubers say yes
2025-10-28T12:39:34 < zyp> december probably 2009, was gonna drive to my parents for christmas, was probably 4-500km into the trip when the car suddenly lost all power
2025-10-28T12:39:44 < zyp> and it was like -25C
2025-10-28T12:39:50 -!- teknix_ [~unknown@user/hsv] has quit [Read error: Connection reset by peer]
2025-10-28T12:40:03 < tomeaton17> oh dear
2025-10-28T12:40:11 < tomeaton17> was it way past interval?
2025-10-28T12:41:07 < ventYl> https://digital-nomad.sk/img/IMG_0839.jpg
2025-10-28T12:41:21 < ventYl> I had to reballance fuel distributor for the car to pass emissions
2025-10-28T12:41:32 < ventYl> apparently I am one of very few people in this country who now how to do it
2025-10-28T12:45:34 < qyx> now you can start distilling something else
2025-10-28T12:46:01 < ventYl> too bad I don't drink
2025-10-28T12:46:06 < tomeaton17> is it golf
2025-10-28T12:46:16 < ventYl> nope
2025-10-28T12:48:28 < ventYl> its KE-Jetronic injection, it was in tons of cars during '70s, '80s and '90s
2025-10-28T12:48:52 -!- akaWolf [~akaWolf@akawolf.org] has quit [Ping timeout: 256 seconds]
2025-10-28T12:52:13 < englishman> that is a clean lookin car for its age
2025-10-28T12:53:36 < ventYl> thanks
2025-10-28T13:19:47 -!- kovalevsky_ [~kovalevsk@190.103.220.83] has joined ##stm32
2025-10-28T13:36:07 < mawk> who are you voting for Steffanx 
2025-10-28T13:39:30 < Steffanx> I have no idea mawk.
2025-10-28T13:39:37 < Steffanx> They all suck arse and balls
2025-10-28T13:40:05 < Steffanx> It's all a shit show.
2025-10-28T13:40:28 < qyx> you don't say
2025-10-28T13:40:32 < Steffanx> It's all about the people, not about what they stand for. 
2025-10-28T13:41:17 < qyx> we have some great people who I am able to trust but they don't have any real power
2025-10-28T13:41:22 < qyx> only populists have
2025-10-28T13:41:32 < Steffanx> All I hear is "you did this and this wrong" "you had the chance to do x and y, but didn't do anything" .. not a single realistic solution given
2025-10-28T13:42:23 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-28T13:42:29 < qyx> oh we have parties with their programme very concisely and precisely written, incl. solutions
2025-10-28T13:42:32 < qyx> but as I say..
2025-10-28T13:43:07 < qyx> we apparently have higher priority things to solve like adoptions by homosexuals, etc.
2025-10-28T13:43:28 < Steffanx> Yes they have them here too, but some solutions are impossible to implement because of other rules and regulations 
2025-10-28T13:44:02 < Steffanx> One of them is the housing problem. You could say: build more. But we can't because of some regulations and shit
2025-10-28T13:44:07 < qyx> none of our currently ruling parties has any, none.
2025-10-28T13:44:31 < Steffanx> Immigration issues. Can't solve them because EU regulations and agreements
2025-10-28T13:44:31 < qyx> and never had
2025-10-28T13:44:54 < qyx> immigration is a non-issue here, nobody wants to stay here
2025-10-28T13:45:07 < qyx> despite this we had massive police activities on the border
2025-10-28T13:45:20 < qyx> they weren't able to catch any immigrant
2025-10-28T13:45:40 < qyx> and despite this it is the main topic in every single election
2025-10-28T13:51:18 < tomeaton17> what about PVV?
2025-10-28T13:51:30 < tomeaton17> qyx: Hungarian?
2025-10-28T13:51:44 < qyx> tomeaton17: slovak
2025-10-28T13:52:16 < tomeaton17> qyx ah Visegrád enjoyer
2025-10-28T13:52:19 < zyp> our current ruling party were talking about the election about what benefits the opposing parties would take away if they got power, and now they proposed doing the exact same thing
2025-10-28T13:52:30 < zyp> before the election*
2025-10-28T13:52:44 < tomeaton17> looking like we are going to get Big Nige in next election over here
2025-10-28T14:26:59 -!- grindhold [~quassel@2a0a:4cc0:c0:70c9::1] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
2025-10-28T14:27:26 -!- grindhold [~quassel@v2202504104743335453.luckysrv.de] has joined ##stm32
2025-10-28T14:28:42 -!- grindhold [~quassel@v2202504104743335453.luckysrv.de] has quit [Client Quit]
2025-10-28T14:30:00 -!- grindhold [~quassel@v2202504104743335453.luckysrv.de] has joined ##stm32
2025-10-28T15:10:05 < karlp> reap what you sow I guess.
2025-10-28T15:10:20 < karlp> let the grift continue
2025-10-28T15:10:52 < BrainDamage> the grift will continue until the economy improves
2025-10-28T15:12:53 < qyx> hey iot pros, anyone ever tried SPI-connected lorawan "minipci-e" cards?
2025-10-28T15:14:35 < Steffanx> No.
2025-10-28T15:15:18 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2025-10-28T15:22:15 < qyx> https://files.seeedstudio.com/wiki/WM1302_module/WM1302_1.png
2025-10-28T15:22:24 < qyx> sounds like there is some proprietary SPI pinout
2025-10-28T15:30:02 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-28T15:41:16 < qyx> RAK5146 is also manageable
2025-10-28T15:43:12 < qyx> nah but I would probably add some series resistors just to be sure nothing happens if somebody puts a brick inside
2025-10-28T15:48:16 < qyx> retarded that AI friend
2025-10-28T15:48:29 < qyx> minipcie LEd ouputs are open-drain, aren't they
2025-10-28T16:08:58 < tomeaton17> I am not a nige enjoyer btw
2025-10-28T16:21:09 -!- teknix_ [~unknown@user/hsv] has joined ##stm32
2025-10-28T16:34:23 < Steffanx> Yes you are tomeaton17 
2025-10-28T16:37:54 -!- teknix_ [~unknown@user/hsv] has quit [Remote host closed the connection]
2025-10-28T16:42:29 < tomeaton17> Steffanx: no I am not, I cancelled my reform membership after the kicked out rupert lowe
2025-10-28T16:42:37 < tomeaton17> s/the/they
2025-10-28T17:04:24 < ventYl> i have checked how MPU really works in freertos and zephyr and it is even larger mess I expected it to be
2025-10-28T17:05:33 -!- teknix_ [~unknown@user/hsv] has joined ##stm32
2025-10-28T17:46:08 < qyx> does it really work,
2025-10-28T17:46:15 < qyx> I have not seen anyone actually using it
2025-10-28T17:52:23 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-28T17:53:07 < qyx> so, I have a bluetooth module connected over uart
2025-10-28T17:53:32 < qyx> ok.
2025-10-28T17:55:00 < qyx> I was about to ask if it supports software flow control but the datasheet already answered RTS/CTS is mandatory
2025-10-28T17:55:18 < qyx> and that's a bummer
2025-10-28T17:58:33 < qyx> To set a configuration bit to 0, attach a 51 kOhm resistor from the pin to ground.
2025-10-28T18:14:21 -!- teknix_ [~unknown@user/hsv] has quit [Remote host closed the connection]
2025-10-28T19:35:31 -!- jadew [~rcc@user/rcc] has joined ##stm32
2025-10-28T19:37:07 < jadew> Hi
2025-10-28T19:56:28 < qyx> lo
2025-10-28T19:56:45 < jadew> Hey, what's up?
2025-10-28T19:57:56 < jadew> I've been meaning to join the channel on multiple occasions, but it was either too late or too early in the day.
2025-10-28T19:58:55 < jadew> Came to let you all know that I finished the temperature logger.
2025-10-28T19:59:55 < jadew> How are you qyx?
2025-10-28T20:09:48 < englishman> welcome back
2025-10-28T20:10:02 < jadew> Thanks
2025-10-28T20:10:44 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-28T20:12:59 < qyx> welcome jadew, hows the logger?
2025-10-28T20:13:25 < jadew> Heh, I was kidding.
2025-10-28T20:14:07 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 264 seconds]
2025-10-28T20:14:20 < jadew> Didn't do any electronics the past two years. I miss it.
2025-10-28T20:26:07 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-28T20:56:39 -!- ThatDamnRanga [~ThatDamnR@UNASSIGNED-218-100-26-71.3cix.nzix.net] has joined ##stm32
2025-10-28T21:15:31 < Steffanx> Did you go mason jadew ? Your fellow.ro guy did that after founding #stm32
2025-10-28T21:17:26 < jadew> No, I tried to start a SaaS but it's impossible to promote anything these days.
2025-10-28T21:45:58 < qyx> were you consiiderig datalogging as a service?
2025-10-28T21:46:06 < qyx> (no joke)
2025-10-28T21:46:44 < qyx> monetizing dataloggers is pretty hard
2025-10-28T21:55:54 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-28T21:56:58 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-28T21:57:26 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-28T21:58:45 < Steffanx> Yeah who even tries to do that qyx?
2025-10-28T22:02:04 -!- kovalevsky_ [~kovalevsk@190.103.220.83] has quit [Ping timeout: 246 seconds]
2025-10-28T22:20:23 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-28T22:31:20 < ds2> you could sell data to third parties }:-)
2025-10-28T22:49:02 -!- teknix_ [~unknown@user/hsv] has joined ##stm32
2025-10-28T23:04:03 -!- teknix_ [~unknown@user/hsv] has quit [Read error: Connection reset by peer]
2025-10-28T23:11:43 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has joined ##stm32
2025-10-28T23:41:18 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-28T23:45:45 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
--- Day changed Wed Oct 29 2025
2025-10-29T00:24:43 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 256 seconds]
2025-10-29T00:37:31 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has quit [Ping timeout: 264 seconds]
2025-10-29T01:01:50 -!- nomorekaki [~nomorekak@188-67-167-20.bb.dnainternet.fi] has joined ##stm32
2025-10-29T01:33:44 < qyx> what is the night crew innovating
2025-10-29T01:36:35 < nomorekaki> passing time
2025-10-29T01:57:22 < qyx> unrouted: 376
2025-10-29T02:09:04 < zyp> qyx, pcie
2025-10-29T02:13:41 < qyx> zyp: pcie what?
2025-10-29T02:20:46 < zyp> pcie core
2025-10-29T02:22:27 < zyp> I got the ecp5 serdes going the other day, wrote a rudimentary link training state machine today: https://bin.jvnv.net/file/N0x4S.png
2025-10-29T02:23:08 < zyp> it gets to L0 at the red marker and starts receiving flow control initialization packets for the data link layer
2025-10-29T02:24:22 < qyx> do you want to do pcie host on ecp5?
2025-10-29T02:24:39 < qyx> oh receiving flow control
2025-10-29T02:24:41 < zyp> endpoint initially
2025-10-29T02:24:44 < qyx> so endpoint?
2025-10-29T02:24:51 < zyp> flow control goes both ways
2025-10-29T02:25:22 < qyx> is the DLL/MAC hard?
2025-10-29T02:26:44 < zyp> figuring out how to configure the serdes block was hard, it's poorly documented as lattice expects you to use a generated shim around it
2025-10-29T02:27:37 < zyp> for the LTSSM, I'm currently just handling the happy path, but good enough for now
2025-10-29T02:28:40 < zyp> DLL looks fairly easy, mostly about flow control handling, ACKs and retransmits
2025-10-29T02:29:50 < zyp> and then there's the transaction layer, which is essentially a bunch of read/write commands and their associated responses
2025-10-29T02:43:31 -!- NEYi_ [~NEYi@195.234.78.187] has joined ##stm32
2025-10-29T02:46:57 -!- NEYi [~NEYi@195.234.78.187] has quit [Ping timeout: 265 seconds]
2025-10-29T02:53:45 -!- nomorekaki [~nomorekak@188-67-167-20.bb.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2025-10-29T03:26:53 -!- NEYi_ [~NEYi@195.234.78.187] has quit [Read error: Connection reset by peer]
2025-10-29T03:27:18 -!- NEYi_ [~NEYi@195.234.78.187] has joined ##stm32
2025-10-29T03:32:13 -!- NEYi_ [~NEYi@195.234.78.187] has quit [Quit: Leaving]
2025-10-29T03:44:26 -!- nuxil [~nuxil@telia-5908f6-23.connect.netcom.no] has joined ##stm32
2025-10-29T04:03:50 < jadew> qyx, heh, actually pretty close! It did involve logging lots of data.
2025-10-29T04:41:08 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-29T04:42:19 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-29T04:42:43 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-29T04:55:36 -!- NEYi_ [~NEYi@195.234.78.187] has joined ##stm32
2025-10-29T04:56:04 -!- hexo_ [~hexo@user/hexo] has joined ##stm32
2025-10-29T04:58:44 -!- mercenar- [~mercenary@2001:19f0:7400:85c3:5400:ff:fe03:dad9] has joined ##stm32
2025-10-29T04:58:47 -!- zChris [~zChris@user/zchris] has joined ##stm32
2025-10-29T05:02:39 -!- Netsplit *.net <-> *.split quits: karlp, octorian, zChris_, NEYi, mercenary, hexo__, specing
2025-10-29T05:02:40 -!- specing_ [~specing@user/specing] has joined ##stm32
2025-10-29T05:02:56 -!- Netsplit over, joins: octorian, karlp
2025-10-29T05:03:03 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-29T05:05:04 -!- specing_ is now known as specing
2025-10-29T05:21:25 -!- nuxil [~nuxil@telia-5908f6-23.connect.netcom.no] has quit [Quit: Segmentation fault]
2025-10-29T05:35:30 -!- NEYi_ [~NEYi@195.234.78.187] has quit [Quit: Leaving]
2025-10-29T06:46:07 -!- haritz [~hrtz@user/haritz] has quit [Ping timeout: 255 seconds]
2025-10-29T06:47:05 -!- haritz [~hrtz@140.228.70.141] has joined ##stm32
2025-10-29T06:47:05 -!- haritz [~hrtz@user/haritz] has changed host
2025-10-29T07:12:24 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-29T07:22:49 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-29T07:44:55 -!- qyx [~qyx@84.245.120.252] has quit [Ping timeout: 240 seconds]
2025-10-29T07:46:53 -!- qyx [~qyx@84.245.121.108] has joined ##stm32
2025-10-29T08:09:00 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-29T08:27:37 -!- mercenar- is now known as mercenary
2025-10-29T08:27:40 -!- mercenary [~mercenary@user/mercenary] has changed host
2025-10-29T08:38:23 -!- sugarbee1 [~barbas@81.4.123.134] has quit [Ping timeout: 260 seconds]
2025-10-29T08:39:25 -!- sugarbeet [~barbas@81.4.123.134] has joined ##stm32
2025-10-29T08:55:20 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-29T09:49:24 < qyx> unrouted: 375
2025-10-29T09:49:28 < qyx> looks like I progressed
2025-10-29T10:22:49 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-29T12:26:27 -!- jerrycash2 [~jerrycash@user/jerrycash] has joined ##stm32
2025-10-29T12:29:22 -!- jerrycash [~jerrycash@user/jerrycash] has quit [Ping timeout: 246 seconds]
2025-10-29T12:38:57 -!- hexo_ [~hexo@user/hexo] has quit [Read error: Connection reset by peer]
2025-10-29T12:39:06 -!- duude__- [~duude__@user/duude/x-4676560] has joined ##stm32
2025-10-29T12:39:37 -!- duude__ [~duude__@user/duude/x-4676560] has quit [Ping timeout: 244 seconds]
2025-10-29T12:43:18 -!- duude__- is now known as duude__
2025-10-29T12:51:59 -!- jerrycash [~jerrycash@user/jerrycash] has joined ##stm32
2025-10-29T12:54:05 -!- jerrycash2 [~jerrycash@user/jerrycash] has quit [Ping timeout: 244 seconds]
2025-10-29T13:03:58 < qyx> https://bin.jvnv.net/file/UB808/Screenshot_2025-10-29_12-03-43.png
2025-10-29T13:04:12 < qyx> supporting those RAK/SeeedStudio LoRaWAN cards requires some creativity
2025-10-29T13:14:27 -!- jerrycash2 [~jerrycash@user/jerrycash] has joined ##stm32
2025-10-29T13:17:39 -!- jerrycash [~jerrycash@user/jerrycash] has quit [Ping timeout: 256 seconds]
2025-10-29T13:55:02 < zyp> violating what spec?
2025-10-29T14:00:08 < qyx> pci-sig's
2025-10-29T14:02:17 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-29T14:06:33 < qyx> it clearly says clkreq is an output signal but RAK's card requires chip select on this pin
2025-10-29T14:07:00 -!- kovalevsky_ [~kovalevsk@190.103.220.91] has joined ##stm32
2025-10-29T14:12:09 < zyp> not like it'd work in a regular pcie slot anyway
2025-10-29T14:16:31 < qyx> it would, it can work over usb too
2025-10-29T14:17:15 < zyp> so why don't you do that?
2025-10-29T14:17:29 < qyx> but you can bypass that usb-spi converter, which is kinda required because of strict timing
2025-10-29T14:17:44 < qyx> nearly all pro gateways use spi
2025-10-29T14:18:33 < qyx> not saying usb doesn't work at all, I have a couple of usb cards and they worked reasonably
2025-10-29T14:20:07 -!- teknix_ [~unknown@user/hsv] has joined ##stm32
2025-10-29T14:28:36 -!- nuxil [~nuxil@telia-5908f6-23.connect.netcom.no] has joined ##stm32
2025-10-29T14:30:50 -!- nuxil_ [~nuxil@telia-5908f6-23.connect.netcom.no] has joined ##stm32
2025-10-29T14:33:55 -!- nuxil [~nuxil@telia-5908f6-23.connect.netcom.no] has quit [Ping timeout: 264 seconds]
2025-10-29T14:34:44 -!- nuxil_ is now known as nuxil
2025-10-29T14:44:42 -!- teknix_ [~unknown@user/hsv] has quit [Read error: Connection reset by peer]
2025-10-29T14:55:47 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has joined ##stm32
2025-10-29T15:01:26 < qyx> oh imx-uart supports rts-gpios and cts-gpios
2025-10-29T15:01:53 < qyx> makes me a happy panda
2025-10-29T15:08:54 -!- teknix_ [~unknown@user/hsv] has joined ##stm32
2025-10-29T15:29:47 -!- PhantomWork [~PhantomWo@user/phantom] has joined ##stm32
2025-10-29T15:30:57 < PhantomWork> Hi there, so, an uart circular buffer or any other kind, that use DMA... I need 2 buffers right? One being actively used by the DMA and one for the new data? Or can the same be used?
2025-10-29T15:31:56 < qyx> there is dma circular mode
2025-10-29T15:33:57 < PhantomWork> so can be done with one common buffer, good. The examples I found yesterday used 2 buffers and switched between both. I ran out of space at 1k, so I bumped to 2k, and, well, double that is alot!
2025-10-29T15:36:35 -!- teknix_ [~unknown@user/hsv] has quit [Read error: Connection reset by peer]
2025-10-29T15:51:32 < karlp> well, I think I'm all out of ideas.  if I run the kinetis example, it works for all usbd evices.  if I run the kinetis examples with laks for the clock setup and interrupt vectors, it... sometimes works, but LS devices give me bus timeout errors.  
2025-10-29T15:51:49 < karlp> FS and "HS" (in fs mode) work ok.
2025-10-29T15:51:57 < karlp> I cannot think of what could be the difference.
2025-10-29T15:52:20 < karlp> I've gone though ~all the clock and power and flash and config regss I can think of, and they're all the same.
2025-10-29T15:52:50 < PhantomWork> karlp: I have no idea what you are talking about, but it reminds me of some issues I had due to the interrupts priority, you might want to take a look there... Easy to miss, and havok it can create
2025-10-29T15:53:37 < karlp> kinetis says that you can get bus timeout errors if you have "errors due to memory latency" 
2025-10-29T15:54:04 < PhantomWork> the symptoms I had was dataloss on uart3 and weird corruption on uart1
2025-10-29T15:54:27 < karlp> the beagle implies that with my code, the attach toggles between FS/LS modes, but I can't for the life of me figureout how that woudl happen.
2025-10-29T15:54:29 < PhantomWork> latency can be caused by irq priority
2025-10-29T15:54:34 < karlp> I get none of the CRC check error bits
2025-10-29T15:54:43 < karlp> PhantomWork:yeah, checked all that.
2025-10-29T15:54:54 < karlp> all the nvic and periph bits are the same 
2025-10-29T15:55:56 < karlp> Ieven went and turned on and configured some "unused" clocks that the factory demo does "by default" just inc ase they're actually used somewhere, but unsuprisingly, that didn' tmake any difference.
2025-10-29T16:00:03 < PhantomWork> next would be the wiring quality...
2025-10-29T16:01:10 < karlp> it's the same board, same connections.
2025-10-29T16:01:57 < karlp> it's just "file good.elf; load; run; <check> file bad.elf; load; run <check>"
2025-10-29T16:05:38 < zyp> are compiler flags the same? could the code have UB that behaves differently depending on flags?
2025-10-29T16:06:34 < karlp> that... could be?
2025-10-29T16:07:00 < zyp> I'm just thinking that if you don't find any differences in the code that's different, maybe the differences are hiding in the code that's common instead
2025-10-29T16:07:26 < qyx> did you compare dumps of the peripherals?
2025-10-29T16:07:44 < qyx> or how did you compare registers?
2025-10-29T16:07:47 < karlp> as much as can be, yeah, the USB periph not so much, but that's in the shared core.
2025-10-29T16:08:04 < karlp> but eyah, lots of gdb memory poking all the registers for the clock configs and module enables and power shtis
2025-10-29T16:08:06 < zyp> «dumps of peripherals» doesn't work beyond config bits that's only initialized and left at some value
2025-10-29T16:09:21 < karlp> zyp: UB in the shared code souldn't make the beagle see different things on the bus though?
2025-10-29T16:09:27 < karlp> or I guess, maybe...
2025-10-29T16:09:44 < zyp> if it makes the code take differen branches…
2025-10-29T16:11:57 -!- teknix_ [~unknown@user/hsv] has joined ##stm32
2025-10-29T16:35:30 -!- PaulFertser [~paul@paulfertser.info] has quit [Ping timeout: 252 seconds]
2025-10-29T16:45:38 -!- nuxil [~nuxil@telia-5908f6-23.connect.netcom.no] has quit [Ping timeout: 256 seconds]
2025-10-29T16:48:27 < karlp> well, I chopped out all the freertos and used the "bare metal" demo and it's the same, so that's a bunch less code at least...
2025-10-29T16:48:36 < karlp> man. I need a new approach to this...
2025-10-29T16:49:16 < ventYl> the same := it works ?
2025-10-29T16:49:35 < karlp> wel,l the upstream bare metal demo works just the same as their freertos demo
2025-10-29T16:49:53 < karlp> my board setup works the same (doesn't enumerate LS) with the baremetal or freertos cdoe.
2025-10-29T16:50:34 < qyx> the only difference is vector table, startup code, linker script?
2025-10-29T16:50:38 < qyx> and clock init?
2025-10-29T16:51:14 < karlp> clcokinit is _different_ but ends up with the same bits in all teh clock control regs
2025-10-29T16:51:25 < karlp> and if it was a clock issue, it shouldn't enumerate FS devices.
2025-10-29T16:51:26 < qyx> btw zyp I hate your irc client replacing ... with …, just to be more offtopic
2025-10-29T16:51:36 < karlp> but yeah, startup/linker/vectors are different.
2025-10-29T16:51:53 < qyx> can you compare elf headers? offsets, alignments, etc?
2025-10-29T16:52:01 < zyp> qyx, huh, it's not replacing anything, I'm typing … deliberately
2025-10-29T16:52:09 < qyx> how dare you
2025-10-29T16:52:13 < zyp> … is altgr+. on my keyboard
2025-10-29T16:52:24 < qyx> mine is >
2025-10-29T16:53:01 < karlp> all other fs/hs devices plug in and even if they don't enumerate because they're nto supported devices, they at least read descriptors and reject, they don't just fail to communicate.
2025-10-29T16:53:24 < qyx> does your startup run constructors even for C code?
2025-10-29T16:53:45 < zyp> .init_array is .init_array
2025-10-29T16:53:53 < karlp> you think I would have constructors that only matter for LS devices? I mean, I've not checked... but... that seems odd.
2025-10-29T16:55:35 < qyx> did you step through startup until reaching main?
2025-10-29T16:55:50 < karlp> no?
2025-10-29T16:55:55 < karlp> what would I be looking for?
2025-10-29T16:55:57 < qyx> I would also compare memory content after entering main
2025-10-29T16:56:06 < karlp> what memory content?
2025-10-29T16:56:15 < qyx> the whole ram content
2025-10-29T16:56:50 < qyx> zeroing failures, __attribute__((constructor)) failures (however they work), 
2025-10-29T16:56:59 < qyx> data init failures
2025-10-29T16:57:30 < qyx> I had hit different fuckups in that piece of code over the years, if you ruled everything else out, there are still places..
2025-10-29T16:59:22 < qyx> also heh, vector table alignment
2025-10-29T16:59:34 < zyp> hard to do meaningful direct comparisons when there's gonna be differences due to the different frameworks
2025-10-29T17:00:43 < zyp> just stuff like object link order in the build system would likely reorder the memory, and that's before even considering differences in globals outside the common code
2025-10-29T17:01:10 < qyx> the first thing coming to my mind in such scenario is failing to initialize globals
2025-10-29T17:01:22 < qyx> was there too
2025-10-29T17:01:46 < karlp> vector table alignment shouldn't be an issue if I get the irqs, (which i do) as well as fs/hs devices being ok.
2025-10-29T17:01:49 < zyp> laks startup calls .init_array, so that's unlikely to be the issue
2025-10-29T17:19:06 -!- nuxil [~nuxil@telia-5908f6-23.connect.netcom.no] has joined ##stm32
2025-10-29T17:28:11 -!- PhantomWork [~PhantomWo@user/phantom] has quit [Quit: Leaving]
2025-10-29T18:11:59 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-29T18:19:08 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 256 seconds]
2025-10-29T18:21:14 -!- PaulFertser [paul@paulfertser.info] has joined ##stm32
2025-10-29T18:34:31 -!- teknix_ [~unknown@user/hsv] has quit [Remote host closed the connection]
2025-10-29T18:38:39 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-29T18:39:46 -!- NEYi [~NEYi@195.234.78.187] has quit [Remote host closed the connection]
2025-10-29T18:40:17 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-29T19:50:49 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-29T20:06:35 -!- NEYi [~NEYi@195.234.78.187] has quit [Quit: Leaving]
2025-10-29T21:06:30 < machinehum> Could not get pandas cross compiling, just stole armhf binaries from debian stable and put it in rootfs overlay
2025-10-29T21:06:34 < machinehum> Okay
2025-10-29T21:06:37 < machinehum> party time
2025-10-29T21:09:37 < Steffanx> I'm proud of you machinehum 
2025-10-29T21:09:44 < machinehum> ty Steffanx 
2025-10-29T21:10:07 < machinehum> Should I post a merge request to the mailing list with the binaries?
2025-10-29T21:10:37 < Steffanx> Will that make your or them happy?
2025-10-29T21:11:11 < machinehum> buildroot people will likely not find it funny
2025-10-29T21:14:34 < Steffanx> I would 
2025-10-29T21:17:56 < machinehum> <3
2025-10-29T21:34:37 -!- nuxil [~nuxil@telia-5908f6-23.connect.netcom.no] has quit [Ping timeout: 256 seconds]
2025-10-29T21:41:26 -!- nuxil [~nuxil@telia-5908f6-23.connect.netcom.no] has joined ##stm32
2025-10-29T22:10:31 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-29T22:13:31 -!- kovalevsky_ [~kovalevsk@190.103.220.91] has quit [Ping timeout: 264 seconds]
2025-10-29T22:31:21 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-29T22:57:57 -!- NEYi [~NEYi@195.234.78.187] has joined ##stm32
2025-10-29T23:16:52 -!- kovalevsky_ [~kovalevsk@181.168.239.174] has joined ##stm32
2025-10-29T23:17:37 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-29T23:18:55 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 264 seconds]
2025-10-29T23:27:23 -!- kovalevsky_ [~kovalevsk@181.168.239.174] has quit [Ping timeout: 256 seconds]
2025-10-29T23:44:07 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Ping timeout: 264 seconds]
--- Day changed Thu Oct 30 2025
2025-10-30T00:05:30 -!- nomorekaki [~nomorekak@188-67-167-20.bb.dnainternet.fi] has joined ##stm32
2025-10-30T00:16:15 -!- remcycles [~remcycles@c-24-19-134-216.hsd1.wa.comcast.net] has joined ##stm32
2025-10-30T00:49:37 -!- NEYi [~NEYi@195.234.78.187] has quit [Read error: Connection reset by peer]
2025-10-30T00:57:19 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has quit [Ping timeout: 264 seconds]
2025-10-30T01:34:46 -!- kovalevsky_ [~kovalevsk@181.168.239.174] has joined ##stm32
2025-10-30T01:47:42 -!- nomorekaki [~nomorekak@188-67-167-20.bb.dnainternet.fi] has quit [Quit: Client closed]
2025-10-30T02:36:38 -!- Netsplit *.net <-> *.split quits: karlp, octorian, PaulFertser
2025-10-30T02:37:05 -!- remcycles [~remcycles@c-24-19-134-216.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer]
2025-10-30T02:37:24 -!- remcycles [~remcycles@c-24-19-134-216.hsd1.wa.comcast.net] has joined ##stm32
2025-10-30T02:42:13 -!- PaulFertser [paul@paulfertser.info] has joined ##stm32
2025-10-30T02:42:13 -!- octorian [octo@2600:3c00::f03c:91ff:fe93:a61c] has joined ##stm32
2025-10-30T02:42:13 -!- karlp [karlp@palmtreev6.beeroclock.net] has joined ##stm32
2025-10-30T02:50:31 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-30T03:02:26 -!- System_Error [~SystemErr@user/systemerror] has quit [Ping timeout: 272 seconds]
2025-10-30T03:06:21 -!- kovalevsky_ [~kovalevsk@181.168.239.174] has quit [Ping timeout: 252 seconds]
2025-10-30T03:07:12 -!- flatmush [~benbrewer@149.57.127.128] has quit [Ping timeout: 244 seconds]
2025-10-30T03:18:36 -!- flatmush [~benbrewer@149.57.122.49] has joined ##stm32
2025-10-30T03:19:10 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-30T04:14:00 -!- flatmush [~benbrewer@149.57.122.49] has quit [Ping timeout: 252 seconds]
2025-10-30T04:57:29 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-30T05:46:09 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-30T07:04:29 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-30T07:07:08 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-30T08:17:12 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-30T08:28:07 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-30T08:48:31 -!- catphish [~quassel@user/catphish] has quit [Ping timeout: 255 seconds]
2025-10-30T08:54:34 -!- catphish [~quassel@user/catphish] has joined ##stm32
2025-10-30T09:03:41 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Ping timeout: 256 seconds]
2025-10-30T09:24:58 -!- System_Error [~SystemErr@user/systemerror] has quit [Ping timeout: 272 seconds]
2025-10-30T09:41:57 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-30T10:02:14 < ventYl> Today grain of wisdom from Linkedin: It is obvious why one wouldn't use RTOS: Just toss more chips in there and split the task in between them. No need to complex synchronization.
2025-10-30T10:02:59 < jpa-> entirely correct
2025-10-30T10:03:14 < jpa-> just solve the complex communication first ;)
2025-10-30T10:08:57 < machinehum> ventYl: You can also solve this problem by moving to a MCU with more cores
2025-10-30T10:09:24 < machinehum> If you would like to blink two LEDs at the same time at different frequencies, etc
2025-10-30T10:09:47 < ventYl> yeah, as if multi-core synchronization of memory-bound systems was anything trivial
2025-10-30T10:09:53 < jadew> Pretty sure they have MCUs with multiple timer peripherals :P
2025-10-30T10:12:47 < machinehum> jadew: That's far too complex
2025-10-30T10:12:57 < machinehum> Better of just using 2x delay loops
2025-10-30T10:14:47 < jpa-> < mrec_> timers are a source of evil so many possible issues
2025-10-30T10:15:53 < ventYl> machinehum: you can run one of them on a tiny MCU on your USB controller
2025-10-30T10:17:34 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2025-10-30T10:26:54 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-30T11:11:44 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 244 seconds]
2025-10-30T11:29:08 < tomeaton17> looks like Gert is out
2025-10-30T11:58:41 < Steffanx> Was he ever in?
2025-10-30T12:01:27 < karlp> hrm, will I be able to use one port of an ethercat device as "just" a normal ethernet port?
2025-10-30T12:06:46 < zyp> karlp, in what sense?
2025-10-30T12:07:40 < karlp> as in, device to be used in non-ethercat context, can I just use one of the ports as ethernet.
2025-10-30T12:07:47 < karlp> pinning seems to suggest... no.
2025-10-30T12:09:32 < zyp> used in what sense? is this a chip with ethercat slave ports that you'll be writing firmware for, or an off the shelf ethercat slave device with preexisting firmware?
2025-10-30T12:09:51 < karlp> chip has ethercat slave ports, yeah, xmc4800.
2025-10-30T12:10:21 < karlp> we ahve another device, that is ~same, but with one ethernet port, provides "normal" tcp and http services
2025-10-30T12:10:33 < karlp> I'm considering whether we really need both of them.
2025-10-30T12:11:04 < karlp> them xmc dev board has three damn ports on it, one "extra" ethernet port for "other stuff"
2025-10-30T12:11:13 < karlp> but I find the idea of a third port abhorrent.
2025-10-30T12:11:39 < zyp> that really depends on how the ethercat MAC is designed
2025-10-30T12:12:26 < zyp> in theory an ethercat MAC can absolutely have a plain ethernet mode, but I have no idea whether this specific one does
2025-10-30T12:13:03 < zyp> e.g. the netx parts that can do ethercat are generic enough that they can also do other stuff
2025-10-30T12:24:20 < karlp> hrm, as best I can tell, the xmc4800 just has beckhoff et1100 IP core blobbed down, so guessing no... they wouldn't want to do that sort of thing.
2025-10-30T12:25:35 < zyp> yeah, I glanced through the RM, it's just ethercat
2025-10-30T12:26:14 < zyp> in theory you could just mux one PHY between the ethercat MAC and the regular MAC though
2025-10-30T12:26:46 < zyp> can probably just wire rx in parallel and mux tx
2025-10-30T12:27:00 < karlp> "Note: For debugging purposes it is
2025-10-30T12:27:02 < karlp> possible
2025-10-30T12:27:05 < karlp> to
2025-10-30T12:27:06 < karlp> disable
2025-10-30T12:27:09 < karlp> the
2025-10-30T12:27:10 < karlp> checksum validation with a
2025-10-30T12:27:12 < karlp> checksum value of 0x88A4.
2025-10-30T12:27:14 < karlp> Never use this for production!"
2025-10-30T12:27:16 < karlp> ffs it was text, why did it do that to it...
2025-10-30T12:27:37 < karlp> zyp: eh, hardware is "done" I'm not sure I can swing that change, but nice to have behind the ear...
2025-10-30T12:28:56 < zyp> yeah, just saying it'd be an alternative to adding a third port in hardware
2025-10-30T12:29:08 < karlp> yeah, it would be nice to try out.
2025-10-30T12:29:21 < karlp> I'm not sure how much leverage I have to actually think about things properly though.
2025-10-30T12:29:37 < karlp> a lto of this is reactionary designs of "this part is obsolete" without thinking abotu the big picture.
2025-10-30T12:31:25 -!- jerrycash3 [~jerrycash@user/jerrycash] has joined ##stm32
2025-10-30T12:34:30 -!- jerrycash2 [~jerrycash@user/jerrycash] has quit [Ping timeout: 252 seconds]
2025-10-30T13:04:44 < ventYl> that nexperia case is lol
2025-10-30T13:04:48 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has joined ##stm32
2025-10-30T13:05:04 -!- Linux_Kerio [~Linux_Ker@chello085216213137.chello.sk] has quit [Read error: Connection reset by peer]
2025-10-30T13:18:39 -!- kovalevsky_ [~kovalevsk@190.103.220.90] has joined ##stm32
2025-10-30T13:48:22 -!- PhantomWork [~PhantomWo@user/phantom] has joined ##stm32
2025-10-30T13:50:59 < PhantomWork> Hi there, am I crazy or does HAL does not provide a mean to tell it where to start the uart DMa transfer in the buffer? So it always start at the start of the pointer, and end pointer+nbdata later? So you can't directly use it for your circular tx buffer, you need to do it in 2 shot: from the head to end of the array, then from the start to the tail? You can't do it in 1 call?
2025-10-30T13:52:59 < zyp> correct
2025-10-30T13:53:25 < zyp> it's not a HAL issue, the hardware simply doesn't support doing a wrapping fixed length DMA job
2025-10-30T13:54:29 < zyp> circular DMA is endless; it'll keep looping and there's no way to sync it to your write pointer, so it's not suitable for UART TX
2025-10-30T13:55:56 < zyp> use regular DMA jobs for TX, submitting it as two jobs when you have to wrap
2025-10-30T13:56:06 < PhantomWork> ok thanks
2025-10-30T13:56:24 < PhantomWork> so I was not crazy, atleast for this.   good
2025-10-30T13:56:42 < zyp> for RX you can use circular mode, since overruns are easier to guard against than underruns
2025-10-30T13:57:19 < zyp> assuming that you're okay with RX overwriting the oldest data on an overrun
2025-10-30T13:57:27 < PhantomWork> trying to see if I can optimise my code, I transmit ALOT of uart data, 1k buffer wasn't enough at 1Mbps, I had to bump to 2k, or change the way the code work
2025-10-30T13:58:23 < zyp> what are you transmitting?
2025-10-30T13:58:25 < PhantomWork> for rx, I hasn't looked into it yet, but yeah, circular would be fine
2025-10-30T13:58:34 < PhantomWork> a crapton of debug data
2025-10-30T13:59:03 < PhantomWork> I can't io block
2025-10-30T13:59:30 < PhantomWork> and 1 page refresh is more than 1k
2025-10-30T13:59:39 < zyp> what do you do if you can't keep up?
2025-10-30T14:00:36 < PhantomWork> right now, it drop data
2025-10-30T14:01:23 < PhantomWork> which was fun when I miscalculated the refresh rate by 1 decimal place, and was wondering why only 1/4 was showing up :D
2025-10-30T14:02:09 < zyp> if you can't block, you need enough buffering to keep up with the largest burst of data you can have
2025-10-30T14:02:31 < zyp> but otherwise stuff should be pretty easy
2025-10-30T14:03:40 < PhantomWork> yeah  hence the 2k buffer
2025-10-30T14:04:05 < zyp> when you put a chunk into the buffer, check if DMA is busy, if not, start a DMA job on the current content
2025-10-30T14:04:18 < PhantomWork> man it is so tempting to simplify the code by using 2 linear buffers instead, but 4k instead of 2k ram is so wastefull
2025-10-30T14:04:37 < zyp> enable interrupt on DMA job complete, in handler, check if there's more data; if so, restart DMA
2025-10-30T14:04:49 < PhantomWork> yup
2025-10-30T14:04:49 < zyp> that's it
2025-10-30T14:04:59 < PhantomWork> brb
2025-10-30T14:05:04 < zyp> linear buffers doesn't simplify anything
2025-10-30T14:05:39 < zyp> when you're doing a circular buffer and have to wrap around, just schedule a job until the end of the buffer
2025-10-30T14:05:57 < zyp> once that job completes, the check for more data will restart from the beginning of the buffer
2025-10-30T14:06:24 < zyp> it'll work the same whether the additional data after the wrap were already there or got written while the first job were running
2025-10-30T14:18:19 < jpa-> also, if everything is idle (buffer is empty), you can reset your pointers to the start of the buffer before doing the new write.. to avoid unnecessary wrap-over
2025-10-30T14:18:51 < zyp> ah, yeah, that too
2025-10-30T14:19:32 < jpa-> you can also consider doing double-buffering instead: have 1k buffer for "currently transmitting" that is used by DMA, and separate 1k buffer for "currently being written by application"
2025-10-30T14:19:47 < jpa-> and then just block the application if the 1k fills up until DMA is done with the other buffer
2025-10-30T14:19:55 < zyp> actually, if everything is idle, you'd be better off writing the first chunk to the end of the buffer since you'll have an interrupt firing after that anyway
2025-10-30T14:20:32 < zyp> jpa-, double buffering is less memory efficient than a ringbuffer
2025-10-30T14:20:44 < jpa-> it is, but it can be simpler in software
2025-10-30T14:21:10 < jpa-> especially if you do zero-copy filling of the buffer, it's easier to have application generate the data without worrying about wrap-over
2025-10-30T14:27:09 < zyp> in that case, aren't you just generating into anything with a Write trait, and having the trait implementation handle both wraparound and DMA interaction? :p
2025-10-30T14:27:37 < qyx> we call it interfaces
2025-10-30T14:28:18 < zyp> I think interfaces are out of fashion, traits are all the rage now
2025-10-30T14:28:53 < qyx> will it boost my project-fu if I rename them to traits?
2025-10-30T14:31:02 < jpa-> do read & write traits support zero-copy, if you want to e.g. read data from SDIO peripheral and write it to UART or something, do you need to copy it to a separate RAM buffer in between?
2025-10-30T14:31:19 < jpa-> (assuming both SDIO and UART use DMA and have a buffer you can access)
2025-10-30T14:31:22 < PhantomWork> zyp: it would simplify, just swap buffers
2025-10-30T14:31:42 < PhantomWork> but, very little
2025-10-30T14:34:20 < zyp> jpa-, embedded_io::Read and embedded_io::Write (and their async counterparts) both take a buffer slice argument, and then it's implementation specific whether they DMA against the buffer directly or copy to/from an intermediate buffer
2025-10-30T14:35:18 < jpa-> but can you get a buffer slice from Write that you can write to, or a slice from Read that you can read from?
2025-10-30T14:35:26 < zyp> for UART RX, I'd expect an intermediate ringbuffer to be common, since lack of flow control means you always need to be ready to receive, but anything with flow control can easily be zero copy
2025-10-30T14:35:46 < zyp> no, caller owns the buffers
2025-10-30T14:37:08 < jpa-> so not really zero-copy as far as processing goes :)
2025-10-30T14:38:42 < zyp> it'd be possible to design a trait so that it returns a buffer reference, using RAII to release it afterwards
2025-10-30T14:39:41 < zyp> but I don't see why caller-owner buffers wouldn't be zerocopy
2025-10-30T14:40:14  * qyx calls zyp's trait with a CCM allocated buffer
2025-10-30T14:40:19 < zyp> first you pass a buffer to a read(), and then once filled you pass the same buffer to a write()
2025-10-30T14:40:36 < jpa-> true, it would be zero copy if the hardware driver directly reads to the provided buffer
2025-10-30T14:40:49 < zyp> yes
2025-10-30T14:41:03 < jpa-> if the hardware driver has its own DMA buffer running in the background, it would need a copy
2025-10-30T14:41:45 < jpa-> but i guess at the point where you need micromanaging like that, you wouldn't use the generic traits anyway
2025-10-30T14:41:50 < zyp> and if write() is async, it can set up a DMA job directly with the passed buffer, wait until it's finished, and then return
2025-10-30T14:42:12 < zyp> I mean, this is how stuff is usually done
2025-10-30T14:44:21 < zyp> https://github.com/embassy-rs/embassy/blob/eb096476cc34ff9775801b9b4d2d6f3b1861583e/embassy-stm32/src/usart/mod.rs#L492-L507
2025-10-30T15:02:26 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-30T15:09:35 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-30T15:13:02 -!- jadew [~rcc@user/rcc] has quit [Quit: WeeChat 4.1.1]
2025-10-30T16:05:00 -!- nuxil [~nuxil@telia-5908f6-23.connect.netcom.no] has quit [Ping timeout: 256 seconds]
2025-10-30T16:22:52 -!- nuxil [~nuxil@telia-5908f6-23.connect.netcom.no] has joined ##stm32
2025-10-30T16:30:57 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2025-10-30T16:51:19 -!- ice [~ice@loud.house] has joined ##stm32
2025-10-30T17:10:11 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-30T17:57:37 -!- teknix_ [~unknown@user/hsv] has joined ##stm32
2025-10-30T18:28:39 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 256 seconds]
2025-10-30T18:47:44 -!- c10ud [~c10ud@user/c10ud] has quit [Read error: Connection reset by peer]
2025-10-30T18:51:30 -!- c10ud [~c10ud@user/c10ud] has joined ##stm32
2025-10-30T19:59:14 < mawk> I got our board to 2-3mA in deep sleep 
2025-10-30T20:01:24 < mawk> the minimum is something like 1.3mA with the cpu completely off
2025-10-30T20:01:26 < mawk> I could do lower with standby mode but it sounds super annoying to restart
2025-10-30T20:02:09 < Steffanx> 2-3 is a lot.
2025-10-30T20:02:15 < mawk> it's a F7
2025-10-30T20:02:29 < mawk> it's not meant to be low power
2025-10-30T20:02:40 < mawk> and it's the total of the board not just the cpu
2025-10-30T20:02:46 < mawk> there's a lot going on
2025-10-30T20:03:00 < mawk> normally it's like 100-200mA when doing nothing 
2025-10-30T20:03:01 < Steffanx> Still a lot :P
2025-10-30T20:03:38 < mawk> I can't turn off the 3.3V rail, for obvious reasons
2025-10-30T20:03:49 < mawk> there's a bunch of random stuff drawing power on the board
2025-10-30T20:04:09 < mawk> the goal is to last 48h, not 10 years
2025-10-30T20:04:27 < Steffanx> Nah
2025-10-30T20:04:37 < mawk> yes
2025-10-30T20:05:13 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-30T20:08:53 < mawk> all unused pins are in analog mode, all peripheral clocks are gated, adc is off, the low power regulator is in underdrive mode, the flash is off, only low power timer, iwdg, rtc are running 
2025-10-30T20:09:26 < mawk> nothing more I can do
2025-10-30T20:15:22 -!- splud [~noneya.bi@user/splud] has quit [Ping timeout: 260 seconds]
2025-10-30T20:15:50 -!- splud [~noneya.bi@user/splud] has joined ##stm32
2025-10-30T20:16:18 < mawk> typical minimum is 1.1mA in the datasheet
2025-10-30T20:16:22 < mawk> I'm very close to it
2025-10-30T20:16:27 < mawk> you lied Steffanx 
2025-10-30T20:16:47 < Steffanx> Uh?
2025-10-30T20:16:57 < mawk> you said it's still a lot
2025-10-30T20:17:04 < mawk> while it's close to the minimum I can do
2025-10-30T20:17:16 < Steffanx> It's still a lot :P
2025-10-30T20:17:54 < mawk> wrong
2025-10-30T20:17:56 < mawk> it's almost 0
2025-10-30T20:18:02 < mawk> let's round it to 0
2025-10-30T20:18:07 < mawk> infinite runtime 
2025-10-30T20:19:32 < Steffanx> Qyx will confirm it's a lot
2025-10-30T20:21:00 < qyx> mawk: 2 to 3 mA is tokerable for wifi
2025-10-30T20:21:03 < qyx> I like your effort
2025-10-30T20:21:16 < mawk> it's not wifi it's the board at work
2025-10-30T20:21:22 < mawk> it's got LTE-M
2025-10-30T20:21:28 < mawk> but comms are off
2025-10-30T20:21:38 < mawk> with the nrf wifi board I could probably get a lot lower
2025-10-30T20:22:01 < qyx> oh
2025-10-30T20:22:38 < mawk> the wifi chip on my home project allegedly does 380μA in low power mode
2025-10-30T20:59:51 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-30T21:03:04 < PhantomWork> Can someone look at this and help me figure out why I appear to lose the first character after an idle time?  https://bpa.st/6PXQ    and I know, it's probably ugly, and yes, it is on purpose that I do a transfert of 1...
2025-10-30T21:06:46 < mawk> idle how
2025-10-30T21:07:02 < mawk> is the UART off in idle?
2025-10-30T21:07:41 < mawk> why the critical sections 
2025-10-30T21:07:46 < PhantomWork> the code send the data in burst, basically some printf. So let's say I have hal_delay(very long); printf     then I lose the first byte
2025-10-30T21:08:24 < PhantomWork> so every start of the burst I lose 1 byte
2025-10-30T21:08:56 < PhantomWork> and the criticals are to make sure that the interrupts don't mess things up, I may have went overboard however
2025-10-30T21:09:58 < PhantomWork> and no, the uart does not turn off at idle
2025-10-30T21:11:00 < mawk> if interrupts don't use printf you don't need the critical section 
2025-10-30T21:12:58 < mawk> your tx complete interrupt relies, well, on interrupts
2025-10-30T21:13:31 < PhantomWork> my interrupts does use printf
2025-10-30T21:13:47 < PhantomWork> all of my code is interrupt based
2025-10-30T21:14:09 < mawk> if they're all the same priority it's fine without the critical sections
2025-10-30T21:14:24 < mawk> you can worry about making writing to the buffer threadsafe later 
2025-10-30T21:16:33 < mawk> at least add __WFI() at the end of each loop in uartDebugWaitTxDone()
2025-10-30T21:17:22 < mawk> also provide the overrun callbacks and check the return code of the various HAL functions
2025-10-30T21:18:13 < PhantomWork> what would the __WFI() do beside being good practice?
2025-10-30T21:19:34 < mawk> it will probably not help here, but it waits outside the critical section for an interrupt to occur
2025-10-30T21:20:58 < mawk> but my money is on all this head tail business 
2025-10-30T21:22:16 < PhantomWork> the code was working fine using standard interrupts
2025-10-30T21:22:49 < PhantomWork> so I don't know if I broke something while doing the conversion or if it worked by pure luck, or was bugfree...
2025-10-30T21:24:50 < PhantomWork> chatgpt and gemini, while both ain't great, hate my code. both insist that transmitting 1 bytes at a time is a disaster that need fixing ASAP like if it was a national security risk   :D lol
2025-10-30T21:29:21 -!- kovalevsky_ [~kovalevsk@190.103.220.90] has quit [Remote host closed the connection]
2025-10-30T21:29:25 < mawk> well you don't use DMA if it's for 1 byte yeah
2025-10-30T21:29:39 -!- kovalevsky_ [~kovalevsk@190.103.220.89] has joined ##stm32
2025-10-30T21:30:05 < mawk> if you have that many critical sections in the rest of the code that might be a problem
2025-10-30T21:31:18 < mawk> and you shouldn't use printf in high priority interrupts to begin with
2025-10-30T21:31:29 < mawk> use a RTOS if you want tasks 
2025-10-30T21:31:43 < mawk> interrupts are meant to finish quickly 
2025-10-30T21:32:19 < mawk> http://www.efton.sk/STM32/gotcha/g26.html
2025-10-30T21:33:12 < mawk> what do your DMA settings look like, is it byte per byte with no FIFO?
2025-10-30T21:49:20 -!- kovalevsky_ [~kovalevsk@190.103.220.89] has quit [Ping timeout: 240 seconds]
2025-10-30T21:50:21 < PhantomWork> not sure what you mean by fifo
2025-10-30T21:53:03 < mawk> it's a setting of the dma peripheral 
2025-10-30T21:53:22 < mawk> if you used cubemx/cubeide that stuff should be in main.c or stm32xxx_msp.c
2025-10-30T21:58:49 < ds2> where is that 1-3mA going? 
2025-10-30T22:04:23 < PhantomWork> cubeide, and I don't see a fifo there, circular and normal is maybe what you are refearing to? if so normal
2025-10-30T22:28:16 < PhantomWork> I wonder if the DMA could be busy when I start it... hmm...
2025-10-30T22:35:20 < mawk> that's not how dma works
2025-10-30T22:35:35 < mawk> unless you mean busy with another UART transfer 
2025-10-30T22:35:45 < mawk> but the channel is specific to UART 
2025-10-30T22:36:08 < mawk> idk ds2 there's a ton of things on the board
2025-10-30T22:37:03 < mawk> protection circuit, charging circuit, motor controllers, step up stuff, step down stuff
2025-10-30T22:38:44 < PhantomWork> mawk: well, the led say: return HAL_OK,  so not an issue there...      
2025-10-30T22:39:02 < mawk> on all the calls?
2025-10-30T22:39:08 < PhantomWork> the one I suspected
2025-10-30T22:39:18 < PhantomWork> so, time for the next one, the callback
2025-10-30T22:39:19 < mawk> try without the critical sections
2025-10-30T22:39:27 < mawk> and add the error callback for dma
2025-10-30T22:42:21 < PhantomWork> 	ansiCursorXY(1,1);    void ansiCursorXY(uint8_t x, uint8_t y) {
2025-10-30T22:42:21 < PhantomWork> 	printf("\033[%i;%iH", y, x);
2025-10-30T22:42:21 < PhantomWork> }          and the output is   "1;1H"     so it is 2 bytes that is missing??
2025-10-30T22:42:37 < PhantomWork> ... stupid windows build of hexchat... didn't show the newlines 
2025-10-30T22:43:24 < qyx> how do yo u watch the output
2025-10-30T22:43:33 < qyx> of course the escape \x1b escapes (at least) the next char
2025-10-30T22:43:41 < qyx> and is not a visible character
2025-10-30T22:43:45 < PhantomWork> simplyserial.exe    so the \e might be hidden
2025-10-30T22:44:40 < qyx> also it is pretty daring to using uint8_T for x, y parameters
2025-10-30T22:44:49 < qyx> *to use
2025-10-30T22:45:09 < qyx> it doesn't have any sense and it will bring you issues
2025-10-30T22:45:42 < qyx> my terminal is already 240 chars wide and I only have 1920x1080 displays
2025-10-30T22:46:08 < PhantomWork> I don't plan to do more than 80
2025-10-30T22:46:20 < qyx> that's sad
2025-10-30T22:46:36 < PhantomWork> but yes it could be an issue in some case, easy fix if it is when it will happen
2025-10-30T22:47:54 < qyx> it is a pretty bad habit, there is no sense in using uint8_t in 99% of cases
2025-10-30T22:47:58 < qyx> it is not even an optimization
2025-10-30T22:48:47 < qyx> and using uint8_t may/will make things slower, especially in combination with eg. packed data
2025-10-30T22:49:26 < PhantomWork> what the...  Ok, I removed the ansi code... and I get expected output    o.O
2025-10-30T22:54:23 < PhantomWork> that will be a tomorrow issue, thanks for the help
2025-10-30T22:54:56 < mawk> you should really use bigger buffers when transmitting DMA
2025-10-30T22:56:37 < PhantomWork> oh I will, and I added it in the code already
2025-10-30T22:56:48 < PhantomWork> the 1 byte was to debug
2025-10-30T22:57:24 < PhantomWork> old code was interrupt based, so I just dropped the DMA call instead
2025-10-30T22:57:42 < PhantomWork> then, once it work, implement the big buffer
2025-10-30T22:59:43 < PhantomWork> hollycow....
2025-10-30T22:59:51 < PhantomWork> it's...
2025-10-30T23:00:00 < Steffanx> Are you indian?
2025-10-30T23:00:11 < PhantomWork> POWERSHELL!   simplyserial run in powershell, which for some reasons stopped working with ansi!
2025-10-30T23:00:14 < PhantomWork> putty work
2025-10-30T23:00:30 < PhantomWork> time to go home and decompress
2025-10-30T23:00:34 < PhantomWork> thanks
2025-10-30T23:01:19 < qyx> powershell
2025-10-30T23:01:20 < qyx> what
2025-10-30T23:01:35 < qyx> I haven't heard this curse in a while
2025-10-30T23:17:56 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has joined ##stm32
2025-10-30T23:19:13 < qyx> unrouted: 92, maybe after one week I am close to the finish line
2025-10-30T23:29:25 -!- teknix_ [~unknown@user/hsv] has quit [Ping timeout: 264 seconds]
2025-10-30T23:53:12 < ds2> lift pins and measure?
2025-10-30T23:57:19 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 256 seconds]
--- Day changed Fri Oct 31 2025
2025-10-31T00:46:31 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has quit [Ping timeout: 264 seconds]
2025-10-31T01:06:54 < ventYl> FOSDEM devrooms list was published
2025-10-31T04:23:25 -!- emeb_mac [~emeb_mac@ip174-73-147-156.ph.ph.cox.net] has joined ##stm32
2025-10-31T04:26:25 < emeb_mac> Anyone here have experience using STM32H7R/S parts?
2025-10-31T04:27:14 < emeb_mac> Just built up a little board w/ and H7R3 and although it shows up in DFU mode on the ST programmer, OOCD doesn't seem to support it yet.
2025-10-31T04:29:11 < emeb_mac> looking on the OOCD gerrit server it seems that there is a dev branch that has support but when I try to build latest OOCD I run into lots of issues - seems that the way jimtcl is built has changed so I can't seem to get thru the build process w/o errors.
2025-10-31T04:42:07 < ds2> emeb_mac?
2025-10-31T04:42:23 < emeb_mac> yo ds2! Long time.
2025-10-31T04:42:43 < ds2> has it been a decade?
2025-10-31T04:42:50 < emeb_mac> if not more
2025-10-31T04:44:06 < ds2> moving into the realm of non DSPs?
2025-10-31T04:46:03 < emeb_mac> hah - I've been in the non-dsp realm for a long time. 
2025-10-31T04:58:22 -!- noarb [~noarb@user/noarb] has quit [Ping timeout: 246 seconds]
2025-10-31T04:59:47 -!- noarb [~noarb@user/noarb] has joined ##stm32
2025-10-31T06:11:57 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-31T06:16:40 -!- nerozero [~nerozero@87.253.63.54] has quit [Remote host closed the connection]
2025-10-31T06:18:28 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2025-10-31T07:45:23 -!- qyx [~qyx@84.245.121.108] has quit [Ping timeout: 256 seconds]
2025-10-31T07:47:00 -!- qyx [~qyx@84.245.121.39] has joined ##stm32
2025-10-31T08:02:14 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-31T08:03:13 -!- emeb_mac [~emeb_mac@ip174-73-147-156.ph.ph.cox.net] has quit [Quit: Leaving.]
2025-10-31T09:14:45 < qyx> FOSDEM sounds like MOSFET
2025-10-31T09:15:00 < qyx> *MOSFED
2025-10-31T09:22:26 -!- teknix_ [~unknown@user/hsv] has joined ##stm32
2025-10-31T09:37:04 < ventYl> **MOSSAD
2025-10-31T09:40:07 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 240 seconds]
2025-10-31T10:01:31 -!- nuxil [~nuxil@telia-5908f6-23.connect.netcom.no] has quit [Remote host closed the connection]
2025-10-31T10:01:53 -!- nuxil [~nuxil@telia-5908f6-23.connect.netcom.no] has joined ##stm32
2025-10-31T10:03:01 -!- nuxil [~nuxil@telia-5908f6-23.connect.netcom.no] has quit [Remote host closed the connection]
2025-10-31T10:03:19 -!- nuxil [~nuxil@telia-5908f6-23.connect.netcom.no] has joined ##stm32
2025-10-31T11:15:07 -!- Thorn [~Thorn@user/thorn] has joined ##stm32
2025-10-31T11:19:44 < zyp> oh, for once I'm positively surprised by zephyr
2025-10-31T11:20:22 < zyp> if I pass a string with an IP address to the DNS resolve function, I get a sockaddr back with that IP
2025-10-31T11:20:59 < zyp> so I don't have to special case for whether I need to do a DNS lookup or just parse an IP addr
2025-10-31T11:24:36 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-31T11:31:20 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-31T11:32:10 < ventYl> isn't zephyr just wrapping something like lwip?
2025-10-31T11:32:17 < ventYl> it's DNS resolver behaves the same
2025-10-31T11:32:53 < ventYl> actually, most resolvers I've met behave this way
2025-10-31T11:38:04 < zyp> it's a reasonable thing to do, I've just learned to not expect things to be reasonable
2025-10-31T11:41:29 < qyx> that's a reasonable thing to expect
2025-10-31T11:53:03 < qyx> unrouted: 0 \o/
2025-10-31T12:12:31 < jpa-> drc errors: 9999
2025-10-31T12:12:54 < Steffanx> You can ignore those right?
2025-10-31T12:19:45 < karlp> PhantomWork: re what qyx was saying about uint8_t: https://false.ekta.is/2012/07/code-size-changes-with-int-on-8bit-and-32bit-platforms/
2025-10-31T12:22:42 < jpa-> "(Though I still think it’s dodgy that int_least8_t resulted in bigger code than int_fast8_t)" why? isn't int_least8_t equal to int8_t always except if the platform does not support 8-bit types at all?
2025-10-31T12:31:09 < karlp> I no longer remember the details of what they're defined to do, but I remember being surprised. the "(u)int8_t is bigger than (u)int" on arm32bit is the takeaway that qyx was trying to get across
2025-10-31T12:31:57 -!- jerrycash2 [~jerrycash@user/jerrycash] has joined ##stm32
2025-10-31T12:34:58 -!- jerrycash3 [~jerrycash@user/jerrycash] has quit [Ping timeout: 256 seconds]
2025-10-31T12:43:25 < qyx> I would say int_least8_t is 32 bit in all reasonable circumstances, what is like 90%
2025-10-31T12:43:41 < jpa-> qyx: why?
2025-10-31T12:43:53 < qyx> why not
2025-10-31T12:44:01 < jpa-> "smallest signed integer type with width of at least 8, 16, 32 and 64 bits respectively"
2025-10-31T12:44:13 < jpa-> so if the platform has int8_t available, int_least8_t == int8_t
2025-10-31T12:44:20 < jpa-> it is *not* "smallest code size"
2025-10-31T12:44:57 < qyx> hm ok
2025-10-31T12:45:22 < jpa-> on the other hand, i'd say int_fast8_t will be smallest codesize too
2025-10-31T12:47:02 < qyx> isnt'it? it is according to his table
2025-10-31T12:52:55 < karlp> what surprised me was that int was faster/smalelr on one, but unsigned was faster/smaller on the other.
2025-10-31T12:55:54 < qyx> it surprises me there is a difference
2025-10-31T12:56:54 < qyx> I am using size_t for anything regarding memory, inclusing counting memory locations, array indices, etc.
2025-10-31T12:57:05 < qyx> and uint32_t for other things
2025-10-31T12:57:31 < qyx> I am not using signed unless required
2025-10-31T12:58:50 < karlp> what pisses me off the most is that %u doesn't work for uint32_t :)
2025-10-31T13:07:16 < qyx> oh the police found ventYl's scrapyard https://m.smedata.sk/api-media/media/image/sme/8/92/9224408/9224408_1000x.jpg
2025-10-31T13:25:37 -!- nuxil [~nuxil@telia-5908f6-23.connect.netcom.no] has quit [Read error: Connection reset by peer]
2025-10-31T13:37:44 -!- kovalevsky_ [~kovalevsk@190.103.220.93] has joined ##stm32
2025-10-31T13:45:13 < zyp> hrm, cancellation is hard
2025-10-31T13:46:11 < zyp> as in, I'm passing a buffer to get filled by a callback in another thread
2025-10-31T13:46:23 < zyp> callback then sets a signal once it's done
2025-10-31T13:46:33 < zyp> happy path is easy enough
2025-10-31T13:47:13 < zyp> callback might arrive before I've passed a buffer, so I can have a semaphore that the callback waits for
2025-10-31T13:48:23 < zyp> but then I would like a way to cancel this operation so I can invalidate the buffer before it gets filled
2025-10-31T13:49:58 < zyp> so, okay, I can take the semaphore to take the buffer back before the callback takes it
2025-10-31T13:50:09 -!- nuxil [~nuxil@telia-5908f6-23.connect.netcom.no] has joined ##stm32
2025-10-31T13:50:45 < zyp> but if the callback already has the buffer, I must wait for it to get filled
2025-10-31T13:52:08 < zyp> and a destructor can't wait for an async signal
2025-10-31T13:58:35 < jpa-> make the callback release the semaphore at the end, so you can always wait on it?
2025-10-31T13:58:45 < jpa-> or can't you wait on semaphore either?
2025-10-31T13:59:14 < zyp> I can, but then the semaphore wouldn't indicate buffer availabilty anymore
2025-10-31T13:59:45 < jpa-> why not?
2025-10-31T13:59:59 < zyp> because the callback just filled the buffer
2025-10-31T14:00:13 < jpa-> ah, so you might get another callback before anyone takes out the buffer?
2025-10-31T14:00:49 < tomeaton17> moin
2025-10-31T14:00:50 < zyp> yes, the callback in this case is called from a socket service
2025-10-31T14:02:11 < zyp> I've got async mqtt_recv() that takes a buffer and passes it to the service callback, if the service callback gets a message, it waits for an available buffer and fills it
2025-10-31T14:04:13 < zyp> but I want to be able to cancel the recv in a clean manner
2025-10-31T14:04:23 < PhantomWork> karlp: interessing for the code size
2025-10-31T14:05:34 < jpa-> zyp: sounds like you might need a separate "callback busy" semaphore
2025-10-31T14:06:06 < zyp> yeah
2025-10-31T15:04:32 < zyp> ok, this seems to work: https://paste.jvnv.net/view/weLIq
2025-10-31T15:34:46 < karlp> nice, goog is now allowing external transactions and payments _for users in the us_  ... "Note these changes only apply to users of these apps and games in the US and while the injunction is in effect. "
2025-10-31T15:35:56 < mrec_> did anyone try to switch between circular and normal DMA mode? (DMA_SxCR_CIRC). Is there anything that needs to be taken care about after removing this flag?
2025-10-31T15:47:17 -!- infisc [uid692580@user/infisc] has joined ##stm32
2025-10-31T15:50:14 -!- emeb_mac [~emeb_mac@ip174-73-147-156.ph.ph.cox.net] has joined ##stm32
2025-10-31T15:57:08 < karlp> feck, stack smashing protect failure on the main task..
2025-10-31T15:59:14 < karlp> ahh, no, it's the bt controller task. hopefully I can just grow that shit
2025-10-31T16:05:06 -!- emeb_mac [~emeb_mac@ip174-73-147-156.ph.ph.cox.net] has quit [Quit: Leaving.]
2025-10-31T16:15:49 -!- nuxil_ [~nuxil@telia-5908f6-23.connect.netcom.no] has joined ##stm32
2025-10-31T16:20:25 -!- nuxil [~nuxil@telia-5908f6-23.connect.netcom.no] has quit [Ping timeout: 264 seconds]
2025-10-31T16:43:26 < jpa-> mrec_: i would assume you can only do it when the channel is stopped, and at that point it is as if you were starting a new transfer anyway
2025-10-31T16:44:14 < mrec_> I fixed it already, it wasn't so difficult after all
2025-10-31T16:44:39 < mrec_> I'm just finishing my homing sequence for the 3 motors now
2025-10-31T16:47:32 < mrec_> the final controller will end up on the H7 since my F4 doesn't have enough timers / interfaces for my servos.
2025-10-31T17:04:35 -!- martinmoene [~martinmoe@132.229.46.129] has quit [Read error: Connection reset by peer]
2025-10-31T17:06:07 -!- martinmoene [~martinmoe@132.229.46.129] has joined ##stm32
2025-10-31T17:12:18 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-31T17:19:25 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-31T17:24:25 -!- DemolitionMan [~kvirc@77.39.229.101] has joined ##stm32
2025-10-31T17:57:01 -!- infisc [uid692580@user/infisc] has quit [Quit: Connection closed for inactivity]
2025-10-31T18:00:58 < qyx> oh I ran out of accessible uarts
2025-10-31T18:01:22 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2025-10-31T18:38:59 < mawk> I broke my temperature sensor
2025-10-31T18:39:10 < mawk> but it wasn't working anyway, unless it's 3°C in the room and I haven't noticed
2025-10-31T18:39:26 < mawk> so I ordered a 1-wire alternative instead of this analog crap
2025-10-31T18:48:26 < qyx> I hope not ds18b20
2025-10-31T18:48:36 < mawk> maybe
2025-10-31T18:48:39 < mawk> it starts with ds
2025-10-31T18:48:41 < mawk> why?
2025-10-31T18:48:50 < qyx> that thing should die
2025-10-31T18:48:53 < mawk> lol
2025-10-31T18:49:00 < mawk> because it's slow?
2025-10-31T18:49:46 < qyx> I bet your analog crap is much more stable long term
2025-10-31T18:50:25 < qyx> no because it is low precision, low accuracy shit with a weird protocol
2025-10-31T18:51:16 < mawk> because of the self-heating?
2025-10-31T18:51:18 < mawk> I ordered another piece of the analog thing just in case
2025-10-31T18:51:20 < mawk> well I need 0.5⁰C precision I hope it can at least do that
2025-10-31T18:51:44 < qyx> it has 0.125 or so resolution?
2025-10-31T18:51:47 < qyx> iirc
2025-10-31T18:52:07 < mawk> the rradings are like 12 bits but I suppose lots of them are garbage
2025-10-31T18:52:45 < mawk> the thing with the LM35 analog thing is that it's super sensitive to the line capacitance, it just refuses to output a value if you don't add a bunch of stuff around it
2025-10-31T18:52:48 < qyx> all pros use pt100/pt1000
2025-10-31T18:53:03 < mawk> I put 2k in series with the analog output but even then it didn't work
2025-10-31T18:53:12 < qyx> you can get pt1000 in AA claass which is 0.1°C accuracy right from the manufacturer
2025-10-31T18:53:25 < mawk> I would need a bypass capacitor and using constant current tricks with twisted pair
2025-10-31T18:53:30 < qyx> my riglol has mode to convert directly to °C over scpi
2025-10-31T18:53:36 < mawk> ah nice
2025-10-31T18:54:06 < mawk> it's pretty big
2025-10-31T18:55:41 < mawk> it's even got its own wiki page https://nl.wikipedia.org/wiki/Pt100
2025-10-31T18:55:44 < mawk> but only in dutch
2025-10-31T18:56:45 < qyx> pt can be as small as 1 or 2 mm
2025-10-31T18:58:45 < jpa-> why not jadew's templogger, i hear it's finished?
2025-10-31T19:00:49 < jpa-> ds18b20 is fine IMO and the 1-wire protocol is genius
2025-10-31T19:01:19 < mawk> for the analog thing before I broke it the plan was to put it in series with a 200Ω resistor while grounding its analog output through a 200Ω resistor, and then I measure the voltage drop, and supply VCC and GND as twisted pair to the thing
2025-10-31T19:01:24 < mawk> but now it's kaput
2025-10-31T19:01:42 < jpa-> only problem being it doesn't go well over looong cables, but then again i2c and analog don't either
2025-10-31T19:02:10 < mawk> wikipedia says 300m with a stronger pullup
2025-10-31T19:02:51 < jpa-> yeah, i had it working at 100+m as a kid, and it kept failing every now and then
2025-10-31T19:03:11 < mawk> using parasitic power? or supplying it normally 
2025-10-31T19:03:51 < jpa-> mostly direct supply, though there were some parasitic ones on the bus too
2025-10-31T19:04:16 < mawk> I had like a 1m telephone cable with the analog LM35 but that was already no good
2025-10-31T19:04:45 < jpa-> it was on old unshielded telephone cable between buildings
2025-10-31T19:06:44 < jpa-> at one point i had an old nokia monochrome LCD screen as a clock that was driven by gpio expander over 1wire.. surprisingly it wasn't even that slow
2025-10-31T19:08:17 < jpa-> the best part of 1wire was that maximic used to give free samplea and they came in cute plastic boxes
2025-10-31T19:10:24 < qyx> you bet you can get analol working over 1km
2025-10-31T19:14:20 < jpa-> but with what accuracy?
2025-10-31T19:15:23 < qyx> accuracy is not impacted, fully differential, 4 wire pt100/1000
2025-10-31T19:15:56 < jpa-> ah, i thought you meant lm35 :)
2025-10-31T19:16:40 < jpa-> i2c also works when you use differential transceiver
2025-10-31T19:17:30 < qyx> oh lm35 is worse than ds18b20
2025-10-31T19:19:22 < jpa-> time to upgrade to TMP100
2025-10-31T19:21:59 -!- emeb_mac [~emeb_mac@ip174-73-147-156.ph.ph.cox.net] has joined ##stm32
2025-10-31T19:32:19 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-31T19:43:22 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 256 seconds]
2025-10-31T20:00:01 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has joined ##stm32
2025-10-31T20:15:06 -!- noarb [~noarb@user/noarb] has quit [Ping timeout: 256 seconds]
2025-10-31T20:23:30 -!- DemolitionMan [~kvirc@77.39.229.101] has quit [Quit: KVIrc 5.2.8 Quasar http://www.kvirc.net/]
2025-10-31T20:26:22 -!- Livio [~livio@user/livio] has quit [Ping timeout: 272 seconds]
2025-10-31T20:27:40 -!- Livio [~livio@user/livio] has joined ##stm32
2025-10-31T21:04:50 -!- System_Error [~SystemErr@user/systemerror] has quit [Remote host closed the connection]
2025-10-31T21:11:54 -!- System_Error [~SystemErr@user/systemerror] has joined ##stm32
2025-10-31T21:33:14 < mawk> how do you do that qyx
2025-10-31T21:33:23 < mawk> with a constant current source ?
2025-10-31T21:33:32 < mawk> and factoring the wire resistance
2025-10-31T21:39:38 < qyx> no, it is independent of the wire residtance
2025-10-31T21:40:21 < qyx> no constant current source, those are hard
2025-10-31T21:43:56 < qyx> https://www.analog.com/en/resources/technical-articles/highaccuracy-temperature-measurements.html
2025-10-31T21:44:00 < qyx> fig. 1
2025-10-31T21:52:27 -!- nuxil_ [~nuxil@telia-5908f6-23.connect.netcom.no] has quit [Ping timeout: 244 seconds]
2025-10-31T22:09:00 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 256 seconds]
2025-10-31T22:11:32 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2025-10-31T22:43:34 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 256 seconds]
2025-10-31T22:45:02 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2025-10-31T22:45:32 -!- kovalevsky_ [~kovalevsk@190.103.220.93] has quit [Ping timeout: 260 seconds]
2025-10-31T23:01:16 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 255 seconds]
2025-10-31T23:03:36 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2025-10-31T23:14:12 -!- Livio [~livio@user/livio] has quit [Ping timeout: 272 seconds]
2025-10-31T23:17:53 -!- ventZl [~ventZl@46-13-58-131.customers.tmcz.cz] has joined ##stm32
2025-10-31T23:37:58 -!- martinmoene__ [~Martin@210-212-21-31.ftth.glasoperator.nl] has quit [Ping timeout: 256 seconds]
--- Log closed Sat Nov 01 00:00:44 2025