--- Log opened ma tammi 01 00:00:39 2024
2024-01-01T00:05:37 -!- machinehum [~machinehu@213.55.221.112] has joined ##stm32
2024-01-01T00:09:56 -!- machinehum [~machinehu@213.55.221.112] has quit [Ping timeout: 245 seconds]
2024-01-01T00:54:08 -!- machinehum [~machinehu@213.55.221.112] has joined ##stm32
2024-01-01T00:58:47 -!- machinehum [~machinehu@213.55.221.112] has quit [Ping timeout: 256 seconds]
2024-01-01T00:59:03 -!- Spirit532 [~Spirit532@user/Spirit532] has quit [Read error: Connection reset by peer]
2024-01-01T01:01:21 -!- Spirit532 [~Spirit532@user/Spirit532] has joined ##stm32
2024-01-01T01:17:11 -!- machinehum [~machinehu@213.55.221.112] has joined ##stm32
2024-01-01T01:18:10 < qyx> so hny for those in utc+1
2024-01-01T01:18:38 < qyx> I wish you all a year full of great stm32 innovations
2024-01-01T01:21:55 < PaulFertser> Or ESP32-C3 probably?
2024-01-01T01:22:01 -!- machinehum [~machinehu@213.55.221.112] has quit [Ping timeout: 256 seconds]
2024-01-01T01:32:32 < Steffanx> Whatever makes you feel all fuzzy and nice.
2024-01-01T01:47:21 -!- boB_K7IQ [~boB_K7IQ@184-98-64-136.phnx.qwest.net] has quit [Read error: Connection reset by peer]
2024-01-01T02:01:49 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-202c-5788-5ca4-5f11.fixed6.kpn.net] has joined ##stm32
2024-01-01T02:08:59 -!- machinehum [~machinehu@213.55.221.112] has joined ##stm32
2024-01-01T02:13:15 -!- machinehum [~machinehu@213.55.221.112] has quit [Ping timeout: 245 seconds]
2024-01-01T02:32:37 < emeb_mac> inb4 ch32
2024-01-01T02:38:40 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 245 seconds]
2024-01-01T02:54:28 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has quit [Quit: Bye]
2024-01-01T02:57:24 -!- machinehum [~machinehu@213.55.221.112] has joined ##stm32
2024-01-01T03:01:58 -!- machinehum [~machinehu@213.55.221.112] has quit [Ping timeout: 276 seconds]
2024-01-01T03:08:28 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-202c-5788-5ca4-5f11.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-01T03:23:12 -!- hsv_ [~unknown@user/hsv] has joined ##stm32
2024-01-01T03:25:37 -!- hsv [~unknown@user/hsv] has quit [Ping timeout: 246 seconds]
2024-01-01T03:30:56 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-01T03:31:27 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Client Quit]
2024-01-01T03:31:36 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-01T03:47:33 -!- machinehum [~machinehu@213.55.221.112] has joined ##stm32
2024-01-01T03:51:56 -!- machinehum [~machinehu@213.55.221.112] has quit [Ping timeout: 268 seconds]
2024-01-01T04:38:27 -!- machinehum [~machinehu@213.55.221.112] has joined ##stm32
2024-01-01T04:42:55 -!- machinehum [~machinehu@213.55.221.112] has quit [Ping timeout: 255 seconds]
2024-01-01T05:28:43 -!- machinehum [~machinehu@213.55.221.112] has joined ##stm32
2024-01-01T05:33:19 -!- machinehum [~machinehu@213.55.221.112] has quit [Ping timeout: 255 seconds]
2024-01-01T06:09:11 -!- machinehum [~machinehu@213.55.221.112] has joined ##stm32
2024-01-01T06:13:15 -!- machinehum [~machinehu@213.55.221.112] has quit [Ping timeout: 245 seconds]
2024-01-01T06:56:25 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-01T06:59:12 -!- machinehum [~machinehu@213.55.221.112] has joined ##stm32
2024-01-01T07:03:34 -!- machinehum [~machinehu@213.55.221.112] has quit [Ping timeout: 264 seconds]
2024-01-01T07:49:19 -!- machinehum [~machinehu@213.55.221.112] has joined ##stm32
2024-01-01T07:53:58 -!- machinehum [~machinehu@213.55.221.112] has quit [Ping timeout: 264 seconds]
2024-01-01T08:39:42 -!- machinehum [~machinehu@213.55.221.112] has joined ##stm32
2024-01-01T08:44:02 -!- machinehum [~machinehu@213.55.221.112] has quit [Ping timeout: 252 seconds]
2024-01-01T08:50:16 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-01T08:58:59 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-01T09:25:48 -!- machinehum [~machinehu@213.55.221.112] has joined ##stm32
2024-01-01T09:30:34 -!- machinehum [~machinehu@213.55.221.112] has quit [Ping timeout: 264 seconds]
2024-01-01T09:48:47 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
2024-01-01T10:13:27 -!- machinehum [~machinehu@213.55.221.112] has joined ##stm32
2024-01-01T10:18:16 -!- machinehum [~machinehu@213.55.221.112] has quit [Ping timeout: 268 seconds]
2024-01-01T10:31:01 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-ed37-2a1b-e0d2-d669.fixed6.kpn.net] has joined ##stm32
2024-01-01T10:34:52 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-01T10:43:36 -!- machinehum [~machinehu@213.55.221.112] has joined ##stm32
2024-01-01T11:09:59 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-01T11:16:12 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-01T11:23:20 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-ed37-2a1b-e0d2-d669.fixed6.kpn.net] has quit [Ping timeout: 268 seconds]
2024-01-01T11:23:56 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-e565-2946-fd8a-d85b.fixed6.kpn.net] has joined ##stm32
2024-01-01T11:31:28 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-01T11:35:40 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 268 seconds]
2024-01-01T11:42:29 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-e565-2946-fd8a-d85b.fixed6.kpn.net] has quit [Ping timeout: 260 seconds]
2024-01-01T11:52:30 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has joined ##stm32
2024-01-01T12:33:16 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-e565-2946-fd8a-d85b.fixed6.kpn.net] has joined ##stm32
2024-01-01T12:37:13 -!- machinehum [~machinehu@213.55.221.112] has quit [Ping timeout: 276 seconds]
2024-01-01T12:39:55 -!- machinehum [~machinehu@213.55.221.112] has joined ##stm32
2024-01-01T12:59:50 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-01T13:00:19 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-01T13:18:20 -!- machinehum [~machinehu@213.55.221.112] has quit [Ping timeout: 268 seconds]
2024-01-01T13:56:28 -!- machinehum [~machinehu@213.55.221.112] has joined ##stm32
2024-01-01T14:29:44 -!- vekay [~vekay@user/vekay] has joined ##stm32
2024-01-01T14:45:17 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-e565-2946-fd8a-d85b.fixed6.kpn.net] has quit [Ping timeout: 268 seconds]
2024-01-01T15:53:07 -!- machinehum [~machinehu@213.55.221.112] has quit [Ping timeout: 268 seconds]
2024-01-01T15:55:28 -!- machinehum [~machinehu@213.55.221.112] has joined ##stm32
2024-01-01T16:09:35 -!- duude__ [~duude__@user/duude/x-4676560] has quit [Ping timeout: 264 seconds]
2024-01-01T16:10:08 -!- duude__- [~duude__@user/duude/x-4676560] has joined ##stm32
2024-01-01T16:12:10 -!- duude__- is now known as duude__
2024-01-01T16:42:44 -!- machinehum2 [~machinehu@213.55.221.115] has joined ##stm32
2024-01-01T16:44:04 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-01T16:45:33 -!- machinehum [~machinehu@213.55.221.112] has quit [Ping timeout: 256 seconds]
2024-01-01T17:00:16 -!- alan_o [~alan_o@2600:1700:1902:210f:54e1:d69:6f58:8e8a] has quit [Remote host closed the connection]
2024-01-01T17:00:36 -!- alan_o [~alan_o@2600:1700:1902:210f:9df7:3cfd:eff4:4cfd] has joined ##stm32
2024-01-01T17:10:26 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-01T17:12:23 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-d9bf-e744-8414-79b4.fixed6.kpn.net] has joined ##stm32
2024-01-01T17:29:45 -!- machinehum2 [~machinehu@213.55.221.115] has quit [Ping timeout: 256 seconds]
2024-01-01T17:35:12 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-01T17:38:16 -!- machinehum [~machinehu@213.55.221.115] has quit [Read error: Connection reset by peer]
2024-01-01T18:33:16 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 245 seconds]
2024-01-01T18:59:34 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has joined ##stm32
2024-01-01T19:30:15 -!- nuxil [~nuxil@141.195.51.41] has joined ##stm32
2024-01-01T19:33:55 < nuxil> Hi. i have a nucleo64 F446RE, been laying on the shelf for years. but now i need to do some usb stuff with it. i need to create a hid device, a joystick. is there any official examples for setuping up a hid device ? i been googeling and yea. result is a bit willy nilly.
2024-01-01T19:34:40 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-01T19:37:27 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-01T19:38:11 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-01T20:00:01 -!- vekay [~vekay@user/vekay] has quit [Quit: Leaving]
2024-01-01T20:03:15 < nomorekaki> https://learn.microsoft.com/en-us/windows/package-manager/winget/
2024-01-01T20:05:40 < qyx> it took them only 25 years
2024-01-01T20:06:00 < qyx> Windows Package Manager was first announced at the Microsoft Build developer conference in May 2020.[5][4] 
2024-01-01T20:06:03 < qyx> sorry, 21
2024-01-01T20:07:01 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-d9bf-e744-8414-79b4.fixed6.kpn.net] has quit [Ping timeout: 276 seconds]
2024-01-01T20:07:26 < nomorekaki> there must have been third party solutions
2024-01-01T20:07:40 < nomorekaki> I mean companies need to maintain their comfusers after all
2024-01-01T20:21:53 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 260 seconds]
2024-01-01T20:38:40 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-01T20:43:29 < nomorekaki> how was the new year?
2024-01-01T20:43:45 < zyp> snowy
2024-01-01T20:47:03 < nomorekaki> fireworks?
2024-01-01T20:55:46 < nomorekaki> dogs barking inside houses all night an stuff
2024-01-01T21:09:03 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 256 seconds]
2024-01-01T21:35:59 -!- vekay [~vekay@user/vekay] has joined ##stm32
2024-01-01T21:37:03 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-01T21:43:51 -!- MGF_Fabio [~MGF_Fabio@81.56.161.139] has joined ##stm32
2024-01-01T21:45:25 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
2024-01-01T21:48:39 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2024-01-01T21:53:35 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-01T21:57:50 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 245 seconds]
2024-01-01T22:02:00 < jbo> can somebody tell me how I can achieve a net-tie to connect two ground planes on an inner layer in kicad? .__.
2024-01-01T22:36:26 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-01T22:40:29 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 240 seconds]
2024-01-01T22:47:24 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-edec-af56-e02a-dcac.fixed6.kpn.net] has joined ##stm32
2024-01-01T22:51:34 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-01T22:58:11 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 252 seconds]
2024-01-01T23:10:18 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has quit [Quit: Bye]
2024-01-01T23:11:07 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-01T23:16:10 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 276 seconds]
2024-01-01T23:31:58 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-01T23:35:37 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 268 seconds]
2024-01-01T23:37:58 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-01T23:41:36 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 245 seconds]
2024-01-01T23:42:01 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-01T23:44:50 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-01T23:44:56 -!- hackkitten [~hackkitte@2a00:6020:5090:5700::878] has quit [Read error: Connection reset by peer]
2024-01-01T23:45:18 -!- hackkitten [~hackkitte@2a00:6020:5090:5700::878] has joined ##stm32
2024-01-01T23:48:30 -!- Miyu [~hackkitte@94.31.104.136] has joined ##stm32
2024-01-01T23:48:40 -!- hackkitten [~hackkitte@2a00:6020:5090:5700::878] has quit [Read error: Connection reset by peer]
2024-01-01T23:50:44 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 268 seconds]
2024-01-01T23:51:45 -!- hackkitten [~hackkitte@2a00:6020:5090:5700::878] has joined ##stm32
2024-01-01T23:53:11 -!- Miyu [~hackkitte@94.31.104.136] has quit [Read error: Connection reset by peer]
2024-01-01T23:55:29 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-01T23:59:05 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 245 seconds]
--- Day changed ti tammi 02 2024
2024-01-02T00:03:05 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-02T00:07:36 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 256 seconds]
2024-01-02T00:14:35 -!- MGF_Fabio [~MGF_Fabio@81.56.161.139] has quit [Ping timeout: 260 seconds]
2024-01-02T00:17:57 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-02T00:20:29 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-02T00:21:24 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:bd63:f645:deab:5aff] has joined ##stm32
2024-01-02T00:21:49 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 276 seconds]
2024-01-02T00:25:46 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 245 seconds]
2024-01-02T00:42:25 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-02T00:42:27 < Laurenceb_> https://e3.365dm.com/23/04/1600x900/skynews-obama-white-house-bin_6137475.png?20230429110736
2024-01-02T00:42:30 < Laurenceb_> when u see it
2024-01-02T00:48:35 < nomorekaki> sup
2024-01-02T00:49:12 < nomorekaki> how was the new year?
2024-01-02T00:52:37 < Laurenceb_> ok thanks
2024-01-02T00:55:28 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-02T00:58:53 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 240 seconds]
2024-01-02T00:59:31 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-edec-af56-e02a-dcac.fixed6.kpn.net] has quit [Ping timeout: 245 seconds]
2024-01-02T01:23:03 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:bd63:f645:deab:5aff] has quit [Ping timeout: 256 seconds]
2024-01-02T01:23:19 < stgl> jbo: do they have the same net? any polygon or shape should do
2024-01-02T01:29:29 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-02T01:32:50 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 245 seconds]
2024-01-02T01:53:53 < Laurenceb_> looks like there are no STM32s with ethernet and >2DAC channels?
2024-01-02T01:59:30 < Laurenceb_> wtf is I3C bus
2024-01-02T01:59:46 < Laurenceb_> I3C v1.1.1
2024-01-02T01:59:46 < Laurenceb_> Published in June 2021, it has deprecated the terms "master/slave"
2024-01-02T01:59:47 < Laurenceb_> kek
2024-01-02T02:00:14 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 252 seconds]
2024-01-02T02:02:48 < zyp> i3c is this magic spec that's supposed to fix all the issues with i2c
2024-01-02T02:03:22 < zyp> kinda «all the benefits of i2c combined with all the benefits of spi»
2024-01-02T02:03:34 < zyp> plus another few, probably
2024-01-02T02:03:42 < zyp> e.g. neither i2c nor spi has in band interrupts
2024-01-02T02:04:10 < qyx> such as the mipi was?
2024-01-02T02:04:23 < qyx> I don't see any wide adoption yet
2024-01-02T02:04:30 < qyx> and it is already a few years old
2024-01-02T02:04:34 < zyp> I should add that I haven't tried i3c yet, so I've got no idea how it delivers on the promises
2024-01-02T02:04:37 < zyp> and yeah
2024-01-02T02:04:57 < zyp> that's the issue, it's not really common enough yet
2024-01-02T02:05:13 < qyx> I remmeber seeing maybe 2-3 sensors with it and 1-2 MCUs?
2024-01-02T02:05:16 < zyp> not sure if it's a chicken/egg problem or what
2024-01-02T02:05:19 < qyx> U5 afaik?
2024-01-02T02:05:41 < qyx> or that H5 thing or whatever it is
2024-01-02T02:05:55 < zyp> I figure if we see MCU starting to get i3c periphs now, we'll start to see more i3c devices eventually
2024-01-02T02:06:35 < zyp> could also potentially be useful as a mcu-mcu interconnect
2024-01-02T02:06:40 < qyx> maybe the main problem is it is harder to bitbang, so no ardweeno support, no maker community
2024-01-02T02:07:00 < qyx> yeah H5 has it, not U5
2024-01-02T02:07:26 < zyp> I figure it might be more of an issue that it's expensive to implement
2024-01-02T02:07:30 < qyx> oh what wait what
2024-01-02T02:07:36 < qyx> that MIPI was a joke
2024-01-02T02:07:43 < zyp> haha
2024-01-02T02:07:44 < qyx> is I3C really designed by MIPI?
2024-01-02T02:07:46 < zyp> yep
2024-01-02T02:07:53 < qyx> god save it
2024-01-02T02:12:19 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-02T02:17:50 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 252 seconds]
2024-01-02T02:34:01 -!- vekay [~vekay@user/vekay] has quit [Quit: Leaving]
2024-01-02T02:34:41 < Laurenceb_> lmao
2024-01-02T02:46:26 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-02T02:47:12 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-02T02:50:09 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 260 seconds]
2024-01-02T02:51:21 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Quit: Client closed]
2024-01-02T03:11:05 < mawk> well at least they have usecases for it
2024-01-02T03:11:08 < mawk> so they're testing it
2024-01-02T03:11:09 < mawk> I hope
2024-01-02T03:31:32 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-02T03:46:07 -!- Jak_o_Shadows [~Jak_o_Sha@user/jak-o-shadows/x-5091859] has joined ##stm32
2024-01-02T03:49:50 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 260 seconds]
2024-01-02T04:03:02 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-02T04:07:34 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 260 seconds]
2024-01-02T04:20:15 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-02T04:25:21 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 245 seconds]
2024-01-02T04:36:34 -!- nuxil_ [~nuxil@141.195.51.41] has joined ##stm32
2024-01-02T04:37:16 -!- nuxil [~nuxil@141.195.51.41] has quit [Read error: Connection reset by peer]
2024-01-02T04:37:24 -!- _nuxil_ [~nuxil@141.195.51.41] has joined ##stm32
2024-01-02T04:39:28 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-02T04:41:23 -!- nuxil_ [~nuxil@141.195.51.41] has quit [Ping timeout: 252 seconds]
2024-01-02T04:43:49 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 255 seconds]
2024-01-02T04:46:53 -!- veverak [~veverak@ip-89-103-173-67.bb.vodafone.cz] has quit [Ping timeout: 252 seconds]
2024-01-02T04:47:16 -!- veverak [~veverak@ip-89-103-173-67.bb.vodafone.cz] has joined ##stm32
2024-01-02T04:56:00 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-02T05:00:31 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 256 seconds]
2024-01-02T05:08:00 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-02T05:11:51 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 256 seconds]
2024-01-02T05:12:43 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-02T05:29:11 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-02T05:33:59 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Remote host closed the connection]
2024-01-02T05:56:39 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
2024-01-02T06:24:05 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 240 seconds]
2024-01-02T06:52:24 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-02T06:58:53 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 252 seconds]
2024-01-02T07:11:52 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-02T07:16:10 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 245 seconds]
2024-01-02T07:28:53 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-02T07:34:04 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 276 seconds]
2024-01-02T07:45:22 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-428-9c65-2d08-ef6f.fixed6.kpn.net] has joined ##stm32
2024-01-02T07:47:04 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-02T07:51:41 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 252 seconds]
2024-01-02T07:52:50 -!- Jak_o_Shadows [~Jak_o_Sha@user/jak-o-shadows/x-5091859] has quit [Ping timeout: 250 seconds]
2024-01-02T08:05:39 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-02T08:10:56 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 252 seconds]
2024-01-02T08:17:26 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-02T08:22:58 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-02T08:26:55 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-428-9c65-2d08-ef6f.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-02T08:28:44 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 268 seconds]
2024-01-02T08:42:11 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-02T08:51:17 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 240 seconds]
2024-01-02T09:00:37 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-02T09:03:40 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-02T09:09:14 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 252 seconds]
2024-01-02T09:23:14 -!- smooker [~smooker@185.165.96.228] has quit [Quit: Lost terminal]
2024-01-02T09:40:57 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-02T09:47:11 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 252 seconds]
2024-01-02T09:54:13 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-02T10:06:41 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-02T10:44:24 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 268 seconds]
2024-01-02T10:58:02 -!- Jak_o_Shadows [~Jak_o_Sha@user/jak-o-shadows/x-5091859] has joined ##stm32
2024-01-02T11:04:28 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:611d:9cab:8a7a:7f7c] has joined ##stm32
2024-01-02T11:25:50 -!- machinehum [~machinehu@213.55.221.115] has joined ##stm32
2024-01-02T11:51:10 -!- Jak_o_Shadows [~Jak_o_Sha@user/jak-o-shadows/x-5091859] has quit [Ping timeout: 250 seconds]
2024-01-02T12:06:20 -!- machinehum2 [~machinehu@213.55.221.115] has joined ##stm32
2024-01-02T12:06:43 -!- machinehum [~machinehu@213.55.221.115] has quit [Ping timeout: 268 seconds]
2024-01-02T12:12:43 -!- samkent [~samkent@85.133.2.154] has joined ##stm32
2024-01-02T12:29:45 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has joined ##stm32
2024-01-02T12:55:17 -!- machinehum2 [~machinehu@213.55.221.115] has quit [Read error: Connection reset by peer]
2024-01-02T14:48:21 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-02T14:53:19 < nomorekaki> moved my project to microchip studio and some statements started to have integer overflows
2024-01-02T14:54:47 -!- machinehum [~machinehu@213.55.221.169] has joined ##stm32
2024-01-02T14:54:55 < nomorekaki> intermediate steps when calculating const in statement default to some integer type based on what cpu you are compiling for?
2024-01-02T15:20:25 < nomorekaki> it's int unless casted otherwise?
2024-01-02T15:35:30 < nomorekaki> let's read about integer promotion / implicit conversions
2024-01-02T15:36:44 < PaulFertser> https://en.cppreference.com/w/cpp/language/implicit_conversion#Integral_promotion
2024-01-02T15:49:49 < nomorekaki> it needed just UL and ULL to 2 macro defs
2024-01-02T15:51:37 < nomorekaki> I wonder if compiler can demote consts all the way to unsigned char?
2024-01-02T15:52:22 < jpa-> maybe you have 16 bit int
2024-01-02T15:53:14 < nomorekaki> yes
2024-01-02T15:53:29 < nomorekaki> avr int is 2byte
2024-01-02T15:54:06 < nomorekaki> int is the minimum and if unsigned char is intended it needs a cast?
2024-01-02T15:54:08 < qyx> why did I think you are dealing with pic
2024-01-02T16:04:00 < nomorekaki> During datatype conversion, if operand on the right hand side is of higher rank type then it becomes the type of left hand side operand which is of lower rank. This kind of type conversion from higher rank to lower rank is called Demotion.
2024-01-02T16:04:32 < nomorekaki> if(rx_period<(constant))
2024-01-02T16:04:53 < nomorekaki> if rx_period is short then constant becomes short automatically
2024-01-02T16:06:50 -!- IanW_ [~IceChat9@jindivik.force9.co.uk] has quit [Quit: Bye]
2024-01-02T16:11:30 < nomorekaki> does that apply only for assignment operator?
2024-01-02T16:24:46 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-02T16:43:40 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-02T16:58:24 -!- machinehum [~machinehu@213.55.221.169] has quit [Ping timeout: 268 seconds]
2024-01-02T17:05:53 -!- machinehum [~machinehu@213.55.221.169] has joined ##stm32
2024-01-02T17:06:11 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:611d:9cab:8a7a:7f7c] has quit [Ping timeout: 245 seconds]
2024-01-02T17:30:48 < nomorekaki> time to pooppify code
2024-01-02T17:42:29 < ventYl> I remember one case when our human static analyzer came to me with question "why this doesn't fail?" pointing at line of code having simple if ()
2024-01-02T17:43:01 < ventYl> we then googled and found out that there was entirely different bug involving type promotion present
2024-01-02T17:44:04 < nomorekaki> ventYl: is it true that compiler promotes both side of an operation to at least to int if one or both are smaller than int?
2024-01-02T17:44:26 < nomorekaki> in case of comparisons etc
2024-01-02T17:45:51 < ventYl> nomorekaki: TBK i don't remember the details anymore
2024-01-02T17:46:06 < ventYl> but it was about some unexpected promotion or typecast
2024-01-02T17:46:47 < nomorekaki> that would mean even carefully casting everything into unsigned char would not do almost anything
2024-01-02T17:46:53 < nomorekaki> I cant believe it
2024-01-02T17:47:07 < ventYl> IIRC, promotion only happens if types don't match
2024-01-02T17:47:27 < nomorekaki> thats what I thought
2024-01-02T17:47:55 < ventYl> now the root of our issue was that we somehow ignored, that immediates aren't type-less
2024-01-02T17:49:10 < ventYl> immediates are usually typed as `signed int`, whatever that means for your platform
2024-01-02T17:49:49 < nomorekaki> just int
2024-01-02T17:49:55 < ventYl> that's the same
2024-01-02T17:50:09 < ventYl> unless you use something like 10U, or 10ULL to override the type
2024-01-02T17:51:04 < ventYl> our problem was something like we had `unsigned char var;` and we did if (var == 256)
2024-01-02T17:51:30 < ventYl> original question was, why the compiler doesn't say anything about the value not fitting into `var`'s range
2024-01-02T17:52:38 < nomorekaki> var is just promoted
2024-01-02T17:52:46 < ventYl> then we found out that the immediate value is actually typed as int and var was promoted
2024-01-02T17:54:47 < nomorekaki> and the actual mistake was using 256 instead of 255?
2024-01-02T17:59:30 < ventYl> something like that, but it also had some context regarding the rest of the code around
2024-01-02T17:59:31 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 245 seconds]
2024-01-02T18:01:19 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:ca77:c8a6:7dc4:4e2c] has joined ##stm32
2024-01-02T18:02:48 < fenugrec> gcc -Wextra should pick up a lot of those issues
2024-01-02T18:03:07 < fenugrec> but yeah, classic C footgun
2024-01-02T18:03:36 < fenugrec> e.g. https://godbolt.org/z/j8G4xbae5
2024-01-02T18:09:21 -!- machinehum [~machinehu@213.55.221.169] has quit [Read error: Connection reset by peer]
2024-01-02T18:10:52 < ventYl> sometimes I have a feeling, that setting highest possible warning and error level by default would be the single most beneficial improvement with least costs that could happen
2024-01-02T18:20:55 < karlp> please no -Werror though.
2024-01-02T18:23:08 -!- begriffs [~begriffs@user/begriffs] has quit [Quit: Leaving]
2024-01-02T18:24:45 -!- duude__ [~duude__@user/duude/x-4676560] has quit [Quit: ZNC 1.8.2 - https://znc.in]
2024-01-02T18:25:03 -!- duude__ [~duude__@user/duude/x-4676560] has joined ##stm32
2024-01-02T18:26:13 < qyx> I tried once
2024-01-02T18:26:15 < qyx> twice..
2024-01-02T18:26:35 < qyx> that's exactly what would my OCPD do
2024-01-02T18:26:38 < qyx> but life is hard
2024-01-02T18:39:11 < karlp> well,I spent all day, and I can cahgne ip addresses on esp32, but mdns doesn't update at the same time, it updates... later?
2024-01-02T18:39:17 < karlp> which makes no real sense.
2024-01-02T18:46:30 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has joined ##stm32
2024-01-02T18:49:46 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-02T18:58:02 -!- samkent [~samkent@85.133.2.154] has quit [Ping timeout: 268 seconds]
2024-01-02T19:17:30 -!- begriffs [~begriffs@user/begriffs] has joined ##stm32
2024-01-02T19:20:21 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-02T20:03:20 -!- begriffs [~begriffs@user/begriffs] has quit [Quit: Leaving]
2024-01-02T20:29:54 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
2024-01-02T20:31:41 < fenugrec> agreed re -Werror, breaks builds way too often when gcc adds a warning (which is pretty often). I like -Wall -Wextra -pedantic
2024-01-02T20:34:03 -!- nomorekaki34 [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-02T20:35:56 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-02T20:40:15 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-40e8-3868-c01e-420.fixed6.kpn.net] has joined ##stm32
2024-01-02T20:43:06 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-02T21:05:21 -!- nomorekaki34 is now known as nomorekaki
2024-01-02T21:11:32 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Quit: Client closed]
2024-01-02T21:20:34 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-02T22:42:41 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has joined ##stm32
2024-01-02T22:43:39 -!- begriffs [~begriffs@user/begriffs] has joined ##stm32
2024-01-02T22:50:58 -!- qyx [~qyx@84.245.121.199] has quit [Ping timeout: 264 seconds]
2024-01-02T22:52:25 -!- qyx [~qyx@84.245.120.242] has joined ##stm32
2024-01-02T22:57:46 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-02T22:57:50 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 245 seconds]
2024-01-02T22:58:05 < nomorekaki> oh wow ansi c90 sucks
2024-01-02T22:59:32 < Steffanx> C90 in 2024 nomorekaki ?
2024-01-02T23:00:00 < nomorekaki> -ansi + -pedantic
2024-01-02T23:00:26 < nomorekaki> Steffanx: what is reasonable cXX for year 2024?
2024-01-02T23:00:30 < nomorekaki> c11?
2024-01-02T23:00:34 < ventYl> at least
2024-01-02T23:00:37 < ventYl> ansi C sucks
2024-01-02T23:02:10 < nomorekaki> why would anyone use -ansi option that equals to -std=c90
2024-01-02T23:02:45 < ventYl> go ask into germany
2024-01-02T23:07:39 < nomorekaki> c11 and pedantic is fine
2024-01-02T23:07:58 < nomorekaki> nothing happens
2024-01-02T23:16:23 < nomorekaki> now I need to write hello world app
2024-01-02T23:19:27 < Steffanx> Time to go C23 nomorekaki 
2024-01-02T23:20:16 < nomorekaki> I don't C why
2024-01-02T23:21:16 < Steffanx> use constexpr  in C
2024-01-02T23:21:26 < nomorekaki> :O
2024-01-02T23:21:37 < nomorekaki> yes
2024-01-02T23:21:57 < nomorekaki> that's fantastic news
2024-01-02T23:24:10 < ventYl> I would wish for compile-time execution
2024-01-02T23:25:25 < octorian> I'm curious...  Does anyone have any thoughts on TinyUSB vs CherryUSB vs ST's own USB Library?  I'm particularly interested in the *host* side of things, which I guess is a little less common.
2024-01-02T23:25:54 < ventYl> someone tried TinyUSB host side and IIRC, he was bithin' a lot
2024-01-02T23:26:16 < octorian> TinyUSB doesn't support host on STM32 anyway, AFAIK.
2024-01-02T23:26:30 < octorian> CherryUSB does, but only on USB peripherals with DMA support.
2024-01-02T23:26:53 < octorian> And so does ST's own USB library, but it feels kinda incomplete.
2024-01-02T23:27:50 < octorian> I'm currently using ST's USB Host Library on a project, and considering switching to CherryUSB.  Only thing holding me back is that my current MCU doesn't have a DMA-capable USB peripheral, so I need to either switch or do a lot of work to the USB code in the library.
2024-01-02T23:27:53 < ventYl> I guess that DMA limitation is due to the throughtput. bulk transfer is way too demanding to be handled by CPU itself
2024-01-02T23:28:37 < octorian> For my specific application, its really not a concern.
2024-01-02T23:29:56 < octorian> My other gripe with CherryUSB is that all the documentation is in Chinese, but it otherwise "feels" like the best library.
2024-01-02T23:32:52 < Steffanx> karlp was messing with tinyusb and host iirc
2024-01-02T23:34:33 < qyx> and cherry too
2024-01-02T23:35:46 < qyx> and was complaining about the dma thing too?
2024-01-02T23:36:21 < qyx> hopefuly he responds when he digs out of lava
2024-01-02T23:56:04 < karlp> cherry only supports usb on the otg-hs parts, yeah, was a bit of a downer.
2024-01-02T23:56:15 < karlp> gave me a good fealing that they care about perf, bu tstill sucked.
2024-01-02T23:56:30 < karlp> lotttts of china chips and rtthread only though, I didn't get real far with it.
2024-01-02T23:57:00 < karlp> tinyusb host I was looking at musb, but I filed three bugs and walked away...
2024-01-02T23:59:02 < fenugrec> c++ pros : when did it become "common" to have c++ headers with extension ".hh" ? since forever ?
--- Day changed ke tammi 03 2024
2024-01-03T00:00:21 < ventYl> that's probably customary to your project/compiler/environment
2024-01-03T00:00:38 < ventYl> judging by project I've seen it is not "common"
2024-01-03T00:00:42 < fenugrec> right, just wondering if the original c++ specs mentioned .h / .hh at all as suggested extensions
2024-01-03T00:01:29 < ventYl> I assume that nobody gave the fuck about extension in the original C++ specs
2024-01-03T00:02:22 < ventYl> compiler does not care much about file extensions even these days
2024-01-03T00:02:59 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:ca77:c8a6:7dc4:4e2c] has quit [Ping timeout: 268 seconds]
2024-01-03T00:03:24 < fenugrec> soupstroop's book from 97 doesn't mention .hh but does cxx, cpp and cc
2024-01-03T00:04:56 < ventYl> wel, for sources it kind-of matters, for headers, not that much
2024-01-03T00:05:10 < ventYl> you mostly can include C header into C++ source without being punished
2024-01-03T00:05:19 < ventYl> but you can't do the opposite
2024-01-03T00:05:25 < fenugrec> m̀ostly', yes
2024-01-03T00:05:51 < ventYl> if you armor header with extern "C" {, you can do it freely
2024-01-03T00:06:06 < ventYl> or, if you compile your C sources using C++ compiler, so they will use C++ ABI
2024-01-03T00:29:56 -!- ColdKeyboard [~ColdKeybo@user/coldkeyboard] has quit [Quit: ZNC - https://znc.in]
2024-01-03T00:30:25 -!- ColdKeyboard [~ColdKeybo@user/coldkeyboard] has joined ##stm32
2024-01-03T01:19:01 -!- hsv_ is now known as hsv
2024-01-03T01:24:21 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-03T01:43:28 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-40e8-3868-c01e-420.fixed6.kpn.net] has quit [Ping timeout: 276 seconds]
2024-01-03T02:44:40 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-03T02:49:48 < octorian> karlp, I'd be tempted to port it to a non-DMA peripheral, but I'm kinda scared to dig too deep into that portion of the code without an intimate understanding of everything.
2024-01-03T02:50:42 < octorian> karlp, my current project is on an F411, so I can't use it as-is.  But I ordered an F446 Nucleo board so I can give it a shot and see how it handles some situations.
2024-01-03T02:51:34 < octorian> Right now I'm contemplating some design changes that'll make me want to add a hub IC in front of the MCU, so if I do that then I might consider switching to the F446 or similar.
2024-01-03T02:51:53 < octorian> (also ordered a few other eval boards related to that side-quest)
2024-01-03T03:02:17 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 252 seconds]
2024-01-03T04:11:24 < qyx> any recommendations for spi nor filesystems with extremely small footprint?
2024-01-03T04:11:35 < qyx> spiffs/littlefs are out of question as the are > 29K
2024-01-03T04:11:39 < qyx> sorry >20K
2024-01-03T05:06:15 < fenugrec> run your littlefs code from external NOR, problem solved
2024-01-03T05:06:18 < fenugrec> heh
2024-01-03T06:29:22 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Remote host closed the connection]
2024-01-03T07:17:39 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
2024-01-03T08:24:19 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-d6f-d70b-2785-6fe3.fixed6.kpn.net] has joined ##stm32
2024-01-03T08:41:19 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-03T08:57:55 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-d6f-d70b-2785-6fe3.fixed6.kpn.net] has quit [Ping timeout: 246 seconds]
2024-01-03T08:59:41 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-03T09:23:41 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-03T09:31:31 < jpa-> qyx: no, but you should write one and release it
2024-01-03T09:31:49 < jpa-> then abandon it so it can join the N+1 abandoned "tiny flash filesystem" projects on github
2024-01-03T10:27:17 -!- machinehum [~machinehu@213.55.221.169] has joined ##stm32
2024-01-03T10:50:02 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:a8e7:e681:2bc8:b483] has joined ##stm32
2024-01-03T10:57:29 -!- machinehum [~machinehu@213.55.221.169] has quit [Ping timeout: 252 seconds]
2024-01-03T11:02:46 -!- machinehum [~machinehu@213.55.221.169] has joined ##stm32
2024-01-03T11:11:15 < karlp> octorian: yah, I do believe cherry has a good base, but it's very chinese, and very targetted at different parts, and it was just.. too much extra.
2024-01-03T11:11:29 < karlp> tinyusb just had different problems.
2024-01-03T11:12:25 < karlp> so, back to mdns today then I guess.
2024-01-03T11:16:45 -!- samkent [~samkent@2a02:6b66:e03e:0:4e18:d4c:a622:bd1e] has joined ##stm32
2024-01-03T11:31:06 -!- Thorn [~Thorn@user/thorn] has quit [Quit: Never put off till tomorrow, what you can do the day after tomorrow]
2024-01-03T11:37:37 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-03T11:38:03 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-03T11:56:20 < qyx> jpa-: I did once, that's the reason I am asking
2024-01-03T12:47:02 -!- samkent [~samkent@2a02:6b66:e03e:0:4e18:d4c:a622:bd1e] has quit [Ping timeout: 268 seconds]
2024-01-03T13:24:05 < srk> https://github.com/DistRap/emhell now with :set for setting reg fields and some openocd control commands
2024-01-03T13:28:13 -!- samkent [~samkent@85.133.2.154] has joined ##stm32
2024-01-03T13:31:23 < PaulFertser> srk: let's feature in on openocd.org blog and mailing list when you think it's ready
2024-01-03T13:33:26 < srk> PaulFertser: cool, think I'll add reg, get/set_reg as well and work on readmes a bit more. and also :help 
2024-01-03T13:33:42 < srk> PaulFertser: openocd docs are great btw!
2024-01-03T13:34:27 < ventYl> I feel I will learn something new about linking, when I crack this "undefined symbol" situation
2024-01-03T13:39:19 < karlp> meh, crosstool-ng fails to compile m68k.
2024-01-03T13:39:35 < karlp> fucking legacy shit
2024-01-03T13:40:07 < ventYl> IME crosstool-ng eventually failed every time I tried to use it
2024-01-03T13:44:43 -!- machinehum [~machinehu@213.55.221.169] has quit [Ping timeout: 256 seconds]
2024-01-03T13:58:56 -!- HelloShi1ty [~user@bl15-39-23.dsl.telepac.pt] has joined ##stm32
2024-01-03T14:08:01 -!- HelloShi1ty [~user@bl15-39-23.dsl.telepac.pt] has quit [Quit: leaving]
2024-01-03T14:08:44 -!- HelloShi1ty [~user@bl15-39-23.dsl.telepac.pt] has joined ##stm32
2024-01-03T14:09:35 < ventYl> the what?! have function in one source file -> undefined symbol. move the function into another source file belonging to the same static library -> OK
2024-01-03T14:10:58 -!- HelloShi1ty [~user@bl15-39-23.dsl.telepac.pt] has quit [Client Quit]
2024-01-03T14:10:59 -!- machinehum [~machinehu@213.55.221.169] has joined ##stm32
2024-01-03T14:11:45 -!- HelloShi1ty [~user@bl15-39-23.dsl.telepac.pt] has joined ##stm32
2024-01-03T14:11:46 < PaulFertser> ventYl: probably linking order? ld is single-pass by default, so the file order on the command line matters
2024-01-03T14:13:09 < ventYl> PaulFertser: I moved the function over between sources of the same library. so the linking order is virtually the same.
2024-01-03T14:13:20 < jpa-> or c vs. c++ files
2024-01-03T14:13:25 < ventYl> no C++ files in there
2024-01-03T14:13:34 < ventYl> nm dump of the library looks the same regardless of where the file is
2024-01-03T14:13:39 < ventYl> s/file/function/
2024-01-03T14:14:04 < ventYl> I was thinking if linker did not reject the file immediately for some reason
2024-01-03T14:14:36 < ventYl> but the file where I moved the function fixing the linking problem has even higher chance to get rejected
2024-01-03T14:15:17 -!- machinehum [~machinehu@213.55.221.169] has quit [Ping timeout: 240 seconds]
2024-01-03T14:42:30 < karlp> ventYl: so what, I'm meant to just compile newlib and binutils and gcc from scratch like a savage?
2024-01-03T14:44:18 -!- machinehum [~machinehu@213.55.220.212] has joined ##stm32
2024-01-03T14:49:46 -!- machinehum [~machinehu@213.55.220.212] has quit [Ping timeout: 264 seconds]
2024-01-03T15:02:56 -!- machinehum [~machinehu@213.55.220.212] has joined ##stm32
2024-01-03T15:04:34 < qyx> grumplp
2024-01-03T15:14:11 < karlp> nice old "license" https://paste.jvnv.net/view/zEQzt
2024-01-03T15:19:56 < qyx> so he is basically saying "if you steal it, let me know"
2024-01-03T15:20:09 < qyx> please
2024-01-03T15:22:06 < Steffanx> Time to give Ed a call
2024-01-03T15:29:35 < qyx> I am more interested what karlp is doing with m68k
2024-01-03T15:29:56 < karlp> chekcing a build environment for prior gen coldfire shits.
2024-01-03T15:30:01 -!- HelloShi1ty [~user@bl15-39-23.dsl.telepac.pt] has quit [Ping timeout: 255 seconds]
2024-01-03T15:31:56 -!- HelloShi1ty [~user@bl22-255-167.dsl.telepac.pt] has joined ##stm32
2024-01-03T15:43:33 < karlp> yas, found a 2011.09 freescale toolchain on a fileshare. perfect :)
2024-01-03T15:58:22 -!- machinehum [~machinehu@213.55.220.212] has quit [Ping timeout: 256 seconds]
2024-01-03T16:15:09 < fenugrec> I've used ct-ng, it worked despite it being frustrating to watch build gcc and everything twice. Took forever too
2024-01-03T16:16:56 < karlp> well, apparently newlib ~2021 and 2023 won't build with it, and I can't be arsed fixing that right now. 2011 freescale binaries are fine.
2024-01-03T16:17:23 < karlp> apparently all that's actually needed work in the las 5-10 years has been the qt4 com with activex control...
2024-01-03T16:17:29 < karlp> that sounds _super_ fun to build...
2024-01-03T16:28:24 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-03T16:45:00 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-03T16:49:13 < qyx> I remember building 68hc11 stuff with ICC
2024-01-03T16:56:05 < karlp> nice nxp.  revision 6 of the datasheet, "Removed "USB HS/LS/FS on-the-go controller with on-chip high speed transceiver"
2024-01-03T16:56:07 < karlp> from features section
2024-01-03T16:57:46 -!- HelloShi1ty [~user@bl22-255-167.dsl.telepac.pt] has quit [Ping timeout: 246 seconds]
2024-01-03T17:03:53 -!- HelloShi1ty [~user@bl22-255-167.dsl.telepac.pt] has joined ##stm32
2024-01-03T17:25:04 -!- jmcgnh [~jmcgnh@wikipedia/jmcgnh] has quit [Ping timeout: 256 seconds]
2024-01-03T17:28:59 -!- HelloShi1ty [~user@bl22-255-167.dsl.telepac.pt] has quit [Ping timeout: 256 seconds]
2024-01-03T17:29:59 -!- HelloShi1ty [~user@bl22-255-167.dsl.telepac.pt] has joined ##stm32
2024-01-03T17:39:53 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has joined ##stm32
2024-01-03T17:43:03 < karlp> spotted a board with a mini-ab connector on it today...
2024-01-03T17:59:13 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-03T18:34:56 -!- machinehum [~machinehu@213.55.220.212] has joined ##stm32
2024-01-03T18:41:00 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 256 seconds]
2024-01-03T18:54:20 -!- machinehum [~machinehu@213.55.220.212] has quit [Ping timeout: 252 seconds]
2024-01-03T18:59:32 -!- machinehum [~machinehu@213.55.220.212] has joined ##stm32
2024-01-03T19:22:14 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-03T19:27:03 -!- begriffs [~begriffs@user/begriffs] has left ##stm32 [Leaving]
2024-01-03T19:29:33 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-03T19:30:23 -!- machinehum [~machinehu@213.55.220.212] has quit [Ping timeout: 256 seconds]
2024-01-03T19:39:14 -!- jmcgnh [~jmcgnh@wikipedia/jmcgnh] has joined ##stm32
2024-01-03T19:42:06 < Steffanx> Are your balls frozen yet, nomorekaki ?
2024-01-03T19:42:20 < nomorekaki> na
2024-01-03T19:42:35 < Steffanx> - how many °C ?
2024-01-03T19:42:46 < nomorekaki> -29
2024-01-03T19:42:51 < Steffanx> Yay. 
2024-01-03T19:43:02 < nomorekaki> it's the bestest coding weather
2024-01-03T19:43:36 < Steffanx> Best cooling down after a sauna weather 
2024-01-03T19:44:29 -!- machinehum [~machinehu@213.55.220.212] has joined ##stm32
2024-01-03T19:45:47 < ventYl> karlp: I did that for AVR. I guess that m68k is equally stale as AVR, so if you build toolchain now, it will be worky for quite some time
2024-01-03T19:46:32 < nomorekaki> went to sauna when we built sauna before new year
2024-01-03T19:47:20 < nomorekaki> when cooling down on patio my feet started to stick to the floor
2024-01-03T19:56:44 < ventYl> 10 day forecast predicts -12 for monday / tuesday
2024-01-03T19:58:46 -!- samkent [~samkent@85.133.2.154] has quit [Ping timeout: 264 seconds]
2024-01-03T20:02:33 < nomorekaki> interesting it's zero wind here since yesterday but finngrid say 1900MW of wind
2024-01-03T20:03:05 -!- machinehum [~machinehu@213.55.220.212] has quit [Ping timeout: 252 seconds]
2024-01-03T20:03:15 < nomorekaki> solar is 0MW btw. day or night
2024-01-03T20:04:22 < ventYl> don't you have polar night, so it is night even if it is day?
2024-01-03T20:04:38 < BrainDamage> wind in altitude is not the same as ground wind
2024-01-03T20:04:44 -!- machinehum [~machinehu@213.55.220.212] has joined ##stm32
2024-01-03T20:05:22 < BrainDamage> even just 30m can make a big difference
2024-01-03T20:06:32 < nomorekaki> ventYl: little bit of direct sunlight at noon
2024-01-03T20:07:03 < nomorekaki> panels are not only frosted over but under dozens of centimeters of snow
2024-01-03T20:12:53 < qyx> go clear them
2024-01-03T20:16:05 < nomorekaki> I don't know if you understand how frost works
2024-01-03T20:17:21 < qyx> go cover them then
2024-01-03T20:21:33 < nomorekaki> I don't know if you undestand how little there is to gain with such massive amount of work / utilities
2024-01-03T20:22:17 < nomorekaki> sun total radiation maximum is <100W per m2 in january
2024-01-03T20:24:00 < nomorekaki> what is your local maximum for january?
2024-01-03T20:25:29 < qyx> I don't really know because my MPPTs limit me to about 4.5 kW
2024-01-03T20:25:46 < qyx> and there is 7.6 kWp
2024-01-03T20:26:53 < nomorekaki> calculated* maximum for january
2024-01-03T20:26:57 < qyx> if I look up only one half of the array, I can do 2500 W of 4080 W
2024-01-03T20:28:18 < qyx> idk
2024-01-03T20:28:36 < qyx> but I can definitely do 2500 W out of 35 m2
2024-01-03T20:28:51 < qyx> of panels, not sun-orthogonal
2024-01-03T20:38:48 < nomorekaki> nice
2024-01-03T20:41:06 -!- HelloShi1ty [~user@bl22-255-167.dsl.telepac.pt] has quit [Remote host closed the connection]
2024-01-03T20:46:53 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-4c04-920f-f566-cc9d.fixed6.kpn.net] has joined ##stm32
2024-01-03T20:55:05 < ventYl> todays maximum was like 1.35 kW
2024-01-03T21:40:17 -!- Ecco [~user@user/Ecco] has joined ##stm32
2024-01-03T21:40:31 < Ecco> I'm trying to reverse a dumb 433 Mhz transmitter
2024-01-03T21:40:46 < Ecco> (it's a remote with 6 buttons)
2024-01-03T21:41:25 < ventYl> aren't those things just a "floating code" transmitters with some rather primitive modulation?
2024-01-03T21:41:43 < Ecco> Yeah I guess it's very dumb
2024-01-03T21:41:51 < Ecco> well, the remote does have a Cortex M0 on board
2024-01-03T21:41:53 < karlp> ventYl: yah, I got the old 2011 toolchain binary and built it.  that's enough. I'm not planning anything further. I don't even ahve a BDM cable for coldfire, so... fuck that.
2024-01-03T21:42:07 < Ecco> but really I assume it's just the most convenient way to build those nowadays
2024-01-03T21:42:16 < Ecco> Anyway, here's a dump I got w/ an RTL-SDR dongle:
2024-01-03T21:42:16 < Ecco> https://t.ly/5bdSu
2024-01-03T21:42:18 < karlp> in more exciting NXPnews, a freshly configured for download mcuxpresso pack includes this wonderful license clause: "Airbiquity Inc.: The Airbiquity software may only be used in object code and Licensee may not sublicense the Airbiquity software to any third party. Licensee’s license to use the Airbiquity software expires on June 30, 2023"
2024-01-03T21:42:44 < Ecco> Initially there's a lot of alternating "01", apparently that's to sync the clocks (makes sense)
2024-01-03T21:42:51 < Ecco> then the same message is repeated 4 times( again, makes sense)
2024-01-03T21:42:57 < Ecco> what I can't figure out though
2024-01-03T21:43:04 < Ecco> is that each keypress does *not* send the same code over
2024-01-03T21:43:17 < Ecco> *but* replaying a given signal will work on the receiver end
2024-01-03T21:43:28 < ventYl> Ecco: that's the spirit of floating codes
2024-01-03T21:43:42 < Ecco> ok, so then I may need to learn about floating codes
2024-01-03T21:43:45 < ventYl> and the receiver is probably extra shitty
2024-01-03T21:44:04 < ventYl> floating codes were "security through obscurity" kind of security measurement in one-way radio remotes
2024-01-03T21:44:17 < Ecco> ventYl: yes, I would expect the receiver  to be extra shitty
2024-01-03T21:44:23 < ventYl> remote is coded with sequences of few symbols for each button
2024-01-03T21:44:38 < karlp> "MQX RTOS Code: MQX RTOS source code may not be re-distributed by any NXP Licensee under any circumstance, even by a signed written amendment to this Agreement."
2024-01-03T21:44:40 < karlp> lol
2024-01-03T21:44:45 < ventYl> if you press the button, remote will continue transmitting symbols from sequence for this button until it hits the last one, then it will wrap
2024-01-03T21:44:47 < Ecco> ventYl: ok, keep talking, that's very interesting :)
2024-01-03T21:44:54 < Ecco> oh
2024-01-03T21:45:00 < Ecco> so it's like… a pre-set list of codes?
2024-01-03T21:45:04 < ventYl> yeah
2024-01-03T21:45:07 < Ecco> damn
2024-01-03T21:45:07 < BrainDamage> replaying an acknowledged signal should not work
2024-01-03T21:45:10 < karlp> if only my predecessor wasn't so charming as "I never use ST products. I don't trust french people"
2024-01-03T21:45:25 < ventYl> karlp: wtf
2024-01-03T21:45:38 < Ecco> ok, wait, I do have a few questions
2024-01-03T21:45:47 < Ecco> the remote I'm trying to reverse is a remote for a roller blind
2024-01-03T21:45:49 < ventYl> Ecco: now if you pair transmitter with base station, you usually do it by selecting "pair" on station and long-press of given button on transmitter
2024-01-03T21:45:57 < karlp> ventYl: I noticed it early, that were literally zero ST parts on any of our products, didn't think too much of it.
2024-01-03T21:46:05 < karlp> makes more sense now that I've spoken to him more...
2024-01-03T21:46:09 < BrainDamage> Ecco: do you know about hashes?
2024-01-03T21:46:12 < ventYl> this will effectively transmit the whole sequence, base station will record it
2024-01-03T21:46:20 < karlp> I keep trying to stay pleasant and polite to him, but he keeps making it hard :)
2024-01-03T21:46:25 < Ecco> BrainDamage: As in hashing algorithm? Yeah
2024-01-03T21:46:51 < Ecco> BrainDamage: I'm not sure I understood your question tho
2024-01-03T21:46:56 < BrainDamage> the most basic sequence you can generate, is, you take a secret, and then hash( secret + counter)
2024-01-03T21:47:02 < ventYl> then, if you try to use the remote, it will be transmitting one symbol from the sequence, then after few repetitions (depending on the protocol / mfg) another, then another, until it wraps
2024-01-03T21:47:04 < Ecco> indeed
2024-01-03T21:47:17 < Ecco> The blinds have a "pairing" mode
2024-01-03T21:47:19 < BrainDamage> each time you increment the counter, you generate the new code
2024-01-03T21:47:31 < ventYl> base station should remember the last symbol it seen and only accept the symbol which comes next in the sequence
2024-01-03T21:47:39 < ventYl> there's a problem though
2024-01-03T21:47:40 < Ecco> ventYl: Except it does not
2024-01-03T21:47:48 < Ecco> in practice, replaying a signal does work
2024-01-03T21:48:03 < ventYl> if you are out of reach of the base station and press the button, transmitter will transmit a symbol and increment symbol pointer
2024-01-03T21:48:05 < Ecco> (I recorded a "blinds up", and "blinds down" signal, and they can effectively be replayed)
2024-01-03T21:48:13 < Ecco> ventYl: Indeed
2024-01-03T21:48:29 < Ecco> so do they just purposedly accept replays?
2024-01-03T21:48:38 < ventYl> if matching on base station was exact, base would reject the next attempt to unlock, becase you would be off-by-one symbol
2024-01-03T21:48:46 < Ecco> Maybe it's a super dumb hash like xor?
2024-01-03T21:49:01 < BrainDamage> that's not a problem, you generally only allow increments forward, not backwards
2024-01-03T21:49:08 < ventYl> for this reason, mathing is usually like expected offset or something up to X positions in advance
2024-01-03T21:49:13 < BrainDamage> so once a code is received, you cross out until it rolls over
2024-01-03T21:49:33 < ventYl> but maybe some implementor got super dumb and implemented the code as "accept any of known symbols"
2024-01-03T21:49:42 < Ecco> hmm, ok
2024-01-03T21:49:50 < Ecco> Or maybe I didn't try and replay it enough times?
2024-01-03T21:49:54 < Ecco> (I did quite a bit though)
2024-01-03T21:50:06 < Ecco> Here's a link of the different values I got when pressing the same button multiple times:
2024-01-03T21:50:07 < BrainDamage> it should refuse it the 2nd time you use it
2024-01-03T21:50:09 < Ecco> https://t.ly/8L9T6
2024-01-03T21:50:18 < Ecco> Is there any chance it's something different?
2024-01-03T21:50:19 < ventYl> I would expect that symbol which was working once wouldn't work some ~15 attempts until it starts working again
2024-01-03T21:50:37 < BrainDamage> if it doesn't, then it's open to replay attacks, which is a super shit system
2024-01-03T21:50:55 < ventYl> well, the problem is that you have one-way channel and you want to be able to re-synchronize
2024-01-03T21:50:55 < Ecco> Well, in practice, it seems to be absolutely open to replay attacks
2024-01-03T21:51:13 < Ecco> Like I said, I recorded the remote once, and then was able to control the blinds a bunch of times
2024-01-03T21:51:33 < Ecco> I mean, it sucks (a mean smart neighbor could fuck with me), but well
2024-01-03T21:51:42 < ventYl> usually the re-synchronization is done in a way, that if symbol transmitted does not match the symbol expected, base is listening for the symbol stream
2024-01-03T21:52:09 < Ecco> What I don't understand then is why would the remote keep spitting out different values then
2024-01-03T21:52:19 < BrainDamage> if you get a correct sequence of n signalls, you roll forward until you sync
2024-01-03T21:52:27 < ventYl> user keeps the button pressed, because nothing happens, FOB transmits a few symbols from the sequence, base compares them to sequence obtained during pairing and if run of length X matches, if will reset the offset pointer
2024-01-03T21:52:43 < Ecco> ok
2024-01-03T21:52:48 < Ecco> I mean, all this makes sense
2024-01-03T21:53:15 < ventYl> if you can successfully reproduce replay attack for each and every attempt you try, then the base is simply exceptionally shitty
2024-01-03T21:53:18 < Ecco> but wouldn't the fact that I was able to record and successfully replay one signal sort of rule out the fact that it's a floating codes system?
2024-01-03T21:53:24 < Ecco> ok :-D
2024-01-03T21:53:36 < BrainDamage> yes, single signal should not be replayable
2024-01-03T21:53:42 < ventYl> it is a poor implementation of floating code
2024-01-03T21:53:43 < Ecco> Or, alternatively, maybe it's not a floating code system?
2024-01-03T21:53:47 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-03T21:54:05 < ventYl> floating code systems are so old that I expect nobody is manufacturing anything else anymore
2024-01-03T21:54:19 < Ecco> There's this guy who wrote a blog post about something super similar: https://nickwhyte.com/post/2017/reversing-433mhz-raex-motorised-rf-blinds/
2024-01-03T21:54:26 < BrainDamage> it's possible the remote isn't a rolling code, but it's instead a sort of universal remote that spews signals for different models
2024-01-03T21:54:41 < ventYl> if you make the effort to transmit digits, then the effort to add floating code is trivial
2024-01-03T21:54:44 < Ecco> In his case it's definitely not a floating code system
2024-01-03T21:55:21 < ventYl> Ecco: do all the symbols it transmits work with your base?
2024-01-03T21:55:47 < Ecco> This I don't know
2024-01-03T21:55:59 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-03T21:56:11 < Ecco> I guess as an alternative I could try and dump the remote's firmware
2024-01-03T21:56:12 < Ecco> but well
2024-01-03T21:56:43 < ventYl> can't you simply do a long recording of what it transmits and then try to replay it everything?
2024-01-03T21:56:44 < Ecco> (it's a chinese Cortex M0 and there's a SWD header on the PCB)
2024-01-03T21:57:02 < Ecco> ventYl: the problem is that I don't have an RF emitter that I fully control
2024-01-03T21:57:14 < Ecco> I have this all-in-one "smart home" RF bridge
2024-01-03T21:57:23 < Ecco> where you record the remote and then it replays what it got
2024-01-03T21:57:31 < Ecco> now, *maybe* the bridge is super-duper-smart
2024-01-03T21:57:31 < ventYl> ah, ok
2024-01-03T21:57:40 < Ecco> and figured out the floating code system?
2024-01-03T21:57:47 < Ecco> So I *think* it only does a dumb replay
2024-01-03T21:57:54 < Ecco> but in fact it has figured out the whole thing?
2024-01-03T21:58:04 < ventYl> can't you record what this bridge transmits?
2024-01-03T21:58:12 < Ecco> ventYl: dang, that's smart
2024-01-03T21:58:16 < Ecco> absolutely
2024-01-03T21:58:37 < Ecco> but given it really only has recorded one keypress
2024-01-03T21:58:45 < Ecco> I mean, it really most likely just replays it
2024-01-03T21:58:53 < ventYl> how long that keypress was?
2024-01-03T21:59:13 < ventYl> pairing with my garage door base station took some three seconds?
2024-01-03T21:59:14 < Ecco> oh, well, the remote keeps transmitting for maybe 1 sec
2024-01-03T21:59:31 < Ecco> (oh, I have to go. I'll be back in a bit, sorry)
2024-01-03T21:59:37 < Ecco> (thanks for the cool pointers tho)
2024-01-03T22:01:40 < ventYl> karlp: that license is super awkward. how can you use the stuff then? is it "developer" license mandating you to buy production licenses for production devices?
2024-01-03T22:02:56 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-03T22:13:18 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-03T22:24:26 -!- machinehum [~machinehu@213.55.220.212] has quit [Ping timeout: 252 seconds]
2024-01-03T22:26:03 -!- machinehum [~machinehu@213.55.224.60] has joined ##stm32
2024-01-03T22:29:34 -!- HelloShitty [~psysc0rpi@bl21-251-151.dsl.telepac.pt] has quit [Ping timeout: 246 seconds]
2024-01-03T22:55:02 < Ecco> back
2024-01-03T22:55:09 < Ecco> So, I've been looking at rolling code implementations
2024-01-03T22:55:17 < Ecco> and often the payload itself is not encrypted
2024-01-03T22:56:08 < Ecco> But in my case there's not a single bit that remains constant
2024-01-03T22:56:16 < Ecco> I wonder if I'm decoding the bits properly
2024-01-03T23:03:20 < ventYl> the floating code itself is a form of hungry programmer's encryption
2024-01-03T23:03:35 < ventYl> as the channel is simplex, so that base station can't talk to FOB
2024-01-03T23:14:46 -!- machinehum [~machinehu@213.55.224.60] has quit [Ping timeout: 260 seconds]
2024-01-03T23:52:20 -!- machinehum [~machinehu@213.55.224.60] has joined ##stm32
2024-01-03T23:56:29 -!- machinehum [~machinehu@213.55.224.60] has quit [Ping timeout: 240 seconds]
--- Day changed to tammi 04 2024
2024-01-04T00:13:52 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 246 seconds]
2024-01-04T00:42:48 -!- machinehum [~machinehu@213.55.224.60] has joined ##stm32
2024-01-04T00:47:03 -!- machinehum [~machinehu@213.55.224.60] has quit [Ping timeout: 260 seconds]
2024-01-04T00:48:17 -!- HelloShitty [~psysc0rpi@bl21-251-151.dsl.telepac.pt] has joined ##stm32
2024-01-04T01:06:39 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-4c04-920f-f566-cc9d.fixed6.kpn.net] has quit [Ping timeout: 260 seconds]
2024-01-04T01:27:58 -!- machinehum [~machinehu@213.55.224.60] has joined ##stm32
2024-01-04T01:32:24 -!- machinehum [~machinehu@213.55.224.60] has quit [Ping timeout: 256 seconds]
2024-01-04T01:37:08 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-04T01:51:10 < qyx> We have PCB assemblies built that contain STM324L7 with 1M and 2M flash memory
2024-01-04T01:51:13 < qyx> what the hell are they
2024-01-04T01:52:17 < qyx> @CWedg.1​  I am facing the same issue here. I have 2 STM32L4 with 128MByte and 256MByte flash size respectively
2024-01-04T01:52:20 < qyx> those too
2024-01-04T01:53:04 < qyx> I should browse ST's marketing materials again, I seem to have missed a lot of things
2024-01-04T02:01:36 < Steffanx> Lol wut qyx?
2024-01-04T02:11:53 < qyx> reading ST forums
2024-01-04T02:13:46 < qyx> so to stay on topic, there is apparently no sane way to determine sector sizes
2024-01-04T02:13:55 < qyx> of the internal flash
2024-01-04T02:14:49 -!- machinehum [~machinehu@213.55.224.60] has joined ##stm32
2024-01-04T02:19:10 -!- machinehum [~machinehu@213.55.224.60] has quit [Ping timeout: 264 seconds]
2024-01-04T02:20:33 < qyx> another interesting thing is STM32G491 is category 3 device and according to RM it can only have 512K of flash
2024-01-04T02:21:51 < qyx> ok it is "up to", openocd says 256K and the FLASH_SIZE register too
2024-01-04T02:33:22 < Steffanx> KE is 512K right?
2024-01-04T02:33:52 < Steffanx> More like *E
2024-01-04T02:34:52 < Steffanx> Oh nevermind that's what you said
2024-01-04T02:35:36 < qyx> I have 491CCU6
2024-01-04T02:35:46 < qyx> so CEU6 is 512K
2024-01-04T02:36:19 < qyx> also, I hate ECC, no 1->0 bit flips
2024-01-04T02:38:47 < jbo> you hate ECC?
2024-01-04T02:38:55 < jbo> like generally or something specific about the ST implementation?
2024-01-04T02:39:54 < qyx> on stm32 families implementing ECC on the internal flash memory you cannot flip individual bits from 1 to 0
2024-01-04T02:39:58 < qyx> like in "normal" flash
2024-01-04T02:40:26 < qyx> which makes flash filesystems sad
2024-01-04T02:40:53 < jbo> it that only 1->0 or also 0->1 ?
2024-01-04T02:41:19 < qyx> for non-ecc you can 1->0 and can't 0->1
2024-01-04T02:41:23 < qyx> for ECC you can neither
2024-01-04T03:03:55 -!- machinehum [~machinehu@213.55.224.60] has joined ##stm32
2024-01-04T03:08:37 -!- machinehum [~machinehu@213.55.224.60] has quit [Ping timeout: 260 seconds]
2024-01-04T03:37:03 < jbo> aye
2024-01-04T03:39:05 < zyp> in theory you somewhat can, as long as the new ecc also only needs to do 1->0
2024-01-04T03:39:22 < zyp> assuming the controller doesn't just disallow any writes to an already written line
2024-01-04T03:41:28 < qyx> they explicitly say you can only write full zeros to a partially written doubleword
2024-01-04T03:41:43 < qyx> so I assume ecc of full zeros are zeros
2024-01-04T03:54:28 -!- machinehum [~machinehu@213.55.224.60] has joined ##stm32
2024-01-04T03:58:49 -!- machinehum [~machinehu@213.55.224.60] has quit [Ping timeout: 255 seconds]
2024-01-04T04:09:44 < fenugrec> you could encode 1 bit per byte, as all-0 or all-1
2024-01-04T04:09:48 < fenugrec> such efficiency
2024-01-04T04:24:45 -!- blathijs [~matthijs@tika.stderr.nl] has quit [Ping timeout: 256 seconds]
2024-01-04T04:25:36 -!- blathijs_ [~matthijs@tika.stderr.nl] has joined ##stm32
2024-01-04T04:33:50 < qyx> ok anyone got G4 flash writing working?
2024-01-04T04:34:16 < qyx> it hardfaults and I am not even able to dig out the reason and the exact location, I am probably just dumb
2024-01-04T04:38:54 < qyx> aha it faults here https://github.com/libopencm3/libopencm3/blob/master/lib/stm32/g4/flash.c#L152
2024-01-04T04:38:57 < qyx> when callit the function
2024-01-04T04:39:12 < qyx> if I call it directly, it programs the doubleword correctly
2024-01-04T04:40:01 < qyx> len and data is properly 8-byte aligned
2024-01-04T04:41:45 < qyx> uint64_t is the problem, if I dumbfully change it do uint32_t, it works
2024-01-04T04:44:52 -!- machinehum [~machinehu@213.55.224.60] has joined ##stm32
2024-01-04T04:49:43 < qyx> the first uint64_t hardfault related issue is https://github.com/nanopb/nanopb/issues/663
2024-01-04T04:49:46 -!- machinehum [~machinehu@213.55.224.60] has quit [Ping timeout: 276 seconds]
2024-01-04T05:20:18 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-04T05:33:14 -!- machinehum [~machinehu@213.55.224.60] has joined ##stm32
2024-01-04T05:36:49 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:a8e7:e681:2bc8:b483] has quit [Ping timeout: 268 seconds]
2024-01-04T05:37:26 -!- machinehum [~machinehu@213.55.224.60] has quit [Ping timeout: 245 seconds]
2024-01-04T05:54:36 -!- boB_K7IQ [~boB_K7IQ@184-98-64-136.phnx.qwest.net] has joined ##stm32
2024-01-04T05:54:36 -!- boB_K7IQ [~boB_K7IQ@184-98-64-136.phnx.qwest.net] has quit [Excess Flood]
2024-01-04T05:54:58 -!- boB_K7IQ [~boB_K7IQ@184-98-64-136.phnx.qwest.net] has joined ##stm32
2024-01-04T06:25:01 -!- machinehum [~machinehu@213.55.224.60] has joined ##stm32
2024-01-04T06:29:35 -!- machinehum [~machinehu@213.55.224.60] has quit [Ping timeout: 260 seconds]
2024-01-04T06:32:44 -!- haritz [~hrtz@user/haritz] has quit [Read error: Connection reset by peer]
2024-01-04T06:42:27 -!- haritz [~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220] has joined ##stm32
2024-01-04T06:42:29 -!- haritz [~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220] has quit [Changing host]
2024-01-04T06:42:29 -!- haritz [~hrtz@user/haritz] has joined ##stm32
2024-01-04T07:14:05 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 252 seconds]
2024-01-04T07:15:01 -!- machinehum [~machinehu@213.55.224.60] has joined ##stm32
2024-01-04T07:15:04 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-04T07:19:31 -!- machinehum [~machinehu@213.55.224.60] has quit [Ping timeout: 260 seconds]
2024-01-04T07:31:11 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-04T08:07:02 -!- machinehum [~machinehu@213.55.224.60] has joined ##stm32
2024-01-04T08:11:11 -!- machinehum [~machinehu@213.55.224.60] has quit [Ping timeout: 245 seconds]
2024-01-04T08:22:20 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
2024-01-04T08:55:47 -!- machinehum [~machinehu@213.55.224.60] has joined ##stm32
2024-01-04T08:59:30 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-04T09:00:38 -!- machinehum [~machinehu@213.55.224.60] has quit [Ping timeout: 268 seconds]
2024-01-04T09:31:03 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-494c-41f5-2f3d-2fdb.fixed6.kpn.net] has joined ##stm32
2024-01-04T09:33:06 -!- machinehum [~machinehu@213.55.224.60] has joined ##stm32
2024-01-04T09:37:26 -!- machinehum [~machinehu@213.55.224.60] has quit [Ping timeout: 245 seconds]
2024-01-04T10:22:20 -!- machinehum [~machinehu@213.55.224.60] has joined ##stm32
2024-01-04T10:27:07 -!- machinehum [~machinehu@213.55.224.60] has quit [Ping timeout: 276 seconds]
2024-01-04T10:47:32 -!- machinehum [~machinehu@213.55.224.60] has joined ##stm32
2024-01-04T10:59:02 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 252 seconds]
2024-01-04T11:17:03 -!- samkent [~samkent@2a02:6b66:e03e:0:7d2a:e0b7:71f0:1cf7] has joined ##stm32
2024-01-04T11:35:24 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:33e2:f4e3:7dc8:bb0c] has joined ##stm32
2024-01-04T11:58:48 < karlp> lol. all the espressif example webserver code tears down the webserver on link loss, and turns it on again _when it gets an IP_
2024-01-04T11:59:25 < karlp> but if do a cable pull, then put it back in again, it doesn't get a new ip, or refresh it's dhcp lease or static, so no new event, so it just stays off.
2024-01-04T12:28:41 < Steffanx> Lol. :)
2024-01-04T12:30:48 < karlp> I wonder if this is an ethernet thing, and wifi ~always gets a new ip. and there's such a small set of esp32 ethernet boards that it just never comes up...
2024-01-04T12:32:28 < ventYl> does it register cable pull event?
2024-01-04T12:34:52 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-04T12:38:15 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 245 seconds]
2024-01-04T12:40:35 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-494c-41f5-2f3d-2fdb.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-04T12:52:26 < karlp> yeah, that works fine.
2024-01-04T12:52:46 < karlp> I'd been testing that handling earlier with ping, hadn't noticed that the webserver had been torn down and wasn't restarting.
2024-01-04T12:58:12 -!- HelloShi1ty [~user@bl15-39-23.dsl.telepac.pt] has joined ##stm32
2024-01-04T13:20:09 -!- HelloShi1ty [~user@bl15-39-23.dsl.telepac.pt] has quit [Quit: leaving]
2024-01-04T13:20:43 -!- HelloShi1ty [~user@bl15-39-23.dsl.telepac.pt] has joined ##stm32
2024-01-04T13:22:11 -!- samkent [~samkent@2a02:6b66:e03e:0:7d2a:e0b7:71f0:1cf7] has quit [Remote host closed the connection]
2024-01-04T13:22:34 -!- samkent [~samkent@2a02:6b66:e03e:0:7d2a:e0b7:71f0:1cf7] has joined ##stm32
2024-01-04T13:38:35 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-494c-41f5-2f3d-2fdb.fixed6.kpn.net] has joined ##stm32
2024-01-04T13:42:55 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-494c-41f5-2f3d-2fdb.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-04T13:43:14 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-8d44-cf10-e05-5bbc.fixed6.kpn.net] has joined ##stm32
2024-01-04T13:55:57 -!- machinehum [~machinehu@213.55.224.60] has quit [Ping timeout: 256 seconds]
2024-01-04T13:59:39 -!- machinehum [~machinehu@213.55.224.60] has joined ##stm32
2024-01-04T14:01:04 -!- quinor [08c0f10716@2604:bf00:561:2000::dad] has quit [Read error: Connection reset by peer]
2024-01-04T14:01:21 -!- quinor [08c0f10716@2604:bf00:561:2000::dad] has joined ##stm32
2024-01-04T14:03:53 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-8d44-cf10-e05-5bbc.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-04T14:12:34 -!- HelloShi1ty [~user@bl15-39-23.dsl.telepac.pt] has quit [Quit: leaving]
2024-01-04T14:19:00 -!- HelloShi1ty [~user@bl15-39-23.dsl.telepac.pt] has joined ##stm32
2024-01-04T14:35:18 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-04T15:01:31 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-04T15:16:15 -!- alan_o [~alan_o@2600:1700:1902:210f:9df7:3cfd:eff4:4cfd] has quit [Remote host closed the connection]
2024-01-04T15:42:20 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-04T15:53:57 -!- machinehum [~machinehu@213.55.224.60] has quit [Ping timeout: 260 seconds]
2024-01-04T16:01:19 -!- machinehum [~machinehu@213.55.224.60] has joined ##stm32
2024-01-04T16:01:49 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-04T16:11:58 -!- HelloShi1ty [~user@bl15-39-23.dsl.telepac.pt] has quit [Quit: leaving]
2024-01-04T16:17:05 -!- alan_o [~alan_o@2600:1700:1902:210f:a557:fbdf:2187:dc34] has joined ##stm32
2024-01-04T16:30:30 -!- iamzim [~iamzim@c-174-162-220-48.hsd1.ut.comcast.net] has joined ##stm32
2024-01-04T16:31:44 -!- samkent [~samkent@2a02:6b66:e03e:0:7d2a:e0b7:71f0:1cf7] has quit [Remote host closed the connection]
2024-01-04T16:45:33 -!- iamzim [~iamzim@c-174-162-220-48.hsd1.ut.comcast.net] has left ##stm32 []
2024-01-04T16:48:42 -!- machinehum [~machinehu@213.55.224.60] has quit [Ping timeout: 256 seconds]
2024-01-04T17:09:37 < nomorekaki> is there f function for looking for certain string in a file?
2024-01-04T17:10:11 < fenugrec> what like grep
2024-01-04T17:12:00 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-04T17:13:17 < ventYl> nomorekaki: grep, or if file is actually binary, you can use "strings" to extract all the string and then grep them
2024-01-04T17:14:32 < nomorekaki> f__ function in C
2024-01-04T17:16:29 < nomorekaki> I want file position to be placed after string ie. "DATA:"
2024-01-04T17:16:36 < ventYl> no
2024-01-04T17:16:43 < nomorekaki> just asking if there is easy way
2024-01-04T17:17:11 < ventYl> implementing it yourself is the easy way
2024-01-04T17:17:51 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has joined ##stm32
2024-01-04T17:23:46 < karlp> mmap strstr....
2024-01-04T17:24:50 < karlp> well, memmem probably, soyou don't have to worry about \0s...
2024-01-04T17:25:12 < karlp> but that's not posix.
2024-01-04T17:27:41 < qyx> yeah mmap string match works even in python for large files
2024-01-04T17:27:46 < qyx> did that once
2024-01-04T17:38:53 < nomorekaki> is it possible to fscan without buffer is the rest of the line is not needed?
2024-01-04T17:40:19 < nomorekaki> plan is to fscanf with limited width equal to "DATA:" and see if it does match
2024-01-04T17:40:39 < nomorekaki> if doesn't fscanf all the way to newline
2024-01-04T17:40:44 < nomorekaki> then do it again
2024-01-04T17:43:43 -!- ferdna_ [~ferdna@user/ferdna] has joined ##stm32
2024-01-04T17:45:17 < qyx> do you even need to consider newlines?
2024-01-04T17:45:41 < qyx> and I would say scanf is super slow
2024-01-04T17:46:13 < qyx> python has mmap.find for that, maybe there is something similar in C
2024-01-04T17:46:17 -!- ferdna_ [~ferdna@user/ferdna] has quit [Remote host closed the connection]
2024-01-04T17:46:20 -!- ferdna [~ferdna@user/ferdna] has quit [Ping timeout: 268 seconds]
2024-01-04T17:47:21 < qyx> oh yeah memmem what karl mentioned
2024-01-04T17:48:16 -!- benishor [~benishor@scene.ro] has quit [Quit: tah tah!]
2024-01-04T17:49:50 < karlp> heh. "why can't I set the clock?" find bugs in string parsing, fix those, still doesn't work... https://paste.jvnv.net/view/aLGrP
2024-01-04T17:50:32 -!- benishor [~benishor@scene.ro] has joined ##stm32
2024-01-04T18:14:12 < qyx> what are you using to convert time_t to to rtc registers?
2024-01-04T18:14:40 < qyx> I was dealing with that yesterday, newlib's functions are huge
2024-01-04T18:16:15 < karlp> I'm not sure, I'm currently trying to work out why there's a file called "gmtime_r_fixed" that says "newlib's gmtime_r has locking bugs..."
2024-01-04T18:16:23 < karlp> which... I find deeply suspicious
2024-01-04T18:17:03 < karlp> the code in this "fixed" one appears to be a ripoff of some bsd code like this: https://github.com/LK8000/LK8000/blob/3d5b33491be830abb423b0ef543e3d4b484fd165/Common/Header/mingw32compat/gmtime_r.h#L76 which comes from a claim that gmtime is not safe, and to use gmtime_r...
2024-01-04T18:17:18 < karlp> but. this "fixed" shit is in a massive blob commit, so no idea what was really going on.
2024-01-04T18:17:30 < karlp> I'll probably just use newlib, we've got mountains of flash ehre.
2024-01-04T18:18:10 < qyx> but that's in the order of 10K
2024-01-04T18:18:23 < karlp> I'm pretty sure it's already pulled in.
2024-01-04T18:18:24 < qyx> and I don't even need TZ
2024-01-04T18:19:02 < karlp> firmware is 370k or somethign right now. not going to get upset about 10k here or there...
2024-01-04T18:19:42 < qyx> ok what, so this gmtime_r doesn't even consider leap seconds?
2024-01-04T18:20:06 < qyx> I had the impression it should
2024-01-04T18:20:35 < karlp> lol
2024-01-04T18:20:56 < qyx> as it is an approximation of UTC and UTC has leap seconds, so your diff computations are going to be wrong
2024-01-04T18:21:17 < karlp> only if I have hardware doing leapseconds...
2024-01-04T18:21:32 < qyx> also te computation between 1970-72 and the to 74 or so was a bit different
2024-01-04T18:21:46 < karlp> apparently gmtime can return 0..61 for the seconds field?
2024-01-04T18:22:08 < qyx> I feel fooled now
2024-01-04T18:22:38 < karlp> bu.. apparently that will never get filled in, because posix defines it as time since epoch without leap seconds?
2024-01-04T18:22:43 < karlp> fuck I hate time sometimes.
2024-01-04T18:23:01 < fenugrec> there's a great computerphile(?) vid about that
2024-01-04T18:23:45 < qyx> but that's *wrong*
2024-01-04T18:24:04 < karlp> it can be as wrong as it wants.
2024-01-04T18:24:07 < fenugrec> the takeaway was "you don't want to implement non-trivial time functions"
2024-01-04T18:24:11 < qyx> fuk such life
2024-01-04T18:24:31 < fenugrec> https://www.youtube.com/watch?v=-5wpm-gesOY
2024-01-04T18:24:32 < karlp> when's the next leap second anyway?
2024-01-04T18:24:39 < qyx> every year or so
2024-01-04T18:24:41 < karlp> I'm 99% sure I don't actually care.
2024-01-04T18:24:55 < karlp> apparently windows just ignores them and lets ntp update the clock when they happen...
2024-01-04T18:24:58 < karlp> sounds good to me...
2024-01-04T18:25:49 < qyx> In 2021, it was reported that Earth was spinning faster in 2020 and experienced the 28 shortest days since 1960, each of which lasted less than 86399.999 seconds.[29] This caused engineers worldwide to discuss a negative leap second and other possible timekeeping measures, some of which could eliminate leap seconds.[30] 
2024-01-04T18:26:18 < karlp> lol
2024-01-04T18:26:18 < qyx> I think I just decided too
2024-01-04T18:30:23 < qyx> but it is still somewhat important to convert the same as the host computer if you are using timestamps to carry time information
2024-01-04T18:30:35 < qyx> otherwise there is that 37 second shift
2024-01-04T18:30:44 < ventYl> it depends on your goals and needed timekeeping accuracy
2024-01-04T18:30:56 < ventYl> if you have some constant intervals, then you don't care about leap whatever
2024-01-04T18:31:56 < qyx> for the purpose of daq you definitely need to care
2024-01-04T18:32:27 < qyx> your RTCs are gonna tick the same, but as soon as you transfer the information using timestamps and both sides compute it differently, you introduce an offset in your measurement
2024-01-04T18:32:50 < karlp> "revert to older gmtime, rtc_gmtime_r in core/rtc.c due to posix freeze"
2024-01-04T18:32:55 < karlp> wtf are people smoking here...
2024-01-04T18:33:20 < qyx> is it even thread safe?
2024-01-04T18:37:46 < qyx> ok, so NTP is UTC based, PTP is TAI based
2024-01-04T18:38:29 < qyx> GPS is TAI too
2024-01-04T18:38:44 < qyx> it looks like UTC is a bad idea as a whole
2024-01-04T18:39:01 < qyx> except there are legal considerations mandating use of UTC
2024-01-04T18:39:20 < ventYl> qyx: can't you simply timestamp it using format, which is immune to irregularities such as DST and leap seconds?
2024-01-04T18:40:01 < karlp> TAI is what, UTC-leapseconds?
2024-01-04T18:40:47 < qyx> basically
2024-01-04T18:41:31 < qyx> idk if TAI considers leap years
2024-01-04T18:42:57 < qyx> unlike the United States's global navigation satellite system, GPS, which does not adjust its time with leap seconds, Russia's system, GLONASS, does adjust its time with leap seconds
2024-01-04T18:43:00 < nomorekaki> was there something like s_strcmp
2024-01-04T18:43:01 < qyx> lol
2024-01-04T18:43:17 < qyx> time is hard
2024-01-04T18:43:25 < fenugrec> ^
2024-01-04T18:43:48 < qyx> and we are still living on a single planet and not considering other anomalies
2024-01-04T18:51:36 < nomorekaki> strncmp yes
2024-01-04T18:52:19 -!- machinehum [~machinehu@213.55.224.60] has joined ##stm32
2024-01-04T18:56:05 -!- _nuxil_ is now known as nuxil
2024-01-04T18:56:10 < karlp> heh, bsd has a build option to have gmtime be posix or not, ie, with or without leapseconds.
2024-01-04T19:03:23 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-78da-da31-bff2-7dce.fixed6.kpn.net] has joined ##stm32
2024-01-04T19:13:17 < qyx> it is a damned deep rabbit hole
2024-01-04T19:13:27 < qyx> I just lost more than an hour
2024-01-04T19:14:49 < qyx> ..First of all, lets be totally clear from the start: leap seconds are a
2024-01-04T19:14:50 < qyx> *user interface* issue..
2024-01-04T19:15:16 < qyx> .. And (do I have to say it?), user interface crap doesn't belong in operating system kernels
2024-01-04T19:17:36 < qyx> so yes, to me it looks like RTC should be a monotonic simple second counter, nothing more
2024-01-04T19:18:06 < qyx> no calendar, no DST shit, no leap seconds or whatever
2024-01-04T19:25:40 < BrainDamage> TAI is the monotonic one, without leap seconds
2024-01-04T19:25:45 < BrainDamage> UTC has leap seconds
2024-01-04T19:26:08 < BrainDamage> RTC should ideally be in tune with TAI, and then leap seconds added on top
2024-01-04T19:27:50 < qyx> yeah
2024-01-04T19:28:42 < qyx> but that's probably not the case, linux used to set RTC to UTC, windows to local time (that changed?)
2024-01-04T19:29:56 < BrainDamage> linux indeed sets RTC to UTC
2024-01-04T19:30:00 < BrainDamage> and windows sets to localtime
2024-01-04T19:30:14 < BrainDamage> there's a "secret" registry key to make windows use RTC in UTC
2024-01-04T19:30:28 < BrainDamage> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal
2024-01-04T19:32:57 < qyx> unrelated, another similar ambiguity is harmonised cable marking and eg. "2G0.75", which is invalid in TN-S
2024-01-04T19:33:38 < qyx> this world is simply not pedantic enough
2024-01-04T19:34:07 < qyx> I am just looking at a H05VV-F 2G0.75 with blue and brown conductors
2024-01-04T19:34:43 < ventYl> BrainDamage: in linux, there is actually an option. for example slackware lets you select this.
2024-01-04T19:34:58 < BrainDamage> the option is to set the RTC in localtime, not TAI
2024-01-04T19:35:26 < BrainDamage> fedora and a few other distros will automatically set the RTC in localtime if a windows installation is detected, to avoid user annoyances
2024-01-04T19:39:44 < qyx> another valid question is what should we save in time series databases
2024-01-04T19:40:15 < qyx> saving local time is out of question because of DST and the resulting problems with computations
2024-01-04T19:40:28 < qyx> but the same applies to UTC when leap second occurs
2024-01-04T19:41:33 < ventYl> timestamp-ish value
2024-01-04T19:41:38 < qyx> I just came across several incidents of large infrastructure providers caused by the last leap second (cloudflare, etc.)
2024-01-04T19:42:28 < ventYl> yet even with it you cannot avoid glitches entirely
2024-01-04T19:53:16 -!- machinehum [~machinehu@213.55.224.60] has quit [Ping timeout: 276 seconds]
2024-01-04T19:59:41 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 252 seconds]
2024-01-04T20:05:19 -!- machinehum [~machinehu@213.55.224.60] has joined ##stm32
2024-01-04T20:17:42 < nomorekaki> how to tell if real innovating or advanced cargoculting? #deep32
2024-01-04T20:18:15 < nomorekaki> https://www.youtube.com/watch?v=uKRIH-b8Xcg musiks
2024-01-04T20:19:10 -!- machinehum [~machinehu@213.55.224.60] has quit [Ping timeout: 264 seconds]
2024-01-04T20:22:15 -!- machinehum [~machinehu@213.55.224.60] has joined ##stm32
2024-01-04T20:57:06 < nuxil> <qyx> time is hard  .. add in some space to it and it will be bendy :P
2024-01-04T21:08:27 < nuxil> "another valid question is what should we save in time series databases".
2024-01-04T21:08:41 < nuxil> imo you save as a unsigned int to the database. either unix epoc, MS Windows time, Apple time or, gps time.  cos its faster to store and fetch than a stored string and make the user interface code do the conversion for X time epoc to whatever is wanted.. 
2024-01-04T21:14:38 < ventYl> well, if you convert whatever value that undergoes any kind of transformation into timestamp-ish value, you solve nothing
2024-01-04T21:15:39 < ventYl> take DST as example. convert non-DST time just 1 second before DST switch happens to int value. then convert DST time just 1 second after DST switch happens to int value. Their diff most probably won't be 2, as you'd expect.
2024-01-04T21:15:45 < nuxil> well. is the database is a remote database. if want as fast access to it as possible. example a unix epoc is way less data than a stored string with time and date..
2024-01-04T21:15:50 < nuxil> *is if.
2024-01-04T21:17:17 < ventYl> speed is not a point here
2024-01-04T21:17:22 < nomorekaki> reverse stepping would be nice
2024-01-04T21:18:33 < nuxil> i havent messed around with DST time. i mostly been dealing with unix epoc and windows time. all i can say is. dealing with time is a bit annoying with all the different time standards around. 
2024-01-04T21:19:21 < nuxil> nomorekaki, what do you mean ?
2024-01-04T21:19:36 < nomorekaki> in debugging session
2024-01-04T21:19:43 < nuxil> ah. 
2024-01-04T21:19:55 < nomorekaki> it's possible with emulator going in reverse
2024-01-04T21:21:00 < BrainDamage> for desktop programs: https://rr-project.org/
2024-01-04T21:21:57 < ventYl> gdb has reverse stepping; I wonder where does it actually work
2024-01-04T21:22:16 < nuxil> "replacing — well, enhancing — gdb. "
2024-01-04T21:22:23 < nuxil> thatsd a bold claim
2024-01-04T21:24:26 < nuxil> all you need is printf for your debugging :P
2024-01-04T21:27:12 < nomorekaki> for sure
2024-01-04T21:33:16 < fenugrec> I've tried rr a few times and never got good results
2024-01-04T21:35:29 < fenugrec> either refused to run/segfaulted, or problem didn't reproduce when run with rr
2024-01-04T21:35:53 < fenugrec> still, a commendable effort and someday I'll try it again and it'll work
2024-01-04T21:43:49 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-04T22:04:22 < qyx> nuxil: of course timestamp, but the question here is which one, because it matters
2024-01-04T22:05:48 < qyx> and even unix timestamp may be computed in multiple ways (it is utc but posix mandates ignoring leap seconds despite that)
2024-01-04T22:06:18 < qyx> and if the timestamp is converted back on the client side,do you know which algo was used to compute it?
2024-01-04T22:06:43 < qyx> the database says "oh utc, always utc"
2024-01-04T22:06:47 < nuxil> thats a choice for the dev. to consider the pros and cons for each one. use case etc and just pick the best once for the application. 
2024-01-04T22:07:15 < nuxil> *once-> one
2024-01-04T22:07:48 < qyx> but in realityit was saved with something like now()
2024-01-04T22:08:04 < qyx> which grabbed the underlying timestamp
2024-01-04T22:08:34 < qyx> so what, is it really utc? or some unix-ish posix-ish supplement
2024-01-04T22:08:44 < qyx> time is hard.
2024-01-04T22:09:10 < nuxil> its more an annoyance than hard
2024-01-04T22:20:27 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-04T22:23:47 -!- machinehum [~machinehu@213.55.224.60] has quit [Ping timeout: 252 seconds]
2024-01-04T22:35:19 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-04T22:35:47 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-04T22:39:58 -!- machinehum [~machinehu@213.55.224.133] has joined ##stm32
2024-01-04T22:46:55 -!- machinehum [~machinehu@213.55.224.133] has quit [Ping timeout: 256 seconds]
2024-01-04T22:54:02 -!- qyx [~qyx@84.245.120.242] has quit [Ping timeout: 252 seconds]
2024-01-04T22:56:08 -!- qyx [~qyx@84.245.121.92] has joined ##stm32
2024-01-04T23:00:17 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-04T23:00:25 < Laurenceb_> tfw I'm on the right https://nitter.net/pic/media%2FGC_48eNWgAA9raj.jpg%3Fname%3Dsmall%26format%3Dwebp
2024-01-04T23:04:55 < nomorekaki> nice watch
2024-01-04T23:06:30 < nomorekaki> i have 3bit and 8bit bitfields
2024-01-04T23:06:49 < nomorekaki> when I access them the bits are wrong way around
2024-01-04T23:10:31 < nomorekaki> I guess I need to refactor all the way from transceiver code to bitpos--; instead of bitpos++; ?
2024-01-04T23:11:30 < nomorekaki> the bits are going to be wrong way regardless of the endianess of the machine right?
2024-01-04T23:11:33 < ventYl> is it a regular C bitfield, or are you just manipulating individual bits?
2024-01-04T23:12:34 < ventYl> oh, transciever. so your bits are being transmitted LSB to MSB and you are writing them MSB to LSB? or other way around?
2024-01-04T23:12:51 < nomorekaki>         context->frame_buffer[context->rxtx_framebuf_pos].frame.value = frame.value | ( (uint32_t)1 << ( context->frame_buffer[context->rxtx_framebuf_pos].frame_bitcount ) );
2024-01-04T23:13:18 < nomorekaki> and bit_count++;
2024-01-04T23:14:03 < nomorekaki> .frame is union of .value and .fields
2024-01-04T23:16:32 < nomorekaki> let's see in the bus msb comes first
2024-01-04T23:17:19 < nomorekaki> and it's written to lsb of the field
2024-01-04T23:17:48 < fenugrec> C doesn't guarantee ordering of bitfields. https://stackoverflow.com/questions/1490092/c-c-force-bit-field-order-and-alignment
2024-01-04T23:19:46 < nomorekaki> single bit flags at least are at right place
2024-01-04T23:21:26 < nomorekaki> r/w, parity, ack
2024-01-04T23:22:54 < qyx> fenugrec: a that makes me a sad panda again, because I am using a struct full of bitfields to communicate between app and a bootloader
2024-01-04T23:23:12 < qyx> which are compiled independently and I have not failed yet
2024-01-04T23:23:58 < qyx> which reminds me there was some vendor MCU code accessing registers as bitfields
2024-01-04T23:24:55 < nomorekaki> with MCU it's unlikelly for the platform to change
2024-01-04T23:25:00 < zyp> bitfields are endianness-dependant
2024-01-04T23:25:35 < nuxil> ^^
2024-01-04T23:25:35 < zyp> building the same code for the same platform should result in the same layout, is only an issue for portable code
2024-01-04T23:26:30 < nomorekaki> zyp: my union between uint32_t and fields can result in worse things than single bitfield having reversed order?
2024-01-04T23:27:01 < nomorekaki> *all larger than 1 bitfields
2024-01-04T23:27:10 < qyx> zyp: the citations say it is not defined
2024-01-04T23:27:20 < qyx> from the c standards
2024-01-04T23:27:23 < zyp> sure
2024-01-04T23:29:50 < nomorekaki> how do you handle receiving and accessing different individual bits or ranges in buffer?
2024-01-04T23:29:59 < nomorekaki> *while keeping code portable
2024-01-04T23:30:58 < ventYl> by masking
2024-01-04T23:31:49 < nomorekaki> but bitfields are nice
2024-01-04T23:32:17 < ventYl> there's also this concept of "network byte order"
2024-01-04T23:32:34 < zyp> network byte order is just an euphemism for big endian
2024-01-04T23:32:41 -!- machinehum [~machinehu@213.55.224.133] has joined ##stm32
2024-01-04T23:32:46 < ventYl> it is defined, but that does not matter much. the point is to actually define it and then convert to/from at every node
2024-01-04T23:33:18 < ventYl> zyp: generally yes, but no. application specific network byte orders might be little endian, if major application deployment occurred at Intel
2024-01-04T23:33:34 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has quit [Ping timeout: 264 seconds]
2024-01-04T23:33:59 < ventYl> and it does not affect network transmission exclusively. it takes effect each time you want to save the data in a way it is processable on platform with different endianity
2024-01-04T23:34:06 < karlp> my prior solution was "use ntp time, all records are in ntp time, no records without sync, configure ntp for smearing by default" 
2024-01-04T23:34:44 < karlp> so, UTC all the time, always, and let ntp handle leap seconds, and I just pretend they don't exist.
2024-01-04T23:35:47 < karlp> fuck bitfields.
2024-01-04T23:36:00 < karlp> damn minefield.
2024-01-04T23:36:04 < qyx> karlp: one example from my life, influxdb is utc only, it acceps iso8601 string and a timestamp, now let's guess how is the timestamp computed
2024-01-04T23:36:34 < qyx> because I have not found out yet
2024-01-04T23:36:50 < nomorekaki> I think my solution is let the application handle it
2024-01-04T23:37:01 -!- machinehum [~machinehu@213.55.224.133] has quit [Ping timeout: 246 seconds]
2024-01-04T23:37:06 < qyx> this ambiguity arises whenever your api uses timestamps
2024-01-04T23:37:36 < qyx> and I am not speaking about the current event of inserting a leap second, but all past calculations may be offset
2024-01-04T23:37:47 < qyx> the current event is handled by ntp, sure
2024-01-04T23:37:48 < ventYl> not really, I would expect that there is only one possible interpretation that satisfies the description "number of seconds since the epoch"
2024-01-04T23:38:16 < qyx> so there isn't, bsd and linux disagree
2024-01-04T23:38:55 < qyx> in the past even linux and posix-linux disagreed
2024-01-04T23:39:28 < ventYl> well, disagreement on that topic does not mean that both intepretations satisfy the description
2024-01-04T23:39:55 < ventYl> it just means that someone was willing to sacrifice compliance in exchange for something else
2024-01-04T23:47:43 -!- Ecco [~user@user/Ecco] has quit [Ping timeout: 255 seconds]
2024-01-04T23:51:58 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Quit: Client closed]
2024-01-04T23:54:26 -!- Ecco [~user@user/Ecco] has joined ##stm32
2024-01-04T23:58:45 < karlp> current and all are always handled if you just require ntp sync on devices...
2024-01-04T23:58:52 < karlp> it's just "always utc" 
--- Day changed pe tammi 05 2024
2024-01-05T00:03:25 < qyx> that's not the question if they are ntp synced or no, even if they are perfectly sinced and the time stops now, you will end up with an offset in the database
2024-01-05T00:03:30 < qyx> *synced
2024-01-05T00:03:54 < karlp> what offset?
2024-01-05T00:04:22 < karlp> you mean you say it's utc but gmtime and posix said "lol, fuck you" and converted?
2024-01-05T00:04:26 < karlp> don't convert?
2024-01-05T00:04:34 < karlp> don't use C? :)
2024-01-05T00:05:16 < nomorekaki> ventYl: https://drive.google.com/file/d/1_hC71cY-iXH_SX3Odh_vFRQCGb-LerAy/view?usp=sharing next make that thing run on mcu and spit to uart
2024-01-05T00:05:28 < qyx> for example, now() is "utc without leap seconds" (so not UTC at all) but influx query language now() IS UTC
2024-01-05T00:05:45 < qyx> yes I am saying exactly that
2024-01-05T00:08:27 < qyx> everybody is inserting timestamps into influx but influx says it processes them as UTC
2024-01-05T00:08:58 < qyx> but thta's just an example
2024-01-05T00:09:09 < ventYl> nomorekaki: you should be able to send the data out on uart byte by byte, shouldn't you?
2024-01-05T00:10:26 < nomorekaki> I have" fake isr" reading a file now I need to implement timer capture isr and uart putc
2024-01-05T00:11:46 < nomorekaki> uncomment uart_putc('\r')
2024-01-05T00:15:20 -!- Ecco [~user@user/Ecco] has quit [Ping timeout: 245 seconds]
2024-01-05T00:15:30 -!- Ecco [~user@user/Ecco] has joined ##stm32
2024-01-05T00:17:47 -!- machinehum [~machinehu@213.55.224.133] has joined ##stm32
2024-01-05T00:17:57 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 260 seconds]
2024-01-05T00:18:11 < nomorekaki> ventYl: you mean I would actually just dump the bus to uart?
2024-01-05T00:21:38 < ventYl> I don't know what "bus" means here
2024-01-05T00:25:54 -!- Ecco [~user@user/Ecco] has quit [Read error: Connection reset by peer]
2024-01-05T00:25:57 -!- machinehum [~machinehu@213.55.224.133] has quit [Ping timeout: 256 seconds]
2024-01-05T00:27:01 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-05T00:27:40 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-05T00:30:01 -!- Ecco [~user@user/Ecco] has joined ##stm32
2024-01-05T00:30:29 < nomorekaki> you mean instead of formating the data I would push the frames raw to uart?
2024-01-05T00:32:23 < ventYl> I am lacking context to be able to give you any definitive answer to this question
2024-01-05T00:35:23 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-05T00:39:15 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 260 seconds]
2024-01-05T00:45:43 < qyx> karlp: ok when I am thinking about it a bit more your approach may work except for LoRaWAN nodes
2024-01-05T00:50:05 < qyx> but it still produces wrong results for math on time ranges
2024-01-05T00:56:02 -!- machinehum [~machinehu@213.55.224.133] has joined ##stm32
2024-01-05T01:00:25 -!- machinehum [~machinehu@213.55.224.133] has quit [Ping timeout: 260 seconds]
2024-01-05T01:01:04 < nuxil> so i have a question. is there a way to send a struct over uart ? lets say i have something like: 
2024-01-05T01:01:16 < nuxil> typedef struct JoyStickData {
2024-01-05T01:01:16 < nuxil>     uint16_t adcVal0;           // 2, 2,
2024-01-05T01:01:16 < nuxil>     uint16_t adcVal1;           // 2, 4,
2024-01-05T01:01:16 < nuxil>     uint16_t adcVal2;           // 2, 6,
2024-01-05T01:01:16 < nuxil>     float axis_x;               // 4, 10
2024-01-05T01:01:16 < nuxil>     float axis_x;               // 4, 14
2024-01-05T01:01:18 < nuxil>     float axis_x;               // 4, 18
2024-01-05T01:01:20 < nuxil> } JoyStickData
2024-01-05T01:01:23 < nuxil> in the example the struct JoyStickData will be 20 bytes. 4 bytes aligned. but the actual size of the data is 18 bytes.
2024-01-05T01:01:34 < nuxil> currently i am doing stuff like like this for every variable in the struct JoyStickData. 
2024-01-05T01:01:42 < nomorekaki> keyword "serialization struct"
2024-01-05T01:01:46 < nuxil> ..., uint8_t buffer[18];
2024-01-05T01:01:47 < nuxil> uint8_t *Ptr_axis_x = (uint8_t *)&joystick.axis_x;
2024-01-05T01:01:47 < nuxil> buffer[0] = Ptr_axis_x[0]; buffer[1] = Ptr_axis_x[1];
2024-01-05T01:01:47 < nuxil> buffer[2] = Ptr_axis_x[2]; buffer[3] = Ptr_axis_x[3];
2024-01-05T01:01:50 < nuxil> etc
2024-01-05T01:01:58 < nuxil> i then reconstruct the on data types on the receiving end.
2024-01-05T01:02:38 < nuxil> "serialization struct" you say.
2024-01-05T01:02:42 < nomorekaki> I think zyp had some nifty ways for serialization
2024-01-05T01:02:43 < nuxil> i will look into that
2024-01-05T01:03:07 < qyx> serialise and frame because uart is a stream device
2024-01-05T01:05:42 < nomorekaki> https://en.wikipedia.org/wiki/Protocol_Buffers I think this is what zyp talked about
2024-01-05T01:06:22 < nomorekaki> or some fork of that
2024-01-05T01:06:48 < qyx> yes we are all using nanopb
2024-01-05T01:07:13 < qyx> or tinycbor (me)(for cbor instead of protobuf)
2024-01-05T01:07:25 < nomorekaki> yes because protocol buffers is heavy
2024-01-05T01:08:51 < nuxil> c++ but not c, meh :p
2024-01-05T01:08:53 < nomorekaki> nuxil: read what qyx said
2024-01-05T01:09:08 < nuxil> was reading your link
2024-01-05T01:10:27 < nomorekaki> https://jpa.kapsi.fi/nanopb/ subdomain looks familiar :o
2024-01-05T01:10:55 < qyx> nomorekaki: we have a saying for that "good morning, grandma"
2024-01-05T01:11:20 < nomorekaki> ?
2024-01-05T01:22:53 < zyp> I'm actually gonna use nanopb in a new work project I just started on
2024-01-05T01:23:56 < zyp> for other stuff I'm using protonium, which is my own c++ protobuf lib, but it's not production ready yet
2024-01-05T01:24:40 < zyp> (it works, but it's not optimized to run on embedded yet, so it eats flash)
2024-01-05T01:44:45 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-78da-da31-bff2-7dce.fixed6.kpn.net] has quit [Ping timeout: 260 seconds]
2024-01-05T01:46:13 < qyx> now that I have lost all day doing unrelated things, I am finally starting doing work
2024-01-05T01:47:13 -!- machinehum [~machinehu@213.55.224.133] has joined ##stm32
2024-01-05T01:50:35 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-05T01:51:28 -!- machinehum [~machinehu@213.55.224.133] has quit [Ping timeout: 255 seconds]
2024-01-05T02:15:33 < nomorekaki> night pump
2024-01-05T02:27:28 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-05T02:37:42 -!- machinehum [~machinehu@213.55.224.133] has joined ##stm32
2024-01-05T02:41:56 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-05T02:42:32 -!- machinehum [~machinehu@213.55.224.133] has quit [Ping timeout: 268 seconds]
2024-01-05T02:54:12 < nomorekaki> what englishman thinks about Poilievre?
2024-01-05T03:09:48 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-05T03:27:30 -!- machinehum [~machinehu@213.55.224.133] has joined ##stm32
2024-01-05T03:32:05 -!- machinehum [~machinehu@213.55.224.133] has quit [Ping timeout: 260 seconds]
2024-01-05T04:15:07 < englishman> i havent been told what to think yet
2024-01-05T04:15:28 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-05T04:21:50 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-05T04:25:46 -!- machinehum [~machinehu@213.55.224.133] has joined ##stm32
2024-01-05T04:30:11 -!- machinehum [~machinehu@213.55.224.133] has quit [Ping timeout: 256 seconds]
2024-01-05T04:42:02 -!- stgl [~stgl@164.92.162.3] has quit [Quit: ZNC 1.8.2 - https://znc.in]
2024-01-05T05:25:55 -!- machinehum [~machinehu@213.55.224.133] has joined ##stm32
2024-01-05T05:29:55 -!- machinehum [~machinehu@213.55.224.133] has quit [Ping timeout: 245 seconds]
2024-01-05T05:30:53 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-05T06:16:20 -!- machinehum [~machinehu@213.55.224.133] has joined ##stm32
2024-01-05T06:21:01 -!- machinehum [~machinehu@213.55.224.133] has quit [Ping timeout: 260 seconds]
2024-01-05T07:06:22 -!- machinehum [~machinehu@213.55.224.133] has joined ##stm32
2024-01-05T07:10:41 -!- machinehum [~machinehu@213.55.224.133] has quit [Ping timeout: 252 seconds]
2024-01-05T07:17:46 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-05T07:35:23 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 264 seconds]
2024-01-05T07:42:09 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-1548-fc01-ea0-7ebf.fixed6.kpn.net] has joined ##stm32
2024-01-05T08:03:24 -!- machinehum [~machinehu@213.55.224.133] has joined ##stm32
2024-01-05T08:07:53 -!- machinehum [~machinehu@213.55.224.133] has quit [Ping timeout: 252 seconds]
2024-01-05T08:18:09 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-1548-fc01-ea0-7ebf.fixed6.kpn.net] has quit [Ping timeout: 260 seconds]
2024-01-05T08:46:09 -!- machinehum [~machinehu@213.55.224.133] has joined ##stm32
2024-01-05T08:50:31 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-05T08:50:59 -!- machinehum [~machinehu@213.55.224.133] has quit [Ping timeout: 268 seconds]
2024-01-05T09:00:29 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-05T09:34:19 -!- machinehum [~machinehu@213.55.224.133] has joined ##stm32
2024-01-05T09:38:58 -!- machinehum [~machinehu@213.55.224.133] has quit [Ping timeout: 264 seconds]
2024-01-05T10:13:11 -!- machinehum [~machinehu@213.55.224.133] has joined ##stm32
2024-01-05T10:17:41 -!- machinehum [~machinehu@213.55.224.133] has quit [Ping timeout: 252 seconds]
2024-01-05T10:36:39 -!- machinehum [~machinehu@213.55.224.133] has joined ##stm32
2024-01-05T10:57:17 -!- machinehum [~machinehu@213.55.224.133] has quit [Ping timeout: 252 seconds]
2024-01-05T11:01:34 -!- machinehum [~machinehu@213.55.224.133] has joined ##stm32
2024-01-05T11:54:23 < Steffanx> The comment about the subdomain was a joke right nomorekaki? :o
2024-01-05T12:14:53 -!- machinehum [~machinehu@213.55.224.133] has quit [Ping timeout: 240 seconds]
2024-01-05T12:19:14 < jpa-> for the record, i do not use nanopb 
2024-01-05T12:29:06 < Steffanx> What would you recommend?
2024-01-05T12:35:51 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-05T12:39:05 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 245 seconds]
2024-01-05T12:47:32 -!- pragmalin [~pragmalin@user/pragmalin] has joined ##stm32
2024-01-05T12:53:09 -!- jerkey_ [~jerkey@artsf1.spaz.org] has quit [Read error: Connection reset by peer]
2024-01-05T12:53:18 -!- jerkey [~jerkey@artsf1.spaz.org] has joined ##stm32
2024-01-05T12:54:03 -!- zapb__ [~zapb@static.127.92.47.78.clients.your-server.de] has quit [Quit: *]
2024-01-05T12:54:12 -!- zapb_ [~zapb@2a01:4f8:c010:372f::1] has joined ##stm32
2024-01-05T12:54:45 -!- phryk [~totallyno@user/phryk] has quit [Quit: ZNC 1.8.2 - https://znc.in]
2024-01-05T12:55:05 -!- phryk [~totallyno@user/phryk] has joined ##stm32
2024-01-05T13:06:15 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2024-01-05T13:06:16 < Laurenceb_> suppp
2024-01-05T13:06:39  * Laurenceb_ has a weird issue: cant send more that 64bytes over usb-cdc
2024-01-05T13:06:48 < Laurenceb_> should probably stop using tarduino libs
2024-01-05T13:22:14 < Laurenceb_> CDC_TRANSMIT_QUEUE_BUFFER_SIZE might fix it
2024-01-05T13:26:50 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Ping timeout: 250 seconds]
2024-01-05T13:29:06 -!- qyx [~qyx@84.245.121.92] has quit [Ping timeout: 245 seconds]
2024-01-05T13:29:21 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-05T13:31:14 -!- qyx [~qyx@84.245.120.20] has joined ##stm32
2024-01-05T13:34:02 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2024-01-05T13:34:12 < Laurenceb_> looks like tarduino can only send 64bytes per main loop iteration
2024-01-05T13:35:05 < jpa-> Steffanx: plain C structs or json
2024-01-05T13:37:53 < qyx> you don't like the idl?
2024-01-05T13:39:50 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Ping timeout: 250 seconds]
2024-01-05T13:55:25 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2024-01-05T13:55:37 < Laurenceb_> hmm stm32duino usb looks horribly broken
2024-01-05T13:55:46 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:33e2:f4e3:7dc8:bb0c] has quit [Ping timeout: 245 seconds]
2024-01-05T13:55:55 < Laurenceb_> cant seem to be able to send more than approx 16bytes per main loop
2024-01-05T13:57:21 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Client Quit]
2024-01-05T14:00:27 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-05T14:05:56 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 252 seconds]
2024-01-05T14:06:45 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2024-01-05T14:09:36 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Client Quit]
2024-01-05T14:12:08 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-05T14:26:42 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2024-01-05T14:26:44 < Laurenceb_> wtf tarduino
2024-01-05T14:26:49 < Laurenceb_> availableForWrite is always 64
2024-01-05T14:35:10 -!- machinehum [~machinehu@213.55.226.137] has quit [Read error: Connection reset by peer]
2024-01-05T14:37:02 -!- stgl [~stgl@2a03:b0c0:3:d0::cad:a001] has joined ##stm32
2024-01-05T14:41:29 < Laurenceb_> wtf is going on https://github.com/stm32duino/Arduino_Core_STM32/blob/2c45eba88a36cf95299ec44efe91ecb215fe06e4/cores/arduino/stm32/usb/cdc/cdc_queue.h
2024-01-05T14:41:52 < Laurenceb_> I added "-DCDC_TRANSMIT_QUEUE_BUFFER_PACKET_NUMBER=8" to build_opt.h, but no change in output code
2024-01-05T14:49:58 < Laurenceb_> does anyone know where stm32duino is installed on windows?
2024-01-05T14:57:40 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-05T15:24:42 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Ping timeout: 250 seconds]
2024-01-05T15:27:54 -!- pragmalin [~pragmalin@user/pragmalin] has quit [Remote host closed the connection]
2024-01-05T15:49:24 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 268 seconds]
2024-01-05T15:54:18 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-05T16:16:18 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-05T16:21:48 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-05T16:24:51 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 268 seconds]
2024-01-05T16:31:46 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 264 seconds]
2024-01-05T16:43:28 < jpa-> qyx: i don't like messing with code generation
2024-01-05T16:43:44 < jpa-> especially the python protobuf library is a horrible mess
2024-01-05T16:44:36 < fenugrec> Who makes decent isolated handheld scopes except fluke scopemeter ? hantek ?
2024-01-05T16:45:03 < fenugrec> 'handheld' could mean 'compact, benchtop' but those usually aren't isolated
2024-01-05T16:49:17 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-05T17:37:50 < englishman> R&S
2024-01-05T17:38:10 -!- vekay [~vekay@user/vekay] has joined ##stm32
2024-01-05T17:39:17 -!- mid-kid [~mid-kid@2a01:7c8:aac8:1e8:5054:ff:fe5e:cd48] has quit [Ping timeout: 240 seconds]
2024-01-05T17:46:10 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 264 seconds]
2024-01-05T17:50:35 -!- Ecco [~user@user/Ecco] has quit [Remote host closed the connection]
2024-01-05T17:56:55 < qyx> jpa-: tinycbor to the rescue then, I don't like protobuf for the same reason
2024-01-05T17:59:30 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-05T18:04:05 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 252 seconds]
2024-01-05T18:08:46 -!- ferdna_ [~ferdna@user/ferdna] has joined ##stm32
2024-01-05T18:11:37 -!- ferdna [~ferdna@user/ferdna] has quit [Ping timeout: 276 seconds]
2024-01-05T18:15:41 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-05T18:16:42 -!- ferdna_ [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-05T18:19:13 -!- Ecco [~user@user/Ecco] has joined ##stm32
2024-01-05T18:19:21 < Ecco> So, I've taken apart thos roller blinds
2024-01-05T18:19:54 < Ecco> The PCB is interesting: it takes 9V in, uses a LDO to power a RF transceiver and a chinese MCU, and feeds 9V to a DC motor
2024-01-05T18:20:47 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 268 seconds]
2024-01-05T18:20:48 < Ecco> Now, the motor is controlled by an AP2714SD : https://datasheet.lcsc.com/lcsc/2105241820_ALLPOWER-ShenZhen-Quan-Li-Semiconductor-AP2714SD_C2828583.pdf
2024-01-05T18:20:56 < specing> 9V? So, the 6 celled blokly alkaleaks that used to be common in radios?
2024-01-05T18:21:02 < Ecco> it's an N-channel and P-channel in a single package
2024-01-05T18:21:04 < Ecco> and there's two of those
2024-01-05T18:21:14 < Ecco> (so 4 transistors total)
2024-01-05T18:21:27 < Ecco> One is used to move the motor in one direciton, the other one for the other direction
2024-01-05T18:21:39 < Ecco> I'm not quite sure why they need 2 transistor per direction?
2024-01-05T18:21:47 < Ecco> Do you guys have any idea?
2024-01-05T18:22:01 < Ecco> Also, those ("power"?) mosfets are not controlled by a GPIO
2024-01-05T18:22:25 < Ecco> there's an SOT-23-6 IC between the controlling GPIO and the gate of the power mosfets
2024-01-05T18:23:14 < Ecco> Last but not least, the IC outputs a PWM signal (50% duty, 8kHz) on the control pins. Not quit sure why.
2024-01-05T18:23:43 < Ecco> There are also other pins that seem to go from the MCU to the power mosfets
2024-01-05T18:23:48 < Ecco> but I'm really not quite sure what they do…
2024-01-05T18:26:41 < specing> Ecco: you have to connect both ends of the motor
2024-01-05T18:27:11 < specing> so, one pair connects motor's wires to + -, the other to - +
2024-01-05T18:28:25 < specing> Ecco: other pins? Maybe for increased current?
2024-01-05T18:28:52 < Ecco> specing: ok, that makes total sense, thanks
2024-01-05T18:33:04 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-05T18:34:17 < Ecco> Ok, so here's a photo
2024-01-05T18:34:17 < Ecco> https://i.imgur.com/25WqCoF.jpeg
2024-01-05T18:34:37 < Ecco> It's terrible because I took it on a flatbed scanner and the PCB is populated, so the components make the PCB out of focus
2024-01-05T18:34:44 < Ecco> We can still see most of this
2024-01-05T18:34:53 < Ecco> I *really* wonder what the two parts on the right do
2024-01-05T18:35:04 < Ecco> Very visibly there's one per motor direction
2024-01-05T18:35:30 < Ecco> Also, the MOSFETs get *really* hot if I try to replicate just the PWM signal on the GPIO
2024-01-05T18:37:04 < Ecco> The two parts on the right look like tranistors, with what looks like a pull resistor next to each one of them
2024-01-05T18:38:11 < Ecco> There's a GPIO that goes to each one of them through a resistor
2024-01-05T18:38:23 < Ecco> but I have no idea what the other side is
2024-01-05T18:38:29 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 256 seconds]
2024-01-05T18:39:25 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-05T18:47:29 < specing> gate driver?
2024-01-05T18:49:19 < Ecco> What would that mean?
2024-01-05T18:50:10 < Ecco> The marking on those is "188B a"
2024-01-05T19:06:02 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-05T19:17:47 < karlp> getting pretty sick of jlink just lying to me.
2024-01-05T19:29:34 < jpa-> fenugrec: out of interest, for what kind of use does isolated scope make sense? the poor outer insulation on typical probes means that you can't safely clip ground to a mains voltage line, and the imbalance of loading makes it not ideal for high speed stuff either
2024-01-05T19:30:28 < jpa-> fenugrec: i was designing an inline isolator for scopes a few years ago, but ended up thinking that differential probes are superior in every respect
2024-01-05T19:30:52 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 246 seconds]
2024-01-05T19:47:59 < fenugrec> jpa- good question, diff probes definitely relevant (should get one someday...), but proper isolate scope like fluke, with the proper probes, is mostly gorilla-proof. My use case is I've often found myself poking around in industrial CNC stuff at a buddy's place with just a DMM, because there's no way I'm lugging my tds744 there, and wishing for a scope to look at some signals. And since it's not
2024-01-05T19:48:01 < fenugrec> easy to figure out if it's safe to put a ground clip anywhere, and not obvious how much common-mode I would be putting on a hypothetical diff probe, I thought maybe the right tool would be a completely floating scope
2024-01-05T19:48:26 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-05T19:49:52 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-05T19:53:48 < jpa-> hypothetical diff probes can usually handle pretty large common mode voltages, and tolerate even larger
2024-01-05T19:54:09 < jpa-> but yeah, floating scope or isolated inputs are better than nothing
2024-01-05T19:55:21 < fenugrec> haven't shopped much for diff probes TBH, any suggestions
2024-01-05T19:55:52 < jpa-> not really, i built my own
2024-01-05T19:58:09 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-05T20:10:46 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 246 seconds]
2024-01-05T20:21:35 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 252 seconds]
2024-01-05T20:34:36 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-05T20:39:19 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 256 seconds]
2024-01-05T20:40:07 < Ecco> What would be a common IC package that has 6 pins but is smaller than SOT-23-6?
2024-01-05T20:41:30 < jpa-> sot353?
2024-01-05T20:42:06 < Ecco> Maybe :)
2024-01-05T20:42:06 < jpa-> *sot363 == tssop6
2024-01-05T20:42:07 < Ecco> https://www.onsemi.com/site/cdroms/micropackages/pdf-docs/onsemi/SOT563%20footprint-prof%23B3380.pdf
2024-01-05T20:42:16 < Ecco> This mentions sot363
2024-01-05T20:42:16 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-05T20:42:22 < Ecco> notn 353
2024-01-05T20:42:27 < Ecco> oh ok you corrected yourself,s orry
2024-01-05T20:42:34 < Ecco> yes most likely this, thanks!
2024-01-05T20:43:56 < Ecco> Do you guys have any recommendation on how to identify ICs?
2024-01-05T20:44:14 < fenugrec> boring answer : google
2024-01-05T20:44:21 < Ecco> Wlel, yeah, but I mean
2024-01-05T20:44:27 < Ecco> I'm looking at an SOT363 IC
2024-01-05T20:44:31 < Ecco> marked "12 6"
2024-01-05T20:45:03 < fenugrec> hunt for schematics of your or similar things; mfg catalogue (i.e. if your board is full of richtek or torex parts, that may or may not be a lead;
2024-01-05T20:45:15 < Ecco> hmm, that's a good idea
2024-01-05T20:45:35 < fenugrec> be as sure as you can of what it does; and there's a few websites with 'smd marking' databases
2024-01-05T20:47:02 < Ecco> Yeah, it's hard
2024-01-05T20:47:04 < fenugrec> those websites are less and less useful because nobody can keep up with china IC mfgs
2024-01-05T20:47:12 < Ecco> I'm trying to reverse the PCB of those roller blinds
2024-01-05T20:47:19 < Ecco> I'll share my findings with you guys
2024-01-05T20:47:33 < Ecco> The good news is that I ID'ed the most important parts
2024-01-05T20:49:19 < fenugrec> so what does this one do, dual mosfet ? smps regulator ? opamp/comparator ?
2024-01-05T20:49:38 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 252 seconds]
2024-01-05T20:56:55 < fenugrec> that's one thing where AI could actually do something helpful. Scrape all datasheets from suppliers like lcsc and parse for marking information and pinout. "find me a sot23-6 buck regulator with FB on pin 2, marking 'AV' or 'AU'"
2024-01-05T21:00:55 -!- iamzim [~iamzim@user/invaderzim] has joined ##stm32
2024-01-05T21:11:00 -!- iamzim [~iamzim@user/invaderzim] has left ##stm32 []
2024-01-05T21:36:32 < Ecco> ok, *done*
2024-01-05T21:36:33 < Ecco> Finally
2024-01-05T21:36:37 < Ecco> Took forever
2024-01-05T21:36:38 < Ecco> https://i.imgur.com/fe5LNvd.png
2024-01-05T21:36:55 < Ecco> So that's only a part of the schematics. It's the PCB of some electric roller blinds
2024-01-05T21:37:14 < Ecco> There's a small Cortex M0+ MCU on board, and three of its GPIOs are connected as in this schematic
2024-01-05T21:37:20 < Ecco> This... makes no sense to me whatsoever
2024-01-05T21:37:49 < Ecco> (I put transistor symbols, but maybe those are not transistors. They are SOT-23-3 tho.)
2024-01-05T21:38:20 < Ecco> What's super weird is that this doesn't seem to have any "side effect"
2024-01-05T21:40:45 < Ecco> Do you guys have any idea what this could be?
2024-01-05T21:41:48 < qyx> fenugrec: did it succeed?
2024-01-05T22:16:26 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-05T22:29:59 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-05T22:31:12 < qyx> Ecco: could be a temp sensor?
2024-01-05T22:31:29 < qyx> sot363 is a bias supply with enale input
2024-01-05T22:31:51 < qyx> those two transistors are some sensors (hall? temperature?) with decoupling caps
2024-01-05T22:31:56 < qyx> and pullups on the outputs
2024-01-05T22:32:10 < qyx> some caps to ground to low pass filter the output
2024-01-05T22:32:27 < qyx> and a series resistor just for the lulz (as a protection of some sort)
2024-01-05T22:33:43 < qyx> yes hall sensors have vcc on pin 1, gnd on pin 3 and output on pin 2
2024-01-05T22:34:03 < qyx> eg. DRV5023
2024-01-05T22:35:07 < qyx> makes sense for roller blinds to detect whether the motor is rotating
2024-01-05T22:37:04 -!- machinehum2 [~machinehu@5.226.148.123] has joined ##stm32
2024-01-05T22:37:59 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 252 seconds]
2024-01-05T22:38:06 < nomorekaki> my first project was roller blinds
2024-01-05T22:38:16 < nomorekaki> it had interesting features
2024-01-05T22:38:19 < qyx> machinehum2: youtubez is recommending me your psu over and over again
2024-01-05T22:38:32 < qyx> yeah I have custom controllers too
2024-01-05T22:38:43 < qyx> but I have to redo them to be more water resistant
2024-01-05T22:39:43 < nomorekaki> had sound of concrete mixer
2024-01-05T22:40:58 < nomorekaki> start projector and hearing sound of concrete mixer left right and back
2024-01-05T22:45:38 -!- machinehum2 [~machinehu@5.226.148.123] has quit [Ping timeout: 260 seconds]
2024-01-05T22:56:08 < nomorekaki> how should I make directory structure for my lib if I want to provide lib, extensions_lib1, extensions_lib2 and a couple of example programs?
2024-01-05T22:56:29 < qyx> with a mkdir supposedly?
2024-01-05T22:56:40 < nomorekaki>  /include and /examples ?
2024-01-05T22:56:49 < nomorekaki> qyx: indeed
2024-01-05T22:57:34 < qyx> sry :P
2024-01-05T22:57:55 < qyx> I would do src, include, examples
2024-01-05T22:58:05 < nomorekaki> ah yes src
2024-01-05T22:58:35 < nomorekaki> or just drop them sources to bottom directory?
2024-01-05T23:00:10 < qyx> if it is a single-source lib, I would not care
2024-01-05T23:02:38 < nomorekaki> tell me again why we have separate source files?
2024-01-05T23:04:09 < nomorekaki> I'll google that
2024-01-05T23:10:55 < ventYl> because 386 had too small RAM to fit all the code in one take
2024-01-05T23:11:23 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-05T23:12:36 < nomorekaki> interesting answer!
2024-01-05T23:13:22 < ventYl> I use /src /include /cmake /test
2024-01-05T23:13:54 -!- machinehum2 [~machinehu@213.55.226.137] has joined ##stm32
2024-01-05T23:13:57 < ventYl> if code is potentially shared, I don't tend to store examples along it, so if you git submodule it, your repository won't miraculously grow to 25 megabytes
2024-01-05T23:14:37 < nomorekaki> hmm
2024-01-05T23:14:50 < ventYl> another good point is to do /include/<name>/<header>.h
2024-01-05T23:15:07 < nomorekaki> name?
2024-01-05T23:15:09 < ventYl> so you can do -Ipath/to/include and then do #include <name/header.h>
2024-01-05T23:15:21 < ventYl> name stands for your library / project name if it has public headers
2024-01-05T23:15:42 < ventYl> it prevents naming clashes, if your header file names are generic
2024-01-05T23:15:56 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 252 seconds]
2024-01-05T23:16:01 < ventYl> no need to do that if all that the integrator includes is one header named after the project
2024-01-05T23:20:48 < nomorekaki> maybe include/lib.h , include/extra/lib_helper_func.h, include/extra/lib_uart_formatter.h, include/test/lib_test.h
2024-01-05T23:21:30 < ventYl> rather something like include/lib.h, include/lib/helper_func.h, include/lib/uart_formatter.h, etc
2024-01-05T23:21:45 < nomorekaki> aah
2024-01-05T23:21:47 < nomorekaki> got it
2024-01-05T23:21:59 < ventYl> so then you can point -I at include dir and then do #include <lib.h>, #include <lib/helper_func.h>
2024-01-05T23:22:12 < ventYl> and it will work both for your code and for code of all library users
2024-01-05T23:22:34 < nomorekaki> cool cool
2024-01-05T23:23:43 < nomorekaki> sounds like you have some experience based insight to this
2024-01-05T23:23:50 < nomorekaki> thanks for advice
2024-01-05T23:27:49 < nomorekaki> still a lot of work
2024-01-05T23:28:05 < nomorekaki> not so much coding but more of making the project look clean
2024-01-05T23:33:27 < Ecco> qyx: Damn, you're good
2024-01-05T23:33:34 < Ecco> (sorry I was offline for a bit)
2024-01-05T23:34:01 < Ecco> damn boy
2024-01-05T23:34:06 < Ecco> You're actually *spot on*
2024-01-05T23:34:16 < Ecco> The motor has a weird magnet-like thing on the axle
2024-01-05T23:34:28 < Ecco> that happens to be… *right above* those SOT-23 chips!
2024-01-05T23:34:32 < Ecco> damn
2024-01-05T23:34:57 < Ecco> How you figured this out apparently so easily is beyond me
2024-01-05T23:35:28 < Ecco> I mean, yes, it did not make sense for those to be transistors, but well
2024-01-05T23:36:12  * Ecco is impressed
2024-01-05T23:36:53 < Ecco> Ok, cool, let me try and do the rest of the schematics :)
2024-01-05T23:37:59 -!- Mangy_Dog [~Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-05T23:42:22 < qyx> np, crystal ball
2024-01-05T23:47:13 < fenugrec> qyx , did what succeed ?
2024-01-05T23:48:22 < qyx> 18:56 < fenugrec> that's one thing where AI could actually do something helpful...
2024-01-05T23:49:01 -!- machinehum2 [~machinehu@213.55.226.137] has quit [Ping timeout: 256 seconds]
2024-01-05T23:49:22 < fenugrec> ah, I meant 'one could train some AI to XYZ', sry. I'm not really into ML 
2024-01-05T23:51:47 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-ece7-31c3-9861-47f9.fixed6.kpn.net] has joined ##stm32
2024-01-05T23:53:43 < nomorekaki> how was the rules with static and inline with source-header?
2024-01-05T23:56:09 < nomorekaki> hmm for static functions just leave them out of header?
2024-01-05T23:57:52 < fenugrec> What's the point of a diff probe rated to 100MHz if it has non-detachable flying leads https://probemaster.com/pt-8101-differential-probe-1-10-100-100-mhz-700v/
--- Day changed la tammi 06 2024
2024-01-06T00:02:10 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-06T00:07:25 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 245 seconds]
2024-01-06T00:16:37 < Ecco> nomorekaki: what's the context?
2024-01-06T00:16:52 < nomorekaki> answer is to leave them out of header
2024-01-06T00:17:06 < nomorekaki> now I'm figuring out inline
2024-01-06T00:17:27 < Ecco> static in C is a weird keyword. For functions, it means the visibility is restricted to the compile unit (the current .c file)
2024-01-06T00:18:22 < Ecco> So if you put a static function in a shared header, it will be regenerated for every compile unit
2024-01-06T00:18:37 < Ecco> which is kinda dumb, unless you want that function to be inlined
2024-01-06T00:19:08 < Ecco> Read this: https://stackoverflow.com/questions/7762731/whats-the-difference-between-static-and-static-inline-function
2024-01-06T00:19:11 < Ecco> :)
2024-01-06T00:19:16 -!- mid-kid [~mid-kid@2a01:7c8:aac8:1e8:5054:ff:fe5e:cd48] has joined ##stm32
2024-01-06T00:30:20 -!- scrts [~scrts@163.116.249.46] has joined ##stm32
2024-01-06T00:32:02 < nomorekaki> ofc the case of static inline
2024-01-06T00:36:20 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-06T00:39:13 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-06T00:39:55 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 246 seconds]
2024-01-06T00:43:56 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 252 seconds]
2024-01-06T00:59:37 -!- Spirit532 [~Spirit532@user/Spirit532] has quit [Read error: Connection reset by peer]
2024-01-06T01:01:50 -!- Spirit532 [~Spirit532@user/Spirit532] has joined ##stm32
2024-01-06T01:03:23 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-ece7-31c3-9861-47f9.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-06T01:26:56 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-06T01:31:10 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 245 seconds]
2024-01-06T01:31:38 < nomorekaki> I wish to look .vscode files of your c/c++ projects
2024-01-06T01:32:03 < nomorekaki> to "get inspirations" from
2024-01-06T02:05:50 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 260 seconds]
2024-01-06T02:18:41 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-06T02:23:12 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 256 seconds]
2024-01-06T02:49:48 < zyp> I don't really have the patience to make them
2024-01-06T02:51:26 < nomorekaki> but there is potential to do a lot of things
2024-01-06T02:52:13 < nomorekaki> you bypass all the configuring and use makefiles?
2024-01-06T02:52:31 < zyp> makefiles? for what?
2024-01-06T02:53:27 < nomorekaki> building
2024-01-06T02:54:49 < zyp> I don't tend to pick make for anything where I get to choose, but in the general sense, yeah, I absolutely wouldn't have a project depend on vscode to build it
2024-01-06T02:56:14 < nomorekaki> but you would have task to trigger your make?
2024-01-06T02:57:03 < zyp> hmm, depends
2024-01-06T02:57:14 < zyp> usually I don't bother setting up tasks
2024-01-06T02:58:59 < nomorekaki> do you have cpp settings?
2024-01-06T02:59:37 < zyp> no
2024-01-06T03:00:18 < nomorekaki> it seems to work without them
2024-01-06T03:00:47 < zyp> depends on the codebase, but yeah
2024-01-06T03:01:20 < zyp> usually I find it more hassle than it's worth to get all the fancy stuff working for cpp so I just don't bother with it
2024-01-06T03:01:49 -!- Thorn [~Thorn@bl18-149-68.dsl.telepac.pt] has joined ##stm32
2024-01-06T03:01:49 -!- Thorn [~Thorn@bl18-149-68.dsl.telepac.pt] has quit [Changing host]
2024-01-06T03:01:49 -!- Thorn [~Thorn@user/thorn] has joined ##stm32
2024-01-06T03:01:50 < zyp> for python it tends to work pretty well out of the box, except I sometimes have to help it a bit with import paths
2024-01-06T03:01:51 < Ecco> ok, I *finally* finished!
2024-01-06T03:01:52 < Ecco> https://i.imgur.com/NbUBsc2.png
2024-01-06T03:01:52 < nomorekaki> intellisense picks up the outputs from gcc I think and applies build errors
2024-01-06T03:02:27 < Ecco> I'm really curious about two things in those schematics:
2024-01-06T03:02:36 < Ecco> 1/ Why are there 4 GPIOs to control one motor?
2024-01-06T03:02:48 < Ecco> 2/ What's the point of the two ICs in front of the MOSFETs that control the motor?
2024-01-06T03:03:31 < zyp> you're reverse engineering this?
2024-01-06T03:03:46 < zyp> are you sure both 1 and 4 are grounded, not one of them being power?
2024-01-06T03:04:25 < nomorekaki> it's half bridge controller /w deadtime or something
2024-01-06T03:04:31 < Ecco> zyp: Yes. Well at least I'm trying to
2024-01-06T03:04:53 < Ecco> 1 and 4 of the surprice IC?
2024-01-06T03:05:06 < Ecco> Oh yeah most definitely a mistake from my end
2024-01-06T03:05:08 < Ecco> let me check
2024-01-06T03:05:12 < Ecco> but I'm pretty sure one is 3.3V
2024-01-06T03:05:13 < nomorekaki> *half-bridge gate driver /w deadtime
2024-01-06T03:05:22 < zyp> hmm, I was thinking it could be a 74lvc2g34 or similar, but the pinout doesn't match
2024-01-06T03:05:36 < Ecco> Just effed it up when doing the schematics
2024-01-06T03:05:44 < nomorekaki> or yes indeed simple logic buffer ic
2024-01-06T03:05:52 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-06T03:05:53 < Ecco> what are those?
2024-01-06T03:06:03 < nomorekaki> like amplifier
2024-01-06T03:06:14 < Ecco> a GPIO couldn't drive the MOSFET?
2024-01-06T03:06:16 < zyp> just a buffer to go from logic level to whatever is suitable to drive the gates
2024-01-06T03:06:30 < zyp> depends wha Vdrive is
2024-01-06T03:06:49 < zyp> a 3.3V IO can't drive the high side gate if Vdrive is like 5V
2024-01-06T03:07:02 < zyp> hm
2024-01-06T03:07:19 < zyp> actually, since they both got pullups, it's probably a dual nfet
2024-01-06T03:07:47 < Ecco> Vdrive is 9V
2024-01-06T03:07:57 -!- Mangy_Dog [~Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 260 seconds]
2024-01-06T03:07:59 < zyp> Si1902CDL or similar
2024-01-06T03:08:02 < zyp> pinout matches
2024-01-06T03:08:10 < Ecco> https://i.imgur.com/tmMPxsH.png here's vdrive
2024-01-06T03:08:17 < Ecco> Wait, that being said
2024-01-06T03:08:22 < Ecco> 1 and 4 are infact GND
2024-01-06T03:08:29 < zyp> yes
2024-01-06T03:08:32 < Ecco> there doesn't seem to be any VDD pin :-/ ???
2024-01-06T03:08:34 < zyp> https://www.vishay.com/docs/67876/si1902cdl.pdf
2024-01-06T03:08:37 < zyp> correct
2024-01-06T03:08:48 < zyp> those are just two transistors in one package
2024-01-06T03:08:50 < Ecco> Oh so it's *again* two transistor in one package
2024-01-06T03:08:56 < Ecco> just like the power mosfets then
2024-01-06T03:09:03 < zyp> yeah
2024-01-06T03:09:08 < Ecco> ok cool but then
2024-01-06T03:09:32 < Ecco> how does this work?
2024-01-06T03:09:37 < zyp> so the gpio turns on that transistor to pull the gate of the power transistor low
2024-01-06T03:09:43 < Ecco> The transistor's job is to either pull low or leave floating?
2024-01-06T03:09:48 < zyp> otherwise it's pulled high by the pullups
2024-01-06T03:09:52 < Ecco> oh
2024-01-06T03:10:00 < Ecco> oh right
2024-01-06T03:10:04 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 246 seconds]
2024-01-06T03:10:05 < Ecco> makes sense!
2024-01-06T03:10:08 < zyp> that's how you get 9V logic on the power transistor gates from 3.3V GPIOs
2024-01-06T03:10:17 < Ecco> hmm, perfect
2024-01-06T03:10:22 < Ecco> awesome, thanks!
2024-01-06T03:11:18 < Ecco> ok, now nomorekaki explained it
2024-01-06T03:11:27 < Ecco> but I don't understand why there are two GPIOs per direction
2024-01-06T03:11:33 < zyp> one for each transistor
2024-01-06T03:11:43 < Ecco> Yeah, but how should they behave?
2024-01-06T03:11:51 < Ecco> I *did* measure one GPIO from the original IC
2024-01-06T03:12:01 < Ecco> it was outputing a 8kHz, 50% duty PWM
2024-01-06T03:12:05 < Ecco> but I only measured one
2024-01-06T03:12:07 < qyx> Ecco: what is Vdriver?
2024-01-06T03:12:09 < nomorekaki> Ecco: both cannot be active at same time
2024-01-06T03:12:11 < qyx> I mean what voltage
2024-01-06T03:12:20 < qyx> oh 9 V
2024-01-06T03:12:30 < Ecco> https://i.imgur.com/tmMPxsH.png
2024-01-06T03:12:37 < Ecco> It's 9V behind a diode and with a filtering cap
2024-01-06T03:12:45 < Ecco> well, actually, a bunch of caps
2024-01-06T03:12:51 < qyx> do you have a photo of that thing as a whole?
2024-01-06T03:12:51 < Ecco> and 9V comes from 6 AA batteries
2024-01-06T03:12:52 < zyp> a halfbridge has three possible states: drive low, drive high, tristate (and a fourth that's short circuit, which you never want)
2024-01-06T03:13:10 < nomorekaki> four if short circuit is counted
2024-01-06T03:13:11 < qyx> I have never seen battery powered blinds
2024-01-06T03:13:12 < Ecco> zyp: pretty sure I got it into short circuit
2024-01-06T03:13:22 < Ecco> (became crazy hot and I burnet my finter a little :-D)
2024-01-06T03:13:38 < Ecco> qyx: Well, those are. Not sure it lasts long
2024-01-06T03:13:46 < Ecco> I wired them to a 9V DC power supply tho
2024-01-06T03:13:59 < Ecco> so I'm trying to replace the shitty controller with an ESP8266
2024-01-06T03:14:12 < qyx> it won't be much low power
2024-01-06T03:14:13 < Ecco> let me take some photos
2024-01-06T03:14:31 < Ecco> yeah, which is most likely why they don't do WiFi+battery powered
2024-01-06T03:14:38 < zyp> in your case, you get low if both gpios are low, high if both gpios are high, tristate if only the signal controlling the low side transistor is high, and short circuit if only the signal controlling the high side transistor is high
2024-01-06T03:14:39 < Ecco> but I don't really care now that I've wired it
2024-01-06T03:16:31 < Ecco> qyx: PCB from the top https://i.imgur.com/2NgUhe3.jpg
2024-01-06T03:17:17 < Ecco> from the bottom: https://i.imgur.com/4CIO3ul.jpg
2024-01-06T03:17:47 < Ecco> Bonus pic: hall sensor next to motor: https://i.imgur.com/449PvTF.jpg
2024-01-06T03:18:08 < nomorekaki> you need timer with 2x pwm outputs and deadtime configured
2024-01-06T03:18:29 < qyx> omg that antenna and receiver
2024-01-06T03:18:36 < qyx> looks indeed pretty cheap
2024-01-06T03:18:56 < nomorekaki> another half bridge you can control with just GPIO but never have condition where both fets active
2024-01-06T03:19:12 < Ecco> I think the half-wavelength of 433MHz is 17cm, so it's kind of hard to make it fit on a PCB :)
2024-01-06T03:19:37 < qyx> heh the motor
2024-01-06T03:19:40 < qyx> yeah
2024-01-06T03:19:48 < zyp> do you even need PWM to run that?
2024-01-06T03:19:49 < qyx> not a bad solution tho
2024-01-06T03:20:00 < zyp> no need for deadtime if you're not even running pwm
2024-01-06T03:20:01 < Ecco> zyp: I don't know, that's what *they* do
2024-01-06T03:20:13 < zyp> okay, fair enough
2024-01-06T03:20:18 < nomorekaki> if you want smooth
2024-01-06T03:20:32 < nomorekaki> cool smooth ramps
2024-01-06T03:20:54 < Ecco> wait, so I'm still a complete noob about half bridge
2024-01-06T03:21:08 < Ecco> I understand that ther are 2 digital inputs, so 2^2=4 possible states 
2024-01-06T03:21:16 < nomorekaki> never have both fets active at the same time
2024-01-06T03:21:23 < zyp> a half bridge is just like a tristateable gpio
2024-01-06T03:21:40 < Ecco> yes, that's one of the 4 possibilities, the one that made me burn my finger
2024-01-06T03:21:50 < zyp> I mean, a cmos output is itself a little halfbridge
2024-01-06T03:22:17 < zyp> just one transistor to drive low, one to drive high and if both are off the output is floating
2024-01-06T03:22:35 < Ecco> oh, ok
2024-01-06T03:22:40 < Ecco> yes, that's actually easy
2024-01-06T03:22:47 < Ecco> What about the 13 Ohms resistor to ground?
2024-01-06T03:23:17 < zyp> the issue with power transistors is that they take time switching, so if you just wired them together, one would start switching on before the other has switched fully off
2024-01-06T03:23:24 < Ecco> ohh, ok
2024-01-06T03:23:28 < zyp> and then you get a short circuit
2024-01-06T03:23:33 < Ecco> ok, got it
2024-01-06T03:23:40 < Ecco> only for a short amount of time tho, right?
2024-01-06T03:23:46 < zyp> so the deadtime nomorekaki is talking about is a delay between switching one side off and the other side on
2024-01-06T03:23:54 < Ecco> yeah, ok, makes perfect sense
2024-01-06T03:24:18 < Ecco> Now why do they PWM the GPIOs?
2024-01-06T03:24:24 < nomorekaki> Ecco: could be shunt for current measurement
2024-01-06T03:24:36 < zyp> probably to regulate current
2024-01-06T03:24:37 < Ecco> nomorekaki: oh smart
2024-01-06T03:24:50 < nomorekaki> or that^
2024-01-06T03:24:52 < Ecco> I mean, those blinds are *that* dumb
2024-01-06T03:25:00 < Ecco> the hall sensor is kinda neat
2024-01-06T03:25:05 < Ecco> I really didn't expect this
2024-01-06T03:25:17 < nomorekaki> well you cannot really do it without the sensor
2024-01-06T03:25:18 < Ecco> I just thought it would just time the whole thing
2024-01-06T03:25:21 < Ecco> why not?
2024-01-06T03:25:22 < zyp> motor current is proportional to motor torque
2024-01-06T03:25:42 < zyp> you can't time it if you don't know how fast it is running
2024-01-06T03:25:53 < Ecco> hmm, makes sense if it's on battery
2024-01-06T03:26:06 < nomorekaki> Ecco: have multiple blinds and all of them set to different positions
2024-01-06T03:26:07 < Ecco> (i.e. the motor will end up running slower)
2024-01-06T03:26:15 < zyp> you don't know how fast it is running even if you knew the voltage
2024-01-06T03:26:30 < nomorekaki> ^
2024-01-06T03:26:37 < nomorekaki> what zyp said
2024-01-06T03:26:38 < Ecco> why not?
2024-01-06T03:26:49 < Ecco> I mean, assuming the voltage is constant
2024-01-06T03:26:58 < Ecco> wouldn't the motor turn at a constant rate?
2024-01-06T03:27:16 < Ecco> And therefore we could simply infer the blind's position from the time it took to go up or down?
2024-01-06T03:27:21 < zyp> no, motor speed is a function of voltage and load
2024-01-06T03:27:30 < zyp> and you don't know the load
2024-01-06T03:27:48 < Ecco> well, isn't the load sort of constant too? (I mean, the blinds don't change)
2024-01-06T03:27:57 < Ecco> Well, of course anything where you integrate would drift anyway
2024-01-06T03:27:57 < qyx> no, you need it.
2024-01-06T03:28:01 < zyp> this is a roller blind, right?
2024-01-06T03:28:08 < Ecco> zyp: yes
2024-01-06T03:28:13 < nomorekaki> load depends on blind position
2024-01-06T03:28:16 < zyp> the further unrolled it is, the more hanging mass you've got
2024-01-06T03:28:19 < Ecco> Yess
2024-01-06T03:28:25 < Ecco> but that's constant for each roll
2024-01-06T03:28:36 < Ecco> it changes during a roll
2024-01-06T03:28:41 < Ecco> but you could still time it I guess
2024-01-06T03:28:54 < Ecco> but you'd be integrating to figure out a position, and at the very least end up drifting
2024-01-06T03:29:00 < Ecco> I mean, if they didn't cheap out on this
2024-01-06T03:29:02 < qyx> no Ecco, it is 3:1, this approach doesn't work
2024-01-06T03:29:04 < Ecco> I agree with you zyp
2024-01-06T03:29:07 < zyp> now the problem is that calculating the position requires you to know the initial position
2024-01-06T03:29:10 < Ecco> it's most definitely needed :-D
2024-01-06T03:29:24 < Ecco> qyx: ok I'll take your word for it :)
2024-01-06T03:29:26 < zyp> so you end up making an estimate based on an estimate based on an estimate…
2024-01-06T03:29:34 < zyp> i.e. accumulating error
2024-01-06T03:29:52 < qyx> if they want to cheap it out, they can sense commutating interference, I have done that on a motor without a hall
2024-01-06T03:29:53 < Ecco> yeah, that's the kind of problem I was trying to describe with "drifing"
2024-01-06T03:29:55 < qyx> but it is meh
2024-01-06T03:29:57 < zyp> and that's even without considering process variation
2024-01-06T03:30:14 < Ecco> now, a simpler question: why do they PWM the GPIOs?
2024-01-06T03:30:20 < zyp> to regulate current
2024-01-06T03:30:21 < nomorekaki> let's say motor brushes wear, gearbox wears and you have then different multiplier for voltage and load than in begin
2024-01-06T03:30:33 < zyp> current is proportional with torque
2024-01-06T03:30:35 < nomorekaki> blind drags to wall - different load
2024-01-06T03:30:41 < Ecco> damn
2024-01-06T03:30:46 < qyx> or variable load, for that only a single resistor and ADC is required and you can somehow get the rotor position
2024-01-06T03:31:22 < Ecco> what would be the problem to just turn the GPIOs fully on/off?
2024-01-06T03:32:01 < nomorekaki> nothing
2024-01-06T03:32:03 < zyp> poor utilization of the motor, or risk of a burnout
2024-01-06T03:32:19 < qyx> Ecco: https://www.precisionmicrodrives.com/using-dc-motor-commutation-spikes-measure-motor-speed-rpm
2024-01-06T03:32:20 < Ecco> Hmm
2024-01-06T03:32:41 < Ecco> qyx: oh that's interesting
2024-01-06T03:32:45 < zyp> the motor current is limited by winding resistance and back-emf, and the latter is a function of speed
2024-01-06T03:32:48 < Ecco> so the brushes are the sensor, in a way
2024-01-06T03:33:06 < Ecco> so wait
2024-01-06T03:33:08 < zyp> so the faster a motor spins, the less current can be pushed into it by a given voltage
2024-01-06T03:33:16 < Ecco> if I run a PWM with a low-duty PWM
2024-01-06T03:33:21 < Ecco> that will make the motor run slower, right?
2024-01-06T03:33:34 < Ecco> This way I can make the blinds run quieter?
2024-01-06T03:33:34 < zyp> yes, because that's effectively a lower voltage
2024-01-06T03:33:45 < Ecco> Ohh, fancy :-D
2024-01-06T03:33:47 < zyp> 9V at 50% duty is effectively the same as driving it with 4.5V
2024-01-06T03:34:11 < Ecco> oh, the motor acts like it's own low-pass filter then?
2024-01-06T03:34:18 < zyp> yes
2024-01-06T03:34:21 < Ecco> cool
2024-01-06T03:34:31 < Ecco> Ok, so that was neat
2024-01-06T03:35:06 < Ecco> If I want to do things right
2024-01-06T03:35:10 < Ecco> and implement a deadtime
2024-01-06T03:35:16 < Ecco> how do I know which one to turn on first?
2024-01-06T03:35:26 < Ecco> I guess the idea is to aim for the "floating" state
2024-01-06T03:35:30 < Ecco> instead of the shortcircuit
2024-01-06T03:35:45 < Ecco> (during the transition)
2024-01-06T03:35:48 < zyp> I think jpa- once said that he thought of motor control as a buck regulator, I also find that a good mental model
2024-01-06T03:36:09 < nomorekaki> Ecco: does the blinds bottom out in top position?
2024-01-06T03:36:22 < Ecco> nomorekaki: I don't understand your question
2024-01-06T03:36:38 < nomorekaki> what method of reseting the position it has?
2024-01-06T03:36:43 < zyp> if there's a physical stop, I guess
2024-01-06T03:36:50 < Ecco> well, originally
2024-01-06T03:36:54 < Ecco> it comes with a remote
2024-01-06T03:36:55 < nomorekaki> does it run until it cannot run anymore?
2024-01-06T03:37:00 < Ecco> no
2024-01-06T03:37:07 < Ecco> with the remote
2024-01-06T03:37:17 < Ecco> you can send a message to the controller (the PCB I just sent pictures of)
2024-01-06T03:37:34 < Ecco> the message can be "remember this as the "top" position"
2024-01-06T03:37:41 < Ecco> or "remember this as the bottom position"
2024-01-06T03:37:41 < nomorekaki> ah
2024-01-06T03:37:54 < nomorekaki> it never resets position at top?
2024-01-06T03:38:04 < Ecco> what would that mean?
2024-01-06T03:38:12 < Ecco> (again, I've only had those blinds for like a week)
2024-01-06T03:38:17 < zyp> no need to do that when it counts pulses on the motor
2024-01-06T03:38:19 < Ecco> (so I'm not super familiar with them)
2024-01-06T03:38:28 < nomorekaki> zyp: true
2024-01-06T03:38:33 < Ecco> I don't think there's any drift
2024-01-06T03:38:35 < nomorekaki> how about if powercycled
2024-01-06T03:38:38 < zyp> pulse counting shouldn't drift
2024-01-06T03:38:48 < Ecco> agreed
2024-01-06T03:38:55 < Ecco> nomorekaki: good question
2024-01-06T03:38:58 < Ecco> it also remembers the remote
2024-01-06T03:38:58 < zyp> might have to reset positions after a battery change
2024-01-06T03:39:03 < Ecco> so I guess there's a Flash memory?
2024-01-06T03:39:07 < zyp> unless they're stored
2024-01-06T03:39:12 < Ecco> You know what? I haven't looked up the main IC just yet
2024-01-06T03:39:16 < Ecco> I looked up the IC of the remote
2024-01-06T03:39:25 < Ecco> and it was a Cortex M0+ with some Flash
2024-01-06T03:39:35 < Ecco> I guess the blinds have the same kind of stuff
2024-01-06T03:39:37 < Ecco> let me see
2024-01-06T03:40:09 < nomorekaki> my blinds bottomed out at top getting the absolute zero pos
2024-01-06T03:40:30 < nomorekaki> hit top at full speed then shunt voltage spiked
2024-01-06T03:40:40 < Ecco> "2F1028
2024-01-06T03:40:43 < Ecco> 32F1028
2024-01-06T03:41:17 < Ecco> http://www.aptchip.com/
2024-01-06T03:41:49 < Ecco> http://www.aptchip.com/list_65
2024-01-06T03:42:26 < Ecco> http://www.aptchip.com/list_112/656.html
2024-01-06T03:43:00 < Ecco> APT32F1028H8S6
2024-01-06T03:43:08 < Ecco> 64k Flash, 4K RAM
2024-01-06T03:43:24 < Ecco> 2K of Dflash, whatever that is
2024-01-06T03:43:52 < Ecco> I really wish I would have been able to reverse-engineer the RF protocol
2024-01-06T03:44:06 < Ecco> Took several dumps from the remote
2024-01-06T03:44:32 < qyx> and whats the problem? does it look like some sort of encryption?
2024-01-06T03:44:32 < Ecco> (which I know are good because I also took some from a GPIO on the receiver and they were similar)
2024-01-06T03:44:38 < Ecco> it does
2024-01-06T03:44:43 < Ecco> but what's super weird
2024-01-06T03:44:56 < Ecco> is that it *will* take a replay
2024-01-06T03:45:10 < qyx> so replay works?
2024-01-06T03:45:13 < Ecco> yes
2024-01-06T03:45:19 < qyx> it is not a rolling code then most probably
2024-01-06T03:45:26 < Ecco> indeed
2024-01-06T03:45:29 < Ecco> but surprisingly
2024-01-06T03:45:38 < Ecco> the message from the same keypress on the same remote
2024-01-06T03:45:54 < Ecco> will be *completely* different from one keypress to the next
2024-01-06T03:46:08 < Ecco> it doesn't even look like "data + checksum" or "data  + crypto signature"
2024-01-06T03:46:11 < qyx> it maybe a random nonce + key encrypted
2024-01-06T03:46:18 < Ecco> it really looks like "random shit" every single time
2024-01-06T03:47:23 < qyx> something like E = nonce | (M xor H(nonce | key))
2024-01-06T03:48:04 < Ecco> how would the receive decode this?
2024-01-06T03:48:06 < qyx> and the receiver splits the E message to nonce and the encrypted part Me, then M = Me xor H(nonce, key)
2024-01-06T03:48:16 < Ecco> so wait, the nonce is a shared secret?
2024-01-06T03:48:23 < qyx> no, key is a shared secret
2024-01-06T03:48:24 < Ecco> oooh
2024-01-06T03:48:25 < Ecco> sorry
2024-01-06T03:48:29 < qyx> nonnce is, well, nonce
2024-01-06T03:48:31 < Ecco> | == concatenation
2024-01-06T03:48:44 < Ecco> the message sent is 72 bits long
2024-01-06T03:48:48 < Ecco> which is… a lot
2024-01-06T03:48:56 < Ecco> so yeah, this could definitely be something like this
2024-01-06T03:49:10 < Ecco> why would they do this tho?
2024-01-06T03:49:18 < Ecco> I mean, the remote and the receiver have SWD headers
2024-01-06T03:49:31 < Ecco> so another way to proceed would be to "just" do a flash dump
2024-01-06T03:49:38 < Ecco> then reverse the whole thing
2024-01-06T03:49:46 < qyx> to prevent your neighbour messing with your visibility
2024-01-06T03:49:58 < Ecco> qyx: but it's replayable…
2024-01-06T03:50:08 < qyx> hm, yeah, that's called broken crypto
2024-01-06T03:50:12 < Ecco> :-D
2024-01-06T03:50:29 < Ecco> I don't know what's the best course of action
2024-01-06T03:50:43 < Ecco> now that (thanks to you guys) I've figured out the controller
2024-01-06T03:50:55 < qyx> dump it, disassemble it and try to figure out if the message is split
2024-01-06T03:50:55 < Ecco> honestly it doesn't seem that complicated to hook up an ESP
2024-01-06T03:51:09 < qyx> and if yes, where
2024-01-06T03:51:18 < Ecco> boy I've never done that
2024-01-06T03:51:22 < Ecco> I wouldn't even know where to start
2024-01-06T03:51:30 < qyx> the hash would be something much simpler than a PRF
2024-01-06T03:52:14 < qyx> (although in modern days we have simple hashes conforming to PRF requirements)
2024-01-06T03:52:37 < Ecco> what I'm thinking
2024-01-06T03:52:41 < Ecco> is that this would be a lot of work
2024-01-06T03:52:46 < Ecco> especially since I've never done this
2024-01-06T03:52:54 < Ecco> and that, eventually, the crypto is broken anyway
2024-01-06T03:53:03 < Ecco> (i.e. my neighbors can totally fuck with my blinds :-D)
2024-01-06T03:53:10 < Ecco> Now, that's very theoretical of course
2024-01-06T03:53:15 < Ecco> but on the other hand
2024-01-06T03:53:19 < fenugrec> depends, it can be simple as 'dump firmware because it's not read-protected', then binwalk 'oh look there's S-boxes or SHA256 constants'
2024-01-06T03:53:23 < Ecco> putting an ESP in seems way easier
2024-01-06T03:53:39 < Ecco> you lost me at "S-boxes'
2024-01-06T03:53:44 < qyx> heh
2024-01-06T03:53:45 < Ecco> also, would binwalk see shit?
2024-01-06T03:53:55 < Ecco> It's a Cortex-M
2024-01-06T03:54:04 < Ecco> binwalk is not going to find a JFFS2 fs :)
2024-01-06T03:54:13 < qyx> jffs2?
2024-01-06T03:54:17 < Ecco> (I've only ever used binwalk to reverse a linux embedded router)
2024-01-06T03:54:21 < fenugrec> you don't need to understand a crypto implementation to recognize it; binwalk recognizes tables and constants that are often used for hashes
2024-01-06T03:54:40 < Ecco> qyx: a filesystem popular on embedded linux. https://en.wikipedia.org/wiki/JFFS2
2024-01-06T03:54:48 < qyx> yes because jffs2 is compresssed
2024-01-06T03:55:02 < qyx> but the firmware isn't 
2024-01-06T03:55:09 < Ecco> would binwalk see *anything* in a Cortex-M firmware?
2024-01-06T03:55:14 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-06T03:55:20 < Ecco> I really thought it was targetted at embedded linux dumps
2024-01-06T03:55:25 < fenugrec> can you afford to spend 5 seconds to try ? IME always worth it
2024-01-06T03:55:28 < nomorekaki> just load it to ghidra
2024-01-06T03:55:35 < Ecco> yeah, ghidra this I've done
2024-01-06T03:55:37 < Ecco> but boy
2024-01-06T03:55:40 < Ecco> that's… hard
2024-01-06T03:55:44 < Ecco> I can try and do it
2024-01-06T03:56:04 < nomorekaki> click click and it poops out func_ func_ func_
2024-01-06T03:56:10 < Ecco> now that's the fun part where you guys are going to make fun of me
2024-01-06T03:56:12 < fenugrec> that's the spirit. It gets easier with practice
2024-01-06T03:56:24 < Ecco> remember that STlinkV3 I was so happy about?
2024-01-06T03:56:29 < Ecco> Well, that's my only SWD debugger
2024-01-06T03:56:34 < qyx> oh yes
2024-01-06T03:56:35 < Ecco> and it only works with STM32, right?
2024-01-06T03:56:36 < qyx> you are fucked now
2024-01-06T03:56:40 < Ecco> Yeah :-D
2024-01-06T03:56:41 < qyx> sorry
2024-01-06T03:56:45 < Ecco> you *did* warn me tho :-D
2024-01-06T03:57:02 < Ecco> well, I only wasted $10 on that thing
2024-01-06T03:57:06 < Ecco> and it's still cute
2024-01-06T03:57:15 < Ecco> oh, I may have a chinese clone of a STlinkv2
2024-01-06T03:57:30 < Ecco> ok, it's getting late tho
2024-01-06T03:57:32 < Ecco> I'm of to bed
2024-01-06T03:57:38 < Ecco> thank you guys for all the help
2024-01-06T03:57:42 < Ecco> that was *super* interesting
2024-01-06T03:57:48 < Ecco> I'll keep you guys posted if I make any progress
2024-01-06T03:58:06 < qyx> late, meh
2024-01-06T03:58:08 < qyx> 3 am here
2024-01-06T03:58:16 < qyx> it is too early I would say
2024-01-06T03:58:18 < Ecco> damn
2024-01-06T03:58:20 < Ecco> :-D
2024-01-06T03:58:22 < Ecco> 9 pm here :-D
2024-01-06T03:58:29 < Ecco> And I'm exhausted :-D
2024-01-06T03:59:45 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 260 seconds]
2024-01-06T04:41:14 -!- forsakenfirer [~Thunderbi@240e:471:2e90:1304:fd80:41c9:e601:7c47] has joined ##stm32
2024-01-06T04:41:29 -!- forsakenfirer [~Thunderbi@240e:471:2e90:1304:fd80:41c9:e601:7c47] has left ##stm32 []
2024-01-06T04:44:19 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-06T04:48:41 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 252 seconds]
2024-01-06T05:31:46 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-06T05:36:21 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 260 seconds]
2024-01-06T05:49:14 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-06T05:53:02 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-06T05:59:38 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 252 seconds]
2024-01-06T06:23:21 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-06T06:27:41 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 260 seconds]
2024-01-06T06:51:55 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-06T06:58:51 < \dev\ice> datasheet says - PA0 and PA1 can be both on ADC1 and ADC2. Is there any difference if I will use both on ADC1 or one on ADC1 and another on ADC2? 
2024-01-06T07:00:31 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-06T07:13:55 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-06T07:18:24 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 268 seconds]
2024-01-06T07:20:19 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-06T08:04:56 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-06T08:09:05 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 245 seconds]
2024-01-06T08:42:33 < qyx> yes the possibility of simultaneous sampling
2024-01-06T08:43:18 < qyx> also the max achievable sample rate
2024-01-06T08:52:13 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-06T08:56:33 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 256 seconds]
2024-01-06T08:59:42 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-06T09:33:17 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-06T09:37:46 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 268 seconds]
2024-01-06T10:22:35 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-06T10:26:53 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 240 seconds]
2024-01-06T10:35:48 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-06T11:04:46 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-06T11:09:44 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-06T11:24:22 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 256 seconds]
2024-01-06T11:25:38 -!- machinehum [~machinehu@213.55.226.137] has joined ##stm32
2024-01-06T12:15:21 -!- machinehum [~machinehu@213.55.226.137] has quit [Ping timeout: 260 seconds]
2024-01-06T12:36:49 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-06T12:40:13 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 246 seconds]
2024-01-06T12:46:13 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-06T12:56:44 -!- machinehum [~machinehu@213.55.225.66] has joined ##stm32
2024-01-06T12:58:13 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-7d92-6880-e322-4f3c.fixed6.kpn.net] has joined ##stm32
2024-01-06T14:36:38 -!- machinehum [~machinehu@213.55.225.66] has quit [Ping timeout: 252 seconds]
2024-01-06T14:36:38 -!- vekay [~vekay@user/vekay] has quit [Ping timeout: 252 seconds]
2024-01-06T14:38:03 -!- machinehum [~machinehu@213.55.225.66] has joined ##stm32
2024-01-06T14:39:46 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-06T14:48:53 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-7d92-6880-e322-4f3c.fixed6.kpn.net] has quit [Ping timeout: 260 seconds]
2024-01-06T15:07:06 -!- machinehum [~machinehu@213.55.225.66] has quit [Read error: Connection reset by peer]
2024-01-06T15:18:36 -!- iamzim [~iamzim@user/invaderzim] has joined ##stm32
2024-01-06T15:24:13 -!- machinehum [~machinehu@213.55.225.66] has joined ##stm32
2024-01-06T15:28:41 -!- iamzim [~iamzim@user/invaderzim] has left ##stm32 []
2024-01-06T16:07:12 -!- machinehum2 [~machinehu@213.55.225.66] has joined ##stm32
2024-01-06T16:07:12 -!- machinehum [~machinehu@213.55.225.66] has quit [Read error: Connection reset by peer]
2024-01-06T16:18:16 -!- machinehum2 [~machinehu@213.55.225.66] has quit [Ping timeout: 246 seconds]
2024-01-06T16:30:08 -!- machinehum [~machinehu@213.55.225.66] has joined ##stm32
2024-01-06T16:45:15 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-06T16:52:13 -!- machinehum [~machinehu@213.55.225.66] has quit [Ping timeout: 246 seconds]
2024-01-06T17:35:05 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8e90:3d40:7ba5:ce8f:6978] has joined ##stm32
2024-01-06T17:39:58 -!- machinehum [~machinehu@213.55.225.66] has joined ##stm32
2024-01-06T17:41:12 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8e90:3d40:7ba5:ce8f:6978] has quit [Remote host closed the connection]
2024-01-06T17:41:37 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8e90:e456:6d0a:d9c9:f7e2] has joined ##stm32
2024-01-06T17:44:22 -!- machinehum [~machinehu@213.55.225.66] has quit [Ping timeout: 264 seconds]
2024-01-06T17:56:21 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 268 seconds]
2024-01-06T17:56:37 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-06T18:06:51 -!- CygniX [~CygniX@user/CygniX] has left ##stm32 [Konversation terminated!]
2024-01-06T18:11:57 -!- CygniX [~CygniX@user/CygniX] has joined ##stm32
2024-01-06T18:23:32 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-06T18:23:34 < Laurenceb_> new copypasta just dropped
2024-01-06T18:23:36 < Laurenceb_> https://dspace.mit.edu/handle/1721.1/59192
2024-01-06T18:27:27 -!- machinehum [~machinehu@213.55.225.66] has joined ##stm32
2024-01-06T18:31:35 -!- machinehum [~machinehu@213.55.225.66] has quit [Ping timeout: 245 seconds]
2024-01-06T18:42:01 < karlp> fenugrec: if you don't need highspeed/qulity scope, there's a bunch of "DMMs" out of chian on ali now that do scope too... like https://www.aliexpress.com/item/33021370646.html and similar...
2024-01-06T18:45:06 < fenugrec> fnirsi has a fairly abysmal reputation
2024-01-06T18:49:33 < PaulFertser> I ordered https://www.aliexpress.com/item/1005005005692275.html . Hope it's good to have something on battery to be able to scope between arbitrary points of mains equipment.
2024-01-06T18:50:22 < PaulFertser> I mean yes it's a toy but often times even 5 MHz bandwidth is perfectly adequate.
2024-01-06T18:54:05 < karlp> fenugrec: there's differentbrands :) but yeah, YMMV as they say...
2024-01-06T19:03:31 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-75e2-b5c3-3c4d-dc66.fixed6.kpn.net] has joined ##stm32
2024-01-06T19:03:34 < jpa-> PaulFertser: with the uninsulated BNC on the probe and GND probably connected to the screw standoffs, i wouldn't go plugging it to arbitrary points of mains equipment
2024-01-06T19:16:02 < PaulFertser> jpa-: taking appropriate care of course but you're right
2024-01-06T19:16:43 < PaulFertser> Very good point about standoffs.
2024-01-06T19:17:29 < PaulFertser> An RCD should save my life no matter what right? :)
2024-01-06T19:17:35 -!- machinehum [~machinehu@213.55.225.66] has joined ##stm32
2024-01-06T19:17:56 < jpa-> yeah, though it might not be fast enough to save your keyboard
2024-01-06T19:56:11 -!- machinehum [~machinehu@213.55.225.66] has quit [Ping timeout: 252 seconds]
2024-01-06T20:05:59 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-06T20:10:58 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-75e2-b5c3-3c4d-dc66.fixed6.kpn.net] has quit [Ping timeout: 276 seconds]
2024-01-06T20:12:42 -!- machinehum [~machinehu@213.55.224.44] has joined ##stm32
2024-01-06T20:18:02 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Ping timeout: 250 seconds]
2024-01-06T20:22:05 -!- machinehum [~machinehu@213.55.224.44] has quit [Read error: Connection reset by peer]
2024-01-06T20:23:32 -!- machinehum [~machinehu@213.55.224.44] has joined ##stm32
2024-01-06T21:03:06 -!- scrts [~scrts@163.116.249.46] has quit [Ping timeout: 250 seconds]
2024-01-06T21:29:06 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 245 seconds]
2024-01-06T21:57:44 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 252 seconds]
2024-01-06T22:54:28 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8e90:e456:6d0a:d9c9:f7e2] has quit [Ping timeout: 246 seconds]
2024-01-06T23:21:20 -!- machinehum [~machinehu@213.55.224.44] has quit [Ping timeout: 268 seconds]
2024-01-06T23:23:25 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 256 seconds]
2024-01-06T23:41:53 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-1894-c215-97d0-8006.fixed6.kpn.net] has joined ##stm32
--- Day changed su tammi 07 2024
2024-01-07T00:13:16 -!- machinehum [~machinehu@213.55.224.44] has joined ##stm32
2024-01-07T00:17:26 -!- machinehum [~machinehu@213.55.224.44] has quit [Ping timeout: 252 seconds]
2024-01-07T00:37:20 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-07T00:41:30 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 268 seconds]
2024-01-07T01:04:31 -!- machinehum [~machinehu@213.55.224.44] has joined ##stm32
2024-01-07T01:08:58 -!- machinehum [~machinehu@213.55.224.44] has quit [Ping timeout: 264 seconds]
2024-01-07T01:50:47 -!- machinehum [~machinehu@213.55.224.44] has joined ##stm32
2024-01-07T01:55:17 -!- machinehum [~machinehu@213.55.224.44] has quit [Ping timeout: 260 seconds]
2024-01-07T02:28:05 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-1894-c215-97d0-8006.fixed6.kpn.net] has quit [Ping timeout: 240 seconds]
2024-01-07T02:38:37 -!- machinehum [~machinehu@213.55.224.44] has joined ##stm32
2024-01-07T02:42:53 -!- machinehum [~machinehu@213.55.224.44] has quit [Ping timeout: 260 seconds]
2024-01-07T03:25:26 -!- machinehum [~machinehu@213.55.224.44] has joined ##stm32
2024-01-07T03:29:56 -!- machinehum [~machinehu@213.55.224.44] has quit [Ping timeout: 252 seconds]
2024-01-07T04:14:05  * karlp lols. for the lulz?
2024-01-07T04:15:55 -!- machinehum [~machinehu@213.55.224.44] has joined ##stm32
2024-01-07T04:20:21 -!- machinehum [~machinehu@213.55.224.44] has quit [Ping timeout: 245 seconds]
2024-01-07T05:08:29 -!- machinehum [~machinehu@213.55.224.44] has joined ##stm32
2024-01-07T05:12:47 -!- machinehum [~machinehu@213.55.224.44] has quit [Ping timeout: 252 seconds]
2024-01-07T06:01:36 -!- machinehum [~machinehu@213.55.224.44] has joined ##stm32
2024-01-07T06:06:10 -!- machinehum [~machinehu@213.55.224.44] has quit [Ping timeout: 255 seconds]
2024-01-07T06:29:55 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-07T06:50:04 -!- machinehum [~machinehu@213.55.224.44] has joined ##stm32
2024-01-07T06:54:37 -!- machinehum [~machinehu@213.55.224.44] has quit [Ping timeout: 256 seconds]
2024-01-07T07:08:31 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-07T07:12:51 < octorian> Looks like I just managed to get CherryUSB up and running host-side on a Nucleo F446 board :-)
2024-01-07T07:13:01 < octorian> And the best part is that it works with hubs.  (the ST stack doesn't)
2024-01-07T07:15:15 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Read error: Connection reset by peer]
2024-01-07T07:15:41 < octorian> Next step is to see how hard it is to figure out writing some custom class drivers if I'm going to consider switching.
2024-01-07T07:16:13 < octorian> Though if I do switch, I'll also need to change my project from an F411 to an F446, or brave figuring out how to make CherryUSB work w/o DMA on the host side.
2024-01-07T07:36:24 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-07T07:39:55 -!- machinehum [~machinehu@213.55.224.44] has joined ##stm32
2024-01-07T07:41:05 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-07T07:44:22 -!- machinehum [~machinehu@213.55.224.44] has quit [Ping timeout: 264 seconds]
2024-01-07T08:32:58 -!- machinehum [~machinehu@213.55.224.44] has joined ##stm32
2024-01-07T08:37:00 -!- machinehum [~machinehu@213.55.224.44] has quit [Ping timeout: 245 seconds]
2024-01-07T08:39:32 < octorian> Wonderful...  for some reason, CherryUSB fails on the short config descriptor request with a data toggle error, when I plug in an FT232 dongle.  Though it seems to work fine with everything else I've tried so far.  (and the ST host stack doesn't hit that error)
2024-01-07T08:41:11 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-07T09:02:02 < octorian> And the way its behaving, it feels like its some sort of timing issue.
2024-01-07T09:04:20 < jpa-> time to put logic analyzer on the usb wires
2024-01-07T09:06:28 < octorian> By timing, I mean synchronization issue between the ISR and the routines that send the device requests.
2024-01-07T09:06:45 < octorian> But I'll have to dig into it more later.  Its about time to go to bed.
2024-01-07T09:08:46 -!- machinehum [~machinehu@213.55.224.44] has joined ##stm32
2024-01-07T09:09:01 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Ping timeout: 268 seconds]
2024-01-07T09:13:08 -!- machinehum [~machinehu@213.55.224.44] has quit [Ping timeout: 252 seconds]
2024-01-07T10:02:54 -!- machinehum [~machinehu@213.55.224.44] has joined ##stm32
2024-01-07T10:06:53 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 240 seconds]
2024-01-07T10:07:31 -!- machinehum [~machinehu@213.55.224.44] has quit [Ping timeout: 276 seconds]
2024-01-07T10:24:09 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-1840-b420-ea29-b7db.fixed6.kpn.net] has joined ##stm32
2024-01-07T10:50:56 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-07T10:53:53 -!- machinehum [~machinehu@213.55.224.44] has joined ##stm32
2024-01-07T10:58:11 -!- machinehum [~machinehu@213.55.224.44] has quit [Ping timeout: 252 seconds]
2024-01-07T11:07:46 -!- machinehum [~machinehu@213.55.224.44] has joined ##stm32
2024-01-07T11:12:27 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-07T11:14:52 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-1840-b420-ea29-b7db.fixed6.kpn.net] has quit [Ping timeout: 255 seconds]
2024-01-07T11:23:34 -!- machinehum [~machinehu@213.55.224.44] has quit [Ping timeout: 276 seconds]
2024-01-07T11:29:39 -!- machinehum [~machinehu@213.55.224.44] has joined ##stm32
2024-01-07T11:47:22 -!- machinehum [~machinehu@213.55.224.44] has quit [Ping timeout: 264 seconds]
2024-01-07T11:49:44 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-07T11:49:49 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-1840-b420-ea29-b7db.fixed6.kpn.net] has joined ##stm32
2024-01-07T12:24:43 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8e90:caeb:b35d:cd1:3d1] has joined ##stm32
2024-01-07T12:30:51 -!- crazy_imp [~mj@user/crazy-imp/x-1371519] has joined ##stm32
2024-01-07T12:39:09 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-1840-b420-ea29-b7db.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-07T12:39:50 < crazy_imp> hi, i've got a gd32f350 here - trying to dump the firmware with the st-flash tool. it doesn't refuse to dump, but at the start of every 1kB (page size) it i get identical bytes (80 00 00 00 03 00 03 01) followed by zeros until the end of the page. is this because maybe the security bit is set to prevent reading the code (or does it reject reading at all if it's set?)?
2024-01-07T12:58:14 < jpa-> there are many tools called "st-flash" or similar, is this going through SWD or serial or USB or what?
2024-01-07T13:02:17 < crazy_imp> jpa-: st-flash from https://github.com/stlink-org/stlink , usb st-link v2 clone -> swd -> gd32f350
2024-01-07T13:03:43 < PaulFertser> ST forked texane stlink? Heh, interesting.
2024-01-07T13:04:55 < PaulFertser> I'd say just connect with OpenOCD and see with "mdw". It's likely that the flash is just read-protected.
2024-01-07T13:06:45 < qyx> also I have not seen f350
2024-01-07T13:06:50 < qyx> oh gd
2024-01-07T13:11:59 < crazy_imp> according to https://i.imgur.com/88KeYR0.png i get 0xbb followed by 0x44 (inverted 0xbb), so the code security feature is on :|
2024-01-07T13:17:32 < jpa-> sometimes the code security can be hacked
2024-01-07T13:29:26 -!- qyx [~qyx@84.245.120.20] has quit [Ping timeout: 252 seconds]
2024-01-07T13:31:28 -!- qyx [~qyx@84.245.121.170] has joined ##stm32
2024-01-07T14:01:34 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-1840-b420-ea29-b7db.fixed6.kpn.net] has joined ##stm32
2024-01-07T14:20:26 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-07T14:28:12 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-07T15:16:24 < crazy_imp> jpa-: guess i have tondig deeper in this direction - talk about bypassing the option bytes i found https://offzone.moscow/upload/iblock/0a5/nad1d86e3ah3ayx38ue56vxbh2j07kd4.pdf
2024-01-07T15:21:05 < nomorekaki> what are we hacking today?
2024-01-07T15:22:18 < nomorekaki> is there macro to indicate if printf is present?
2024-01-07T15:22:47 < nomorekaki> directly indicate
2024-01-07T15:32:43 < crazy_imp> nomorekaki: me? a synth, want to write my own firmware for it, but having a backup of the original code would be great. on the other hand, i could desolder the chip and put in a new one
2024-01-07T15:34:31 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-07T16:03:46 < zyp> PaulFertser, I don't think stlink-org is official :)
2024-01-07T16:23:32 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-07T16:37:07 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-07T16:44:06 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8e90:caeb:b35d:cd1:3d1] has quit [Remote host closed the connection]
2024-01-07T16:44:31 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8e90:86e1:baba:1edd:d78b] has joined ##stm32
2024-01-07T16:51:59 < jbo> I'm currently looking at absolute encoders:  https://www.hengstler.de/gfx/file/shop/encoder/AD34/Datasheet_AD34_en.pdf
2024-01-07T16:52:09 < jbo> they say:  absolute accuracy +-35"
2024-01-07T16:52:16 < jbo> what is that? arc seconds?
2024-01-07T17:01:28 < Steffanx> Would think so..
2024-01-07T17:14:41 < fenugrec> UTC or astronomic arcseconds ?
2024-01-07T17:14:57 < fenugrec> better hope it doesn't have leap-arc-seconds
2024-01-07T17:17:15 < Steffanx> Good morning fenugrec :)
2024-01-07T17:17:47 < fenugrec> thank you
2024-01-07T17:29:06 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-07T17:29:39 < Laurenceb_> before freebsd https://tab2.team23.org/~feh39068/NetBSD/images/ceren-daemonbabe/bsd.jpg , after freebsd https://pbs.twimg.com/media/Bi95ucXCEAASceJ?format=png&name=900x900
2024-01-07T17:54:23 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-07T17:59:55 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Quit: Client closed]
2024-01-07T18:29:58 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 276 seconds]
2024-01-07T19:39:18 < octorian> Well, good news on the CherryUSB front...  I noticed that the latest code on master had reordered a few things and added some additional synchronization stuff (as part of their multi-host support work), so I decided to give it a try to see how it worked.
2024-01-07T19:39:38 < octorian> And guess what?  The strange data toggle error no longer happens with that FTDI dongle :-)
2024-01-07T19:40:50 < octorian> So I guess this is step 1.  Step 2 is actually learning how to write a custom class driver against this stack.  (gotta port over drivers for a whole bunch of USB<->Serial chips, but maybe first I'll try writing a driver for the FT260 USB<->I2C thing I really want to test.)
2024-01-07T19:47:33 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-1840-b420-ea29-b7db.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-07T20:13:01 -!- machinehum [~machinehu@213.55.226.15] has joined ##stm32
2024-01-07T20:40:42 -!- boB_K7IQ [~boB_K7IQ@184-98-64-136.phnx.qwest.net] has quit []
2024-01-07T20:43:32 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-1840-b420-ea29-b7db.fixed6.kpn.net] has joined ##stm32
2024-01-07T21:10:12 < ColdKeyboard> Anyone knows what the HS code is for (DIY) PCB module?
2024-01-07T21:16:34 < zyp> I use 8473.
2024-01-07T21:16:35 < zyp> 30.11
2024-01-07T21:16:44 < zyp> 8473.30.11
2024-01-07T21:17:03 < zyp> assuming you mean an assembled PCB
2024-01-07T21:19:02 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-07T21:22:01 -!- boB_K7IQ [~boB_K7IQ@184-98-64-136.phnx.qwest.net] has joined ##stm32
2024-01-07T21:28:15 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-07T21:28:56 < nomorekaki> what is HS?
2024-01-07T21:29:11 < zyp> harmonized system
2024-01-07T21:29:34 < zyp> it's used for customs declarations
2024-01-07T21:29:34 < nomorekaki> :O
2024-01-07T21:29:45 < nomorekaki> yes
2024-01-07T21:34:59 < jbo> hmm, I have an LSE crystal that specs load of 6pf -> loading caps are 12pf. I already have 10pf in the design elsewhere. I assume that will be fine?
2024-01-07T21:35:36 < zyp> sounds like you risk loading it a bit too much
2024-01-07T21:35:45 < zyp> your clock might end up running a little slow
2024-01-07T21:35:56 < jbo> alright, I'll get some 12pf caps on there then D:
2024-01-07T21:36:10 < zyp> oh, wait
2024-01-07T21:36:23 < zyp> you mean you consider using 10p for it?
2024-01-07T21:36:30 < fenugrec> or put caps in series
2024-01-07T21:36:35 < jbo> yes, 10pf instead of 12pf
2024-01-07T21:36:51 < jbo> this is my crystal: https://www.mouser.ch/ProductDetail/ABRACON/ABS07-120-32.768KHZ-T?qs=z9S2%252BbP5pWhyNaQ4AovDCg%3D%3D
2024-01-07T21:36:55 < zyp> yeah, 10pF is probably more suitable than 12pF
2024-01-07T21:36:59 < jbo> is says load capacitance 6pf
2024-01-07T21:37:12 < jbo> and Cload = c1*c2/(c1+c2)
2024-01-07T21:37:14 < zyp> traces add some capacitance too
2024-01-07T21:37:20 < jbo> which would mean 12pf caps, right?
2024-01-07T21:37:37 < jbo> but that would add extra parts to the BOM and I already have 10pF C0G elsewhere in the design
2024-01-07T21:37:50 < zyp> https://github.com/karlp/zypsnips/blob/master/crystal-load-wisdom.txt#L15
2024-01-07T21:38:10 < zyp> 2pF is probably a reasonable amount for «some»
2024-01-07T21:38:41 < jbo> well I guess I could just take the proper 12pF and replace the 10pF in the other part of the design as that is just decoupling cap for a cellular modem :p
2024-01-07T21:57:33 -!- iamzim [~iamzim@user/invaderzim] has joined ##stm32
2024-01-07T21:58:11 -!- iamzim [~iamzim@user/invaderzim] has quit [Quit: I AM ZIM]
2024-01-07T22:04:10 < Steffanx> jbo missed the part about stray capacitance? 
2024-01-07T22:16:30 -!- machinehum [~machinehu@213.55.226.15] has quit [Ping timeout: 260 seconds]
2024-01-07T22:20:16 -!- machinehum [~machinehu@213.55.226.15] has joined ##stm32
2024-01-07T22:39:56 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 268 seconds]
2024-01-07T23:09:32 -!- machinehum [~machinehu@213.55.226.15] has quit [Ping timeout: 268 seconds]
2024-01-07T23:10:46 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8e90:86e1:baba:1edd:d78b] has quit [Ping timeout: 245 seconds]
2024-01-07T23:11:14 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8e90:1759:4f8f:24e7:ef14] has joined ##stm32
2024-01-07T23:15:52 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-07T23:25:03 -!- flom84 [~flom84@user/flom84] has joined ##stm32
2024-01-07T23:45:59 -!- machinehum [~machinehu@213.55.226.15] has joined ##stm32
2024-01-07T23:50:31 -!- machinehum [~machinehu@213.55.226.15] has quit [Ping timeout: 256 seconds]
--- Day changed ma tammi 08 2024
2024-01-08T00:02:53 -!- flom84 [~flom84@user/flom84] has quit [Remote host closed the connection]
2024-01-08T00:20:14 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Ping timeout: 250 seconds]
2024-01-08T00:25:58 < nomorekaki> ventYl: are you around?
2024-01-08T00:33:09 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 256 seconds]
2024-01-08T00:34:17 -!- machinehum [~machinehu@213.55.226.15] has joined ##stm32
2024-01-08T00:38:34 -!- machinehum [~machinehu@213.55.226.15] has quit [Ping timeout: 255 seconds]
2024-01-08T01:21:46 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-1840-b420-ea29-b7db.fixed6.kpn.net] has quit [Ping timeout: 255 seconds]
2024-01-08T01:42:55 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8e90:1759:4f8f:24e7:ef14] has quit [Ping timeout: 255 seconds]
2024-01-08T02:09:48 -!- Ad0 [~Ad0@93.124.245.194] has joined ##stm32
2024-01-08T02:12:59 < qyx> jpa-: thats a bypass for the modem, you mean 10p, 33n, 100n?
2024-01-08T02:13:20 < qyx> they are probably selected with some math
2024-01-08T02:13:38 < qyx> but for lse fukit, just use 10p instead of 12p
2024-01-08T02:13:53 < qyx> you will be syncing your clock either way
2024-01-08T02:19:50 < qyx> sry jbo ^
2024-01-08T02:22:25 < jbo> aye, thanks!
2024-01-08T02:22:40 < jbo> qyx, also yes, that is 100n, 33p 10p
2024-01-08T02:22:44 < jbo> from quectel ref design
2024-01-08T02:47:29 -!- Ad0 [~Ad0@93.124.245.194] has left ##stm32 [Leaving]
2024-01-08T04:05:44 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-08T04:09:32 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 268 seconds]
2024-01-08T05:11:43 -!- crazy_imp [~mj@user/crazy-imp/x-1371519] has quit [Ping timeout: 255 seconds]
2024-01-08T05:13:37 -!- crazy_imp [~mj@user/crazy-imp/x-1371519] has joined ##stm32
2024-01-08T06:28:26 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Remote host closed the connection]
2024-01-08T07:32:35 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-08T07:52:31 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-08T07:55:45 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-935-392f-105-1bca.fixed6.kpn.net] has joined ##stm32
2024-01-08T08:37:38 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-935-392f-105-1bca.fixed6.kpn.net] has quit [Ping timeout: 260 seconds]
2024-01-08T08:45:35 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-08T09:23:50 -!- rob_w_ [~bob@2001:a61:6072:1f01:16d2:91d2:1ce5:7958] has joined ##stm32
2024-01-08T09:23:57 -!- rob_w_ [~bob@2001:a61:6072:1f01:16d2:91d2:1ce5:7958] has quit [Remote host closed the connection]
2024-01-08T10:09:13 -!- boB_K7IQ [~boB_K7IQ@184-98-64-136.phnx.qwest.net] has quit [Ping timeout: 276 seconds]
2024-01-08T10:44:45 -!- machinehum [~machinehu@213.55.226.15] has joined ##stm32
2024-01-08T10:49:13 -!- machinehum [~machinehu@213.55.226.15] has quit [Ping timeout: 255 seconds]
2024-01-08T11:10:53 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has joined ##stm32
2024-01-08T11:37:42 -!- boB_K7IQ [~boB_K7IQ@184-98-64-136.phnx.qwest.net] has joined ##stm32
2024-01-08T11:43:00 -!- machinehum [~machinehu@213.55.226.15] has joined ##stm32
2024-01-08T12:03:52 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-08T12:08:04 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 268 seconds]
2024-01-08T12:49:22 -!- machinehum [~machinehu@213.55.226.15] has quit [Ping timeout: 255 seconds]
2024-01-08T12:51:13 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-08T14:22:12 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 268 seconds]
2024-01-08T14:23:53 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-08T14:30:20 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 245 seconds]
2024-01-08T14:37:38 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-08T14:43:43 -!- machinehum2 [~machinehu@213.55.226.74] has joined ##stm32
2024-01-08T14:44:17 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 256 seconds]
2024-01-08T15:43:56 -!- skz81_ is now known as skz81
2024-01-08T16:26:52 -!- machinehum2 [~machinehu@213.55.226.74] has quit [Ping timeout: 276 seconds]
2024-01-08T16:31:38 < karlp> found one of these today: https://www.delock.com/produkt/84804/merkmale.html?g=759 reverisble micro-b...
2024-01-08T16:31:42 < karlp> weird diamond shape
2024-01-08T16:48:15 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-08T17:07:12 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-08T17:15:13 < jbo> yeah delock makes some weird ass shit
2024-01-08T17:15:23 < jbo> I have those EASY-USB 2.0 A connectors
2024-01-08T17:23:25 < nomorekaki> hmm now I need to do extern "C" to my code
2024-01-08T17:27:54 < nomorekaki> just put everything in that extern?
2024-01-08T17:27:59 < nomorekaki> includes and all
2024-01-08T17:28:48 < jpa-> https://www.newnex.com/images/waterproof_photo_1.png  this is HARD-USB 3.0
2024-01-08T17:32:16 -!- skz81 [~skz81@vps-68d3ea17.vps.ovh.net] has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
2024-01-08T17:32:33 -!- skz81 [~skz81@vps-68d3ea17.vps.ovh.net] has joined ##stm32
2024-01-08T17:41:11 < machinehum> https://imgur.com/a/quVcMLk
2024-01-08T17:41:55 < machinehum> What do you guys think? Will my jank RTL8723 work perfectly the first time?
2024-01-08T17:42:32 < machinehum> hmm I guess I should add my stiching vias
2024-01-08T17:44:47 < nomorekaki> you calculated impendance for that track?
2024-01-08T17:45:34 < nomorekaki> oh I have small screen
2024-01-08T17:46:04 < nomorekaki> how about copper clearance? is that 0.127?
2024-01-08T17:46:35 < nomorekaki> your ground pins don't have thermal reliefs
2024-01-08T17:47:26 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-08T17:52:51 < machinehum> Yes they do
2024-01-08T17:53:19 < machinehum> It's 0.1mm
2024-01-08T17:53:39 < machinehum> I seem to remember a 50ohm coplanar waveguide being skinner
2024-01-08T17:55:19 < machinehum> Maybe it was a Microstrip with a thinner PCB
2024-01-08T17:55:31 < machinehum> Or just thinner pcb in general...
2024-01-08T18:06:07 < karlp> machinehum: why no u.FL?
2024-01-08T18:06:34 < karlp> it will owrk or not, indpendento of that RF trace.
2024-01-08T18:06:40 < karlp> is that a 8723 in sdio mode?
2024-01-08T18:21:39 < machinehum> Yeah
2024-01-08T18:21:41 < machinehum> RTL8723DS
2024-01-08T18:21:59 < machinehum> I want the sturdyness of a sma
2024-01-08T18:32:53 < Ecco> Ok, mystery of the day
2024-01-08T18:32:53 < Ecco> https://i.imgur.com/Sj2qlQx.jpg
2024-01-08T18:32:59 < Ecco> This is what I suppose is a MEMS accelerometer
2024-01-08T18:33:11 < Ecco> would it be possible that it would have been "re-branded"?
2024-01-08T18:33:18 < Ecco> Look at how shitty the markings are
2024-01-08T18:33:31 < Ecco> It looks like some kind of a botched QR code (which I can't decode)
2024-01-08T18:33:41 < Ecco> and a "TP6823" identifier, which yields zero result
2024-01-08T18:35:42 < Ecco> I did find this NXP one with a similar package https://mm.digikey.com/Volume0/opasdata/d220001/medias/docus/795/MMA7660FC.pdf
2024-01-08T18:39:05 < Ecco> So this chip is used as a motion sensor in a "smart lamp"
2024-01-08T18:39:17 < Ecco> the lamp is powered by 5V from USB VBUS
2024-01-08T18:39:26 < Ecco> (using a USB connector, no data)
2024-01-08T18:39:35 < Ecco> Now, this chip received 3.3V on one pin
2024-01-08T18:39:39 < Ecco> *and* 5.0V on another one
2024-01-08T18:39:53 < Ecco> That seems super weird to me, would you guys have any idea what's up?
2024-01-08T18:41:05 < Ecco> The pinout would kind of match the NXP mems
2024-01-08T18:41:14 < Ecco> with AVDD = 3.3V and DVDD = 5.0V
2024-01-08T18:41:22 < Ecco> and SDA/SCL are indeed +5V
2024-01-08T18:41:28 < Ecco> so it would be doing I2C at 5V?
2024-01-08T18:41:42 < Ecco> (that's *not* in the spec of the NXP part tho)
2024-01-08T18:44:29 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has quit [Ping timeout: 252 seconds]
2024-01-08T18:49:59 < Ecco> ok my mistake
2024-01-08T18:50:01 < Ecco> not a MEMS
2024-01-08T18:50:06 < Ecco> probably some kind of a shit PMIC
2024-01-08T18:50:12 < Ecco> maybe even just an LDO
2024-01-08T18:50:26 < Ecco> (the MEMS was somewhere else, under a metal shield)
2024-01-08T18:54:54 < Ecco> ok so the actual MEMS is marked "7" and then "C03"
2024-01-08T18:54:59 < Ecco> not super helpful…
2024-01-08T18:56:37 < englishman> ecco taht does not look like a MEMS package, usually they are in an LGA due to packaging requirements to not stress the components
2024-01-08T18:56:53 < englishman> TP6823 could be a cheap 8051
2024-01-08T18:58:18 < englishman> lol no that one is an 80pin
2024-01-08T19:00:16 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 276 seconds]
2024-01-08T19:03:52 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-08T19:07:19 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-08T19:25:53 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 260 seconds]
2024-01-08T19:31:41 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 240 seconds]
2024-01-08T19:55:25 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-08T20:10:55 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-08T20:17:47 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-a4ae-4923-692e-c77e.fixed6.kpn.net] has joined ##stm32
2024-01-08T21:26:45 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-08T21:26:49 < Laurenceb_> suppppp
2024-01-08T21:27:06 < Laurenceb_> is it normal to read 470ohms to GND on an unpowered stm32 gpio pin?
2024-01-08T21:27:54 < jpa-> depends on test voltage
2024-01-08T21:33:33 < Laurenceb_> hmm fair point
2024-01-08T21:33:39 < Laurenceb_> this only happens on one of the GPIOs
2024-01-08T21:34:07 < Laurenceb_> maybe there is a board fault, tomorrow I will remove PCB from enclosure its mounted inside
2024-01-08T21:34:33 < Laurenceb_> symptom is the GPIOs never go high, but other pins on the micro (including on same ports) seem to work ok
2024-01-08T21:35:12 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
2024-01-08T21:35:34 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2024-01-08T21:37:40 < Laurenceb_> actually this could be a bug in either stm32duino r my codez
2024-01-08T21:39:02 < Laurenceb_> yeah working GPIOs all use this format: digitalWrite(pinNametoDigitalPin(HIGH_VOLTAGE_EN),voltage_invert?LOW:HIGH);
2024-01-08T21:39:40 < Laurenceb_> failing GPIOs all use this format: digitalWrite(RELAY2,(mask&0x02)?HIGH:LOW);
2024-01-08T21:40:35 < Laurenceb_> yet they are defined as: #define RELAY2 PB12         #define HIGH_VOLTAGE_EN PC_7
2024-01-08T21:40:41 < Laurenceb_> so should both work.. odd
2024-01-08T21:52:36 < Laurenceb_> oh sheeeettt
2024-01-08T21:52:53 < Laurenceb_> second format should take the tarduino land pin numbering
2024-01-08T21:52:56 < Laurenceb_> epic fail
2024-01-08T21:53:35 < Laurenceb_> so PB12 should be D28
2024-01-08T21:56:36 < Laurenceb_> my fail was touching the tarduino
2024-01-08T22:00:04 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 268 seconds]
2024-01-08T22:05:06 < Laurenceb_> hmm but PB12 should be defined as 28, confusing
2024-01-08T22:06:52 < PaulFertser> Can't use pinNametoDigitalPin ?
2024-01-08T22:20:09 < Laurenceb_> yeah, dont have hardware atm, just looking over firmware and test data
2024-01-08T22:26:38 < PaulFertser> Is mask correct?
2024-01-08T22:26:49 < catphish> my experience is that it's never a chip hardware fault :)
2024-01-08T22:34:10 < Laurenceb_> yeah its too much of a coincidence that the "failing" pins use the different method in the code
2024-01-08T22:34:31 < Laurenceb_> but I'd like to work out why its wrong
2024-01-08T22:38:43 < Laurenceb_> looks like maybe my variant file is not correct
2024-01-08T22:38:59 < Laurenceb_> digitalWrite cant work out what port to use
2024-01-08T22:39:32 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:ed49:9df8:9f7:4e9c] has joined ##stm32
2024-01-08T22:46:12 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-08T22:56:09 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 256 seconds]
2024-01-08T22:57:38 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-08T23:26:20 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Quit: Client closed]
2024-01-08T23:27:07 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-08T23:30:06 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-08T23:42:52 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Quit: Client closed]
2024-01-08T23:43:02 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-08T23:45:35 < Ecco> It's weird, my (cheap-ish but not too crappy) oscilloscope doesn't decode I2C like my (dirty cheap chinese) logic analyzer
2024-01-08T23:45:43 < Ecco> Like, I'm sniffing the same bus
2024-01-08T23:45:48 < Ecco> but they don't give the same output :-/
2024-01-08T23:47:01 < Ecco> What's even weirder is that the captured waveforms do match (well, ofc the logic analyzer sees the signal in binary, but the timings are identical)
2024-01-08T23:49:08 < Ecco> Let me grab a screenshot
2024-01-08T23:49:11 < Ecco> that's too weird
2024-01-08T23:50:58 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 264 seconds]
2024-01-08T23:54:46 < Ecco> https://i.imgur.com/7DpVacN_d.webp?maxwidth=1520&fidelity=grand
2024-01-08T23:56:56 < Ecco> I mean, the alignment is not perfect, but still
2024-01-08T23:58:58 < Ecco> ok, here the alignment is good
2024-01-08T23:58:59 < Ecco> https://i.imgur.com/fPIC5OB.png
2024-01-08T23:59:07 < Ecco> Rigol says Read address 0x5B
2024-01-08T23:59:14 < Ecco> Chinese LA says Read 0x2D
2024-01-08T23:59:17 < Ecco> WTFBBQ
2024-01-08T23:59:27 < octorian> Is signal 1 supposed to be SCK?
2024-01-08T23:59:36 < Ecco> Yes
2024-01-08T23:59:42 < octorian> Because that doesn't look like a clean clock signal.
2024-01-08T23:59:53 < Ecco> Agreed
2024-01-08T23:59:55 < octorian> Also, isn't I2C supposed to be high when idle?  That trace seems to start low.
--- Day changed ti tammi 09 2024
2024-01-09T00:00:07 < Ecco> It's labeled "I2C-SCL" on the PCB tho
2024-01-09T00:00:23 < Ecco> octorian: also true
2024-01-09T00:00:27 < Ecco> Let me check this
2024-01-09T00:00:29 < PaulFertser> 5B/2 = 2D
2024-01-09T00:00:34 < octorian> Also see what you're triggering on.
2024-01-09T00:00:43 < octorian> Normally to capture I2C, I trigger on the falling edge of SCL.
2024-01-09T00:00:49 < zyp> PaulFertser, was about to say
2024-01-09T00:01:08 < Ecco> I was actually about to compare 0x5D and 0x2D in binary notation :)
2024-01-09T00:01:18 < Ecco> Ok, so maybe it's baing sampled in a shifted way?
2024-01-09T00:01:25 < Ecco> Like a hardware division by 2 ? :-D
2024-01-09T00:01:27 < zyp> no, it's just 7 vs 8 bit notation
2024-01-09T00:01:43 < Ecco> oh
2024-01-09T00:01:50 < Ecco> I mean, I'm new to I2C
2024-01-09T00:01:59 < Ecco> but none of the decoder seem to offer any configuration
2024-01-09T00:02:00 < zyp> some people include the r/w bit in the address, and then you get 5A/5B
2024-01-09T00:02:06 < zyp> if you strip that off, you get 2D
2024-01-09T00:02:10 < Ecco> oh
2024-01-09T00:02:30 < zyp> the latter is the sane way to write i2c addrs
2024-01-09T00:02:33 < Ecco> Actually on the Rigol there *is* an option labeled "R/W : With/Without"
2024-01-09T00:02:45 < zyp> set it to without :)
2024-01-09T00:02:51 < Ecco> zyp: ok, so which one do you recommend I use, and why?
2024-01-09T00:02:54 < octorian> When I'm looking at stuff like this on my scope, trigger settings are separate from serial decode settings.
2024-01-09T00:02:57 < zyp> 7-bit
2024-01-09T00:03:08 < Ecco> ok
2024-01-09T00:03:11 < zyp> it doesn't make sense to think of read and write as separate addrs
2024-01-09T00:03:11 < octorian> I think your first task should be to capture the correct I2C waveform, then look at the decoded data later.
2024-01-09T00:03:35 < PaulFertser> For consistency. You set some specific 7-bit address for an I2C slave by strap pins or something and use it consistently for reading and writing.
2024-01-09T00:03:52 < PaulFertser> It makes little sense to encode r/w as part of the address of a single device.
2024-01-09T00:03:59 < zyp> exactly
2024-01-09T00:04:30 < PaulFertser> Of course it's used that way in Linux, in i2c-tools etc.
2024-01-09T00:05:09 < zyp> I figure the only reason some people do it is because it's in the LSB slot of the first byte sent, so it's easy to think of that as the «address byte»
2024-01-09T00:05:25 < zyp> if it was in the MSB slot, it'd be much less common
2024-01-09T00:05:39 < Ecco> ok guys that fixed it!
2024-01-09T00:05:42 < Ecco> thanks
2024-01-09T00:11:17 < Ecco> Another question: I just got this Rigol scope
2024-01-09T00:11:25 < Ecco> it comes with a 1x/10x probe
2024-01-09T00:11:41 < Ecco> I've seen a video where a guy explain that you'll most likely always want to use it as 10x (fine)
2024-01-09T00:11:49 < zyp> that's my understanding too
2024-01-09T00:11:53 < Ecco> question: is it possible to tell the scope to default to 10x gain on the probe?
2024-01-09T00:12:20 < zyp> what do you mean? once you set it to 10x doesn't it stay that way until you change it?
2024-01-09T00:12:25 < Ecco> (I realize it's a very Rigol-specific question)
2024-01-09T00:12:34 < Ecco> well… no, apparently when I turn off the scope and turn it back on
2024-01-09T00:12:36 < Ecco> it reverts to 1x
2024-01-09T00:12:45 < zyp> my rigols both keeps whatever settings I used last
2024-01-09T00:13:06 < Ecco> hmm
2024-01-09T00:13:10 < Ecco> ok now I feel dum
2024-01-09T00:13:16 < Ecco> The damn thing takes forever to boot
2024-01-09T00:13:17 < Ecco> but let me try
2024-01-09T00:13:25 < zyp> which one do you have?
2024-01-09T00:13:31 < Ecco> DHO802
2024-01-09T00:13:36 < zyp> oh, the new one
2024-01-09T00:13:37 < Ecco> I know, it's only 2 probes
2024-01-09T00:13:50 < Ecco> *but* it's also only $300
2024-01-09T00:14:00 < Ecco> ok, I turned it off
2024-01-09T00:14:04 < Ecco> let me turn it back on
2024-01-09T00:14:08 < Ecco> now, it's a great little toy
2024-01-09T00:14:12 < Ecco> but boy the fan sure is annoying
2024-01-09T00:14:26 < Ecco> I wonder why those still have a fan…
2024-01-09T00:14:46 < zyp> I've got a mso5k, so roughly a generation older or so
2024-01-09T00:14:54 < zyp> and it remembers everything
2024-01-09T00:15:25 < Ecco> That's what she… well, does :-D
2024-01-09T00:15:29 < zyp> I've had ch3/4 set to show amps instead of volts for a few months now, I use them with current clamp probes
2024-01-09T00:15:38 < Ecco> Damn
2024-01-09T00:15:41 < Ecco> ok, just tried it
2024-01-09T00:15:46 < Ecco> sure enough, it reverted to 1x
2024-01-09T00:16:26 < Steffanx> Checked for firmware updates on the thing? Sounds super annoying.
2024-01-09T00:16:35 < Ecco> Steffanx: Yeah, I might need to
2024-01-09T00:16:41 < Ecco> Mine comes with firmware 1.0
2024-01-09T00:17:57 < Ecco> The touch interface makes the whole thing a lot easier to discover for a noob
2024-01-09T00:17:58 < zyp> Ecco, check Utility -> System -> Power On
2024-01-09T00:18:04 < zyp> you've probably got it set to Default
2024-01-09T00:18:07 < zyp> https://bin.jvnv.net/file/8AenJ.png
2024-01-09T00:18:28 < Ecco> Daaamn
2024-01-09T00:18:37 < Ecco> Ok, it's in a different sub-menu
2024-01-09T00:18:39 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Quit: Client closed]
2024-01-09T00:18:52 < Ecco> It's in "Setup > Load Last" and the options are "Default / Load"
2024-01-09T00:18:58 < Ecco> ok, that's most likely what this is
2024-01-09T00:19:08 < Ecco> that's a pretty shitty copy tho
2024-01-09T00:19:12 < Ecco> ok, let me try!
2024-01-09T00:20:36 < Ecco> Damn, thanks zyp!
2024-01-09T00:20:39 < Ecco> That's what it was
2024-01-09T00:20:45 < Ecco> Guess I'll need to read the whole user manual…
2024-01-09T00:20:45 < zyp> nice
2024-01-09T00:20:57 < Ecco> Thank you very much tho!
2024-01-09T00:21:13 < Ecco> That being said, I still like it
2024-01-09T00:21:24 < Ecco> I used to have an older model
2024-01-09T00:21:27 < Ecco> 1054Z IIRC
2024-01-09T00:21:33 < zyp> I don't think I've done that, but I think I looked through all the menues some time I was bored
2024-01-09T00:21:37 < Ecco> the touch interface changes everything in terms of discoverability
2024-01-09T00:21:49 < Ecco> well, I did look at all the menus too
2024-01-09T00:21:56 < Ecco> but many of them make no sense
2024-01-09T00:22:07 < Ecco> (i.e. you need to have the user manual on the side to understand what the option does)
2024-01-09T00:22:10 < zyp> I've got a 1042c
2024-01-09T00:22:18 < zyp> this was such a nice upgrade
2024-01-09T00:22:19 < Ecco> I guess the touch interface doesn't make much difference for a pro user
2024-01-09T00:22:25 < karlp> did ecco get that 0x2d << 1 with a write bit is 0x5b?
2024-01-09T00:22:41 < Steffanx> Yessir 
2024-01-09T00:22:41 < karlp> yup, nvm missed it.
2024-01-09T00:22:47 < Ecco> karlp: yes, thanks for checking tho ;:)
2024-01-09T00:23:09 -!- boB_K7IQ [~boB_K7IQ@184-98-64-136.phnx.qwest.net] has quit []
2024-01-09T00:23:15 < zyp> touch interface is convenient, but apart from entering stuff in the on screen numpad I don't think I use it much
2024-01-09T00:23:35 < Ecco> The MSO5k looks dope :)
2024-01-09T00:23:39 < Ecco> Different kind of budget tho
2024-01-09T00:23:56 < Ecco> I mnea, it's not *that* pricey tho
2024-01-09T00:24:23 < Ecco> Apparently you can wifi-ize those by adding an el-cheapo WiFi-USB dongle
2024-01-09T00:24:27 < Ecco> Might come in handy
2024-01-09T00:24:47 < zyp> AIUI the new ones like yours have better resolution
2024-01-09T00:24:50 < zyp> 12-bit
2024-01-09T00:24:50 < Ecco> Again, I wonder why this is not standard
2024-01-09T00:24:56 < zyp> not sure how much of a difference that makes
2024-01-09T00:24:59 < karlp> Ecco: so... the fan is loud in the dho8xx?
2024-01-09T00:25:04 < karlp> we're looking at one for the office.
2024-01-09T00:25:10 < zyp> loud is relative
2024-01-09T00:25:11 < Ecco> karlp: I don't know
2024-01-09T00:25:13 < karlp> looking at a dho9xx something.
2024-01-09T00:25:20 < Ecco> I'm super sensitive to noise (aka I hate it)
2024-01-09T00:25:24 < Ecco> Like my PC
2024-01-09T00:25:34 < Ecco> I OCDed the crap out of picking silent parts
2024-01-09T00:25:51 < Ecco> And well, yes, it's virtually silent (unless I max out the CPU/GPU)
2024-01-09T00:25:58 < Ecco> the DHO800, well… I can hear it
2024-01-09T00:26:00 < Ecco> it's not horrible
2024-01-09T00:26:05 < zyp> mso5k fan is noticeable, but much less noisy than old 1042c
2024-01-09T00:26:08 < Ecco> I would recommend you buy it off of Amazon
2024-01-09T00:26:13 < zyp> I don't really mind it at all
2024-01-09T00:26:13 < Ecco> and if you don't like the sound level, just return it
2024-01-09T00:26:22 < zyp> I don't think they've got amazon in iceland
2024-01-09T00:26:26 < Ecco> Maybe the DHO800 is worse? It's not horrible though
2024-01-09T00:26:43 < Ecco> If you want me to run some kind of test, I'd be happy to
2024-01-09T00:26:44 < karlp> we normally get this stuff from eleshop.eu...
2024-01-09T00:26:52 < Ecco> I just don't have any noise measurement tools tho
2024-01-09T00:27:01 < Ecco> It's not expensive tho
2024-01-09T00:27:07 < zyp> karlp, do you consider your RD60xx fan loud?
2024-01-09T00:27:08 < Ecco> and it *is* very small
2024-01-09T00:27:20 < Ecco> I just wished there was some kind of feedback
2024-01-09T00:27:26 < Ecco> the fan is just spining all the time
2024-01-09T00:27:39 < Ecco> Also
2024-01-09T00:27:40 < zyp> not sure I agree
2024-01-09T00:27:45 < Ecco> it's like a 2cm fan
2024-01-09T00:27:53 < Ecco> on a 12cm heatsink
2024-01-09T00:28:02 < Ecco> if they'd made it a 12cm fan, we'd hear *nothing*
2024-01-09T00:28:10 < Ecco> zyp: well, yeah, I know what you mean
2024-01-09T00:28:23 < zyp> a constant reasonably quiet fan is easier to tune out than one that goes on and off all the time
2024-01-09T00:28:24 < Ecco> I think it's useful if it allows to shut down the fan completely most of the time
2024-01-09T00:28:32 < Ecco> yeah, I think we both agree
2024-01-09T00:28:37 < karlp> meh, the rd6012? nah, it's silent compared to the riglol ds1102...
2024-01-09T00:28:41 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 268 seconds]
2024-01-09T00:28:58 < zyp> karlp, my mso5k is quieter than my rd6024
2024-01-09T00:29:06 < Ecco> I wonder if a super slim fan would fit in the enclosure
2024-01-09T00:29:11 < Ecco> There's definietly *some* room
2024-01-09T00:29:20 < Ecco> I don't know what's the slimmest 12cm fan out there
2024-01-09T00:29:30 < karlp> ok, thanks NXP. mculink is "CMSIS-DAP" but instead of using endpoint 3 for trace, it uses another interface.
2024-01-09T00:30:10 < ventYl> some of their debuggers are of quite ancient version
2024-01-09T00:30:18 < ventYl> I wasn't able to make it running without hacking
2024-01-09T00:30:21 < karlp> this is their _new_ one.
2024-01-09T00:30:31 < ventYl> I rather used raspberry pi picoprobe
2024-01-09T00:30:35 < karlp> but yeah, looks ilke it's cmsis-v1?
2024-01-09T00:30:37 < karlp> fuckers
2024-01-09T00:30:46 < karlp> who does usb-hs and uses cmsis-v1?
2024-01-09T00:30:58 < ventYl> yep it is v1
2024-01-09T00:31:26 < karlp> even as v1, it's not being recognised at all in openocd, I thought it thsould still work with v1.
2024-01-09T00:31:54 < ventYl> there is some catch
2024-01-09T00:35:19 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-09T00:39:46 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 256 seconds]
2024-01-09T00:52:01 < karlp> ok, so it's brand new out of box, and it's shipping v0.076...  they're shipping v3.128 now, and that uses cmsis-dap2, and also has release notes abotu doing SWo "per standard for third party interop"
2024-01-09T00:59:30 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-a4ae-4923-692e-c77e.fixed6.kpn.net] has quit [Ping timeout: 260 seconds]
2024-01-09T01:04:42 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:ed49:9df8:9f7:4e9c] has quit [Ping timeout: 256 seconds]
2024-01-09T01:05:38 < karlp> ok, works.
2024-01-09T01:05:43 < karlp> that was a lot of hoops.
2024-01-09T01:05:48 < karlp> Ishoudl write that shit down.
2024-01-09T01:19:19 < karlp> ok, one thing done: https://false.ekta.is/2024/01/updating-an-nxp-mcu-link-to-work-with-openocd/
2024-01-09T01:21:08 < zyp> was gonna ask you to let me know what it does better than orbtrace other than price so I can improve orbtrace, but I see you already wrote bonus uart
2024-01-09T01:21:23 < zyp> (which *is* on the roadmap)
2024-01-09T01:21:23 < karlp> it's only swo, not etm too.
2024-01-09T01:21:39 < zyp> I didn't ask what orbtrace does better :)
2024-01-09T01:22:44 < karlp> according tot he release notes in the binaries, it has power profiling too,
2024-01-09T01:23:00 < karlp> which are not mentioned on the website, and seem to be via undocumented extra commands from mcuxpressoooo
2024-01-09T01:23:07 < karlp> so that would of course be neat too :)
2024-01-09T01:23:15 < karlp> needs all the extra software for it.
2024-01-09T01:23:28 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-09T01:23:51 < zyp> LA is somewhere reasonably near on the orbtrace roadmap
2024-01-09T01:24:07 < karlp> also, I apparently put "pin1" on my debug connector at the wrong end...
2024-01-09T01:24:09 < karlp> bad karl.
2024-01-09T01:24:54 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-09T01:25:10 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-09T01:25:31 < karlp> lol, anyway, I got this for home, so I could debug my keyboard.
2024-01-09T01:25:42 < karlp> turns out my custom function, is... just not being called at all :)
2024-01-09T01:25:53 < karlp> so much for weak and "just define this"
2024-01-09T01:25:57 < zyp> the new trace mux stuff we've worked a bit on will make it easy to add additional data sources to the trace stream, so a LA is a pretty obvious one
2024-01-09T01:26:11 < zyp> just sample the pins fast, RLE encode them and ship them off :)
2024-01-09T01:26:15 < karlp> you gonna make a little addon board for it?
2024-01-09T01:26:30 < zyp> what's the addon board gonna do?
2024-01-09T01:26:44 < karlp> for connecting it all nicecly?
2024-01-09T01:27:00 < karlp> or are you just doing it on those flying leads on the "left" ?
2024-01-09T01:27:06 < zyp> yeah
2024-01-09T01:27:37 < zyp> it has six inputs and ground, not too far off from my old logic8
2024-01-09T01:28:23 < karlp> fucking lol, just opened the other board I got today, I've ordered the wrong fucking thing
2024-01-09T01:28:43 < karlp> if it can do 6 "faster" than a fx2lafw, that's good enough for me.
2024-01-09T01:28:53 < karlp> six is spi+two triggers
2024-01-09T01:29:11 < zyp> exactly, six is more than I use most of the time I pull out a LA
2024-01-09T01:29:31 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 245 seconds]
2024-01-09T01:30:13 < karlp> cunts, they have the wrong board picture here: https://eu.mouser.com/ProductDetail/964-RTK7FPA4E2S001BE
2024-01-09T01:31:30 < zyp> SWO is sampled at 500MSPS, we could theoretically do that for LA as well, bottleneck is gonna be RLE-encoded data vs HS USB throughput anyway
2024-01-09T01:31:52 < karlp> thought I was getting this one, https://eu.mouser.com/ProductDetail/Renesas-Electronics/RTK7EKA4E2S00001BE but yeah, wouldn't have paid $80 for it.
2024-01-09T01:32:03 < karlp> fuckers. this is like a bare arduino though.
2024-01-09T01:34:12 < karlp> one of the whole points was to have R4 for usb testing with tinyusb
2024-01-09T01:34:17 < karlp> this one doesn't even have it.
2024-01-09T01:34:27 < zyp> aww
2024-01-09T01:42:39 < karlp> has it on unpopulated pin headers. nice one. thanks for that renesas...
2024-01-09T01:42:52 < karlp> ah well, guess that's goign to be in the box for a while...
2024-01-09T01:44:55 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 245 seconds]
2024-01-09T02:00:00 < nomorekaki> some days all the code is to add extern "C"
2024-01-09T02:02:34 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-09T02:03:01 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-09T02:21:27 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-09T02:25:46 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 245 seconds]
2024-01-09T03:08:57 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-09T03:13:37 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 276 seconds]
2024-01-09T03:17:00 < Ecco> So, I have an I2C dump from a MEMS
2024-01-09T03:17:13 < Ecco> https://pastebin.com/6MLy0vjG
2024-01-09T03:17:21 < Ecco> Would you guys be able to ID that chip?
2024-01-09T03:50:33 < Ecco> Ha maybe this? https://resource.heltec.cn/download/sensor/DA217/DA217-%E8%BF%90%E5%8A%A8.pdf
2024-01-09T03:54:02 < Ecco> I have *no idea* how I found this datasheet, but it does seem to match!
2024-01-09T03:58:00 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-09T03:58:17 < Ecco> Hmm, it doesn't seem to match *entierly* tho
2024-01-09T03:58:41 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-09T04:02:57 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 260 seconds]
2024-01-09T04:05:29 < Ecco> I mean, it's really, really close tho
2024-01-09T04:05:35 < Ecco> Probably one of http://www.miramems.com/en/product-1.html
2024-01-09T04:05:36 < Ecco> :)
2024-01-09T04:45:26 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-09T04:49:31 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 245 seconds]
2024-01-09T04:55:52 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Remote host closed the connection]
2024-01-09T05:33:37 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-09T05:42:54 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-09T05:50:32 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 252 seconds]
2024-01-09T06:21:48 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-09T06:26:10 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 245 seconds]
2024-01-09T07:04:47 -!- BrainDamage [~BrainDama@user/BrainDamage] has quit [Ping timeout: 264 seconds]
2024-01-09T07:12:57 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-09T07:13:34 -!- BrainDamage [~BrainDama@user/BrainDamage] has joined ##stm32
2024-01-09T07:16:53 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 240 seconds]
2024-01-09T07:34:31 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 245 seconds]
2024-01-09T07:36:39 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-a84e-fe17-cda6-b0a4.fixed6.kpn.net] has joined ##stm32
2024-01-09T07:47:15 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-09T07:48:33 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-09T07:51:32 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 252 seconds]
2024-01-09T08:26:08 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-a84e-fe17-cda6-b0a4.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-09T08:33:20 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-09T08:33:25 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-09T08:37:17 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 240 seconds]
2024-01-09T08:43:38 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-09T08:47:01 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2024-01-09T08:58:52 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-09T09:20:38 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-09T09:24:58 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 246 seconds]
2024-01-09T09:40:19 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-09T10:06:01 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-09T10:10:29 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 256 seconds]
2024-01-09T10:12:21 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has joined ##stm32
2024-01-09T10:50:18 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-09T10:54:41 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 252 seconds]
2024-01-09T11:03:53 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-09T11:31:47 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 264 seconds]
2024-01-09T11:31:59 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-09T11:39:31 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-09T11:44:07 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 255 seconds]
2024-01-09T11:53:42 < PaulFertser> Ecco: what are you reversing there?
2024-01-09T11:58:25 < karlp> anyone know how to set Rds ON for fets in falstad?
2024-01-09T12:00:18 < zyp> https://www.falstad.com/circuit/mosfet-beta.html
2024-01-09T12:09:12 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-09T12:09:42 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-09T12:19:48 < karlp> thanks!
2024-01-09T12:25:12 -!- machinehum [~machinehu@213.55.226.74] has joined ##stm32
2024-01-09T12:29:50 -!- machinehum [~machinehu@213.55.226.74] has quit [Ping timeout: 252 seconds]
2024-01-09T12:32:09 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-09T12:52:55 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-09T12:59:50 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 256 seconds]
2024-01-09T13:08:19 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-09T13:34:09 -!- qyx [~qyx@84.245.121.170] has quit [Ping timeout: 260 seconds]
2024-01-09T13:35:48 -!- qyx [~qyx@84.245.121.117] has joined ##stm32
2024-01-09T13:38:04 < jadew> Pfew... I'm officially done with that job.
2024-01-09T13:40:11 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 268 seconds]
2024-01-09T13:45:24 < zyp> congrats
2024-01-09T13:51:16 < jadew> Thank you!
2024-01-09T13:52:45 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-09T14:15:08 < Steffanx> PicoLogger time? 😝
2024-01-09T14:15:17 < jadew> Haha
2024-01-09T14:15:41 < jadew> Kind of, yeah...
2024-01-09T14:43:05 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2024-01-09T15:08:23 < ventYl> congrats, whatever it is
2024-01-09T15:09:06 < ventYl> s/is/was/
2024-01-09T15:17:39 < jadew> ventYl, heh, thanks, it was an actual job, just very taxing for me.
2024-01-09T15:20:07 < ventYl> jadew: I know the burden. Sometimes I take something which looks trivial only to later find out that I am knee-deep in a shit
2024-01-09T15:39:29 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-09T16:14:12 -!- nuxil_ [~nuxil@141.195.51.41] has joined ##stm32
2024-01-09T16:16:49 -!- nuxil [~nuxil@141.195.51.41] has quit [Ping timeout: 255 seconds]
2024-01-09T16:32:27 < jbo> tme is so fast :>
2024-01-09T16:32:50 < jbo> congratz jadew 
2024-01-09T16:51:47 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-09T16:52:28 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-09T17:00:46 < Steffanx> Lol. Congratulations for not having a job at all. 😝
2024-01-09T17:02:57 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-09T17:07:55 < Steffanx> Planning to find a job locally or going to be self employed again, jadew ?
2024-01-09T17:36:39 < jadew> jbo, thanks.
2024-01-09T17:37:04 < jadew> Steffanx, I think it's congrats for doing the necessary step, as difficult as it may be - because it was.
2024-01-09T17:37:39 < jadew> No planning to get a job atm, maybe something part-time or some freelancing.
2024-01-09T17:37:43 < jadew> *not
2024-01-09T17:40:35 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 252 seconds]
2024-01-09T17:48:40 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-09T18:02:02 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 252 seconds]
2024-01-09T18:06:58 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-09T18:08:07 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-09T18:08:37 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has quit [Read error: Connection reset by peer]
2024-01-09T18:08:53 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-09T18:09:02 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has joined ##stm32
2024-01-09T18:09:22 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-09T18:10:10 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-09T18:12:56 < karlp> today's reminder that this design got shipped: https://www.infineon.com/cms/en/product/evaluation-boards/kit_xmc45_be1_002/
2024-01-09T18:16:02 < zyp> looks like it worked
2024-01-09T18:17:28 < karlp> in being memorable yes :)
2024-01-09T18:17:43 < karlp> it came up here again because I'v egot one of the equaly silly freescale TWR systems on my desk.
2024-01-09T18:18:05 < karlp> it's totally discontinued by infineon though, in favour of more traditional boards.
2024-01-09T18:18:11 < zyp> the TWR concept seemed kinda neat
2024-01-09T18:24:25 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 260 seconds]
2024-01-09T18:29:44 -!- boB_K7IQ [~boB_K7IQ@184-98-64-136.phnx.qwest.net] has joined ##stm32
2024-01-09T18:33:14 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-09T18:35:07 < qyx> wut is that
2024-01-09T18:35:11 < qyx> looks futuristic
2024-01-09T18:35:16 < karlp> it's overly complicated
2024-01-09T18:35:23 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 256 seconds]
2024-01-09T18:35:56 < karlp> no-ones going to make modules that fit on the sides, you're at the stage of making your own, so you get multiple things, hard to probe, hard to reach jumpers, takes up way more space, it's prickly.
2024-01-09T19:09:07 < ventYl> is it that kind of infineon crap where you have to sign the NDA using your blood to actually get any kind of datasheet?
2024-01-09T19:10:34 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has quit [Ping timeout: 260 seconds]
2024-01-09T19:11:57 < ventYl> actually not. i am genuinely surprised
2024-01-09T19:16:36 < nomorekaki> nothing wrong with infineon cortex mcus
2024-01-09T19:17:18 < ventYl> they have this aurix tricore shit which you can get nothing sensible without signing an NDA with your blood
2024-01-09T19:30:49 < nomorekaki> I think it's the whole point of having tricore stuff
2024-01-09T19:32:24 < ventYl> it probably isn't used outside of automotive
2024-01-09T19:32:30 < ventYl> and they like this kind of exclusive shit
2024-01-09T19:32:37 < ventYl> it has funny consequences
2024-01-09T19:57:33 -!- antto [~pewpew@antonsavov.net] has quit [Remote host closed the connection]
2024-01-09T19:57:59 -!- antto [~pewpew@antonsavov.net] has joined ##stm32
2024-01-09T20:00:49 < nomorekaki> when they control the whole supply chain it's harder to copy products at least
2024-01-09T20:01:23 < nomorekaki> and moneys flow in right ways
2024-01-09T20:14:03 < ventYl> it creates an issue on the opposite end.
2024-01-09T20:14:10 < ventYl> companies want to hire skilled engineers
2024-01-09T20:14:29 < ventYl> X years of proven certified hands-on experience with aurix tricore and if you don't have it then sorry we are not seeking for you
2024-01-09T20:14:58 < ventYl> then many month later you read: "hiring market it tough right now"
2024-01-09T20:24:45 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 256 seconds]
2024-01-09T20:27:40 < nomorekaki> companies want engineers of other companies
2024-01-09T20:28:06 < nomorekaki> *senior engineers
2024-01-09T20:28:16 < ventYl> yeah, like 95% of people I interviewed for cariad were actually stolen from other companies in the industry
2024-01-09T20:28:50 < ventYl> OEMs are intellectually castrating their suppliers
2024-01-09T20:29:54 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-09T20:30:05 < ventYl> the problem is that they want some 5k more developers who don't exist
2024-01-09T20:30:26 < ventYl> other OEMs want another 2-5k more people
2024-01-09T20:30:33 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-09T20:30:38 < ventYl> and they, surprisingly, don't exist
2024-01-09T20:33:12 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-09T20:40:19 < nomorekaki> they need to tell da goverment to train 5000k people they wont hire
2024-01-09T20:42:34 < ventYl> they probably would hire them. but such training will take... 5 years?
2024-01-09T20:43:00 < ventYl> and by then, the need won't be there anymore, neither some of these companies
2024-01-09T20:43:36 < nomorekaki> mid europe is about to retire there is just no replacing every job
2024-01-09T20:44:23 < ventYl> some of those people who are going to retire are of no use for these positions either
2024-01-09T20:45:52 < nomorekaki> but some of them are
2024-01-09T20:48:00 < ventYl> what. a. shame.
2024-01-09T20:53:01 < specing> Companies want to do what's best for them, obviously
2024-01-09T20:54:13 < ventYl> * what they thin is the best for them
2024-01-09T20:54:17 < ventYl> think
2024-01-09T20:55:44 < nomorekaki> what is best for the bonuses
2024-01-09T20:56:16 < nomorekaki> bonuses are defined by board so what boards want short term long term
2024-01-09T20:56:55 < ventYl> well, in one such company they've had a goal to hire 600 developers
2024-01-09T20:57:00 < ventYl> or some similar absurd number
2024-01-09T20:57:09 < ventYl> after like three years, they hired -2
2024-01-09T20:57:34 < nomorekaki> :O
2024-01-09T20:57:37 < ventYl> so they decided, that they'll improve their hiring process to expect every candidate to have at least PhD
2024-01-09T20:58:00 < nomorekaki> they hired -2 more then?
2024-01-09T20:58:53 < ventYl> I only know two developers who did not left the company at this location
2024-01-09T20:58:59 < ventYl> everyone else left
2024-01-09T20:59:50 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-84e8-3615-bc61-e7b0.fixed6.kpn.net] has joined ##stm32
2024-01-09T21:05:42 < ventYl> seems that in germany, there is someone still in there
2024-01-09T21:06:47 < nomorekaki> one guy doing all works
2024-01-09T21:07:18 < nomorekaki> development as in programming?
2024-01-09T21:07:45 < ventYl> yes, automotive embedded C
2024-01-09T21:16:29 < nomorekaki> programmers wander off :D
2024-01-09T21:19:14 < nomorekaki> lifting gaze from source code and looking out of the office window - not remembering who he is and what he is doing
2024-01-09T21:19:37 < nomorekaki> then wander off from office door never to be seen again in the company
2024-01-09T21:19:46 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 264 seconds]
2024-01-09T21:20:18 < ventYl> the process is usually more dramatic
2024-01-09T21:20:38 < ventYl> one runs towards north screaming "nichts mehr!"
2024-01-09T21:20:52 < nomorekaki> no moreP
2024-01-09T21:20:53 < nomorekaki> ?
2024-01-09T21:21:10 < ventYl> yep
2024-01-09T21:21:17 < nomorekaki> mental breakdown bonuspoints
2024-01-09T21:23:42 < ventYl> its sad
2024-01-09T21:24:12 < nomorekaki> it is if real mental breakdown
2024-01-09T21:24:50 < ventYl> rumours were, that some people had heart attacks and those were acknowledged by the company as work-induced injury
2024-01-09T21:25:03 < nomorekaki> and not just comically flying across the office yelling quits
2024-01-09T21:27:20 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-09T21:29:41 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-09T21:29:50 < nomorekaki> time to check jadew
2024-01-09T21:30:00 < nomorekaki> if he had "the talks"
2024-01-09T21:30:10 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-09T21:30:31 < ventYl> what talks?
2024-01-09T21:31:12 < ventYl> yay, you weren't here. he expressed relief, so apparently he had
2024-01-09T21:31:27 < nomorekaki> ah good
2024-01-09T21:31:41 < nomorekaki> expressed relief of?
2024-01-09T21:32:16 < ventYl> "he's officialy done with that job"
2024-01-09T21:33:44 < Steffanx> You can congratulate him, nomorekaki. Its allowed
2024-01-09T21:34:47 < nomorekaki> jadew: happy to hear it went well
2024-01-09T21:38:34 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 255 seconds]
2024-01-09T21:39:50 < jadew> nomorekaki, well, it could have gone better, but this is good too.
2024-01-09T21:40:00 < nomorekaki> details?
2024-01-09T21:42:11 < jadew> Well, I told him that if he won't stop interacting with the developers (they were extremely demotivated) and imposing his will on the code, then I will resign, he said he can't do that, but asked me to stick around for a little longer.
2024-01-09T21:43:19 < jadew> Yesterday he was trying to push me to make a change to some code I did. I explained why that change is bad, he understood. Today he came back that he would like to make that change anyway. I said no, and asked to cut short my notice period.
2024-01-09T21:43:44 < ventYl> I would be quite interested in the "he said he can't do that" part. that just doesn't sound right
2024-01-09T21:45:11 < jadew> ventYl, me too, but I don't think I'll ever find out why.
2024-01-09T21:45:37 < jadew> I think he was just too attached to the code - maybe more attached than he was to the business itself.
2024-01-09T21:45:56 < ventYl> ah, so this someone wasn't just random guy, he "owned" the code
2024-01-09T21:46:02 < jadew> Yes.
2024-01-09T21:46:18 < nomorekaki> without "" owned
2024-01-09T21:46:25 < ventYl> ok, that happens quite often
2024-01-09T21:47:29 < jadew> Yeah, it's kind of understandable, but it sucks when you're on the short end of it.
2024-01-09T21:47:42 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-09T21:48:43 < ventYl> i'm glad that the one time I've been facing similar situation, I've been told that on the interview
2024-01-09T21:49:26 < ventYl> our tech lead is an old-school guy, he tends to code in ncedit and is quite stubborn on what will actually be implemented and how. he wrote vast majority of code
2024-01-09T21:54:13 < jadew> It's ok to be stubborn if the reason for that is clear, and you're not constantly asking for the worst stuff possible.
2024-01-09T21:55:53 < ventYl> I felt that it would exectly be the case of worst-possible decisions based on stupid grounds
2024-01-09T21:55:54 < jadew> It could even be "I'm not good enough to understand this, so we need to do it in this other way", but if it's not rooted in reason, then you're just getting stomped on
2024-01-09T21:56:54 < ventYl> back then I've been trying to escape one such company, where "historic reasons" were used as a common excuse why something stupid, bad, blocking and/or useless will stay in place
2024-01-09T21:57:16 < ventYl> I wasn't in a need of another one
2024-01-09T21:57:58 < jadew> Yeah, I've never experienced this before, and it's definitely a lesson that'll stick with me for a while.
2024-01-09T21:58:18 < ventYl> bad is, it is hard to detect early on
2024-01-09T21:59:46 < jadew> Right, because at first you have to give the benefit of the doubt (maybe I'm just dumb - I don't have the whole picture yet).
2024-01-09T22:01:38 < qyx> that's exactly how it is
2024-01-09T22:01:42 < qyx> and what he hinks
2024-01-09T22:02:13 < qyx> when I left one company in the past, the others were told "he was not the right one, he didn't understand"
2024-01-09T22:02:29 < ventYl> you can only ask questions. fortunately, in first months in new job that's usually highly appreciated and absolutely not suspicious
2024-01-09T22:03:45 < jadew> qyx, and in a sense that was probably true (about not being the right one), the problem they have is that they can never find the right one.
2024-01-09T22:04:24 < jadew> It's probably bad to be in their shoes too, because you probably realize that you need help, but you can't get it, because people who can't help you, are necessarily incompatible with what you're doing.
2024-01-09T22:05:24 < jadew> *people who CAN help you
2024-01-09T22:05:47 < ventYl> so it's everyone else's fault anyway
2024-01-09T22:07:09 < jadew> No, I don't think they blame you for not being the one, and they probably understand why you're not the one.
2024-01-09T22:08:42 < ventYl> I did not go that far in my portmortem. I couldn't understand how it is possible that they explicitly expressed they know they have a problem, that they have to deal with it, because it costs them millions
2024-01-09T22:09:15 < ventYl> but then did everything possible in order to reject, neutralize, sabotage and/or fuck up any provided solution
2024-01-09T22:10:21 < jadew> I'm surprised to hear so many similar impressions...
2024-01-09T22:11:04 < ventYl> Now, later, I understand that they were entirely in reactive mindset and they ultimate problem was that there was nobody brave enough who had high-enough position to actually steer towards proactive measures
2024-01-09T22:11:50 < ventYl> so they've been in a spiral. problems -> firefighting; more problem -> more firefigting; no we don't have time for precautions, we have to do firefighting, don't you see?
2024-01-09T22:13:04 < veverak> lol
2024-01-09T22:13:12 < veverak> it's sad how many times osmething like this happen
2024-01-09T22:15:09 < ventYl> when I joined that company I had literally 0 domain-based knowledge
2024-01-09T22:15:24 < ventYl> probably the most detailed information I've had was that CANbus is using copper wires
2024-01-09T22:16:41 < ventYl> and I still managed to deal with the issues in a proactive way, so when they dropped a "I know we promised you you'll have 9 months to do this, but you have to finish it in 2 and half again", I actually made it
2024-01-09T22:17:51 < jadew> Should have asked for increased pay
2024-01-09T22:18:10 < ventYl> i've been at payment ceiling
2024-01-09T22:18:28 < jadew> * 9/2 * bonus for actually doing that.
2024-01-09T22:18:39 < jadew> (if it was possible to get it done in 2.5 months)
2024-01-09T22:18:41 < ventYl> only like three days before my notice period was to expire, my boss called me to have a chat
2024-01-09T22:19:47 < ventYl> jadew: all i'd get would be "thank you for your hard work"
2024-01-09T22:19:59 < ventYl> we got that each time our manager told us some new fuckup he managed to do
2024-01-09T22:24:34 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-09T22:27:50 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 245 seconds]
2024-01-09T23:12:24 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-09T23:13:28 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-09T23:14:25 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 255 seconds]
2024-01-09T23:21:30 -!- drzacek [~quassel@2a01:3d8:44e:5100:7812:3347:154f:126f] has joined ##stm32
2024-01-09T23:22:36 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-09T23:29:51 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-09T23:30:29 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-09T23:42:33 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-09T23:43:15 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-09T23:47:35 < qyx> jadew: in this particular situation the problem was that there is nobody wanting to be misused and overused with no support for low cost, except under special circumstances like "I could do it if the work is interesting and fun"
2024-01-09T23:47:58 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 264 seconds]
2024-01-09T23:48:10 < qyx> but after a while they effectively erased even this very last reason to stay there, it was not interesting long term and not even fun anymore
2024-01-09T23:48:50 < qyx> basically it took the company 1.5 years to replace >50% of employees and after 4 years there were nobody of the original staff
--- Day changed ke tammi 10 2024
2024-01-10T00:01:39 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T00:06:08 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 252 seconds]
2024-01-10T00:25:53 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T00:30:04 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 246 seconds]
2024-01-10T00:36:31 -!- drzacek [~quassel@2a01:3d8:44e:5100:7812:3347:154f:126f] has quit [Quit: https://quassel-irc.org - Czatuj komfortowo. Wszędzie.]
2024-01-10T00:44:28 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T00:49:34 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 268 seconds]
2024-01-10T01:11:52 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T01:16:10 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 245 seconds]
2024-01-10T01:23:39 < jadew> qyx, that's what I was saying, the people capable of doing the job, are not interested, because the mode of being that makes them qualified for that job, is also what makes them hate it. And to put a cherry on top of it, because they're qualified to do that, they're also qualified to do other stuff, that's actually interesting.
2024-01-10T01:23:53 < jadew> The moment you lead a project into that state, it's gone.
2024-01-10T01:24:34 < jadew> You need to throw it out, and start over, which is possible, if management sees that too.
2024-01-10T01:29:25 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T01:30:16 < qyx> yeah you are not hiring experts/capable people because they can do broader range of jobs but because they are capable of doing those jobs others can't
2024-01-10T01:35:13 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 276 seconds]
2024-01-10T01:41:17 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-84e8-3615-bc61-e7b0.fixed6.kpn.net] has quit [Ping timeout: 240 seconds]
2024-01-10T01:46:03 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 256 seconds]
2024-01-10T01:48:27 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T01:53:58 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 264 seconds]
2024-01-10T02:06:18 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T02:10:59 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 252 seconds]
2024-01-10T02:23:14 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T02:25:05 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-10T02:33:26 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Quit: Konversation terminated!]
2024-01-10T02:58:34 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-10T03:02:53 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 260 seconds]
2024-01-10T03:14:48 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-10T03:14:56 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-10T03:17:29 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T03:22:18 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 256 seconds]
2024-01-10T03:42:37 < Ecco> ok, I want to generate the integers from 0 to n in a "random" order
2024-01-10T03:42:50 < Ecco> what's the easiest way to do this?
2024-01-10T03:43:24 < Ecco> I want to write a function "int shuffled_index(int i, int max_value)"
2024-01-10T03:44:12 < Ecco> and when i will vary between 0 and max_value
2024-01-10T03:44:24 < Ecco> shuffled_index will cover all the values between 0 and max_value
2024-01-10T03:44:34 < Ecco> so the identity would be an answer, albeit kinda shitty
2024-01-10T03:45:20 < Ecco> return (i+MY_CONSTANT)%max_value would work too, but would not look much more "random"
2024-01-10T03:46:55 < nomorekaki> have a n size array and run pair swaps with rand indexes
2024-01-10T03:47:10 < nomorekaki> may require some RAM
2024-01-10T03:47:52 < Ecco> well, this could actually be random
2024-01-10T03:47:54 < Ecco> so good
2024-01-10T03:47:59 < Ecco> but I only need pseudo-random
2024-01-10T03:48:07 < Ecco> but I'd like to use O(1) RAM
2024-01-10T03:48:22 < Ecco> I wonder if we could do something fun with xor
2024-01-10T03:48:31 < Ecco> I mean, if len is a PoT
2024-01-10T03:48:37 < Ecco> I think xoring works
2024-01-10T03:48:44 < Ecco> wait
2024-01-10T03:48:50 < Ecco> maybe even if len is not
2024-01-10T03:49:01 < Ecco> as long as I xor with something smaller than len
2024-01-10T03:49:04 < Ecco> might be good
2024-01-10T03:49:09 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T03:49:17 < nomorekaki> maybe your answer can be found from fractals
2024-01-10T03:52:02 < nomorekaki> https://forums.ni.com/t5/LabVIEW/Plot-xy-graph-using-random-number-generator/td-p/2216054?lightbox-message-images-2216084=90836i7874AC662229947B
2024-01-10T03:52:20 < nomorekaki> that is how your xy should look like
2024-01-10T03:52:31 < nomorekaki> no trends of any sorts visible
2024-01-10T03:52:39 < Ecco> Indeed
2024-01-10T03:53:27 < nomorekaki> greph your code as xy and inspect visually if it's sufficient
2024-01-10T03:53:42 < nomorekaki> no trends no patterns
2024-01-10T03:53:50 < Ecco> Well, xor-ing does absolutely work if the set's cardinality is a power of two
2024-01-10T03:56:35 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 245 seconds]
2024-01-10T04:14:09 < Ecco> I just asked ChatGPT
2024-01-10T04:14:18 < Ecco> It failed pathetically
2024-01-10T04:14:25 < Ecco> the worst part was that it was passive-aggressive
2024-01-10T04:14:34 < Ecco> Like it would spit out answers that were utter crap
2024-01-10T04:14:39 < Ecco> but in a very confident way
2024-01-10T04:19:36 < nomorekaki> got too pumped while codings
2024-01-10T04:19:56 < nomorekaki> feeling restless
2024-01-10T04:20:11 < nomorekaki> 4:20AM
2024-01-10T04:26:47 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T04:58:14 -!- nomorekaki34 [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-10T05:02:16 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-10T05:02:21 -!- nomorekaki34 is now known as nomorekaki
2024-01-10T05:31:11 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 252 seconds]
2024-01-10T05:59:29 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T06:04:20 -!- antto [~pewpew@antonsavov.net] has quit [Remote host closed the connection]
2024-01-10T06:05:41 -!- antto [~pewpew@antonsavov.net] has joined ##stm32
2024-01-10T06:06:14 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 268 seconds]
2024-01-10T06:12:30 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Remote host closed the connection]
2024-01-10T06:35:21 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T06:41:35 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 252 seconds]
2024-01-10T06:55:16 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T07:00:48 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 268 seconds]
2024-01-10T07:13:48 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T07:19:10 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 264 seconds]
2024-01-10T07:33:41 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T08:07:44 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-10T08:32:04 -!- Netsplit *.net <-> *.split quits: Kamilion, russell--
2024-01-10T08:32:22 -!- Netsplit *.net <-> *.split quits: specing, karlp, mid-kid, m5zs7k, skz81
2024-01-10T08:32:29 -!- Netsplit over, joins: russell--, Kamilion
2024-01-10T08:32:29 -!- Netsplit *.net <-> *.split quits: aandrew, haritz, quinor, drfff, rkta, krasjet
2024-01-10T08:35:36 -!- skz81 [~skz81@vps-68d3ea17.vps.ovh.net] has joined ##stm32
2024-01-10T08:35:36 -!- mid-kid [~mid-kid@2a01:7c8:aac8:1e8:5054:ff:fe5e:cd48] has joined ##stm32
2024-01-10T08:35:36 -!- specing [~specing@user/specing] has joined ##stm32
2024-01-10T08:35:36 -!- m5zs7k [aquares@web10.mydevil.net] has joined ##stm32
2024-01-10T08:35:36 -!- karlp [karlp@palmtreev6.beeroclock.net] has joined ##stm32
2024-01-10T08:35:44 -!- m5zs7k [aquares@web10.mydevil.net] has quit [Max SendQ exceeded]
2024-01-10T08:35:46 < jpa-> https://blog.rust-embedded.org/embedded-hal-v1/   interesting to see how this works out
2024-01-10T08:35:48 -!- quinor [08c0f10716@2604:bf00:561:2000::dad] has joined ##stm32
2024-01-10T08:35:48 -!- haritz [~hrtz@user/haritz] has joined ##stm32
2024-01-10T08:35:48 -!- drfff [~k\o\w@2607:fea8:1d00:89f0:4662:11c8:f36e:f0ce] has joined ##stm32
2024-01-10T08:35:48 -!- krasjet [~krjst@2604:a880:800:c1::16b:8001] has joined ##stm32
2024-01-10T08:35:48 -!- rkta [~rkta@user/rkta] has joined ##stm32
2024-01-10T08:35:48 -!- aandrew [~aandrew@mail.mixdown.ca] has joined ##stm32
2024-01-10T08:35:52 -!- drfff [~k\o\w@2607:fea8:1d00:89f0:4662:11c8:f36e:f0ce] has quit [Read error: Connection reset by peer]
2024-01-10T08:35:56 -!- m5zs7k_ [aquares@web10.mydevil.net] has joined ##stm32
2024-01-10T08:36:12 -!- drfff [~k\o\w@2607:fea8:1d00:89f0:4662:11c8:f36e:f0ce] has joined ##stm32
2024-01-10T08:36:51 -!- quinor [08c0f10716@2604:bf00:561:2000::dad] has quit [Ping timeout: 260 seconds]
2024-01-10T08:45:12 -!- m5zs7k_ is now known as m5zs7k
2024-01-10T08:49:48 < qyx> so many unknown words.. traits, crates
2024-01-10T08:59:43 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-10T09:37:35 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 252 seconds]
2024-01-10T09:40:23 < jpa-> traits are like interfaces, crates are like packages
2024-01-10T09:43:54 < srk> :) I have such hal for many years in ivory
2024-01-10T09:44:19 < srk> interface is the important word
2024-01-10T09:58:04 -!- quinor [08c0f10716@2604:bf00:561:2000::dad] has joined ##stm32
2024-01-10T10:03:45 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-10T10:04:16 -!- quinor [08c0f10716@2604:bf00:561:2000::dad] has quit [Read error: Connection reset by peer]
2024-01-10T10:07:10 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has joined ##stm32
2024-01-10T10:08:23 -!- quinor [08c0f10716@2604:bf00:561:2000::dad] has joined ##stm32
2024-01-10T10:08:48 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T10:14:05 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 240 seconds]
2024-01-10T10:26:33 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T10:31:55 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 256 seconds]
2024-01-10T10:33:41 -!- quinor [08c0f10716@2604:bf00:561:2000::dad] has quit [Read error: Connection reset by peer]
2024-01-10T10:43:33 -!- quinor [08c0f10716@2604:bf00:561:2000::dad] has joined ##stm32
2024-01-10T10:43:50 -!- quinor [08c0f10716@2604:bf00:561:2000::dad] has quit [Read error: Connection reset by peer]
2024-01-10T10:43:56 -!- quinor [08c0f10716@2604:bf00:561:2000::dad] has joined ##stm32
2024-01-10T10:46:13 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T10:48:06 -!- quinor [08c0f10716@2604:bf00:561:2000::dad] has quit [Read error: Connection reset by peer]
2024-01-10T10:51:45 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 256 seconds]
2024-01-10T10:54:58 -!- quinor [08c0f10716@2604:bf00:561:2000::dad] has joined ##stm32
2024-01-10T11:00:09 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T11:01:59 -!- quinor [08c0f10716@2604:bf00:561:2000::dad] has quit [Ping timeout: 260 seconds]
2024-01-10T11:05:58 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 264 seconds]
2024-01-10T11:20:25 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T11:25:37 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 246 seconds]
2024-01-10T11:54:34 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T11:59:45 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 256 seconds]
2024-01-10T12:00:35 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T12:06:33 -!- quinor [08c0f10716@2604:bf00:561:2000::dad] has joined ##stm32
2024-01-10T12:07:40 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 276 seconds]
2024-01-10T12:12:02 -!- quinor [08c0f10716@2604:bf00:561:2000::dad] has quit [Read error: Connection reset by peer]
2024-01-10T12:20:04 -!- machinehum [~machinehu@213.55.226.205] has joined ##stm32
2024-01-10T12:20:06 -!- martinmoene1 [~martinmoe@132.229.46.129] has quit [Read error: Connection reset by peer]
2024-01-10T12:20:13 -!- martinmoene_ [~martinmoe@132.229.46.129] has quit [Read error: Connection reset by peer]
2024-01-10T12:23:01 -!- martinmoene [~martinmoe@132.229.46.129] has joined ##stm32
2024-01-10T12:24:07 -!- martinmoene [~martinmoe@132.229.46.129] has left ##stm32 []
2024-01-10T12:24:27 -!- martinmoene_ [~martinmoe@132.229.46.129] has joined ##stm32
2024-01-10T12:34:10 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-10T12:44:51 < PaulFertser> jpa-: indeed the standoffs and screws are all connected to this toy oscilloscope ground so one must be careful.
2024-01-10T12:46:38 -!- machinehum2 [~machinehu@213.55.225.22] has joined ##stm32
2024-01-10T12:49:46 -!- machinehum [~machinehu@213.55.226.205] has quit [Ping timeout: 264 seconds]
2024-01-10T13:04:36 < Steffanx> Just replace em with plastic standoffs and screws and PaulFertser is a little bit more safe 
2024-01-10T13:06:21 < srk> PaulFertser: what kind of toy scope?
2024-01-10T13:07:11 < PaulFertser> srk: ZEEWEII DSO154Pro
2024-01-10T13:07:17 < PaulFertser> Steffanx: indeed
2024-01-10T13:08:25 < srk> was playing with riglol dho804 (unlocked it) and it is pretty decent. fun stuff is that it runs android, you can "root" it with adb
2024-01-10T13:08:42 < PaulFertser> https://hackaday.io/page/11837-getting-started-with-w806-240mhz-32-bit-mcu W806-C200 is the MCU. And some IC nearby which has the marking (other than the dot) fully removed.
2024-01-10T13:08:44 < srk> cool stuff is external hdmi and usb input, so you can connect mouse 
2024-01-10T13:09:37 < srk> looks cool, always wanted to build something like this using stm32f103 + tft display dev board
2024-01-10T13:09:57 < srk> there's even a fw for it but making it build would be at least two day project
2024-01-10T13:10:36 < srk> PaulFertser: does it work with sigrok? :D
2024-01-10T13:11:22 < jpa-> srk: does it calculate math functions on whole data or just downsampled screen data?
2024-01-10T13:11:29 < PaulFertser> srk: doesn't look so. It doesn't advertise a USB connection even but CH340 is present on board.
2024-01-10T13:11:30 < jpa-> (and measure functions)
2024-01-10T13:12:07 < srk> jpa-: idk tbh, any easy way to find out?
2024-01-10T13:12:47 < srk> think I could generate a slowly changing waveform soonish and test with that
2024-01-10T13:13:03 < srk> want to try dshot impl on stm, DMA->TIM
2024-01-10T13:13:25 < jpa-> i noticed it most on RMS measurements of noise, e.g. http://jpa.kapsi.fi/stuff/pix/noise_rms.png  changes when i zoom in on stopped waveform
2024-01-10T13:14:09 < srk> hmm, yeah I can try that today with DPS PSUs, we were looking at the noise output of these couple days ago
2024-01-10T13:14:59 < mawk> I accidentally deleted all my files
2024-01-10T13:15:03 < mawk> can someone grep their irc logs for the time I shared my stm32cubeide docker container script?
2024-01-10T13:15:05 < mawk> I need it to start the ide
2024-01-10T13:15:07 < mawk> lol
2024-01-10T13:15:09 < mawk> I forgot what it was doing but it wasn't simple
2024-01-10T13:15:46 < ventYl> windows lost my graphics driver
2024-01-10T13:15:48 < ventYl> again
2024-01-10T13:15:59 < crazy_imp> jpa-: guess it's only doing the math on the visible part on the screen, thus the differences?
2024-01-10T13:17:15 < PaulFertser> Interesting, opening ttyUSB0 doesn't let it work or boot :)
2024-01-10T13:23:04 < jpa-> crazy_imp: not just visible part, but the downsampled visible data
2024-01-10T13:25:26 < crazy_imp> what do you mean by downsampled?
2024-01-10T13:26:30 < jpa-> DS1054Z that i have uses 1200 points in the display buffer and computes measurements on it, even though it has 24Mpts capture depth
2024-01-10T13:27:21 < jpa-> so e.g. the FFT function is quite limited because you get only 2 decades of frequency range
2024-01-10T13:27:46 < jpa-> whereas if you download data to PC and run FFT in octave, you get 6 decades
2024-01-10T13:33:26 < crazy_imp> hm, but it would be even more confusing if it would process data that you cannot see (right now)
2024-01-10T13:34:12 < jpa-> yes, but when it is zoomed out it gives totally wrong RMS readings, while you'd expect it to process the whole data
2024-01-10T13:34:21 < jpa-> i would be fine with it processing only part of the data when zoomed in
2024-01-10T13:34:48 < jpa-> (because normally when you use the scope, it is about 80% zoomed out, so you can zoom in a lot but zoom out only a bit)
2024-01-10T13:36:57 < crazy_imp> at work we've got an R&S scope that sometimes shows simply nothing because it sampled the points perfectly inbetween and you need to zoom in first...
2024-01-10T13:38:09 < PaulFertser> Now that's some sophisticated MCU flashing procedure. Involves Xmodem, AT commands, zip compression https://github.com/IOsetting/wm-sdk-w806/blob/main/tools/W806/wm_tool.c
2024-01-10T13:38:15 < jpa-> heh, well at least rigol does the downsampling quite reasonably (even-odd min-max) so that you see the whole range of variation in data
2024-01-10T13:38:24 < jpa-> could be that the R&S scope has a setting for the mode
2024-01-10T13:39:02 < jpa-> min-max amplifies visual noise so sometimes you want to set it to other modes, but those can hide high frequencies when zoomed out
2024-01-10T13:40:11 < crazy_imp> hmmm, so far i've found nothing in that direction
2024-01-10T13:41:10 < jpa-> it can also be called "decimation mode"
2024-01-10T13:49:24 < crazy_imp> https://www.rohde-schwarz.com/webhelp/RTE_HTML_UserManual_en/Content/cc64a4b65dcb4fad.htm hm, if they would write where to find the option... :D
2024-01-10T14:09:28 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-10T14:15:04 -!- Luggi09498284764 [~lux@ip5b426965.dynamic.kabel-deutschland.de] has quit [Quit: The Lounge - https://thelounge.chat]
2024-01-10T14:30:33 < jpa-> crazy_imp: maybe here? https://www.rohde-schwarz.com/webhelp/RTE_HTML_UserManual_en/Content/e9d60b2a09634e19.htm
2024-01-10T14:44:49 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-10T14:47:22 -!- machinehum2 [~machinehu@213.55.225.22] has quit [Ping timeout: 264 seconds]
2024-01-10T14:50:03 -!- machinehum [~machinehu@213.55.225.22] has joined ##stm32
2024-01-10T14:51:22 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-10T14:58:46 -!- hexo [~hexo@user/hexo] has quit [Ping timeout: 246 seconds]
2024-01-10T15:10:35 -!- machinehum [~machinehu@213.55.225.22] has quit [Ping timeout: 256 seconds]
2024-01-10T15:13:23 -!- machinehum [~machinehu@213.55.225.22] has joined ##stm32
2024-01-10T15:15:28 < crazy_imp> jpa-: maybe, but the menu doesn't look like it's from the scope we have. i'll check the next time :)
2024-01-10T15:15:57 < jpa-> :)
2024-01-10T15:38:32 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-10T16:25:21 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-10T16:25:47 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-10T16:30:28 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-10T16:31:00 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-10T16:34:55 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-10T16:50:52 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-10T16:54:03 < karlp> I knew this was an issue, but I didn't  know how big it was: https://www.usb.org/sites/default/files/327216.pdf
2024-01-10T16:59:13 < PaulFertser> karlp: interesting how relatively lame this official document is. They are testing some weird mice, one laptop model but not wifi and bluetooth. 
2024-01-10T17:00:00 < PaulFertser> It's like an improvised lab work by freshmen students.
2024-01-10T17:00:35 < karlp> i think given how blindingly obvious it was straight away, there wasn't a lot of need for more?
2024-01-10T17:00:53 < karlp> they dod mention that it affected bluetooth as well, but wasn't covered by this paper.
2024-01-10T17:09:15 < nomorekaki> macro expansion pros
2024-01-10T17:11:41 < nomorekaki> https://godbolt.org/z/x5b4jc746 how to replace line 123 with macro that takes PREFIX as an argument while it should also evaluate all the macro stuff inside the "function"?
2024-01-10T17:15:19 -!- machinehum [~machinehu@213.55.225.22] has quit [Ping timeout: 260 seconds]
2024-01-10T17:16:31 -!- duude__ [~duude__@user/duude/x-4676560] has quit [Ping timeout: 256 seconds]
2024-01-10T17:17:17 < fenugrec> heh, a few weeks ago I was thinking about a room-size implementation like GPS, and today happened accross this : guy made a homemade GPS receiver. To nobody's surprises, it's a big project http://www.aholme.co.uk/GPS/Main.htm
2024-01-10T17:21:20 < nomorekaki> looks complex
2024-01-10T17:22:50 -!- duude__ [~duude__@user/duude/x-4676560] has joined ##stm32
2024-01-10T17:23:19 -!- nuxil_ is now known as nuxil
2024-01-10T17:27:50 -!- duude__ [~duude__@user/duude/x-4676560] has quit [Ping timeout: 252 seconds]
2024-01-10T17:28:32 < sauce> im impressed at how simple the frontend is
2024-01-10T17:29:02 < fenugrec> total gain of 119dB for the chain is crazy
2024-01-10T17:29:34 < fenugrec> he lost me at 1-bit ADC and FFT conjugate black magic
2024-01-10T17:29:38 < sauce> and on a 2 layer board at that
2024-01-10T17:32:35 -!- duude__ [~duude__@user/duude/x-4676560] has joined ##stm32
2024-01-10T17:34:42 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-10T17:37:11 -!- duude__ [~duude__@user/duude/x-4676560] has quit [Ping timeout: 252 seconds]
2024-01-10T17:44:57 -!- duude__ [~duude__@user/duude/x-4676560] has joined ##stm32
2024-01-10T17:54:47 < englishman> 1-bit adc heh
2024-01-10T17:54:51 < englishman> aka a logic gate
2024-01-10T18:32:26 < emeb_mac> Wasn't Laurenceb doing some stuff with these low-bit GPS frontends a few years ago?
2024-01-10T19:05:55 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has quit [Ping timeout: 260 seconds]
2024-01-10T19:08:36 -!- flom84 [~flom84@user/flom84] has joined ##stm32
2024-01-10T19:09:34 -!- flom__84__ [~flom84@user/flom84] has joined ##stm32
2024-01-10T19:09:46 -!- flom84 [~flom84@user/flom84] has quit [Remote host closed the connection]
2024-01-10T19:09:49 -!- flom__84__ [~flom84@user/flom84] has quit [Remote host closed the connection]
2024-01-10T19:34:05 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 260 seconds]
2024-01-10T19:36:23 < qyx> emeb_mac: yeah
2024-01-10T19:36:41 < qyx> even I ordered some se4110L or what exactly was the oart number
2024-01-10T19:37:05 < qyx> basically an all-in-one gps frontend with 1 or 2 bit iq output
2024-01-10T19:37:15 < qyx> they were sampling it with SPI
2024-01-10T19:39:53 -!- machinehum [~machinehu@213.55.225.22] has joined ##stm32
2024-01-10T19:44:14 -!- machinehum [~machinehu@213.55.225.22] has quit [Ping timeout: 252 seconds]
2024-01-10T19:51:17 -!- machinehum [~machinehu@213.55.225.22] has joined ##stm32
2024-01-10T20:18:43 -!- haritz [~hrtz@user/haritz] has quit [Ping timeout: 260 seconds]
2024-01-10T20:19:12 -!- haritz [~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220] has joined ##stm32
2024-01-10T20:19:14 -!- haritz [~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220] has quit [Changing host]
2024-01-10T20:19:14 -!- haritz [~hrtz@user/haritz] has joined ##stm32
2024-01-10T20:28:45 -!- quinor [08c0f10716@2604:bf00:561:2000::dad] has joined ##stm32
2024-01-10T20:32:23 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-488a-74c2-4f90-7c19.fixed6.kpn.net] has joined ##stm32
2024-01-10T21:08:10 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-10T21:52:00 < qyx> so, anyone did ipv6 SLAAC with lwip?
2024-01-10T22:34:18 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-10T22:34:21 < Laurenceb_> supp
2024-01-10T22:35:22 < Laurenceb_> does anyone know what could cause stm32 usd cdc device to behave differently to an ftdi? I'm seeing read() from the series port on host side (running linux) returning immediately with 0 bytes of data
2024-01-10T22:35:42 < Laurenceb_> read from ftdi blocks correctly when there is no data available from the device
2024-01-10T22:53:54 < Laurenceb_> looks like maybe low level Lunix driver returns EOF
2024-01-10T22:59:46 -!- hexo [~hexo@user/hexo] has joined ##stm32
2024-01-10T22:59:55 < Laurenceb_> https://forums.raspberrypi.com/viewtopic.php?t=16539
2024-01-10T23:09:56 -!- ColdKeyboard [~ColdKeybo@user/coldkeyboard] has quit [Ping timeout: 252 seconds]
2024-01-10T23:12:20 -!- ColdKeyboard [~ColdKeybo@user/coldkeyboard] has joined ##stm32
2024-01-10T23:13:15 -!- machinehum [~machinehu@213.55.225.22] has quit [Ping timeout: 260 seconds]
2024-01-10T23:23:43 -!- machinehum [~machinehu@213.55.225.22] has joined ##stm32
2024-01-10T23:26:33 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:fe5d:fb72:5ce5:97b5] has joined ##stm32
2024-01-10T23:28:24 -!- ColdKeyboard [~ColdKeybo@user/coldkeyboard] has quit [Ping timeout: 268 seconds]
2024-01-10T23:29:22 -!- ColdKeyboard [~ColdKeybo@user/coldkeyboard] has joined ##stm32
2024-01-10T23:29:38 -!- machinehum [~machinehu@213.55.225.22] has quit [Ping timeout: 268 seconds]
2024-01-10T23:34:15 -!- hexo [~hexo@user/hexo] has quit [Ping timeout: 260 seconds]
2024-01-10T23:40:22 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Quit: Client closed]
2024-01-10T23:45:40 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-10T23:55:58 < nomorekaki> https://www.youtube.com/watch?v=fWR-ci40P-c finnish eurovision song of next eurovision
2024-01-10T23:57:56 < nomorekaki> Steffanx: hear this musics!
--- Day changed to tammi 11 2024
2024-01-11T00:06:47 < ventYl> leningrad cowboys go america!
2024-01-11T00:08:12 < nomorekaki> crazy they used actual red army choir as their band
2024-01-11T00:11:39 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-11T00:13:11 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-11T00:32:46 < nomorekaki> ventYl: any projects?
2024-01-11T00:45:13 < fenugrec> TIL what the 18 in "i18n" means...
2024-01-11T00:45:15 < Steffanx> 12 points to Finland nomorekaki 
2024-01-11T00:45:26 < Ecco> fenugrec: there are others lke this
2024-01-11T00:45:35 < fenugrec> I know (now)
2024-01-11T00:45:38 < Ecco> l10n for instance :)
2024-01-11T00:46:58 < nomorekaki> Steffanx: the canditate has not been chosen yet for EV, but windows95man is in preliminary competition
2024-01-11T00:47:01 < Steffanx> Lol f6c
2024-01-11T00:47:15 < Steffanx> Lol for real nomorekaki ?
2024-01-11T00:47:22 < nomorekaki> for real
2024-01-11T00:47:48 < Ecco> Steffanx: hahaha good one :-)
2024-01-11T00:47:52 < Steffanx> Dutchland's candidate is also "unusual" at least for dutch standards 
2024-01-11T00:48:43 < nomorekaki> your candidate has been selected already?
2024-01-11T00:49:26 < Steffanx> Yeah
2024-01-11T00:49:29 < Steffanx> https://www.youtube.com/watch?v=LMzAssOr2zE
2024-01-11T00:49:51 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 260 seconds]
2024-01-11T00:50:44 < Steffanx> But also this https://www.youtube.com/watch?v=6Cu0o60O6cE so I'm not sure what to expect 
2024-01-11T00:50:53 < ventYl> nomorekaki: what kind of projects?
2024-01-11T00:51:16 < Steffanx> Interesting projects
2024-01-11T00:51:23 < nomorekaki> any personal projects or work projects you are allowed to talk about.. and that might be interesting
2024-01-11T00:53:10 < ventYl> I am still crafting my creepy RTOS
2024-01-11T00:54:01 < nomorekaki> creepyRTOS
2024-01-11T00:54:01 < ventYl> actually I wrapped up something that could be a first public release, just the documentation needs to be improved so anyone else besides me can actually try it out
2024-01-11T00:54:52 < ventYl> you can get you daily dose of creepiness at https://www.digital-nomad.sk/cmrx/index.html
2024-01-11T00:57:42 < nomorekaki> hmm fully static
2024-01-11T00:57:56 < nomorekaki> really?
2024-01-11T00:58:51 < nomorekaki> I can't even start to figure out how that works
2024-01-11T00:59:28 < ventYl> it depends on how strictly static you want to be. it still has some code which initializes runtime structures for threads, but that's just to support future multi-platform ports
2024-01-11T00:59:29 < nomorekaki> I remember when I tried RTOS it probably needed first thing for me to implement srbk and malloc or something
2024-01-11T00:59:48 -!- Spirit532 [~Spirit532@user/Spirit532] has quit [Read error: Connection reset by peer]
2024-01-11T01:00:06 < nomorekaki> or copy from zyp those
2024-01-11T01:00:13 < ventYl> but all memory is fully static, there is no memory allocator available and it will be non-trivial to provide one
2024-01-11T01:01:52 -!- Spirit532 [~Spirit532@user/Spirit532] has joined ##stm32
2024-01-11T01:03:30 < ventYl> nomorekaki: zephyroid could need it
2024-01-11T01:04:53 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-11T01:05:03 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-11T01:05:15 < nomorekaki> what need what?
2024-01-11T01:05:29 < ventYl> zephyr could need malloc and sbrk
2024-01-11T01:06:00 < ventYl> here, it is principally almost impossible to support sbrk and hard to support malloc
2024-01-11T01:06:27 < nomorekaki> I used freertos
2024-01-11T01:06:33 < ventYl> and even if someone found out how to do it, it is none of the business of the kernel
2024-01-11T01:06:37 < nomorekaki> but when I read it has option to static
2024-01-11T01:07:03 < ventYl> qyx tried that and found out that it breaks things sooner or later if you try going static 
2024-01-11T01:08:13 < nomorekaki> freertos?
2024-01-11T01:09:17 < ventYl> IIRC, yes
2024-01-11T01:16:19 < ventYl> going fully static is actually simple, but quite limiting
2024-01-11T01:17:16 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-488a-74c2-4f90-7c19.fixed6.kpn.net] has quit [Ping timeout: 255 seconds]
2024-01-11T01:24:55 < qyx> nomorekaki: enabling static support in freertos doesn't mean 'enable it for the case you want it'
2024-01-11T01:25:23 < qyx> it means let's do things in a totally different way
2024-01-11T01:25:49 < qyx> oh and by the way we forget to tell you that you need to provide some additio al stubs
2024-01-11T01:26:17 < qyx> it breaks timers, idle task and idk what else
2024-01-11T01:32:24 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-11T01:33:45 < sync_> Steffanx: pls wat?
2024-01-11T01:36:00 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has joined ##stm32
2024-01-11T01:36:16 < nomorekaki> maybe I should use a real irc client
2024-01-11T01:38:18 < qyx> oh I though sync_ is not here anymore
2024-01-11T01:39:08 < ventYl> nomorekaki: too much hassle
2024-01-11T01:39:50 < nomorekaki> ventYl: why to use cmake?
2024-01-11T01:40:21 -!- sync_ is now known as Sync
2024-01-11T01:41:07 < Sync> I am qyx, it's just inconvenient for me atm to use irc
2024-01-11T01:41:27 < ventYl> nomorekaki: reasonably large feature support with reasonably low hassle
2024-01-11T01:41:50 < nomorekaki> I don't even know how to makefile
2024-01-11T01:42:26 < ventYl> me neither
2024-01-11T01:42:29 < nomorekaki> or kinda but no - if someone asks yes.. but no
2024-01-11T01:42:54 < ventYl> I can write some basic makefile, but nothing advanced\W intermediate
2024-01-11T01:45:37 < nomorekaki> so i just start with cmake
2024-01-11T01:47:38 < ventYl> cmake is simple for simple things and tends to be less complicated than anything else as the dynamics increase within the buildsystem
2024-01-11T01:48:49 < nomorekaki> I want to build my example files
2024-01-11T01:49:30 < nomorekaki> some I want to have option to build for local testing and also on mcu(s)
2024-01-11T01:50:40 < nomorekaki> should be rather uncomplex
2024-01-11T01:50:47 < nomorekaki> compared to linux kernel
2024-01-11T01:51:19 < ventYl> it is not, the only "caveat" is that CMake tries to be smart about the compiler toolchain. so there is rule that one project has to use one compiler as a whole
2024-01-11T01:51:38 < ventYl> you can't simply redefine CC in part of the project to perform HOSTCC or something similar
2024-01-11T01:51:47 < ventYl> well, you can, but not reliably
2024-01-11T01:51:56 < nomorekaki> I think linux kernel comes with like.. 1000makefiles
2024-01-11T01:53:05 < ventYl> CMake prescribes one CMakeLists per source directory
2024-01-11T01:54:32 < nomorekaki> I guess I need to makefile then
2024-01-11T01:55:36 < ventYl> why?
2024-01-11T01:58:08 < nomorekaki> if cmake doesn't build reliably one file for multiple hosts
2024-01-11T01:58:21 < ventYl> it does
2024-01-11T01:58:46 < ventYl> one CMakeLists per source directory is more about how the project itself has to be organized
2024-01-11T02:00:40 < ventYl> and you can build for multiple hosts, but each different host has to be different configuration, and in turn, different build
2024-01-11T02:02:10 < nomorekaki> yes
2024-01-11T02:02:20 < nomorekaki> sounds good
2024-01-11T02:02:38 < nomorekaki> I still don't understand what is that thing it cannot do
2024-01-11T02:02:44 < nomorekaki> build all of them at once?
2024-01-11T02:03:02 < ventYl> so, for example, the creepy RTOS can build kernel and kernel system tests in one build
2024-01-11T02:03:33 < ventYl> but tests that run on my local machine have to be built in another build, because there, the host compiler is used instead of cross-compiler
2024-01-11T02:06:01 < nomorekaki> same tests?
2024-01-11T02:06:48 < ventYl> for me, those are usually different tests.
2024-01-11T02:06:53 < ventYl> especially in case of kernel
2024-01-11T02:12:02 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-11T02:15:21 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 245 seconds]
2024-01-11T02:19:49 < Steffanx> Pls wat what Sync ?
2024-01-11T02:19:56 < Steffanx> That German song?
2024-01-11T02:24:09 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:fe5d:fb72:5ce5:97b5] has quit [Ping timeout: 268 seconds]
2024-01-11T02:46:13 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-11T02:58:53 -!- hexo [~hexo@user/hexo] has joined ##stm32
2024-01-11T03:07:03 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Remote host closed the connection]
2024-01-11T05:03:58 -!- nomorekaki [~nomorekak@176-93-110-206.bb.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-11T07:07:42 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-11T07:09:58 -!- quinor [08c0f10716@2604:bf00:561:2000::dad] has quit [Read error: Connection reset by peer]
2024-01-11T07:36:16 -!- hexo [~hexo@user/hexo] has quit [Ping timeout: 246 seconds]
2024-01-11T07:53:44 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-11T09:04:22 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Ping timeout: 268 seconds]
2024-01-11T09:32:34 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2024-01-11T09:42:22 -!- alan_o [~alan_o@2600:1700:1902:210f:a557:fbdf:2187:dc34] has quit [Remote host closed the connection]
2024-01-11T09:42:40 -!- alan_o [~alan_o@2600:1700:1902:210f:c965:1406:4d38:1946] has joined ##stm32
2024-01-11T09:45:44 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-c98f-72bc-87e9-d01f.fixed6.kpn.net] has joined ##stm32
2024-01-11T09:57:57 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-11T09:58:24 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-11T10:03:57 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-11T10:04:46 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-11T10:18:59 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:516d:10ea:6aff:8498] has joined ##stm32
2024-01-11T10:53:08 -!- jtj [~jtj@212.66.207.170] has joined ##stm32
2024-01-11T10:57:25 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 264 seconds]
2024-01-11T12:11:50 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-c98f-72bc-87e9-d01f.fixed6.kpn.net] has quit [Ping timeout: 268 seconds]
2024-01-11T12:20:25 -!- hexo [~hexo@user/hexo] has joined ##stm32
2024-01-11T12:20:31 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2024-01-11T12:27:16 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2024-01-11T13:03:05 < karlp> hrm? we're using static freertos here extensively, mixed with dynamic, seems to work just fine?
2024-01-11T13:06:37 < ventYl> isn't dynamic saving the day?
2024-01-11T13:06:55 < karlp> saving the day?
2024-01-11T13:07:05 < karlp> I mean qyx was saying "timers don't work" 
2024-01-11T13:07:27 < karlp> we just have static tasks allocated statically, and dynamic tasks allocated ynamically, it just feels normal and fine.
2024-01-11T13:07:33 < ventYl> yeah, I'd expect that they stop working if you phase dynamic out entirely
2024-01-11T13:07:52 < ventYl> so as long as you just use static allocation side by side with dynamic, it works just fine
2024-01-11T13:08:00 < karlp> I can't imagine freertos in static only just "doesn't work"
2024-01-11T13:08:09 < karlp> I trust freertos user base more htan you and qyx on this I'm afraid.
2024-01-11T13:09:04 < ventYl> as I have abso-fucking-lutely zero experience with freertos, your approach here is right :)
2024-01-11T13:09:37 -!- machinehum [~machinehu@213.55.226.146] has joined ##stm32
2024-01-11T13:24:53 < qyx> karlp: I am not saying doesn't work
2024-01-11T13:25:11 < qyx> but if you configure "allow static allocation" I am expecting it to actually mean "allow" and not "force"
2024-01-11T13:25:24 < qyx> because it also forces the default idle task to be allocated statically
2024-01-11T13:25:29 < qyx> and timer task too
2024-01-11T13:25:39 < qyx> which means you have to provide some stubs for that
2024-01-11T13:27:18 < qyx> it is simply a matter of perception, I didn't tell it to allocate timers statically, I just set configSUPPORT_STATIC_ALLOCATION to 1 and expect it to mean "support"
2024-01-11T13:29:35 < qyx> but it causes undefined reference to `vApplicationGetIdleTaskMemory'
2024-01-11T13:29:41 < qyx> and vApplicationGetTimerTaskMemory
2024-01-11T13:30:41 < qyx> sorry, but that's a totally unrelated thing and if it want's to allocate timers statically, there should be a different define for that
2024-01-11T13:32:18 < qyx> this is simply bullshit https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/timers.c#L253
2024-01-11T13:35:04 -!- qyx_ [~qyx@84.245.121.114] has joined ##stm32
2024-01-11T13:35:12 < qyx_> fuk this interweb
2024-01-11T13:36:25 -!- qyx [~qyx@84.245.121.117] has quit [Ping timeout: 246 seconds]
2024-01-11T13:38:20 -!- qyx_ is now known as qyx
2024-01-11T13:40:30 < karlp> I don't know, given that you don't normally ever manually create the timer task, I think this is a perfectly reasonable, predictable and sensible decision.
2024-01-11T13:41:02 < karlp> you wanted to enable static and then have none? whatever, that's on you...
2024-01-11T13:42:20 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2024-01-11T13:44:03 < qyx> wat
2024-01-11T13:44:26 < qyx> no, the documentation says that if you enable static, you have another API functions available for you to freely use
2024-01-11T13:44:50 < qyx> it doesn't say that if you enable "support static" in the generic config, that you MUST use static
2024-01-11T13:45:08 < qyx> I don't want timers to be allocated statically but I want other tasks (to my liking) to be allocated statically
2024-01-11T13:47:30 < qyx> fucking whole freertos thing
2024-01-11T13:47:43 < qyx> yeah, they mention it, now I found it
2024-01-11T13:48:00 < qyx> "oh by the way if you select allow static, you must provide them"
2024-01-11T13:49:18 < qyx> and they are also saying "oh by the way, you actually don't have to but you need to set some other shit"
2024-01-11T13:49:37 < karlp> it just means the timer _task_ is static if you enable static. that seems totally reasonable, otherwise, you turn on static, use static tasks, but still got a dynamic timer task?
2024-01-11T13:49:57 < karlp> they're doing what 99.9% of people want when they start doign static, and not making more knobs for it.
2024-01-11T13:50:32 < karlp> wwhatever, go use cmrx instead :)
2024-01-11T13:50:32 < qyx> since dynamic is default, I would expect everything is allocated dynamically, even if static support is enabled
2024-01-11T13:50:46 < qyx> don't be grumpy, I am now
2024-01-11T13:51:09 < karlp> I'm predisposed to grump today, havne' been sleeping well at all this week, and am in some deep wtf code.
2024-01-11T13:51:17 < qyx> nah me neither
2024-01-11T13:51:31 < karlp> I have a file in this project that is 1100 lines, and is a single function
2024-01-11T13:52:01 -!- jtj [~jtj@212.66.207.170] has quit [Ping timeout: 245 seconds]
2024-01-11T13:52:53 -!- jtj [~jtj@212.66.207.170] has joined ##stm32
2024-01-11T13:55:00 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-c98f-72bc-87e9-d01f.fixed6.kpn.net] has joined ##stm32
2024-01-11T13:56:23 -!- machinehum [~machinehu@213.55.226.146] has quit [Ping timeout: 256 seconds]
2024-01-11T14:05:20 -!- machinehum [~machinehu@213.55.226.146] has joined ##stm32
2024-01-11T14:12:35 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-11T14:16:11 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 245 seconds]
2024-01-11T15:12:49 -!- jtj [~jtj@212.66.207.170] has quit [Quit: Konversation terminated!]
2024-01-11T15:13:14 -!- jtj [~jtj@212.66.207.170] has joined ##stm32
2024-01-11T15:19:01 -!- machinehum [~machinehu@213.55.226.146] has quit [Ping timeout: 264 seconds]
2024-01-11T15:22:30 -!- quinor [08c0f10716@2604:bf00:561:2000::dad] has joined ##stm32
2024-01-11T15:27:46 -!- machinehum [~machinehu@213.55.226.146] has joined ##stm32
2024-01-11T15:28:16 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-11T15:32:33 -!- machinehum2 [~machinehu@136.144.42.50] has joined ##stm32
2024-01-11T15:34:11 -!- machinehum [~machinehu@213.55.226.146] has quit [Ping timeout: 260 seconds]
2024-01-11T15:38:18 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-c98f-72bc-87e9-d01f.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-11T15:41:12 -!- quinor [08c0f10716@2604:bf00:561:2000::dad] has quit [Ping timeout: 260 seconds]
2024-01-11T15:51:42 -!- quinor [08c0f10716@2604:bf00:561:2000::dad] has joined ##stm32
2024-01-11T15:53:40 -!- machinehum2 [~machinehu@136.144.42.50] has quit [Ping timeout: 245 seconds]
2024-01-11T15:55:23 -!- machinehum [~machinehu@213.55.226.146] has joined ##stm32
2024-01-11T15:56:17 -!- quinor [08c0f10716@2604:bf00:561:2000::dad] has quit [Ping timeout: 260 seconds]
2024-01-11T15:56:21 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-11T16:14:01 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-11T16:28:15 < karlp> ValueError: Invalid format specifier 'int' for object of type 'int'
2024-01-11T16:28:17 < karlp> thanks python.
2024-01-11T16:32:42 < nuxil> the python. saysssss thanksssss.
2024-01-11T16:33:10 < nuxil> why would you have 1k+ lines in a single function. 
2024-01-11T16:33:28 < fenugrec> switch{case} that gets out of control
2024-01-11T16:33:35 < fenugrec> or if(if(if(if....
2024-01-11T16:37:03 < nuxil> thats way out of control that thats the reason :p
2024-01-11T16:37:12 < karlp> wild switch. sprawling with #ifdefs as well.
2024-01-11T16:37:31 < nuxil> #ifdefs in python ?
2024-01-11T16:37:48 < karlp> no, the 1100 lin efunction is C.
2024-01-11T16:37:57 < karlp> I'm doing some python tests to test the C.
2024-01-11T16:37:58 < nuxil> ah,. i was a bit confused
2024-01-11T16:40:05 < nuxil> why are you using py to test C and how are you testing C with py?
2024-01-11T16:41:56 < nuxil> i used to love py. back at 2.6/2.7 but after 3.x, i dont use py much. once in a while to wrap up some simple quick scripts.
2024-01-11T16:47:44 < ventYl> fucking clang-tidy. you can't turn off some check, because it is turned on by something in compile_commands.json, and if you override it on commandline, then clang-tidy ignores the whole contents of .json, so no include paths
2024-01-11T16:47:51 < ventYl> who ordered this?
2024-01-11T16:48:06 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-11T16:48:21 < nuxil> gcc & make ftw :D
2024-01-11T16:49:54 < ventYl> i can't see how it would help me
2024-01-11T16:57:14 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-11T17:03:15 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-c98f-72bc-87e9-d01f.fixed6.kpn.net] has joined ##stm32
2024-01-11T17:05:49 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:516d:10ea:6aff:8498] has quit [Ping timeout: 264 seconds]
2024-01-11T17:06:22 -!- MGF_Fabio [~MGF_Fabio@81.56.161.139] has joined ##stm32
2024-01-11T17:07:41 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-c98f-72bc-87e9-d01f.fixed6.kpn.net] has quit [Ping timeout: 240 seconds]
2024-01-11T17:07:56 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-8534-9128-529a-32e4.fixed6.kpn.net] has joined ##stm32
2024-01-11T17:08:35 < karlp> nuxil: C tcp services, python client.
2024-01-11T17:08:59 < karlp> py3 is great, glad that 2 is all but gone now.
2024-01-11T17:24:25 -!- ferdna [~ferdna@user/ferdna] has quit [Ping timeout: 264 seconds]
2024-01-11T17:34:02 -!- hexo [~hexo@user/hexo] has quit [Ping timeout: 268 seconds]
2024-01-11T17:47:49 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-8534-9128-529a-32e4.fixed6.kpn.net] has quit [Ping timeout: 264 seconds]
2024-01-11T17:51:47 -!- HelloShi1ty [~user@bl15-39-23.dsl.telepac.pt] has joined ##stm32
2024-01-11T18:24:57 < jadew> I remember a while ago, one of you was bragging about their tiling window manager - which one was that?
2024-01-11T18:26:06 < jadew> I need to tile some terminal emultaors, and Terminator, while OK... I just don't like it.
2024-01-11T18:33:17 < jadew> nvm, found the settings panel.
2024-01-11T18:36:51 < karlp> mawk: this might be for you, might bt too slow still though... https://www.youtube.com/watch?v=1qb_Ls-s9SQ
2024-01-11T18:38:21 -!- hexo [~hexo@user/hexo] has joined ##stm32
2024-01-11T18:41:57 < nuxil> toilet trance?
2024-01-11T18:48:49 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-11T18:49:42 < nomorekaki> indeed how to test with py
2024-01-11T18:50:29 < nomorekaki> can structs and defines be accessed?
2024-01-11T18:50:56 < nuxil> you talking about embedeing py ?
2024-01-11T18:51:10 < nomorekaki> I don't even know what I'm talking
2024-01-11T18:51:24 < nomorekaki> but people test their code with py scripts that much I know
2024-01-11T18:52:50 < nuxil> if the py is a external script. i cant see how it can access structs. maybe by using Cpython or something and import a dll/so. but idk. 
2024-01-11T18:54:06 < nomorekaki> so probably the python part is used to generate datasets
2024-01-11T18:54:24 < nomorekaki> for test that is written in C
2024-01-11T18:59:37 < nuxil> actually you can access structs. if you know the mem location of it and its size. then you can use ctypes and reconstruct it example struct.unpack
2024-01-11T18:59:55 < nomorekaki> ah
2024-01-11T19:03:49 < nomorekaki> I have not ever seen example of project having python tests
2024-01-11T19:03:50 < nuxil> i am acually using stuct.unpack to reconstruct data with my current py script :p , to convert data sent over the serial back to uint16, and floats etc.
2024-01-11T19:04:14 < nomorekaki> use nanopb
2024-01-11T19:04:21 < nuxil> nah. 
2024-01-11T19:04:45 < nuxil> im too lazy :P
2024-01-11T19:04:48 < nomorekaki> it's actually easier just do it with python
2024-01-11T19:07:01 -!- machinehum [~machinehu@213.55.226.146] has quit [Ping timeout: 264 seconds]
2024-01-11T19:09:07 < nomorekaki> are macro directives allowed inside a macro?
2024-01-11T19:11:16 < nuxil> yes
2024-01-11T19:11:30 < nuxil> #define A(a,b) (a+b)
2024-01-11T19:11:31 < nuxil> #define B(a,b)  (A(a,b) * (a + b))
2024-01-11T19:11:36 < nuxil> printf("%i", B(2,2));
2024-01-11T19:11:39 < nuxil> 16
2024-01-11T19:11:59 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 264 seconds]
2024-01-11T19:15:08 < nuxil> nomorekaki, have you ever looked at the MarlinFW ? probably not if you dont have a 3d printer.
2024-01-11T19:15:17 < nuxil> but damn. 90% if that stuff is macros
2024-01-11T19:18:20 < fenugrec> but no you can't nest e.g. #define A(x) #define x_asdf. You have other problems if you need to be doing that
2024-01-11T19:19:12 < nomorekaki> how about #if #else #endif?
2024-01-11T19:19:36 < jpa-> you can nest #if stuff
2024-01-11T19:19:48 < jpa-> after all most headers are nested inside #ifndef HEADER_H
2024-01-11T19:20:03 < fenugrec> yea but not the other way around IIRC
2024-01-11T19:20:39 < jpa-> ?
2024-01-11T19:20:58 < mawk> nomorekaki you can call macros in macros but be careful
2024-01-11T19:21:08 < mawk> only one level of nesting at a time
2024-01-11T19:21:10 < fenugrec> #define A  #ifdef M1 #define stuff #endif
2024-01-11T19:21:26 < mawk> #define A(x) B(C(x)) won't work
2024-01-11T19:21:28 < fenugrec> it would be pointless anyway probably
2024-01-11T19:21:35 < mawk> #define A(x) B(x) will work
2024-01-11T19:21:47 < mawk> only one level of indirection can be removed at a time
2024-01-11T19:21:58 < mawk> define a cascade of macros instead if you need nesting 
2024-01-11T19:22:32 < mawk> no you can't do that fenugrec 
2024-01-11T19:23:04 < mawk> or I don't get what you're trying to do I guess 
2024-01-11T19:23:10 < fenugrec> mawk it's not me that wants to do that, kaki wants to bend the fabric of space-time with his macros
2024-01-11T19:23:14 < mawk> you can put defines between #if and #endif
2024-01-11T19:23:40 < jpa-> mawk: B(C(x)) works fine for me: https://godbolt.org/z/Ybf3z4M7q
2024-01-11T19:24:24 < mawk> yeah I guess that's still just one level
2024-01-11T19:24:50 < mawk> if you give a macro argument to A though it will break
2024-01-11T19:24:57 < mawk> at line 7
2024-01-11T19:25:05 < mawk> maybe
2024-01-11T19:25:17 < mawk> I forgot the canonical example 
2024-01-11T19:25:23 < jpa-> doesn't break for me :)
2024-01-11T19:25:41 < jpa-> there are limitations to macro expansion but your rule seems misleading
2024-01-11T19:26:13 < jpa-> https://en.wikipedia.org/wiki/C_preprocessor#Macro_definition_and_expansion  "it's not that simple"
2024-01-11T19:28:36 < mawk> aa
2024-01-11T19:28:41 < mawk> it's about recursion 
2024-01-11T19:31:27 < mawk> jpa- https://ideone.com/HTdmxH
2024-01-11T19:31:36 < mawk> it doesn't break, but it's not compile time anymore 
2024-01-11T19:31:44 < mawk> the macros are not being denested
2024-01-11T19:32:21 < jpa-> it's "compile time", but the stringification operation is just acting on the value you give to x
2024-01-11T19:32:55 < nuxil> but isnt #x trying to stringigy a number ?
2024-01-11T19:33:02 < jpa-> if you want to expand before stringification, you can just do https://ideone.com/YdS8IM
2024-01-11T19:33:16 < mawk> yes, that's the point
2024-01-11T19:33:29 < jpa-> nah, preprocessor doesn't execute calculations in an expression except if it is in #if
2024-01-11T19:33:30 < mawk> you need to add intermediate macros to force evaluation of arguments
2024-01-11T19:34:10 < jpa-> mawk: yeah, that is just the defined order of operations, like "you need to add parentheses if you want to add before multiply"
2024-01-11T19:34:26 < jpa-> one thing has to happen first, either stringification or expansion
2024-01-11T19:52:29 -!- machinehum [~machinehu@213.55.226.146] has joined ##stm32
2024-01-11T20:02:16 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-11T20:09:25 < zyp> one of my coworkers loves doing the macro trick where you include a header multiple times with different defines to generate various stuff from it
2024-01-11T20:15:22 < veverak> x maros
2024-01-11T20:15:25 < veverak> *macros
2024-01-11T20:17:26 < Steffanx> Zephyr loves macros too. Some even so "complex" that it's breaks vs code's intellisense.
2024-01-11T20:22:08 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-1535-9a0b-700d-cd8c.fixed6.kpn.net] has joined ##stm32
2024-01-11T20:23:44 -!- hexo [~hexo@user/hexo] has quit [Remote host closed the connection]
2024-01-11T20:24:06 -!- hexo [~hexo@user/hexo] has joined ##stm32
2024-01-11T20:24:52 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-11T20:25:26 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-11T20:25:37 < zyp> meanwhile I'm hoping P2996 goes into C++26 so there's even less of a reason to use macros
2024-01-11T20:38:04 -!- CygniX [~CygniX@user/CygniX] has quit [Ping timeout: 256 seconds]
2024-01-11T20:40:10 -!- CygniX [~CygniX@user/CygniX] has joined ##stm32
2024-01-11T20:54:29 -!- CygniX [~CygniX@user/CygniX] has quit [Ping timeout: 260 seconds]
2024-01-11T20:57:21 -!- alan_o [~alan_o@2600:1700:1902:210f:c965:1406:4d38:1946] has quit [Remote host closed the connection]
2024-01-11T20:57:26 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-11T20:57:40 -!- alan_o [~alan_o@2600:1700:1902:210f:d43d:e50b:1f38:cff] has joined ##stm32
2024-01-11T21:45:47 < Ecco> Rembmer when we talked about h-bridge to drive a motor?
2024-01-11T21:45:56 < Ecco> Then I realized the manufacturer was PWM-ing the thing?
2024-01-11T21:46:21 < Ecco> And someone said that I'd need to have a deadband to make sure there are no (temporary) short circuits
2024-01-11T21:46:40 < Ecco> I'm not sure I understood that last part
2024-01-11T21:47:02 < Ecco> My understanding is that the H-bridge uses 4 transistors to enable the motor to go either direciton
2024-01-11T21:47:07 < Ecco> so there are 4 possible combinations
2024-01-11T21:47:13 < Ecco> 2 will yield a rotating motor
2024-01-11T21:47:32 < Ecco> sorry, 4 transsitor = 2^4 possibilities
2024-01-11T21:47:45 < Ecco> but anyway, two combinations yield a rotating motor
2024-01-11T21:47:47 < Ecco> and some combinations
2024-01-11T21:47:50 < Ecco> yield a short circuit
2024-01-11T21:48:05 < Ecco> but could I simply just leave one transistor making a connection to the ground
2024-01-11T21:48:09 < Ecco> and just PWM the other one?
2024-01-11T21:48:23 < Ecco> so it would alternate between connected and high impedance?
2024-01-11T21:48:59 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 256 seconds]
2024-01-11T22:25:16 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-11T22:25:44 < PaulFertser> Ecco: transistors might be not turning off immediately so there should be some delay to make sure it's really off I think.
2024-01-11T22:26:27 < PaulFertser> Ecco: what are you trying to do, do you need to rotate both ways or just one way?
2024-01-11T22:27:20 -!- drzacek [~quassel@2a01:3d8:3b0:d100:388:4a5a:b41f:9e21] has joined ##stm32
2024-01-11T22:35:10 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-11T22:59:49 -!- machinehum [~machinehu@213.55.226.146] has quit [Ping timeout: 264 seconds]
2024-01-11T23:03:29 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-11T23:03:45 < Ecco> It's a roller blind that I'm hacking
2024-01-11T23:03:51 < Ecco> It needs to rotate up or down
2024-01-11T23:03:56 < Ecco> like up in the morning, down in the evening
2024-01-11T23:04:04 < Ecco> I'm replacing the MCU
2024-01-11T23:04:09 < Ecco> the MCU receives over 433 MHz
2024-01-11T23:04:11 < nomorekaki> Ecco: ctrl-f your pdf
2024-01-11T23:04:14 < Ecco> I want to control it over Wifi
2024-01-11T23:04:16 < nomorekaki> "deadband"
2024-01-11T23:04:27 < Ecco> There's no pdf whatsoever
2024-01-11T23:04:38 < Ecco> it's a cheap chinese electric rolller I bought off of Amazon
2024-01-11T23:04:39 < nomorekaki> for esp32?
2024-01-11T23:04:53 < Ecco> oh, well, I have an ESP8286
2024-01-11T23:05:00 < Ecco> I don't think it even does PWM in hardware
2024-01-11T23:05:43 < Ecco> It's ok tho, I'll code it in software if needed
2024-01-11T23:21:10 -!- drzacek [~quassel@2a01:3d8:3b0:d100:388:4a5a:b41f:9e21] has quit [Quit: https://quassel-irc.org - Czatuj komfortowo. Wszędzie.]
2024-01-11T23:30:46 < PaulFertser> Ecco: is that same device with weird accelerometer?
2024-01-11T23:31:12 < PaulFertser> Ecco: if you need it up or down how do you expect to reverse the current through motor other than by using a full bridge?
2024-01-11T23:33:28 < karlp> iirc from the schematics they shared, it'ðs got a full bridge
2024-01-11T23:33:40 < karlp> I think they'r emixing up "H" bridge and "half" bridge
2024-01-11T23:34:39 < nomorekaki> Ecco: if you don't drive both transistors another one acts as diode
2024-01-11T23:34:41 < qyx> because 'h' is only one half of 'H'
2024-01-11T23:34:59 < qyx> nomorekaki: no
2024-01-11T23:35:47 < qyx> I mean you have to merge 'h' and a rotated 'h', you know
2024-01-11T23:35:54 < PaulFertser> n is one half of H :)
2024-01-11T23:37:04 < PaulFertser> Ecco: your question is still not clear, please clarify
2024-01-11T23:37:20 < qyx> Ecco: trash tne transistor idea and use a 20 cent H-bridge brushed motor driver IC
2024-01-11T23:37:32 < qyx> and to answer
2024-01-11T23:37:55 < qyx> turning both top and bottom transistor of the same leg makes short circuit
2024-01-11T23:38:02 < qyx> so 2 combination off for those
2024-01-11T23:38:39 < qyx> turning bottom transistors of both legs or both top transistors shorts the motor making it brake
2024-01-11T23:38:48 < qyx> so another two combinations off, 12 left
2024-01-11T23:39:19 < qyx> you can't have 3 transistors on in a H-bridge, so another 4 combinations off, 8 left
2024-01-11T23:39:20 < nomorekaki> qyx: Ecco: in case of driving one half bridge with only one pwm signal instead of inverted pwm pair \w deadtime the other transistor that is inactive will freewheel and produce heat
2024-01-11T23:39:48 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Ping timeout: 250 seconds]
2024-01-11T23:40:07 < qyx> all transistors off obviously do nothing, so 7 left
2024-01-11T23:40:16 < qyx> all 4 on is bullshit, 6 left
2024-01-11T23:41:01 < qyx> you can have just a single transistor on but that doesn'yrotatethe motor, so minus another 4
2024-01-11T23:41:32 < qyx> so there are only 2 sensible combinatios left making the motor turn left and right
2024-01-11T23:42:00 < qyx> from the practical PoV, those 2 + braking with low side + all off makes sense
2024-01-11T23:42:13 < qyx> so 4 combinations
2024-01-11T23:44:14 < qyx> and regarding the deadband stuff, you pwm a h-bridge setting one leg to high and pwm-in the other leg low-side
2024-01-11T23:44:43 < qyx> or the other way around - setinng one leg permamnently low and pwm-in the other leg high side
2024-01-11T23:44:58 < qyx> that way there is no deadband needed
2024-01-11T23:45:20 < qyx> sorryfor my android
2024-01-11T23:46:01 < qyx> nomorekaki: oh that
2024-01-11T23:46:29 < qyx> yeah but who cares here
2024-01-11T23:47:08 < qyx> for a low freq stuff
--- Day changed pe tammi 12 2024
2024-01-12T00:07:13 < nomorekaki> Ecco: states for one half-bridge: H, L, hiZ. Focus on producing those states individually for both half bridges with or without pwm. hiZ needs to be timed intermediary step when switching between H and L.
2024-01-12T00:07:28 < Ecco> yeah, makes sense
2024-01-12T00:07:57 < Ecco> thanks guys!
2024-01-12T00:08:19 < nomorekaki> if you don't switch between H and L but between H and hiZ or L and HiZ you don't nee that timing
2024-01-12T00:08:57 < Ecco> No the device with a weird accelerometer is a "smart" lamp
2024-01-12T00:09:10 < Ecco> This one: https://us.gosund.com/blog/gosund-smart-table-lamp-lb3
2024-01-12T00:09:19 < Ecco> I've just written an ESPHome driver for this
2024-01-12T00:09:26 < Ecco> Works really well now :)
2024-01-12T00:09:58 < Ecco> Now, I can write smart-home routines like "if my bedside lamp is tilted 37° to the left, then turn off my toothbrush". Woo-hoo!
2024-01-12T00:14:57 -!- machinehum [~machinehu@213.55.226.146] has joined ##stm32
2024-01-12T00:15:51 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Quit: Client closed]
2024-01-12T00:19:37 -!- machinehum [~machinehu@213.55.226.146] has quit [Ping timeout: 264 seconds]
2024-01-12T00:21:49 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-12T00:23:21 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-12T00:30:21 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Quit: Client closed]
2024-01-12T00:31:32 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-12T00:36:07 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-12T00:38:49 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-1535-9a0b-700d-cd8c.fixed6.kpn.net] has quit [Ping timeout: 264 seconds]
2024-01-12T00:47:54 -!- fdarling [~forest@h96-61-110-114.mtjltn.dedicated.static.tds.net] has joined ##stm32
2024-01-12T01:07:28 -!- machinehum [~machinehu@213.55.226.146] has joined ##stm32
2024-01-12T01:11:52 -!- machinehum [~machinehu@213.55.226.146] has quit [Ping timeout: 255 seconds]
2024-01-12T01:13:13 < jadew> fenugrec, hey, just wanted to let you know that I didn't forget about your request, but I'm in a bit of a difficult period right now where I'm working 100% of the available time. Odds that I'll find a free day to get into all that in the coming months are slim to none.
2024-01-12T01:22:37 -!- hexo [~hexo@user/hexo] has quit [Ping timeout: 264 seconds]
2024-01-12T01:34:18 -!- hexo [~hexo@user/hexo] has joined ##stm32
2024-01-12T01:59:14 -!- machinehum [~machinehu@213.55.226.146] has joined ##stm32
2024-01-12T02:04:01 -!- machinehum [~machinehu@213.55.226.146] has quit [Ping timeout: 264 seconds]
2024-01-12T02:12:31 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-12T02:14:34 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Quit: Client closed]
2024-01-12T02:16:19 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 260 seconds]
2024-01-12T02:16:29 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 260 seconds]
2024-01-12T02:48:14 -!- machinehum [~machinehu@213.55.226.146] has joined ##stm32
2024-01-12T02:52:37 -!- machinehum [~machinehu@213.55.226.146] has quit [Ping timeout: 264 seconds]
2024-01-12T02:54:17 -!- MGF_Fabio [~MGF_Fabio@81.56.161.139] has quit [Ping timeout: 260 seconds]
2024-01-12T03:18:53 < jadew> I've officially given up on google. Most results are generic garbage that ignore important keywords.
2024-01-12T03:30:25 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-12T03:31:58 < nuxil> google isnt what it used to be.
2024-01-12T03:32:16 < nuxil> now 1/2 the result it gives are ads and other bullshit
2024-01-12T03:37:26 -!- machinehum [~machinehu@213.55.226.146] has joined ##stm32
2024-01-12T03:41:43 -!- machinehum [~machinehu@213.55.226.146] has quit [Ping timeout: 255 seconds]
2024-01-12T04:22:16 -!- fdarling [~forest@h96-61-110-114.mtjltn.dedicated.static.tds.net] has quit [Quit: Leaving]
2024-01-12T04:25:23 < Ecco> https://i.imgur.com/zXpnCes.png
2024-01-12T04:25:33 < Ecco> So I made this "truth table" for the H-bridge controlling a DC motor
2024-01-12T04:25:38 < Ecco> Does this sound about right?
2024-01-12T04:26:03 < Ecco> (it should match what you guys told me, but I may have effed something up)
2024-01-12T04:27:32 -!- machinehum [~machinehu@213.55.226.146] has joined ##stm32
2024-01-12T04:28:32 < Ecco> I renamed the columns to make them a bit easier to follow
2024-01-12T04:28:32 < Ecco> https://i.imgur.com/12AhqfZ.png
2024-01-12T04:29:10 < Ecco> X means disconnected and - means connected
2024-01-12T04:32:10 -!- machinehum [~machinehu@213.55.226.146] has quit [Ping timeout: 276 seconds]
2024-01-12T04:33:14 < nuxil> why are you using 8 transistors ? only 4 is needed
2024-01-12T05:12:32 < nuxil> Ecco, you only need 4 transistors in a h bridge to change direction. 2x pnp and 2x npn. and 4 gpio pints where two are inverted.
2024-01-12T05:14:20 < nuxil> quick example. http://tinyurl.com/yvremt2k  press the top switch and motor goes one way. press the other and it goes the other way.. both can not be closed at the same time tho
2024-01-12T05:17:13 -!- machinehum [~machinehu@213.55.226.146] has joined ##stm32
2024-01-12T05:22:13 -!- machinehum [~machinehu@213.55.226.146] has quit [Ping timeout: 276 seconds]
2024-01-12T05:22:44 < nuxil> actually you can get away with only two gpio pins. but then you must add two extra npn transistors. 
2024-01-12T05:31:21 -!- Thorn [~Thorn@user/thorn] has quit [Quit: I cna ytpe 300 wrods pre mniuet!!!]
2024-01-12T05:32:24 < jadew> Anyone looking for some hair dye? https://ce8dc832c.cloudimg.io/cdn/n/n@753fa15f3eaadb9ebf0eaffdeed8bcf5086b88e8/_cs_/2020/07/5f055f78de742/katalog_2020_box_pl.jpg
2024-01-12T05:33:38 < jadew> Or maybe a different color: https://ce8dc832c.cloudimg.io/cdn/n/n@5bad960992cbecc6de1726b86eed12d18d6430bf/_cs_/2020/07/5f055f765de0b/katalog_2018_box_nl.jpg
2024-01-12T05:41:08 < nuxil> heh, nah. im good :)
2024-01-12T06:06:16 -!- machinehum [~machinehu@213.55.226.146] has joined ##stm32
2024-01-12T06:10:37 -!- machinehum [~machinehu@213.55.226.146] has quit [Ping timeout: 264 seconds]
2024-01-12T06:28:01 -!- HelloShi1ty [~user@bl15-39-23.dsl.telepac.pt] has quit [Ping timeout: 264 seconds]
2024-01-12T06:40:26 -!- machinehum [~machinehu@213.55.226.146] has joined ##stm32
2024-01-12T06:45:25 -!- machinehum [~machinehu@213.55.226.146] has quit [Ping timeout: 264 seconds]
2024-01-12T06:53:08 < fenugrec> hey jadew , no worries, I figured you'd come accross your old boards now and then and it would remind you. Hope things will fall in place favourably job-wise, maybe I'll ping you once a month or something
2024-01-12T07:19:01 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-12T07:29:46 -!- machinehum [~machinehu@213.55.226.146] has joined ##stm32
2024-01-12T07:34:05 -!- machinehum [~machinehu@213.55.226.146] has quit [Ping timeout: 245 seconds]
2024-01-12T08:03:37 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-12T08:09:51 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-7d8b-3f20-a5a0-9519.fixed6.kpn.net] has joined ##stm32
2024-01-12T08:21:13 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Remote host closed the connection]
2024-01-12T08:29:54 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2024-01-12T08:31:33 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-7d8b-3f20-a5a0-9519.fixed6.kpn.net] has quit [Quit: Leaving]
2024-01-12T08:41:18 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-a42a-85ae-3ffa-834c.fixed6.kpn.net] has joined ##stm32
2024-01-12T08:49:01 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-a42a-85ae-3ffa-834c.fixed6.kpn.net] has quit [Ping timeout: 264 seconds]
2024-01-12T08:59:58 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-12T09:57:06 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:ed7e:29c9:bb3:1b6d] has joined ##stm32
2024-01-12T10:22:14 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-12T10:23:02 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-12T10:30:25 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-12T10:30:53 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-12T11:04:41 -!- HelloShi1ty [~user@bl15-39-23.dsl.telepac.pt] has joined ##stm32
2024-01-12T11:08:59 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-12T11:49:27 < qyx> Ecco: your sch is wrong, to drive low side n-channel mosfets, you can connect them directly to GPIO (beware, not always)
2024-01-12T11:49:49 < qyx> and there are pulldowns on both gates
2024-01-12T11:50:19 < qyx> for high side p-mosfets, you need to pull them up + use a n-mosfet to drive the gate, that part of your schematic is good
2024-01-12T11:50:42 < qyx> so 4 power transistors and 2 small signal transistors for high side drive
2024-01-12T11:51:58 < qyx> I still recommend using a bidir brushed motor driver IC
2024-01-12T12:10:17 -!- boB_K7IQ [~boB_K7IQ@184-98-64-136.phnx.qwest.net] has quit [Ping timeout: 252 seconds]
2024-01-12T12:10:39 -!- boB_K7IQ [~boB_K7IQ@184-98-79-231.phnx.qwest.net] has joined ##stm32
2024-01-12T12:22:15 < karlp> they're super cheap. there's little reason to do discrete unless you're reallllly doing retail volume slicing.
2024-01-12T12:25:10 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-12T13:18:04 < mawk> time to learn some ruby
2024-01-12T13:18:16 < mawk> my unit test framework chokes on weak functions 
2024-01-12T13:18:20 < mawk> i have to fix it
2024-01-12T13:48:43 < jbo> cookies
2024-01-12T13:53:15 < Steffanx> I can recommend Stroopwafels, jbo
2024-01-12T13:53:20 < jbo> indeed
2024-01-12T13:53:28 < jbo> so UPS fucked up...
2024-01-12T13:53:45 < Steffanx> Whats new?
2024-01-12T13:54:14 < jbo> they were supposed to deliver a package with "signature required" yesterday. nobody at the office did give a signature or see the package to begin with. UPS claims that it was delivered "in the mail box"
2024-01-12T13:54:24 < jbo> the PITA: It's a PCB deliver from eurocircuits .__.
2024-01-12T13:55:21 < Steffanx> Awesome... so in short, it wasn't delivered because no signature. More time wasted to get new ones though.
2024-01-12T13:55:35 < jbo> yes
2024-01-12T14:05:11 < mawk> =================== SUMMARY =====================
2024-01-12T14:05:11 < mawk> Tests Passed  : 536
2024-01-12T14:05:12 < mawk> Tests Failed  : 0
2024-01-12T14:05:12 < mawk> Tests Ignored : 1
2024-01-12T14:05:17 < mawk> slowly getting there
2024-01-12T14:05:43 < jbo> what are we testing today?
2024-01-12T14:05:44 < mawk> since I introduced unit tests when I started here last year
2024-01-12T14:05:46 < mawk> everything
2024-01-12T14:06:21 < jbo> that would include testing Steffan's ability to craft a nuclear power plant from nothing but toothpicks and tea bags
2024-01-12T14:06:29 < mawk> 20.8% of lines covered
2024-01-12T14:06:35 < mawk> but I'm working to bring that downm
2024-01-12T14:06:42 < mawk> by adding more files to the coverage report
2024-01-12T14:08:54 < Steffanx> How many bugs have you found with your tests so far mawk ?
2024-01-12T14:09:33 < mawk> 2 or 3 maybe
2024-01-12T14:09:42 < mawk> not counting bugs preemptively found before the PR was over
2024-01-12T14:10:10 < Steffanx> Hm
2024-01-12T14:20:25 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2024-01-12T14:21:10 < jpa-> qyx: you are in .sk, right? do you want to be my drug smugg... leaf spring reseller? i'd need 2x https://www.prehome.sk/qeridoo-lamela-dlha-150x25-od-2018 but they don't ship to .fi
2024-01-12T14:23:08 < jbo> :D
2024-01-12T14:25:52 < qyx> jpa-: whats that, for a kid trolley cart?
2024-01-12T14:26:06 < qyx> or how is the thing called exactly
2024-01-12T14:26:22 < jpa-> yeah, exactly
2024-01-12T14:26:38 < jpa-> the springs keep breaking every few years
2024-01-12T14:26:55 < jbo> did you check whether there's something wrong with your kid?
2024-01-12T14:27:17 < qyx> lol
2024-01-12T14:27:33 < jpa-> well.. he *is* over the weight limit already, but nowadays i'm using the cart mostly for cargo
2024-01-12T14:27:47 < qyx> jpa-: it is 4.50 shipping here + 12-20e shipping to .fi, is it < 2 kg total?
2024-01-12T14:27:51 < jpa-> now the spring broke when i brought home a table
2024-01-12T14:28:03 < jbo> :D
2024-01-12T14:28:26 < jpa-> qyx: definitely, about 150g per each
2024-01-12T14:30:00 < jpa-> the only shop that i found that ships to finland (kidscab) wants 20 EUR per spring and 28 EUR shipping
2024-01-12T14:31:10 < qyx> https://bin.jvnv.net/file/7MwhE/Screenshot_2024-01-12_13-30-53.png
2024-01-12T14:31:19 < qyx> it is manageable, ping me later during the weekend
2024-01-12T14:31:43 < qyx> it shoul be possible to send it as a letter
2024-01-12T14:32:05 < jpa-> sounds good
2024-01-12T14:32:37 < jpa-> no hurry, and just let me know the total and i can paypal or IBAN you the money ahead of time
2024-01-12T14:33:03 < jpa-> even if it needs to be parcel, it is still a lot cheaper
2024-01-12T14:33:34 < qyx> < 2kg, x+y+z < 90 cm
2024-01-12T14:33:59 < mawk> I think I've lost at least a year of my life looking at 'make' until it finishes compiling
2024-01-12T14:34:11 < mawk> I tried adding -j16 inside but the parallelism breaks everything
2024-01-12T14:34:13 < mawk> so I have to wait
2024-01-12T14:34:18 < mawk> ccache helps a little but not a lot
2024-01-12T14:34:48 < jbo> qyx, looks like you should definitely be checking the "precious metals" checkbox in the screenshot you sent
2024-01-12T14:34:56 < Steffanx> So make the parallelism work, mawk 
2024-01-12T14:35:16 < mawk> I tried already
2024-01-12T14:35:29 < mawk> but the makefiles are generated in ruby and I'm not paid to learn ruby
2024-01-12T14:37:35 < mawk> last week I deleted all my data on my laptop
2024-01-12T14:37:40 < mawk> all my nice quality of life scripts
2024-01-12T14:37:45 < mawk> because of a typo in rsync command
2024-01-12T14:38:01 < mawk> I think my boss doesn't believe me and thinks it's an excuse for slacking off
2024-01-12T14:48:28 < jbo> is it not? :D
2024-01-12T14:52:12 < mawk> lol
2024-01-12T14:52:13 < mawk> no
2024-01-12T14:52:17 < mawk> I had sweet scripts
2024-01-12T14:52:22 < mawk> I have to rewrite them now
2024-01-12T15:12:42 < Steffanx> y u no backup mawk ?
2024-01-12T15:14:32 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-12T15:22:54 -!- ferdna [~ferdna@user/ferdna] has quit [Ping timeout: 256 seconds]
2024-01-12T15:23:16 < mawk> that's for weaklings
2024-01-12T15:28:48 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-12T15:41:47 < Ecco> ok guys, the schematics I posted yesterday
2024-01-12T15:41:49 < Ecco> *not mine*
2024-01-12T15:41:56 < Ecco> I got some cheap roller blinds off of Amazon
2024-01-12T15:42:40 < Ecco> and reversed the PCB they came in (I don't remember if that was you qyx or zyp that even figured out that what I thought was a transistor was in fact a hall effect sensor)
2024-01-12T15:43:22 < Ecco> So yeah, I also wondered why they would use extra transistor in front of the power mosfests
2024-01-12T15:43:29 < Ecco> (but your explanation was interesting)
2024-01-12T15:43:52 < Ecco> on those roller blinds, there's a Cortex M0+ MCU driving the GPIOs
2024-01-12T15:44:06 < Ecco> I want to replace it with an ESP8226 running ESPHome
2024-01-12T15:45:53 < Ecco> mawk: I'm pretty good at Ruby, if you need help
2024-01-12T15:46:54 < qyx> Ecco: the only reason I can think off is to use standard gate voltage mosfets instead of logic ones
2024-01-12T15:47:12 < qyx> in that case you need higher voltage than 3.3/5 V
2024-01-12T15:47:47 < qyx> so they are basically driving the mosfet with those pullups to Vbat and shorting it to ground to turn them off
2024-01-12T15:48:04 < zyp> IIRC the main reason for the transistors is to buffer the pfet gate, because Vbat is higher than logic level
2024-01-12T15:48:25 < qyx> yeah but they are in front of nfets too
2024-01-12T15:48:36 < zyp> probably to give both similar delay
2024-01-12T15:48:46 < qyx> or to drive them higher
2024-01-12T15:48:57 < zyp> possible
2024-01-12T15:48:59 < qyx> but in thatcase they are both default on
2024-01-12T15:50:44 < zyp> no
2024-01-12T15:51:03 < zyp> both gates are pulled up, for pfet up is off
2024-01-12T15:51:35 < qyx> I mean both nfets are default on
2024-01-12T15:51:40 < qyx> both pfets are default off
2024-01-12T15:51:44 < zyp> correct
2024-01-12T15:52:07 < qyx> so it is basically braking by default with zero curre t through those pullups
2024-01-12T15:56:06 < zyp> don't you call that «recycling»?
2024-01-12T16:01:23 < jpa-> or because of copypaste engineering
2024-01-12T17:07:17 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-12T17:26:58 < jbo> "engineering"
2024-01-12T17:47:56 < nuxil> Ecco> ok guys, the schematics I posted yesterday ,...... good cos it was shit :P just google "H bridge circuit example" and you will find a ton of examples. like this old site. https://www.talkingelectronics.com/projects/H-Bridge/H-Bridge-1.html and more
2024-01-12T17:50:50 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-12T17:53:48 < Ecco> ok :-D
2024-01-12T17:56:38 < nuxil> 200 transistor circuits. many nice things https://www.talkingelectronics.com/projects/200TrCcts/200TrCcts.html
2024-01-12T17:59:26 < nuxil> Ecco, get a ldr and add it to your  roller blinds setup so it will automaticly lower raise based on how much light there is + a override for manual control :)
2024-01-12T18:00:46 < Ecco> ldr?
2024-01-12T18:01:00 < Ecco> oh, light resistor?
2024-01-12T18:01:09 < Ecco> Actually, smart homes are a pretty deep rabbit hole
2024-01-12T18:01:34 < Ecco> You can quite easily make the blinds go down as the sun sets, for example
2024-01-12T18:02:10 < Ecco> I mean, once the motor works
2024-01-12T18:02:16 < Ecco> and, good news, I jsut got it to work
2024-01-12T18:02:24 < Ecco> now I'm working on the hall sensor
2024-01-12T18:03:58 < Ecco> Yay, working too!
2024-01-12T18:05:03 < Ecco> I wonder why they put 2 hall sensors tho
2024-01-12T18:05:13 < Ecco> wouldn't just one be enough?
2024-01-12T18:11:00 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-12T18:11:09 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:ed7e:29c9:bb3:1b6d] has quit [Ping timeout: 256 seconds]
2024-01-12T18:13:11 < nuxil> well. its probably a hall effect latch or switch. so no you would need 2 or more. 
2024-01-12T18:13:24 < nuxil> you will ofte see 3 of them in example pc fans.
2024-01-12T18:13:28 < nuxil> even 4
2024-01-12T18:14:36 < Ecco> I don't get it
2024-01-12T18:15:02 < Ecco> https://i.imgur.com/HgrMcbR.png
2024-01-12T18:15:14 < Ecco> Here's what the two sensors output when the motor is turning in one direction or the other
2024-01-12T18:15:20 < Ecco> (their phase shifts)
2024-01-12T18:15:35 < Ecco> I mean, with 2 sensors you can measure the direction of th emotor
2024-01-12T18:15:41 < Ecco> but given the same chips controls the direction
2024-01-12T18:15:47 < Ecco> it's an information it already has
2024-01-12T18:15:56 < Ecco> now the rotation of the motor
2024-01-12T18:16:01 < Ecco> is given by either of the sensors
2024-01-12T18:16:28 < qyx> quite messy waveform
2024-01-12T18:16:43 < Ecco> Well, yeah
2024-01-12T18:16:43 < qyx> I was expecting a much cleaner one
2024-01-12T18:17:05 < Ecco> Well, maybe my DC power supply is creating the noise?
2024-01-12T18:17:11 < Ecco> It's supposed to be pretty good tho
2024-01-12T18:17:16 < Ecco> (just received it from Aliexpress)
2024-01-12T18:17:19 < Ecco> And… I like it :)
2024-01-12T18:17:31 < qyx> not the noise
2024-01-12T18:17:32 < nuxil> chineesium ?
2024-01-12T18:17:41 < Ecco> Well
2024-01-12T18:17:44 < Ecco> Yes
2024-01-12T18:17:46 < qyx> the overall shift etc.
2024-01-12T18:17:47 < nuxil> lol
2024-01-12T18:17:52 < Ecco> *but* it got a really good review
2024-01-12T18:17:55 < Ecco> from a Japanese dude
2024-01-12T18:18:03 < Ecco> so… I thought it's probably good :)
2024-01-12T18:18:04 < Ecco> https://www.youtube.com/watch?v=JBv-Tyr8y8k
2024-01-12T18:18:30 < Ecco> qyx: if the noise is not the problem, thenb what is? The jitter?
2024-01-12T18:18:40 < Ecco> I was moving the motor with my hand when I recorded that :-D
2024-01-12T18:19:00 < Ecco> That being said, I may have an explanation for the 2 sensors
2024-01-12T18:19:02 < nuxil> you can try to add some extra filter caps to the psu output, but i dont think it will help much. 
2024-01-12T18:19:05 < Ecco> now it behaves like a rotary encoder
2024-01-12T18:19:13 < Ecco> so it took me 2 seconds to get it to work in ESPhome
2024-01-12T18:19:23 < Ecco> and maybe our chinese friends had a rotary encoder library
2024-01-12T18:19:28 < Ecco> so it made their software easier to write
2024-01-12T18:19:46 < nuxil> oh,. motors creates a shit load of noise
2024-01-12T18:20:29 < ventYl> especially worn-out ones
2024-01-12T18:21:06 < Ecco> That jap guy has a pretty dope scope too https://www.youtube.com/watch?v=JBv-Tyr8y8k&t=659s
2024-01-12T18:21:10 < Ecco> I wonder how much it costs :-)
2024-01-12T18:25:01 < nuxil> a lot. its a lecroy
2024-01-12T18:25:25  * nuxil wants a Rohde & Schwarz scope
2024-01-12T18:28:17 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Quit: Client closed]
2024-01-12T18:28:49 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-12T18:29:23 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-12T18:35:49 -!- ferdna [~ferdna@user/ferdna] has quit [Ping timeout: 264 seconds]
2024-01-12T19:29:59 -!- machinehum [~machinehu@213.55.225.253] has joined ##stm32
2024-01-12T19:53:54 < Ecco> Oh, yeah, regarding scope
2024-01-12T19:53:59 < Ecco> On that guy's screenshot
2024-01-12T19:54:04 < Ecco> I can see that the grid matches the signal
2024-01-12T19:54:10 < Ecco> I mean, the rage
2024-01-12T19:54:12 < Ecco> range
2024-01-12T19:54:28 < Ecco> he sets the scope to go from -1V to +7V
2024-01-12T19:54:37 < Ecco> and the grid is neatly aligned, with one line per volt
2024-01-12T19:54:40 < Ecco> on my cheapo Rigol
2024-01-12T19:54:43 < Ecco> the grid is… constant?
2024-01-12T19:54:48 < Ecco> like, always in the same position
2024-01-12T19:54:57 < Ecco> is there a way to make the grid match the range?
2024-01-12T19:55:15 < Ecco> (I would expect it to be like this by default)
2024-01-12T20:03:35 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 260 seconds]
2024-01-12T20:08:45 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-12T20:09:32 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-12T20:22:47 -!- boB_K7IQ [~boB_K7IQ@184-98-79-231.phnx.qwest.net] has quit [Ping timeout: 264 seconds]
2024-01-12T20:26:13 -!- machinehum [~machinehu@213.55.225.253] has quit [Ping timeout: 264 seconds]
2024-01-12T20:29:43 -!- machinehum [~machinehu@213.55.225.253] has joined ##stm32
2024-01-12T20:42:16 -!- boB_K7IQ [~boB_K7IQ@184-98-176-228.phnx.qwest.net] has joined ##stm32
2024-01-12T20:53:12 < nuxil> Rigol is a lowend scope. dont expect it to have all the features a lecroy and and other scopes in that that class.
2024-01-12T20:53:21 -!- machinehum [~machinehu@213.55.225.253] has quit [Ping timeout: 256 seconds]
2024-01-12T20:59:42 < Ecco> yes of course
2024-01-12T20:59:47 < Ecco> but I mean, setting the grid…
2024-01-12T20:59:54 < Ecco> Like a TI-83 can do it :-D
2024-01-12T21:06:26 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-12T21:11:00 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-12T21:11:22 < nuxil> you know the saying. rtfm :P  
2024-01-12T21:11:39 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-12T21:12:08 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-12T21:12:09 < nuxil> its probably described there how it can be done. if can.
2024-01-12T21:19:20 -!- drzacek [~quassel@2a01:3d8:3d4:c100:c396:2a08:ed6f:faed] has joined ##stm32
2024-01-12T21:20:37 -!- machinehum [~machinehu@5.226.148.123] has joined ##stm32
2024-01-12T21:38:19 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-4d30-551e-13c7-4c3c.fixed6.kpn.net] has joined ##stm32
2024-01-12T21:43:20 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-12T21:43:23 < Laurenceb_> sheeeettt
2024-01-12T21:43:28 < Laurenceb_> RIP coachredpill
2024-01-12T21:43:35 < Laurenceb_> press F to pay respects
2024-01-12T21:47:03 < nuxil> ?
2024-01-12T21:50:42 < Laurenceb_> coachredpill got killed
2024-01-12T21:51:05 < Laurenceb_> prob by Azov
2024-01-12T21:52:05 < specing> whosthat
2024-01-12T21:54:43 < Steffanx> You don't know, specing ?!?
2024-01-12T21:54:53 < Laurenceb_> edgelord youtuber
2024-01-12T21:55:22 < zyp> not knowing sounds like a good thing
2024-01-12T22:02:24 < specing> lol
2024-01-12T22:04:06 -!- nuxil [~nuxil@141.195.51.41] has quit [Write error: Connection reset by peer]
2024-01-12T22:06:36 -!- nuxil [~nuxil@141.195.51.41] has joined ##stm32
2024-01-12T22:08:22 -!- boB_K7IQ [~boB_K7IQ@184-98-176-228.phnx.qwest.net] has quit [Ping timeout: 268 seconds]
2024-01-12T22:15:41 -!- machinehum [~machinehu@5.226.148.123] has quit [Ping timeout: 240 seconds]
2024-01-12T22:19:54 -!- machinehum [~machinehu@5.226.148.123] has joined ##stm32
2024-01-12T22:21:47 < Laurenceb_> https://nitter.net/pic/media%2FGDl8zWVXwAEzaCJ.jpg%3Fname%3Dsmall%26format%3Dwebp
2024-01-12T22:34:15 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Quit: Client closed]
2024-01-12T22:38:54 < karlp> Ecco: what power supply did you get?
2024-01-12T22:46:32 -!- drzacek [~quassel@2a01:3d8:3d4:c100:c396:2a08:ed6f:faed] has quit [Quit: https://quassel-irc.org - Czatuj komfortowo. Wszędzie.]
2024-01-12T23:11:23 -!- machinehum [~machinehu@5.226.148.123] has quit [Ping timeout: 252 seconds]
2024-01-12T23:16:04 -!- boB_K7IQ [~boB_K7IQ@184-98-79-231.phnx.qwest.net] has joined ##stm32
2024-01-12T23:21:18 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-12T23:21:42 < nomorekaki> kinda funny Laurenceb_
2024-01-12T23:34:47 -!- MGF_Fabio [~MGF_Fabio@93-58-79-20.ip157.fastwebnet.it] has joined ##stm32
2024-01-12T23:38:54 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Ping timeout: 250 seconds]
2024-01-12T23:40:58 < fenugrec> Why is(/was) everybody so excited about shitty padauk mcus ? apparently their IDA has a special limited flavour of C, undocumented weird reprogramming interface... just so many reasons not to touch
2024-01-12T23:41:13 < nomorekaki> price
2024-01-12T23:45:54 < nomorekaki> cheap and constrained - I love it
2024-01-12T23:46:37 < fenugrec> PIC already provides a lot of the latter, with less toolchain aggravation
2024-01-12T23:47:01 < nomorekaki> I don't know I'll stick to AVR
2024-01-12T23:47:10 < fenugrec> I guess if you're building 1000 then the pennies count. Ah well, we had this conversation a few weeks ago
2024-01-12T23:47:21 < Steffanx> Everyone fenugrec ? Today is the first time I heard about it -_-
2024-01-12T23:48:05 < nomorekaki> https://www.youtube.com/watch?v=1t-gK-9EIq4 musics
2024-01-12T23:48:14 < fenugrec> Steffanx dunno, wasn't it on hackaday and other misc places "wow check out this new cheap-as-dirt useless mcu"
2024-01-12T23:48:39 < Steffanx> Oh I don't visit had so often 
2024-01-12T23:49:05 < fenugrec> me neither, so for me to have heard about padauk, gave me the impression it was getting 'lots' of interest
2024-01-12T23:54:25 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-4d30-551e-13c7-4c3c.fixed6.kpn.net] has quit [Ping timeout: 264 seconds]
--- Day changed la tammi 13 2024
2024-01-13T00:00:08 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-13T00:12:47 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-13T00:15:35 -!- MGF_Fabio [~MGF_Fabio@93-58-79-20.ip157.fastwebnet.it] has quit [Ping timeout: 260 seconds]
2024-01-13T00:23:06 < Ecco> karlp: I got a DP100. This review made me want to get one: https://www.youtube.com/watch?v=JBv-Tyr8y8k
2024-01-13T00:23:15 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-13T00:23:24 < Ecco> I paid $50 for it. https://www.aliexpress.us/item/3256806157505202.html
2024-01-13T00:26:49 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 264 seconds]
2024-01-13T00:36:29 -!- nomorekaki94 [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-13T00:37:24 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-13T01:21:15 < nuxil> a psu that needs a psu 😛
2024-01-13T01:30:37 < nuxil> Ecco, i made myself a psu too using one of thouse module. not the same. made it a couple of years ago.  but i hade mine so i can just plug it in the wall.
2024-01-13T01:32:09 < nuxil> my ugly creation 😛 https://i.imgur.com/jNPzZGT.jpeg .. power button cover is almost all gone. crap plastic they put over the buttons.
2024-01-13T01:36:20 < nuxil> <nomorekaki> I don't know I'll stick to AVR
2024-01-13T01:36:26 < nuxil> 8 bit avr's are fun :)
2024-01-13T01:38:31 < nuxil> but dont ask me about arduino stuff. i just use gcc/avr-libc and plain old C. im not a huge fan of this arduino framework people use on the avr's. to be honest i hate it :P
2024-01-13T01:39:25 < nuxil> oh he left.
2024-01-13T01:49:25 < qyx> hu dat nuxil
2024-01-13T01:49:35 < qyx> besides being a 3d printer maker
2024-01-13T01:51:13 < nuxil> sorry, hu dat? i only know a few acronyms. lol :P
2024-01-13T01:53:34 < nuxil> anywho. time to continue to work on my stupid joystick experiment :P
2024-01-13T01:54:54 < nuxil> im making a joystick using led's and ldr's as sensors instead of using pot's or halleffect sensors.  :)
2024-01-13T01:55:22 < nuxil> https://www.youtube.com/watch?v=32RwQUx6KIc
2024-01-13T03:33:44 -!- Ecco [~user@user/Ecco] has quit [Ping timeout: 252 seconds]
2024-01-13T03:53:53 -!- Ecco [~user@user/Ecco] has joined ##stm32
2024-01-13T04:03:15 -!- hexo__ [~hexo@user/hexo] has joined ##stm32
2024-01-13T04:03:26 -!- specing [~specing@user/specing] has quit [Read error: Connection reset by peer]
2024-01-13T04:03:46 -!- specing [~specing@user/specing] has joined ##stm32
2024-01-13T04:04:31 -!- hexo [~hexo@user/hexo] has quit [Ping timeout: 245 seconds]
2024-01-13T04:05:21 -!- mid-kid [~mid-kid@2a01:7c8:aac8:1e8:5054:ff:fe5e:cd48] has quit [Ping timeout: 245 seconds]
2024-01-13T04:06:13 -!- mid-kid [~mid-kid@2a01:7c8:aac8:1e8:5054:ff:fe5e:cd48] has joined ##stm32
2024-01-13T05:20:21 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-13T07:35:39 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-13T08:59:31 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-13T09:09:56 -!- drkow [~k\o\w@2607:fea8:1d00:89f0:938:f5d2:4b89:104] has joined ##stm32
2024-01-13T09:10:40 -!- drfff [~k\o\w@2607:fea8:1d00:89f0:4662:11c8:f36e:f0ce] has quit [Ping timeout: 268 seconds]
2024-01-13T09:31:38 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-b1f3-a29a-ccdf-73ac.fixed6.kpn.net] has joined ##stm32
2024-01-13T09:54:21 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Read error: Connection reset by peer]
2024-01-13T11:12:01 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-b1f3-a29a-ccdf-73ac.fixed6.kpn.net] has quit [Ping timeout: 246 seconds]
2024-01-13T12:06:09 -!- boB_K7IQ [~boB_K7IQ@184-98-79-231.phnx.qwest.net] has quit [Read error: Connection reset by peer]
2024-01-13T12:08:26 -!- boB_K7IQ [~boB_K7IQ@174-26-251-72.phnx.qwest.net] has joined ##stm32
2024-01-13T13:38:44 -!- qyx [~qyx@84.245.121.114] has quit [Ping timeout: 252 seconds]
2024-01-13T13:40:20 -!- qyx [~qyx@84.245.120.2] has joined ##stm32
2024-01-13T14:14:44 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-13T14:16:01 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-13T14:20:54 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2024-01-13T14:21:31 -!- mouseghost [~draco@user/mouseghost] has joined ##stm32
2024-01-13T14:23:21 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-13T14:42:51 -!- ferdna [~ferdna@user/ferdna] has quit [Ping timeout: 245 seconds]
2024-01-13T14:51:04 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 268 seconds]
2024-01-13T14:54:11 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-13T15:01:14 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 252 seconds]
2024-01-13T15:03:28 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-13T15:03:55 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-13T15:12:30 -!- nomorekaki94 [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Quit: Client closed]
2024-01-13T15:12:39 -!- fridericus [~Thunderbi@2a00:8a60:c000:1:bcb2:93bd:9050:a52e] has joined ##stm32
2024-01-13T15:22:36 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-d0-2cc0-5f80-e66f.fixed6.kpn.net] has joined ##stm32
2024-01-13T15:30:45 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-13T15:32:07 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 260 seconds]
2024-01-13T15:36:20 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-13T15:47:24 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Ping timeout: 250 seconds]
2024-01-13T15:47:34 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 255 seconds]
2024-01-13T15:50:10 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-13T15:53:49 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-d0-2cc0-5f80-e66f.fixed6.kpn.net] has quit [Ping timeout: 264 seconds]
2024-01-13T16:04:37 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 264 seconds]
2024-01-13T16:07:08 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-13T16:09:37 -!- nerozero [~nerozero@87.253.63.54] has quit [Remote host closed the connection]
2024-01-13T16:11:22 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-13T16:16:36 < jbo> moin
2024-01-13T16:18:39 < nuxil> howdy
2024-01-13T16:19:43 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-13T16:37:28 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-13T17:05:34 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 260 seconds]
2024-01-13T17:08:31 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-13T17:49:49 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-a920-226f-5cdb-8d74.fixed6.kpn.net] has joined ##stm32
2024-01-13T17:54:04 -!- mouseghost [~draco@user/mouseghost] has quit [Quit: mew wew]
2024-01-13T18:17:11 < Steffanx> Gooday 
2024-01-13T18:17:24 < jpa-> what flavour of goo?
2024-01-13T18:19:58 -!- alan_o [~alan_o@2600:1700:1902:210f:d43d:e50b:1f38:cff] has quit [Remote host closed the connection]
2024-01-13T18:20:12 -!- alan_o [~alan_o@172-7-159-77.lightspeed.dybhfl.sbcglobal.net] has joined ##stm32
2024-01-13T18:20:45 -!- ferdna [~ferdna@user/ferdna] has quit [Ping timeout: 260 seconds]
2024-01-13T18:30:58 < Steffanx> Whatever you prefer. It's your feast, jpa-
2024-01-13T19:36:28 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-13T19:40:38 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-13T19:50:11 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 260 seconds]
2024-01-13T20:05:39 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-a920-226f-5cdb-8d74.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-13T20:41:12 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Ping timeout: 250 seconds]
2024-01-13T20:41:56 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:c6ef:f452:4f2d:5664] has joined ##stm32
2024-01-13T21:01:59 < qyx> no innovation today?
2024-01-13T21:15:45 -!- fridericus [~Thunderbi@2a00:8a60:c000:1:bcb2:93bd:9050:a52e] has quit [Ping timeout: 260 seconds]
2024-01-13T21:15:58 < Steffanx> Can you eat that qyx ?
2024-01-13T21:16:46 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-a920-226f-5cdb-8d74.fixed6.kpn.net] has joined ##stm32
2024-01-13T21:33:56 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 252 seconds]
2024-01-13T21:42:49 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-13T21:51:30 < qyx> for sure
2024-01-13T21:55:57 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:c6ef:f452:4f2d:5664] has quit [Ping timeout: 268 seconds]
2024-01-13T23:07:05 -!- fridericus [~Thunderbi@xdsl-87-79-135-110.nc.de] has joined ##stm32
2024-01-13T23:26:44 -!- fridericus [~Thunderbi@xdsl-87-79-135-110.nc.de] has quit [Quit: fridericus]
2024-01-13T23:41:25 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 255 seconds]
--- Day changed su tammi 14 2024
2024-01-14T00:18:23 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-14T00:22:46 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 264 seconds]
2024-01-14T01:09:48 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-14T01:13:56 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 252 seconds]
2024-01-14T01:27:37 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-a920-226f-5cdb-8d74.fixed6.kpn.net] has quit [Ping timeout: 255 seconds]
2024-01-14T01:31:03 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-14T01:34:19 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-14T01:36:27 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 260 seconds]
2024-01-14T01:43:15 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 245 seconds]
2024-01-14T01:47:43 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 246 seconds]
2024-01-14T01:48:43 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-14T01:49:21 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Client Quit]
2024-01-14T01:56:45 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-14T02:01:37 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 264 seconds]
2024-01-14T02:22:26 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-14T02:25:52 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 246 seconds]
2024-01-14T02:44:46 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-14T02:49:11 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 268 seconds]
2024-01-14T03:34:14 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-14T03:39:08 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 268 seconds]
2024-01-14T04:26:32 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-14T04:31:02 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 256 seconds]
2024-01-14T05:15:46 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-14T05:20:20 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 252 seconds]
2024-01-14T05:43:25 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-14T06:03:06 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-14T06:07:45 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 260 seconds]
2024-01-14T06:55:41 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-14T07:00:25 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 264 seconds]
2024-01-14T07:41:36 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-14T07:45:49 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-14T07:48:21 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-14T07:50:25 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 268 seconds]
2024-01-14T08:13:12 -!- drkow [~k\o\w@2607:fea8:1d00:89f0:938:f5d2:4b89:104] has quit [Read error: Connection reset by peer]
2024-01-14T08:34:23 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-14T08:39:08 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 268 seconds]
2024-01-14T08:40:35 -!- drfff [~k\o\w@2607:fea8:1d00:89f0:c4af:c9eb:f18f:7248] has joined ##stm32
2024-01-14T09:07:30 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-14T09:27:14 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-14T09:34:29 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 260 seconds]
2024-01-14T09:59:32 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-392b-a885-4b41-91e9.fixed6.kpn.net] has joined ##stm32
2024-01-14T10:02:24 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-14T10:07:04 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 276 seconds]
2024-01-14T11:10:34 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-14T11:25:01 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-392b-a885-4b41-91e9.fixed6.kpn.net] has quit [Ping timeout: 264 seconds]
2024-01-14T11:37:50 < qyx> rip karlp 
2024-01-14T11:47:57 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-14T11:57:12 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-392b-a885-4b41-91e9.fixed6.kpn.net] has joined ##stm32
2024-01-14T12:03:09 -!- boB_K7IQ [~boB_K7IQ@174-26-251-72.phnx.qwest.net] has quit [Read error: Connection reset by peer]
2024-01-14T12:04:07 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 260 seconds]
2024-01-14T12:05:45 -!- boB_K7IQ [~boB_K7IQ@184-98-66-243.phnx.qwest.net] has joined ##stm32
2024-01-14T12:10:11 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Remote host closed the connection]
2024-01-14T12:14:56 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-14T12:17:11 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-14T12:23:49 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 264 seconds]
2024-01-14T12:26:53 < jpa-> qyx: do you want a leaf spring ping now?
2024-01-14T12:37:52 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-14T12:43:43 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 276 seconds]
2024-01-14T12:54:57 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-14T12:59:35 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 252 seconds]
2024-01-14T13:10:34 < jadew> Shot in the dark, but does anyone know why loop/loopnz is slower than dec + cmp + je? (at least it seems to be on the 486 architecture, for which I found documentation)
2024-01-14T13:10:53 < jadew> Is that the case on current architecture too? Is that why g++ refuses to use it?
2024-01-14T13:12:12 < jadew> Best case scenario for dec + cmp + je is 3 clock cycles, worst case 6, while for loop it's 6/9...
2024-01-14T13:12:19 < jadew> 69 :D
2024-01-14T13:13:51 < ventYl> I wouldn't assume anything on current architecture's performance based on 486 documentation
2024-01-14T13:14:21 < jadew> Yeah, there's a lot of optimization for sure, but at the same time, g++ won't use it, so it must still be slower, right?
2024-01-14T13:15:14 < jadew> I wonder if it will use it if I optmize for size
2024-01-14T13:15:53 < ventYl> dec suggests downwards counting only. does it emit the same code even in case of upwards counting?
2024-01-14T13:15:54 < jadew> It won't...
2024-01-14T13:16:22 < jadew> ventYl, sometimes it does, it optimizes for using the zero flag
2024-01-14T13:16:48 < jadew> Sometimes it just repeats the code you want in the loop X number of times :D
2024-01-14T13:17:42 < ventYl> yeah, that's called loop unrolling
2024-01-14T13:18:33 < jadew> Actually wait, it optimizes by using inc instead of dec, and starts with a negative value.
2024-01-14T13:18:34 < ventYl> the inherent problem of loop instruction is, that it is not suitable for for() cycles where you want to increment the iterator
2024-01-14T13:18:59 < ventYl> and actually use it for some useful work
2024-01-14T13:19:11 < jadew> I'm just looking at something simple: int i = 100; while (--i) doSomething();
2024-01-14T13:19:15 < ventYl> there you have to have an iterator and then derive the actual "offset" from it. or have two iterators
2024-01-14T13:20:21 < jadew> https://godbolt.org/z/xezWr5ToG
2024-01-14T13:22:58 < jadew> Maybe it has something to do with ebp? Is that getting special treatment? I don't see it being pushed/popped.
2024-01-14T13:23:57 < jadew> Ah, it always points to the end of the stack, so that must be it.
2024-01-14T13:24:58 < jadew> By doing that, they get rid of the necessary push/pop. I wonder what happens if I have nested loops.
2024-01-14T13:25:55 < ventYl> ebp is used as a "frame pointer"
2024-01-14T13:26:11 < jadew> What's that?
2024-01-14T13:26:55 < jadew> In case of nested loops it seems to recruit another register, so it still won't go to the loop instruction.
2024-01-14T13:26:57 < ventYl> pointer to the base address of automatic variables image on the stack
2024-01-14T13:28:17 < ventYl> when function is entered, SP points "behind" the last function argument. you can copy ESP into EBP and then subtract the cummulative size of automatic variables in the function to create storage space while still maintaining the function of stack
2024-01-14T13:28:58 < jadew> Yeah, just read about it, apparently the CPU offers some functionality for stack management through it, but the compiler can chose to repurpose it.
2024-01-14T13:28:59 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-14T13:29:16 < ventYl> correction: it points "behind" the return address. arguments are placed "in front" of it.
2024-01-14T13:29:22 < jadew> Wait, the CPU won't do that automatically?
2024-01-14T13:29:29 < ventYl> no
2024-01-14T13:29:47 < jadew> So it's just a convention that you can adhere to, if you want to.
2024-01-14T13:29:58 < jadew> And g++ chooses not to.
2024-01-14T13:30:07 < ventYl> CPU can only put return address of CALL instruction there automatically, so you can use the RET instruction
2024-01-14T13:30:39 < ventYl> and that only applies to x86, other architectures may not use stack for this purpose by the hardware
2024-01-14T13:30:47 < ventYl> e.g. ARM is using LR register for this purpose
2024-01-14T13:31:52 < ventYl> in fact, it is even more complicated, because there's -fomit-frame-pointer, which will cause the EBP not being saved :)
2024-01-14T13:32:11 < ventYl> and 64-bit x86 and some other architectures may opt to omit frame pointer entirely in certain scenarios
2024-01-14T13:33:35 < ventYl> like, IIRC, the Itanium ABI omits EBP creation automatically, if function does not have any automatic variables.
2024-01-14T13:33:46 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 276 seconds]
2024-01-14T13:33:48 < ventYl> also for functions which don't all any other functions
2024-01-14T13:36:30 < jadew> Yeah, it makes sense to optimize around it, like g++ seems to do in this case. It seemed to be the answer to why loopnz wasn't used, but it's still not being used with nested loops.
2024-01-14T13:37:13 < jadew> (where EBP is already recruited for one of the loops)
2024-01-14T13:41:07 < ventYl> ah, I assume that the inherent issue with the loop instruction is, that it has fixed iterator register
2024-01-14T13:41:39 < jadew> Yeah, but it can be used for at least one loop.
2024-01-14T13:41:55 < ventYl> in the days of ancient x86, stack was used to pass function arguments as x86 is notoriously short on registers
2024-01-14T13:42:16 < ventYl> so AX, BX, CX, DX registers mostly weren't given specific role by the ABI
2024-01-14T13:43:39 < ventYl> as amd64 was given 8 more general purpose registers, it actually made sense to copy other calling conventions - pass first few arguments to function using registers. IIRC, AX, BX, CX and DX were chosen to do so
2024-01-14T13:44:07 < ventYl> if your function has more than 4 arguments, they continue to be passed via stack. yet still, this ABI covers for most of the functions with *MUCH* faster execution
2024-01-14T13:44:09 < jadew> That would explain it.
2024-01-14T13:44:48 < ventYl> that makes the LOOP instruction largely useless in all modern code as compiler would have to have check if CX is actually used by the argument or not.
2024-01-14T13:45:05 < jadew> Yeah, so they just don't use it.
2024-01-14T13:45:59 < jadew> So technically, the loop instruction could be faster if you ever need it.
2024-01-14T13:47:37 < ventYl> well, this involves branching, so faster / slower are actually quite blurry terms
2024-01-14T13:48:15 < jadew> It's the same with the other approach, just that it's one instruction instead of 3.
2024-01-14T13:48:41 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-14T13:48:42 < jadew> actually two instructions, not 3.
2024-01-14T13:49:04 < jadew> dec + jne
2024-01-14T13:49:26 < jadew> They're probably the same...
2024-01-14T13:49:37 < ventYl> both do the same, so it is possible, that after front-end decodes either LOOP or DEC + JNE using CMP register, identical microcode is generated from both sequences
2024-01-14T13:49:53 < jadew> Exactly what I was thinking now.
2024-01-14T13:50:04 < jadew> It sees that combo, it uses the same shit to execute it.
2024-01-14T13:50:09 < ventYl> these days frontends are typical four-way wide, so it is possible to decode both DEC and JNE in the same cycle
2024-01-14T13:51:03 < jadew> The frontend being the "funnel" in front of the pipeline or what exactly?
2024-01-14T13:51:39 < ventYl> frontend is the instruction decoder. it sees the bytecode in the instruction pipeline and it tries to extract meaningful instructions out of it
2024-01-14T13:51:57 < ventYl> which is exceptionaly troublesome task given the crappy nature of x86 instruction set
2024-01-14T13:53:20 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 268 seconds]
2024-01-14T13:54:52 < jadew> Thanks for the answer ventYl. I can get back to work now :)
2024-01-14T13:55:21 < ventYl> didn't you shorten your notice period down to zero, not waiting to decrement it by one each day?
2024-01-14T13:56:02 < jadew> I did, but I'm working on a personal project, been working furiously on it since I decided to quit.
2024-01-14T13:57:36 < jadew> I have to find another income source ASAP, and I figured I should get back what what I was doing prior to getting a job.
2024-01-14T13:58:51 < jadew> Freeing up my entire day has helped a lot, since working on it only after hours or early in the morning was not moving things along fast enough.
2024-01-14T13:59:14 < ventYl> that's why I decided to work only part-time about two years ago
2024-01-14T13:59:34 < ventYl> I have a chance to get my hands on the creepy RTOS
2024-01-14T14:01:10 < jadew> Part-time is great, everyone should try it.
2024-01-14T14:01:49 < jadew> Working only 2 to 4 hours per day feels like no work at all compared to 8 or 9.
2024-01-14T14:02:30 < ventYl> I don't even have prescribe working hours, so sometimes I do 9 in one day, if I am working on something more complex, or if I enjoy working. then sometimes I have entire day off
2024-01-14T14:03:08 < jadew> I have a similar contract as well, but the amount of work is not super reliable.
2024-01-14T14:03:56 < ventYl> yeah, this contract is slowly getting into similar phase. I have optimized and fixed so many things, that soon, we will essentially run out of work to be done
2024-01-14T14:04:20 < jadew> Heh, same situation here, there's very little that requires my attention anymore.
2024-01-14T14:05:39 < jadew> The only good part is that I don't have to say that I'm unemployed :P
2024-01-14T14:06:12 < ventYl> i don't mind. I am bored of doing coding again and again. having to deal with same stupid decisions from my predecesors. So I plan to switch towards some more "consultant" type of work
2024-01-14T14:06:41 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-14T14:09:50 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-14T14:10:26 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-14T14:21:01 -!- ferdna [~ferdna@user/ferdna] has quit [Ping timeout: 256 seconds]
2024-01-14T14:21:49 < ventYl> its 14th of january and this month's PV production already surpassed december PV production
2024-01-14T14:22:02 < jadew> PV?
2024-01-14T14:22:39 < ventYl> photovoltaics
2024-01-14T14:22:58 < jadew> Should compare it with January of last year.
2024-01-14T14:23:11 < ventYl> it didn't exist back then
2024-01-14T14:23:51 < ventYl> I can only compare to PVGIS data. this shows roughly the same numbers for december and january
2024-01-14T14:51:40 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8e90:eb59:9248:c07:684c] has joined ##stm32
2024-01-14T15:08:02 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-14T15:10:05 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-14T15:11:02 < nomorekaki> Satoshi's wallet has become active
2024-01-14T15:27:36 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-14T15:35:13 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8e90:eb59:9248:c07:684c] has quit [Ping timeout: 264 seconds]
2024-01-14T15:37:12 < Steffanx> Farewell nomorekaki. 
2024-01-14T15:38:56 -!- nomorekaki53 [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-14T15:39:34 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-14T15:40:55 < Steffanx> You aged quickly, nomorekaki53 
2024-01-14T15:41:04 < nomorekaki53> holy shit
2024-01-14T15:41:09 < nomorekaki53> time flies
2024-01-14T15:43:40 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 245 seconds]
2024-01-14T15:46:50 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-14T15:46:53 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 260 seconds]
2024-01-14T16:09:16 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-14T16:09:46 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-14T16:11:33 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-14T16:11:44 -!- ferdna_ [~ferdna@user/ferdna] has joined ##stm32
2024-01-14T16:14:17 -!- ferdna [~ferdna@user/ferdna] has quit [Ping timeout: 252 seconds]
2024-01-14T16:16:22 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-392b-a885-4b41-91e9.fixed6.kpn.net] has quit [Ping timeout: 255 seconds]
2024-01-14T16:25:52 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 246 seconds]
2024-01-14T16:30:20 -!- pragmalin [~pragmalin@user/pragmalin] has joined ##stm32
2024-01-14T16:35:13 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 264 seconds]
2024-01-14T16:37:31 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-14T16:40:32 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8e90:e3d4:8f18:493d:14d] has joined ##stm32
2024-01-14T16:46:44 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 252 seconds]
2024-01-14T16:49:26 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-14T17:03:25 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 260 seconds]
2024-01-14T17:05:50 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-14T17:10:43 -!- machinehum [~machinehu@213.55.225.123] has joined ##stm32
2024-01-14T17:13:18 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-14T17:13:47 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-14T17:18:47 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-392b-a885-4b41-91e9.fixed6.kpn.net] has joined ##stm32
2024-01-14T17:31:52 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-14T17:34:20 < qyx> q
2024-01-14T17:36:02 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-14T17:37:38 < jpa-> a
2024-01-14T17:38:29 < nomorekaki53> q
2024-01-14T17:39:34 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8e90:e3d4:8f18:493d:14d] has quit [Remote host closed the connection]
2024-01-14T17:39:58 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8e90:39b2:bc84:c55c:330e] has joined ##stm32
2024-01-14T17:42:09 -!- machinehum [~machinehu@213.55.225.123] has quit [Ping timeout: 260 seconds]
2024-01-14T18:03:24 < Steffanx> You guys alright? 
2024-01-14T18:04:09 < Mangy_Dog> my brains a mess right now
2024-01-14T18:04:29 < Steffanx> I can imagine after tracing that cube thing
2024-01-14T18:04:31 < Mangy_Dog> coming off ssris for a job im not even sure i have any more even though it was offered... but feels like they ghosted me a few days before start date
2024-01-14T18:05:15 < Steffanx> So visit them 
2024-01-14T18:05:23 < Mangy_Dog> kinda hard theyre based 200 miles away
2024-01-14T18:05:24 < Mangy_Dog> :p
2024-01-14T18:05:41 < Mangy_Dog> im meant to start tomorrow... will call them if they still dont reply to emails
2024-01-14T18:06:03 -!- pragmalin [~pragmalin@user/pragmalin] has quit [Quit: Leaving]
2024-01-14T18:07:37 < Steffanx> Oh lol yeah
2024-01-14T18:15:43 < nuxil> sounds like unseriouse job offer.
2024-01-14T18:22:14 < Mangy_Dog> seemed serious at the time
2024-01-14T18:22:17 < Mangy_Dog> but yeah its feeling iffy
2024-01-14T18:29:36 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-14T18:34:19 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 256 seconds]
2024-01-14T18:36:52 < nomorekaki53> Mangy_Dog: did they give you contract?
2024-01-14T18:36:56 < nomorekaki53> time and place?
2024-01-14T19:00:23 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 260 seconds]
2024-01-14T19:02:47 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-14T19:17:22 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 264 seconds]
2024-01-14T19:19:27 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-14T19:19:39 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-14T19:20:44 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 252 seconds]
2024-01-14T19:23:29 -!- ferdna_ [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-14T19:24:11 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 256 seconds]
2024-01-14T19:35:13 -!- HelloShi1ty [~user@bl15-39-23.dsl.telepac.pt] has quit [Ping timeout: 264 seconds]
2024-01-14T19:38:49 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8e90:39b2:bc84:c55c:330e] has quit [Ping timeout: 264 seconds]
2024-01-14T19:47:38 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 260 seconds]
2024-01-14T19:49:49 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-14T20:11:54 -!- Shaun [~shaun@user/shaun] has quit [Ping timeout: 260 seconds]
2024-01-14T20:14:00 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-14T20:18:27 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 256 seconds]
2024-01-14T20:24:15 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 256 seconds]
2024-01-14T20:27:03 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-14T20:52:04 < nomorekaki53> Steffanx: we have an inside joke with friends that friend's 50th bday is like next year
2024-01-14T20:52:23 < nomorekaki53> he is couple years older than us but he was big boy when we were young
2024-01-14T20:55:32 < nomorekaki53> idk I have not found the joke funny since I got this nick
2024-01-14T20:56:21 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-14T21:01:10 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 264 seconds]
2024-01-14T21:04:10 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Remote host closed the connection]
2024-01-14T21:15:32 < Steffanx> imagine you can change your nick with a few key presses, nomorekaki53 
2024-01-14T21:16:25 -!- nomorekaki53 is now known as nomorekaki
2024-01-14T21:16:31 < nomorekaki> :O
2024-01-14T21:16:56 < nomorekaki> I will eventually be guest829
2024-01-14T21:17:15 < nomorekaki> cannot figth the entropy forever
2024-01-14T21:25:33 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-14T21:26:03 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-14T21:27:47 -!- Shaun [~shaun@user/shaun] has joined ##stm32
2024-01-14T21:40:32 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-14T21:58:20 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 268 seconds]
2024-01-14T22:14:58 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 264 seconds]
2024-01-14T22:21:31 -!- pragmalin [~pragmalin@user/pragmalin] has joined ##stm32
2024-01-14T22:32:05 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-14T22:38:13 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 264 seconds]
2024-01-14T22:45:16 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 256 seconds]
2024-01-14T22:58:31 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-14T22:59:20 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-14T23:08:11 -!- hexo__ [~hexo@user/hexo] has quit [Remote host closed the connection]
2024-01-14T23:09:39 -!- hexo__ [~hexo@user/hexo] has joined ##stm32
2024-01-14T23:16:41 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 252 seconds]
2024-01-14T23:36:08 < karlp> Ecco: ah, yeah, dp100.  I won't ever buy that on principle. using a usb-a female as  a device port is just unforgivable.
--- Day changed ma tammi 15 2024
2024-01-15T00:03:26 -!- HelloShitty [~psysc0rpi@bl21-251-151.dsl.telepac.pt] has quit [Ping timeout: 252 seconds]
2024-01-15T00:04:21 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-15T00:05:31 -!- HelloShitty [~psysc0rpi@bl21-251-151.dsl.telepac.pt] has joined ##stm32
2024-01-15T00:07:00 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-15T00:08:39 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 256 seconds]
2024-01-15T00:12:17 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-15T00:35:00 -!- haritzondo [~hrtz@82-69-11-11.dsl.in-addr.zen.co.uk] has joined ##stm32
2024-01-15T00:35:28 -!- haritz [~hrtz@user/haritz] has quit [Read error: Connection reset by peer]
2024-01-15T00:40:46 -!- pragmalin [~pragmalin@user/pragmalin] has quit [Quit: Leaving]
2024-01-15T00:48:17 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-15T00:52:56 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 252 seconds]
2024-01-15T00:56:45 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2024-01-15T01:21:41 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-15T01:24:31 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 246 seconds]
2024-01-15T01:26:09 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 256 seconds]
2024-01-15T01:34:49 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-392b-a885-4b41-91e9.fixed6.kpn.net] has quit [Ping timeout: 255 seconds]
2024-01-15T02:10:20 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-15T02:14:58 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 260 seconds]
2024-01-15T02:26:32 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-15T02:30:59 -!- haritzondo is now known as haritz
2024-01-15T02:30:59 -!- haritz [~hrtz@82-69-11-11.dsl.in-addr.zen.co.uk] has quit [Changing host]
2024-01-15T02:30:59 -!- haritz [~hrtz@user/haritz] has joined ##stm32
2024-01-15T02:41:08 -!- haritzondo [~hrtz@2a02:6ea0:c318:1::a06e] has joined ##stm32
2024-01-15T02:41:17 -!- haritz [~hrtz@user/haritz] has quit [Ping timeout: 252 seconds]
2024-01-15T02:50:31 -!- haritz [~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220] has joined ##stm32
2024-01-15T02:51:46 -!- haritzondo [~hrtz@2a02:6ea0:c318:1::a06e] has quit [Ping timeout: 256 seconds]
2024-01-15T02:52:17 -!- haritz [~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220] has quit [Changing host]
2024-01-15T02:52:17 -!- haritz [~hrtz@user/haritz] has joined ##stm32
2024-01-15T03:01:35 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-15T03:06:03 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 268 seconds]
2024-01-15T03:18:07 < qyx> lol but yeah
2024-01-15T03:32:23 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-15T04:00:03 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-15T04:04:37 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 264 seconds]
2024-01-15T04:53:12 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-15T04:57:41 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 252 seconds]
2024-01-15T05:41:50 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-15T05:45:58 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 246 seconds]
2024-01-15T06:31:20 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-15T06:35:49 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 264 seconds]
2024-01-15T06:37:37 -!- specing [~specing@user/specing] has quit [Ping timeout: 264 seconds]
2024-01-15T06:45:33 -!- specing [~specing@user/specing] has joined ##stm32
2024-01-15T07:27:11 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-15T07:31:46 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 264 seconds]
2024-01-15T07:52:40 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-15T07:54:44 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-15T07:55:35 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-d4ff-c2ba-8a-afd0.fixed6.kpn.net] has joined ##stm32
2024-01-15T07:59:56 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-15T08:13:10 -!- BrainDamage [~BrainDama@user/BrainDamage] has quit [Ping timeout: 264 seconds]
2024-01-15T08:27:57 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-15T08:28:22 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-d4ff-c2ba-8a-afd0.fixed6.kpn.net] has quit [Ping timeout: 255 seconds]
2024-01-15T08:32:35 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 268 seconds]
2024-01-15T08:49:56 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2024-01-15T09:02:02 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-15T09:11:54 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-15T09:16:22 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 268 seconds]
2024-01-15T09:21:48 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-d4ff-c2ba-8a-afd0.fixed6.kpn.net] has joined ##stm32
2024-01-15T09:31:41 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-d4ff-c2ba-8a-afd0.fixed6.kpn.net] has quit [Ping timeout: 240 seconds]
2024-01-15T09:33:48 -!- c10ud [~c10ud@host-213-26-199-10.business.telecomitalia.it] has joined ##stm32
2024-01-15T09:33:48 -!- c10ud [~c10ud@host-213-26-199-10.business.telecomitalia.it] has quit [Changing host]
2024-01-15T09:33:48 -!- c10ud [~c10ud@user/c10ud] has joined ##stm32
2024-01-15T09:47:24 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Read error: Connection reset by peer]
2024-01-15T10:03:21 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-15T10:07:49 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 255 seconds]
2024-01-15T10:11:06 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has joined ##stm32
2024-01-15T10:40:16 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-15T10:43:53 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 256 seconds]
2024-01-15T10:45:02 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 260 seconds]
2024-01-15T10:48:52 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-15T11:02:00 -!- HelloShi1ty [~user@bl15-39-23.dsl.telepac.pt] has joined ##stm32
2024-01-15T11:39:15 < karlp> lol: hub 3-5.1.3.1.2.6:1.0: Unsupported bus topology: hub nested too deep
2024-01-15T11:39:28 < karlp> laptop->monitor->hub->hub.
2024-01-15T11:39:33 < karlp> didn't feel _that_ deep
2024-01-15T11:41:56 < ventYl> there's probably one additional "invisible" hub inside the laptop
2024-01-15T11:42:48 < ventYl> I would probably bail out way before going that deep due to the spaghetti overwhelm
2024-01-15T11:43:15 < karlp> it's not really much at all, not compared to the rest of the spaghetti on the desk.
2024-01-15T11:43:37 < karlp> dock->monitor are behind the screen, then I have one or two things directly from the monitor, and 7 port hub in the middle for "whatever"
2024-01-15T11:44:02 < karlp> I thought it was maybe 3 or 4 deep, but it turns out its at 6 already...
2024-01-15T11:44:04 < ventYl> ah, so hub is really just an "extension cord"
2024-01-15T11:44:25 < ventYl> non that you have your laptop, dock and monitor already full of devices
2024-01-15T11:45:15 < karlp> 18 usb devices excluding hubs? lsusb | grep -vi hub | wc -l 
2024-01-15T11:45:43 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-15T11:46:14 < ventYl> assuming that laptop itself has a good deal of USB-attached peripherals, not that much
2024-01-15T11:46:48 < karlp> current actual user facing external devices are... 2 swd/jtag dongles, a rs232 dongle, a receiver for the mouse, a keyboard, and a ttl adapter.
2024-01-15T11:47:13 < karlp> so yeah, lots of just "move the ports over there" not that many ports ttoal
2024-01-15T11:47:32 < karlp> still, I don't hink I've eve rhit that nesting limit without deliberately trying before.
2024-01-15T11:48:33 < ventYl> I didn't even know there's one. I known only the total device count limit
2024-01-15T11:48:50 < ventYl> which was like "way too many devices anyone would try to connect to one machine anyway"
2024-01-15T11:49:17 < ventYl> and I think that in one company before we hit limit of devices you can actually address from one hub, or something like that
2024-01-15T11:50:34 < PaulFertser> It's even worse thanks to eUSB: https://www.reddit.com/r/mac/comments/16epzk4/can_your_mac_count_to_7/?rdt=52237
2024-01-15T12:09:31 < PaulFertser> (tldr: modern chips can't handle 3.3 V directly so they include a special translator which counts like an additional hub in the chain)
2024-01-15T12:11:57 < PaulFertser> So sometimes you'll have a hub working nicely with regular devices but if you connect a modern smartphone to it then it won't work as the smartphone includes that eUSB translator and if you were already at the limit nothing can be done.
2024-01-15T12:44:54 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-15T13:09:05 -!- fridericus [~Thunderbi@2a00:8a60:c000:1:bcb2:93bd:9050:a52e] has joined ##stm32
2024-01-15T13:16:15 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 268 seconds]
2024-01-15T13:22:01 < qyx> what's the nesting limit? isn't it like 128 or so?
2024-01-15T13:24:03 < PaulFertser> qyx: root + five hubs
2024-01-15T13:24:06 < karlp> for hubs? no, 5 or 6
2024-01-15T13:24:22 < karlp> it's definitely easier to hit in modern times than it was in the past,
2024-01-15T13:24:56 < qyx> how did you design your hubhub then?
2024-01-15T13:25:00 < qyx> max 5 in a row?
2024-01-15T13:26:29 < karlp> design what?
2024-01-15T13:27:08 < karlp> my hub project I designed to limit nesting where possible, but still not be a crazy custom root/expander design, so it's just "normal"
2024-01-15T13:27:20 < karlp> but it's why I didn't use the classic "2x4port hubs to make a 7 port hub"
2024-01-15T13:29:18 < qyx> I though it was just a 7 port hub with 6 front downstream ports, one upstream and one chaining downstream
2024-01-15T13:29:47 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-15T13:30:21 < qyx> sorry s/hubhub/hubbish
2024-01-15T13:32:35 < karlp> it is.
2024-01-15T13:32:54 < karlp> so yeah, it counts as 3 of your max hubs if you go all the way...
2024-01-15T13:33:30 < karlp> this is cute: https://www.eenewseurope.com/en/nuclear-battery-uses-diamond-for-50-year-life
2024-01-15T13:39:28 -!- qyx [~qyx@84.245.120.2] has quit [Ping timeout: 256 seconds]
2024-01-15T13:41:17 -!- qyx [~qyx@84.245.120.109] has joined ##stm32
2024-01-15T13:44:50 < ventYl> fucking kingston usb stick
2024-01-15T13:45:10 < ventYl> kB_wrtn/s 1905,34 
2024-01-15T13:45:39 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 256 seconds]
2024-01-15T13:49:38 < ventYl> i should have burned DVD
2024-01-15T13:56:24 < Steffanx> It truly is blue Monday for ventYl 
2024-01-15T14:03:21 -!- fridericus [~Thunderbi@2a00:8a60:c000:1:bcb2:93bd:9050:a52e] has quit [Ping timeout: 256 seconds]
2024-01-15T14:06:12 < ventYl> i am being unproductive even before i can start being unproductive
2024-01-15T14:09:36 < qyx> bloody monday
2024-01-15T14:17:11 -!- nuxil_ [~nuxil@141.195.51.41] has joined ##stm32
2024-01-15T14:17:38 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-15T14:19:35 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-15T14:19:37 -!- nuxil [~nuxil@141.195.51.41] has quit [Ping timeout: 264 seconds]
2024-01-15T14:21:48 < Mangy_Dog> IM currently very unproductive at this new job on account that im waiting for the boss to call me :p
2024-01-15T14:22:03 < Mangy_Dog> im actually really eager to get started though
2024-01-15T14:26:14 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 260 seconds]
2024-01-15T14:37:59 -!- BrainDamage [~BrainDama@user/BrainDamage] has joined ##stm32
2024-01-15T14:42:23 -!- nuxil_ is now known as nuxil
2024-01-15T14:51:30 -!- fridericus [~Thunderbi@141-218.eduroam.rwth-aachen.de] has joined ##stm32
2024-01-15T14:54:31 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-15T15:09:56 < ventYl> ok, year is 2024 and windows 11 needs "driver disk" to find pretty much standard AHCI-based SATA drive
2024-01-15T15:10:58 < PaulFertser> Are you sure? Probably you have it in same fake raid mode instead of regular ahci?
2024-01-15T15:11:31 < qyx> wife was grumpy today because a new and fresh printer was asking to install drivers on windows
2024-01-15T15:11:58 < ventYl> no, it is in AHCI mode
2024-01-15T15:12:12 < ventYl> I have actually checked it
2024-01-15T15:12:27 < ventYl> and I recall, I had to deal with similar kind of shite back when installing Windows 10
2024-01-15T15:12:35 < PaulFertser> Funny
2024-01-15T15:12:54 < ventYl> ASRock actually has "SATA floppy drive.zip" on their website
2024-01-15T15:18:33 < jbo> somebody is just claiming that STM32 devices have internal pull-ups on their reset pin - is that true?
2024-01-15T15:19:09 < qyx> yes
2024-01-15T15:19:27 < qyx> the recommended NRST circuit is just a 100n cap to ground
2024-01-15T15:19:37 < jbo> alright
2024-01-15T15:19:41 < qyx> (see the DSň
2024-01-15T15:19:58 < qyx> beware that it is not true for clones
2024-01-15T15:20:10 < qyx> at least eg. gd32
2024-01-15T15:20:38 < jbo> gotta safe that money
2024-01-15T15:39:46 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-15T16:07:56 < nomorekaki> TIL fuzzing
2024-01-15T16:09:26 < nomorekaki> have you used AFL?
2024-01-15T16:17:21 < jbo> yes
2024-01-15T16:17:39 < jbo> AFL++ is the way to go nowdays tho
2024-01-15T16:20:31 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-15T16:37:41 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-15T16:45:51 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 256 seconds]
2024-01-15T16:46:43 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-15T16:50:44 < nomorekaki> qemu + instrumentation jbo?
2024-01-15T16:51:52 < jbo> ?
2024-01-15T16:52:23 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2024-01-15T16:54:39 < nomorekaki> for arm binarys?
2024-01-15T17:06:18 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 260 seconds]
2024-01-15T17:09:44 -!- machinehum [~machinehu@213.55.224.223] has joined ##stm32
2024-01-15T17:30:05 -!- fridericus [~Thunderbi@141-218.eduroam.rwth-aachen.de] has quit [Ping timeout: 240 seconds]
2024-01-15T17:33:59 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-15T17:42:11 -!- machinehum2 [~machinehu@213.55.225.67] has joined ##stm32
2024-01-15T17:44:23 -!- machinehum [~machinehu@213.55.224.223] has quit [Ping timeout: 252 seconds]
2024-01-15T18:03:04 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-15T18:04:10 -!- HelloShi1ty [~user@bl15-39-23.dsl.telepac.pt] has quit [Ping timeout: 264 seconds]
2024-01-15T18:05:32 -!- HelloShi1ty [~user@bl22-255-167.dsl.telepac.pt] has joined ##stm32
2024-01-15T18:27:23 -!- fridericus [~Thunderbi@141-218.eduroam.rwth-aachen.de] has joined ##stm32
2024-01-15T18:33:10 -!- machinehum2 [~machinehu@213.55.225.67] has quit [Ping timeout: 276 seconds]
2024-01-15T18:54:29 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has quit [Ping timeout: 256 seconds]
2024-01-15T19:03:09 < jadew> Big difference between rm core* and rm core *...
2024-01-15T19:04:34 < nomorekaki> did you nuke your company
2024-01-15T19:04:52 < jadew> Just the build folder, but that's some scary stuff...
2024-01-15T19:05:35 < nomorekaki> cannot get the pump on
2024-01-15T19:05:35 < jadew> The space key should come with a confirmation pop-up.
2024-01-15T19:06:02 < jadew> nomorekaki, how come?
2024-01-15T19:06:09 < nomorekaki> coding pumps
2024-01-15T19:06:23 < nomorekaki> I'm depleted
2024-01-15T19:06:54 < jadew> Go for a walk or something, it seems to work for some reason.
2024-01-15T19:07:08 < nomorekaki> yeah blood circulation
2024-01-15T19:08:15 < qyx> wa-what
2024-01-15T19:08:20 < qyx> it is cold outside
2024-01-15T19:10:02 < srk> jadew: rm -i
2024-01-15T19:10:32 < qyx> alias rm echo really?
2024-01-15T19:10:54 < srk> kinda, or use snapshotting fs with autosnapshots :)
2024-01-15T19:11:10 < ventYl> nomorekaki: still pursuading that bimmer pump to actually work?
2024-01-15T19:11:48 < nomorekaki> yeah made interrupts.h to my library now
2024-01-15T19:13:09 < nomorekaki> then need to just few lines for ISRs to uart example
2024-01-15T19:17:54 < nomorekaki> then I think I want to run profiling in qemu for that uart example
2024-01-15T19:21:11 < nomorekaki> have some idea how tight or spacy it is and to babbys first qemu too
2024-01-15T19:27:54 < qyx> the feeling when you rm * in a dir with 5 files and you realise it is taking more than 2 seconds
2024-01-15T19:33:18 < nomorekaki> mouse cursor starts stuttering
2024-01-15T19:35:21 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Quit: Client closed]
2024-01-15T19:37:18 -!- boB_K7IQ [~boB_K7IQ@184-98-66-243.phnx.qwest.net] has quit []
2024-01-15T19:46:25 < karlp> áááíéííiii
2024-01-15T19:57:08 < jadew> qyx, lol
2024-01-15T19:58:01 < jadew> rm * is always nerve wrecking
2024-01-15T19:58:19 < jadew> I erased about 2.5 million files today btw
2024-01-15T19:58:45 < jadew> (did some maintenance job on a server)
2024-01-15T19:59:22 < jadew> Had to filter them out to do it in batches, so I would get a sense of progression.
2024-01-15T19:59:29 -!- fridericus [~Thunderbi@141-218.eduroam.rwth-aachen.de] has quit [Ping timeout: 260 seconds]
2024-01-15T20:00:11 < jadew> But also because when you filter them, you don't rm *
2024-01-15T20:00:55 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 256 seconds]
2024-01-15T20:02:43 < specing> That's a lotta files
2024-01-15T20:03:58 < jadew> Yeah, the folders would still be unusable afterwards, even when empty.
2024-01-15T20:04:05 < jadew> Had to recreate them.
2024-01-15T20:04:52 < jadew> They were all in just two folders :)
2024-01-15T20:09:56 -!- fridericus [~Thunderbi@141-218.eduroam.rwth-aachen.de] has joined ##stm32
2024-01-15T20:14:58 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-9897-2fb2-85e0-ad71.fixed6.kpn.net] has joined ##stm32
2024-01-15T20:32:31 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-15T20:37:11 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-15T21:04:21 -!- fridericus [~Thunderbi@141-218.eduroam.rwth-aachen.de] has quit [Ping timeout: 260 seconds]
2024-01-15T21:18:42 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-15T21:18:44 < aandrew> jadew: that's where I find the 'find' command to be less nerve wracking. something like find /path/to/tree -type f -exec echo rm {} \; >> /tmp/filelist.txt would show me what it wants to do, and I can either remove the echo or tweak/run the resulting shell script after
2024-01-15T21:19:05 < aandrew> karlp> áááíéííiii
2024-01-15T21:19:12 < aandrew> getting a little warm where you are?
2024-01-15T21:29:51 -!- boB_K7IQ [~boB_K7IQ@184-98-66-243.phnx.qwest.net] has joined ##stm32
2024-01-15T21:29:52 -!- boB_K7IQ [~boB_K7IQ@184-98-66-243.phnx.qwest.net] has quit [Excess Flood]
2024-01-15T21:30:19 -!- boB_K7IQ [~boB_K7IQ@184-98-66-243.phnx.qwest.net] has joined ##stm32
2024-01-15T21:40:05 -!- Shaun [~shaun@user/shaun] has quit [Quit: Lost terminal]
2024-01-15T22:14:17 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:f7d1:4291:ab59:5630] has joined ##stm32
2024-01-15T22:22:58 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Ping timeout: 250 seconds]
2024-01-15T22:45:20 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:f7d1:4291:ab59:5630] has quit [Quit: Konversation terminated!]
2024-01-15T22:45:34 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:f7d1:4291:ab59:5630] has joined ##stm32
2024-01-15T22:47:52 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-15T22:48:39 -!- fridericus [~Thunderbi@xdsl-87-79-135-110.nc.de] has joined ##stm32
2024-01-15T22:50:21 -!- Shaun [~shaun@user/shaun] has joined ##stm32
2024-01-15T23:03:57 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 256 seconds]
2024-01-15T23:16:44 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-15T23:22:05 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 252 seconds]
2024-01-15T23:35:51 < jadew> aandrew, yeah, that's similar to my process, I first filter it out with find, then add -delete if it seems to be ok
2024-01-15T23:48:22 < karlp> ~
2024-01-15T23:48:35 < karlp> aandrew: well, wasn't meant to be pressing enter here, no.
2024-01-15T23:48:48 < karlp> debugging a touch typing exercise thing my daughter was using.
2024-01-15T23:48:54 < karlp> turns out it's..... some bad javascript?
2024-01-15T23:49:31 < karlp> icelandic layout uses dead letter style, so you press ' and then you can _release_ it and press the vowel, and it does the right thing.
2024-01-15T23:49:47 < karlp> and "everywhere" on my comptuer, and on my wifes' mac, this .. is how it's done.
2024-01-15T23:50:16 < karlp> but this touch typing thing was forcing my daughter to press them together, and release in a reveser order, absolutely terrible.
2024-01-15T23:50:42 < karlp> after much disgust, it appears to be javascript  chrome vs firefox incompatibility / bad prorgramming...
2024-01-15T23:52:04 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-15T23:52:09 < karlp> but no, not warm at all, quite cold this week, -5 or so.
2024-01-15T23:52:40 < karlp> and the "hot" place you're talking about, because they routed lava over their hot water pipes is now very cold too, so they're going to start damaging these places with busted water pipers now instead of lava.
2024-01-15T23:55:46 < qyx> at least the greenhouse is saved!
2024-01-15T23:56:03 < qyx> also, those 3 burnt houses look like unfinished
2024-01-15T23:56:04 < qyx> *looked
2024-01-15T23:56:25 < qyx> with many other around in a similar state
2024-01-15T23:56:52 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 276 seconds]
--- Day changed ti tammi 16 2024
2024-01-16T00:07:18 < karlp> yeah, the first one to burn was newly built, they had been hoping to move in before christmas
2024-01-16T00:07:25 < karlp> (fools)
2024-01-16T00:10:56 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T00:13:17 < qyx> at least they have the $current_home
2024-01-16T00:15:45 -!- fridericus [~Thunderbi@xdsl-87-79-135-110.nc.de] has quit [Quit: fridericus]
2024-01-16T00:16:05 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 268 seconds]
2024-01-16T00:22:30 < qyx> karlp is our dynamic networking pro, is it true there is no way of configuring dns dynamically for a SLAAC provided address?
2024-01-16T00:24:33 < zyp> what?
2024-01-16T00:25:00 < zyp> what do you mean configuring dns dynamically?
2024-01-16T00:25:14 < zyp> reverse dns for the ip?
2024-01-16T00:25:33 < zyp> or dns resolver?
2024-01-16T00:25:35 < qyx> no, forward
2024-01-16T00:26:05 < qyx> but yeah it is apparently not possible because the slaac client cannot provide its hostname back to the router
2024-01-16T00:26:15 < zyp> well, duh, it's in the name
2024-01-16T00:26:24 < zyp> the SL in SLAAC stands for stateless
2024-01-16T00:26:39 < qyx> it is half true
2024-01-16T00:27:24 < qyx> in a v4/v6 setup the dhcp server may use v4 provided hostname + mac and add AAAA dynamically for v6
2024-01-16T00:27:32 < qyx> dnsmasq can do it apparently
2024-01-16T00:27:46 < qyx> but in this case I can run dhcpv6 as well
2024-01-16T00:27:50 < zyp> the server basically goes: «here's the local network prefix, pick an address you like and have fun»
2024-01-16T00:28:26 < zyp> the server doesn't know which addrs actually get picked, and therefore can't take actions such as adding AAAA records pointing to them
2024-01-16T00:28:35 < qyx> yes but I wonder why there is no hostname in ND then
2024-01-16T00:28:57 < zyp> what do you mean?
2024-01-16T00:29:29 < qyx> you see what was selected by the client in the neighbour list, don't you?
2024-01-16T00:30:22 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-16T00:31:13 < qyx> hm
2024-01-16T00:31:37 < zyp> AIUI neighbor detection is an anticollision measure
2024-01-16T00:33:50 < zyp> anyway, why not just use dhcpv6 if you actually want stateful addressing?
2024-01-16T00:34:29 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T00:34:31 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:f7d1:4291:ab59:5630] has quit [Ping timeout: 255 seconds]
2024-01-16T00:34:52 < qyx> I don't really need it but it is hassle
2024-01-16T00:35:10 < qyx> I guess any zeroconf method would do together with slaac
2024-01-16T00:35:20 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-16T00:35:45 < qyx> a bit of a context: I want those devices to be fully zeroconf on a ipv6 network
2024-01-16T00:36:16 < qyx> they transmit some data and can be optionally confiured using a web interface
2024-01-16T00:36:23 < qyx> (despite being zeroconf)
2024-01-16T00:37:13 < qyx> transmittong is easy, you get an address, a router and you connect to a (mqtt) server and start sending data
2024-01-16T00:37:46 < qyx> the other way is a bit annoying because you can get a list of all IPs but you don't know which is which
2024-01-16T00:39:19 -!- krasjet [~krjst@2604:a880:800:c1::16b:8001] has quit [Ping timeout: 260 seconds]
2024-01-16T00:41:13 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 264 seconds]
2024-01-16T00:44:42 -!- krasjet [~krjst@2604:a880:800:c1::16b:8001] has joined ##stm32
2024-01-16T00:54:25 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T00:55:46 -!- krasjet [~krjst@2604:a880:800:c1::16b:8001] has quit [Ping timeout: 260 seconds]
2024-01-16T00:58:03 -!- krasjet [~krjst@2604:a880:800:c1::16b:8001] has joined ##stm32
2024-01-16T00:58:53 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 252 seconds]
2024-01-16T01:01:45 -!- Spirit532 [~Spirit532@user/Spirit532] has quit [Killed (NickServ (GHOST command used by Spirit5326))]
2024-01-16T01:01:50 -!- Spirit532 [~Spirit532@user/Spirit532] has joined ##stm32
2024-01-16T01:03:40 -!- Netsplit *.net <-> *.split quits: karlp, martinmoene__, boB_K7IQ, Ecco, skz81
2024-01-16T01:05:00 -!- Netsplit over, joins: boB_K7IQ, martinmoene__, Ecco, skz81, karlp
2024-01-16T01:06:09 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T01:06:23 -!- boB_K7IQ [~boB_K7IQ@184-98-66-243.phnx.qwest.net] has quit [Max SendQ exceeded]
2024-01-16T01:06:45 -!- boB_K7IQ [~boB_K7IQ@184-98-66-243.phnx.qwest.net] has joined ##stm32
2024-01-16T01:06:58 < qyx> meh lwip doesn't support stateful config
2024-01-16T01:17:06 < Ecco> Heya
2024-01-16T01:17:06 < Ecco> (Trivia: I actually know the guy who came up with Zeroconf :)
2024-01-16T01:17:06 < Ecco> I have a question though: would you guys have some recommendation for test hooks?
2024-01-16T01:17:06 < Ecco> I got a Saleae LA a while ago and it came with really cool ones
2024-01-16T01:17:06 < Ecco> More recently I got a clone
2024-01-16T01:17:06 < Ecco> and the LA itself is meh (one of you guys here made me realize it had pull-ups on its input, which blows)
2024-01-16T01:17:06 < Ecco> but I mean, at $8 a pop… I've already got every penny out of it
2024-01-16T01:17:06 < Ecco> But anywya, I could use some nice hook probes
2024-01-16T01:17:06 < Ecco> I know theses are utter crap : https://www.aliexpress.us/item/3256806050549035.html?algo_exp_id=1f6d14ee-5e2d-4e81-be8b-99f3790b9513-15&utparam-url=scene%3Asearch%7Cquery_from%3A
2024-01-16T01:17:06 < Ecco> I'm looking for something cheap-ish but decent
2024-01-16T01:17:06 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-9897-2fb2-85e0-ad71.fixed6.kpn.net] has quit [Ping timeout: 245 seconds]
2024-01-16T01:17:06 < Ecco> Also, did I mention that pair of tweezer I got a few weeks ago,
2024-01-16T01:17:06 < Ecco> ?
2024-01-16T01:17:06 < Ecco> I got it for $5 off of Amazon
2024-01-16T01:17:06 < Ecco> And… I really like it! It's well crafted
2024-01-16T01:17:09 < Ecco> It's a "Towot SA-12"
2024-01-16T01:17:37 < Ecco> Paid $7 for them
2024-01-16T01:17:40 < Ecco> they're great
2024-01-16T01:19:10 < Ecco> Also, do you guys have any recommendation for a "helping hand"?
2024-01-16T01:19:22 < Ecco> Any contraption that will hold PCBs and wire in place while I solder
2024-01-16T01:19:35 < zyp> depends what you want to hold
2024-01-16T01:19:53 < zyp> sensepeek/pcbite is awesome for holding and probing PCBs
2024-01-16T01:20:20 < zyp> and I hear omnifixo is good too, I'm planning to get some to complement my pcbites
2024-01-16T01:21:44 < Ecco> Oh, interesting
2024-01-16T01:23:15 < Ecco> What about those? https://www.aliexpress.us/item/3256805105395599.html
2024-01-16T01:23:17 < Ecco> (way cheaper)
2024-01-16T01:23:37 < zyp> looks like shit
2024-01-16T01:23:38 < Ecco> I guess it would never hold a probe in place, but for soldering?
2024-01-16T01:24:31 < zyp> I'd rather try https://www.aliexpress.us/item/1005005598502581.html or similar if you wanna go aliexpress
2024-01-16T01:25:02 < zyp> https://www.aliexpress.us/item/32973845988.html looks even better
2024-01-16T01:25:50 < zyp> you don't want flexible arms for holding pcbs, you want rigid feet
2024-01-16T01:27:51 < Ecco> But that assumes the PCB has holes?
2024-01-16T01:28:18 < Ecco> But I do see your point though
2024-01-16T01:28:37 < zyp> no, looks like there's a groove on the side too
2024-01-16T01:28:51 < zyp> but it's not spring loaded, like the pcbite holders
2024-01-16T01:28:59 < zyp> so I'd still rather get the latter
2024-01-16T01:29:28 < Ecco> Actually I don't really remember when
2024-01-16T01:29:41 < Ecco> but I do remember thinking "damn, I could use something to help me hold that crap in place"
2024-01-16T01:29:53 < Ecco> Usually when I populate a PCB I just lay it flat on my desk
2024-01-16T01:30:05 < Ecco> Yeah, maybe when I use a hot air gun
2024-01-16T01:30:11 < Ecco> because I don't want to burn the desk
2024-01-16T01:30:15 < Ecco> then this could come in handy
2024-01-16T01:33:04 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 276 seconds]
2024-01-16T02:07:25 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 256 seconds]
2024-01-16T02:12:20 < nuxil> just get a small machine vice that can hold the pcb. pref a small alu one. then a couple of cheap "2-arms  helping hand"
2024-01-16T02:19:39 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T02:19:52 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 276 seconds]
2024-01-16T02:24:08 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 252 seconds]
2024-01-16T02:34:58 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-16T02:37:37 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T02:42:50 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 252 seconds]
2024-01-16T03:05:08 < aandrew> Ecco> What about those? https://www.aliexpress.us/item/3256805105395599.html
2024-01-16T03:05:16 < aandrew> I got one of those (or something very very similar) -- it's ... meh
2024-01-16T03:05:49 < aandrew> better than nothing, but a proper pcb holder / vise is much better if you need that kind of thing. I typically just use pcbites when soldering
2024-01-16T03:14:07 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T03:20:29 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 260 seconds]
2024-01-16T03:32:51 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T03:38:13 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 260 seconds]
2024-01-16T03:41:29 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-16T04:06:09 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T04:12:29 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 252 seconds]
2024-01-16T04:17:43 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-16T04:26:54 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T04:31:44 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 252 seconds]
2024-01-16T04:46:12 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T04:50:45 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 256 seconds]
2024-01-16T05:02:14 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T05:07:22 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 246 seconds]
2024-01-16T05:09:30 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Remote host closed the connection]
2024-01-16T05:16:39 -!- bitmask [~bitmask@2601:84:c880:a590:688a:2ddf:caeb:f0cb] has joined ##stm32
2024-01-16T05:16:44 < bitmask> to work or not to work...
2024-01-16T05:20:31 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T05:26:25 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 276 seconds]
2024-01-16T05:37:33 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T05:43:19 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 276 seconds]
2024-01-16T05:57:40 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T06:03:02 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 252 seconds]
2024-01-16T06:16:38 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T06:21:40 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 276 seconds]
2024-01-16T06:25:57 -!- bitmask [~bitmask@2601:84:c880:a590:688a:2ddf:caeb:f0cb] has quit [Quit: Textual IRC Client: www.textualapp.com]
2024-01-16T06:33:05 -!- bitmask [~bitmask@2601:84:c880:a590:688a:2ddf:caeb:f0cb] has joined ##stm32
2024-01-16T06:33:09 < bitmask> https://imgur.com/gallery/nGSToXM
2024-01-16T06:35:02 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T06:40:07 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 246 seconds]
2024-01-16T06:46:26 -!- bitmask [~bitmask@2601:84:c880:a590:688a:2ddf:caeb:f0cb] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
2024-01-16T06:54:37 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T07:00:14 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 252 seconds]
2024-01-16T07:07:36 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-16T07:14:02 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T07:18:39 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 256 seconds]
2024-01-16T07:30:02 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-16T07:30:41 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T07:31:15 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-16T07:36:13 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 260 seconds]
2024-01-16T07:48:51 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T07:54:25 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 260 seconds]
2024-01-16T08:07:13 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 268 seconds]
2024-01-16T08:07:48 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T08:12:53 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 240 seconds]
2024-01-16T08:24:21 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T08:35:31 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-16T08:47:54 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-98b6-dc52-e9d-a47d.fixed6.kpn.net] has joined ##stm32
2024-01-16T08:52:05 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-98b6-dc52-e9d-a47d.fixed6.kpn.net] has quit [Ping timeout: 240 seconds]
2024-01-16T08:52:09 -!- machinehum2 [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T08:53:32 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 252 seconds]
2024-01-16T08:53:32 -!- HelloShi1ty [~user@bl22-255-167.dsl.telepac.pt] has quit [Ping timeout: 252 seconds]
2024-01-16T08:55:07 -!- HelloShi1ty [~user@bl22-255-167.dsl.telepac.pt] has joined ##stm32
2024-01-16T08:59:51 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-48c0-8440-8c8e-452d.fixed6.kpn.net] has joined ##stm32
2024-01-16T09:00:21 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-16T09:27:34 -!- machinehum2 [~machinehu@213.55.225.67] has quit [Ping timeout: 264 seconds]
2024-01-16T09:40:34 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T09:45:19 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 260 seconds]
2024-01-16T09:52:39 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2024-01-16T09:58:28 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T10:04:02 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 256 seconds]
2024-01-16T10:15:19 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T10:20:29 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 240 seconds]
2024-01-16T10:22:49 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-48c0-8440-8c8e-452d.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-16T10:25:13 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T10:26:36 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has joined ##stm32
2024-01-16T10:39:57 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-16T10:59:20 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-16T11:09:08 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 268 seconds]
2024-01-16T11:16:04 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T11:19:55 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-16T11:23:05 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-48c0-8440-8c8e-452d.fixed6.kpn.net] has joined ##stm32
2024-01-16T11:34:59 < martinmoene__> hackkitten is back
2024-01-16T11:39:34 < Steffanx> Ok thanks
2024-01-16T11:40:44 < martinmoene__> :)
2024-01-16T11:51:22 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 268 seconds]
2024-01-16T12:04:14 < hackkitten> :o
2024-01-16T12:04:46 < martinmoene__> nice to see you :)
2024-01-16T12:08:12 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Read error: Connection reset by peer]
2024-01-16T12:18:49 < karlp> qyx: I'm wayyyyy out of touch on ipv6 reccomendations sorry.  I only cared about mdns and upnp advertising for plain ipv4 dhcp client devices, so we could find them on a network.
2024-01-16T12:25:09 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2024-01-16T12:45:31 -!- mrec [~mrec@user/mrec] has joined ##stm32
2024-01-16T12:50:14 < karlp> hrm, my non-blocking ITM putchar is mangling everything, and my "normal" blocking that i've used before is ... hanging?
2024-01-16T12:50:18  * karlp inserts DSB.
2024-01-16T12:50:49 < karlp> hah. fixed
2024-01-16T12:50:52 < karlp> should have tried that earlier.
2024-01-16T12:51:24 < ventYl> interesting that blocking userland function hangs
2024-01-16T12:51:43 < karlp> hanging what?
2024-01-16T12:52:06 < ventYl> > "normak" .... is ... hanging?
2024-01-16T12:52:16 < karlp> for "reasons" there's no watchdog on this board, ("reasons" == "it didn't work" no further details)
2024-01-16T12:52:26 < karlp> no, i didn't want it to hang, 
2024-01-16T12:52:42 < karlp> i was expecting my normal blocking methods that simply stall until the itm write has completed.
2024-01-16T12:52:53 < ventYl> that's something I'd also expect
2024-01-16T12:53:19 < ventYl> I wouldn't expect DSB being needed in normal method.
2024-01-16T12:53:20 < karlp> apparently https://paste.jvnv.net/view/WM4rA
2024-01-16T12:53:31 < karlp> with the __DSB commented out, it hangs on this processor.
2024-01-16T12:53:43 < karlp> it's possible I'd never beenworking on a "fast" m4,
2024-01-16T12:53:56 < karlp> my implementation had been used before on a "slow" m3.
2024-01-16T12:54:15 < karlp> (i've not tried dmb or anything else instead of dsb, but this already fixes things)
2024-01-16T12:57:39 < ventYl> I can't godbolt it. Albeit improbable, isn't this an optimization issue?
2024-01-16T12:59:31  * karlp shrugs
2024-01-16T12:59:44 < ventYl> well it doesn't matter. it is just a matter of curiosity
2024-01-16T13:00:24 < ventYl> IME, DSB was ever only needed whenever I did something disruptive to the core itself
2024-01-16T13:11:25 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 255 seconds]
2024-01-16T13:33:10 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T13:34:57 < zyp> kinda sounds like a forgotten volatile
2024-01-16T13:43:51 < ventYl> yeah, but your average SDK (TM) wouldn't do that, would it?
2024-01-16T13:46:49 < ventYl> s/your//; otherwise it could sound provocative
2024-01-16T13:59:58 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 264 seconds]
2024-01-16T14:13:43 -!- machinehum [~machinehu@213.55.225.67] has joined ##stm32
2024-01-16T14:29:52 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Quit: Client closed]
2024-01-16T15:13:46 < jpa-> karlp: it would be interesting to see disassembly before and after
2024-01-16T15:14:15 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-16T15:14:32 < karlp> I eventually replaced it wiht a __NOP() and it works even better :)
2024-01-16T15:14:37 < karlp> so yeah, computers...
2024-01-16T15:14:53 < karlp> I'll trya nd get you that in a little bit, trying to get RTT working now.
2024-01-16T15:15:31 < jpa-> DMB/DSB waits for the write buffer to drain, but do not affect the speed at which the write buffer drains
2024-01-16T15:16:28 < jpa-> a place where you often do need DMB/DSB is if you write twice to same register
2024-01-16T15:17:29 < ventYl> hm, is that universally true, or may that depend on the core you are running on?
2024-01-16T15:17:45 < jpa-> sure, depends on core
2024-01-16T15:18:13 < ventYl> ok, probably that's the reason why I never saw that. I've been mostly dealing with M0+ and low-end M4s
2024-01-16T15:18:34 < karlp> fuck, am I going to gdb openocd today?
2024-01-16T15:18:39 < jpa-> M3 and M4 have write buffer, M0/M0+ does not
2024-01-16T15:19:01 < jpa-> and even on M3/M4 you mostly see the issue if the bus you are accessing has lower clock rate than the CPU
2024-01-16T15:22:08 < ventYl> I probably never fullfiled the last condition
2024-01-16T16:02:57 < karlp> working with nop: https://paste.jvnv.net/view/Aia8Z from arm-none-eabi-objdump -S
2024-01-16T16:06:17 < karlp> hanging/spinning on the while without the nop: https://paste.jvnv.net/view/J4tiM
2024-01-16T16:06:51 < jpa-> "2c:e7fe      b.n2c <stderr_write_r+0x2c>"   yeah, seems like it doesn't think the ITM port is volatile
2024-01-16T16:28:36 < qyx> since when I started looking at aebi tractors I keep mispelling arm-none-aebi-
2024-01-16T16:29:14 < qyx> -when
2024-01-16T16:29:23 < karlp> huh, indeed, that seems to be an error in the cmsis header, at least, the version we have.  it's defined as https://paste.jvnv.net/view/SoWY0
2024-01-16T16:29:34 < karlp> hrm, this looks like it might be local foolery from someone...
2024-01-16T16:30:17 < karlp> hrm, it's in the initial addition at least.
2024-01-16T16:30:56 < karlp> definitely not in any arm code though.  ffs.
2024-01-16T16:31:23 < karlp> commit says "adding cmsis sources for k70"
2024-01-16T16:31:26 < karlp> fucking cunts.
2024-01-16T16:32:04 < qyx> were you contracted to fix legacy shit
2024-01-16T16:32:07 < qyx> or to do some actual programming
2024-01-16T16:32:40 < karlp> do programming, but if I can't use tools to do the programming, I have to fix that shit too.
2024-01-16T16:32:54 < karlp> and there's 30 years of cruft built up here.
2024-01-16T16:33:42 < karlp> what fucking insane person would do this though, edit out a volatile in a core cmsis header.
2024-01-16T16:35:36 < fenugrec> lol
2024-01-16T16:35:47 < fenugrec> "to silence a compiler warning" ?
2024-01-16T16:36:10 -!- machinehum [~machinehu@213.55.225.67] has quit [Ping timeout: 255 seconds]
2024-01-16T16:37:24 < jpa-> it's kinda funny for the CMSIS header to specify it as __O in the first place, considering it can be read and produces the busy flag
2024-01-16T16:38:26 < karlp> well, yes, that too... I'm just about to go to current cmsis and see if it still does.
2024-01-16T16:39:30 < karlp> nah, it's "__OM" now, with the M for "struct member" but it's sitll considered write only registers.
2024-01-16T16:39:46 < ventYl> reminds me of one Autodesk Inventor shared component which contained "using namespace xml;" in one of its public headers.
2024-01-16T16:39:50 < jpa-> i wonder if stb is initials of somebody
2024-01-16T16:40:01 < ventYl> this single line must have cost Autodesk shitload of money to work around it
2024-01-16T16:40:01 < karlp> hah, yes, I think it is.
2024-01-16T16:40:37 < karlp> I should have recognised it straight away, I thought it was the store boundary or something some instruction 
2024-01-16T16:41:22 < ventYl> well, it takes some time before you include possibility that some of your (ex-)colleagues would do such a dumb thing
2024-01-16T16:41:41 < karlp> I continue to be impressed at some of the levels they have gone to at times.
2024-01-16T16:41:53 < karlp> there'ss remarkable bits in between, but wow there's some rough shit.
2024-01-16T16:42:11 < karlp> but fucking editing out a volatile in a cmsis header?! who even _starts_ that..
2024-01-16T16:42:58 < jpa-> so go blame your nearest Sigurour Thor Björnsen
2024-01-16T16:43:25 < jpa-> (and make sure he doesn't have his hammer with him..)
2024-01-16T16:45:10 < ventYl> karlp: I've seen people suggesting disabling watchdogs by hacking RTOS kernel, just because our MCU was reseting and we couldn't find out why quickly enough
2024-01-16T16:45:50 < ventYl> when I opposed that dumb idea which would backfire sooner than later, that particular person complained that he hates we now have to integrate 3rd party RTOS and are not allowed to hack it
2024-01-16T16:46:06 < karlp> yeh, the watchdog is also disabled on this project..... "because it was giving spurious resets"   [doubt...]
2024-01-16T16:46:55 < jpa-> i've been working on getting some 10+ years old code running on mostly unhacked nuttx after the 10 years of accumulated hacks; sadly i only have myself to blame
2024-01-16T16:48:04 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-16T16:48:57 < ventYl> this particular individual would hack any piece of code in a blink of an eye. I guess he was incompetent enough that he wasn't even aware which piece of code is in-house and which is 3rd party, or generated
2024-01-16T16:49:23 < ventYl> IIRC, it even happened that he hacked some auto-generated code and then complained that someone reverted his hack
2024-01-16T16:49:34 < ventYl> ...yeah, we were storing auto-generated code into version control
2024-01-16T16:51:15 < jpa-> if you hadn't, he would have claimed "works on my system, the CI must be broken!"
2024-01-16T16:52:01 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-16T16:52:28 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-16T16:53:03 < ventYl> the thing was, that he was only responsible for one out of some 20 components
2024-01-16T16:53:33 < karlp> ventYl: that's actaully something that could happen here eeasily too, third party code is all just dumped into "src" with eveyrthing else.  I'm trying to start shuffling some of it out, but finding local mods is... challenging.
2024-01-16T16:53:37 < ventYl> and we had three different workflows involved in building the whole product. he was given output of stage 1 and stage 2 and only built his piece and then integrated everything together
2024-01-16T16:53:54 < ventYl> so he was largely unaware of what really happens before he touches the code
2024-01-16T16:54:27 < ventYl> now we happened the source for stage 1, stage 1 output, source for stage 2, stage 2 output, source for stage 3, stage 3 output and whole binary all stored in VCS "just in case"
2024-01-16T16:54:56 < ventYl> so for any particular VSC content, you were not able to tell if stage outputs match the input or each other or WTF is actually stored in there
2024-01-16T16:55:34 < ventYl> we even managed to use older stage 1 binaries to be linked with newer stage 2 / 3 sources and released to the customer because there was no `make all`
2024-01-16T17:05:58 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-16T17:24:48 < karlp> huh TIL about cmsis Driver apis...
2024-01-16T17:25:40 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-16T17:27:49 < jpa-> IIRC pretty much no-one implements those
2024-01-16T17:28:12 < karlp> found a "cmsis-packs" for h7, and some niche nxp lpc part, but yeah, seems pretty thin on the ground...
2024-01-16T17:28:50 < ventYl> Rust seems to be handling this better. still not ideal, yet much better than standard state of affairs in C world
2024-01-16T17:29:08 < karlp> no, rust just looks like it is, because there's less forked users so far...
2024-01-16T17:29:11 < ventYl> not much surprise given the amount of mistakes they've had chances to learn from
2024-01-16T17:29:40 < karlp> I tried using some early embedded traits and got told "oh no, noone uses those, those are bad apis, use this other niche thing some of us are working on"
2024-01-16T17:29:48 < ventYl> I would say that there will be less will to fork and hack it.
2024-01-16T17:29:48 < jpa-> doesn't rust already have like at least 5 different "embedded HALs"
2024-01-16T17:29:54 < karlp> ^^^
2024-01-16T17:30:07 < jpa-> and also varying success in running even the rust stdlib on embedded targets
2024-01-16T17:30:20 < ventYl> I think they deprecate many of them in rapid pace
2024-01-16T17:30:41 < jpa-> .. and invent new ones in rapid pace? :)
2024-01-16T17:30:53 < ventYl> yeah; causing major of discontent in automotive industry
2024-01-16T17:31:10 < ventYl> as their strategy "select tooling in 1993, live with it until 2023" simply does not work
2024-01-16T17:31:34 < karlp> it works as long as you don't care about your staff sanity or being able to employ people....
2024-01-16T17:31:39 < ventYl> and while cargo has dependency tracking, their project are unable to update, or accept new dependency as soon as 8 months after they were set up
2024-01-16T17:32:06 < ventYl> karlp: I would say that it is not production ready yet, at least not in commercial scale
2024-01-16T17:32:07 < karlp> yeah, youy'd never be able to rely on cargo and the internet to maintain things for you over any meaningful timeframe..
2024-01-16T17:32:54 < ventYl> well, that's another point. online repositories are subject of dependency decay over time. and also supply chain attacks
2024-01-16T17:33:07 < ventYl> I think that there even was one recently
2024-01-16T17:33:33 < ventYl> that's why I rejected Conan, back while working in automotive
2024-01-16T17:33:55 < ventYl> sooner or later someone would drag some external dependency in and sooner than later that dependency would become compromised
2024-01-16T17:35:00 < karlp> yeah, better to just copy it once, keep the bugs....
2024-01-16T17:35:07 < karlp> let people hack out volatile locally... :)
2024-01-16T17:35:44 < ventYl> their ecosystem was so weird, that they were basically not using any standard / sane pieces of software available in the repository
2024-01-16T17:36:26 < ventYl> and they were also so fuckin' backwards that they would copy that damn dependency even despite it was available in the local artifactory
2024-01-16T17:36:52 < ventYl> they even tried to explicitly request, so that all shared packages will be "deployable locally"
2024-01-16T17:37:09 < ventYl> officially "for historic reasons", in fact it was to allow them do unsolicited hacking
2024-01-16T17:44:32 < karlp> ok, so now that I know how to hold eveyrone's hands the right way, openocd can happily do RTT from external sdram too. so that's cool.
2024-01-16T18:02:25 < karlp> can you pass the decoded value to a monitor command like this? `(gdb) monitor rtt setup &_SEGGER_RTT `?
2024-01-16T18:02:38 < karlp> where the monitor command is expecting a number, not a string name?
2024-01-16T18:58:55 -!- machinehum [~machinehu@213.55.224.113] has joined ##stm32
2024-01-16T19:03:15 -!- machinehum [~machinehu@213.55.224.113] has quit [Ping timeout: 245 seconds]
2024-01-16T19:11:07 -!- bitmask [~bitmask@2601:84:c880:a590:688a:2ddf:caeb:f0cb] has joined ##stm32
2024-01-16T19:21:46 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has quit [Ping timeout: 260 seconds]
2024-01-16T20:18:01 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-48c0-8440-8c8e-452d.fixed6.kpn.net] has quit [Ping timeout: 255 seconds]
2024-01-16T20:40:55 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 256 seconds]
2024-01-16T20:47:22 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-48c0-8440-8c8e-452d.fixed6.kpn.net] has joined ##stm32
2024-01-16T20:50:30 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-16T21:04:54 -!- hexo__ [~hexo@user/hexo] has quit [Remote host closed the connection]
2024-01-16T21:11:54 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 260 seconds]
2024-01-16T21:16:58 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-16T21:27:41 -!- alan_o [~alan_o@172-7-159-77.lightspeed.dybhfl.sbcglobal.net] has quit [Remote host closed the connection]
2024-01-16T21:28:06 -!- alan_o [~alan_o@2600:1700:1902:210f:22a9:73f7:2f7a:950a] has joined ##stm32
2024-01-16T21:29:48 -!- alan_o [~alan_o@2600:1700:1902:210f:22a9:73f7:2f7a:950a] has quit [Remote host closed the connection]
2024-01-16T21:30:15 -!- alan_o [~alan_o@2600:1700:1902:210f:22a9:73f7:2f7a:950a] has joined ##stm32
2024-01-16T21:38:59 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-16T21:39:02 < Laurenceb_> kek @ top left https://nitter.net/pic/media%2FGD9pJwGW0AAVJCO.jpg%3Fname%3Dsmall%26format%3Dwebp
2024-01-16T21:43:44 < Ecco> Dude went Copperfield on his chin
2024-01-16T21:50:33 < nomorekaki> did lurence buy himself barn door sized chin inspired by memes?
2024-01-16T22:43:44 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Ping timeout: 250 seconds]
2024-01-16T22:47:49 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-48c0-8440-8c8e-452d.fixed6.kpn.net] has quit [Ping timeout: 264 seconds]
2024-01-16T22:56:05 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-d5f1-4090-158-8372.fixed6.kpn.net] has joined ##stm32
2024-01-16T23:08:26 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-16T23:13:06 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 268 seconds]
2024-01-16T23:14:40 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-16T23:40:39 -!- haritz [~hrtz@user/haritz] has quit [Ping timeout: 260 seconds]
2024-01-16T23:41:33 -!- haritz [~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220] has joined ##stm32
2024-01-16T23:43:16 -!- haritz [~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220] has quit [Changing host]
2024-01-16T23:43:16 -!- haritz [~hrtz@user/haritz] has joined ##stm32
--- Day changed ke tammi 17 2024
2024-01-17T01:02:16 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 276 seconds]
2024-01-17T01:37:01 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-d5f1-4090-158-8372.fixed6.kpn.net] has quit [Ping timeout: 264 seconds]
2024-01-17T01:39:41 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 256 seconds]
2024-01-17T01:42:01 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-17T01:52:34 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2024-01-17T03:14:13 -!- HelloShi1ty [~user@bl22-255-167.dsl.telepac.pt] has quit [Ping timeout: 268 seconds]
2024-01-17T03:15:44 -!- HelloShi1ty [~user@bl22-255-167.dsl.telepac.pt] has joined ##stm32
2024-01-17T03:43:04 < englishman> emeb’s site doesn’t work anymore :(
2024-01-17T05:20:14 -!- bitmask [~bitmask@2601:84:c880:a590:688a:2ddf:caeb:f0cb] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
2024-01-17T07:16:59 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-17T07:26:21 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-17T07:53:11 -!- nuxil [~nuxil@141.195.51.41] has quit [Read error: Connection reset by peer]
2024-01-17T07:53:21 -!- nuxil [~nuxil@141.195.51.41] has joined ##stm32
2024-01-17T07:59:45 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-6199-df1b-8cac-1321.fixed6.kpn.net] has joined ##stm32
2024-01-17T08:07:01 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-6199-df1b-8cac-1321.fixed6.kpn.net] has quit [Ping timeout: 264 seconds]
2024-01-17T08:41:01 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-6199-df1b-8cac-1321.fixed6.kpn.net] has joined ##stm32
2024-01-17T09:00:00 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-17T09:00:22 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-6199-df1b-8cac-1321.fixed6.kpn.net] has quit [Ping timeout: 246 seconds]
2024-01-17T09:30:32 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-17T09:30:58 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-17T09:53:36 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:c4b1:e2dc:4121:9094] has joined ##stm32
2024-01-17T10:08:14 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-17T10:08:42 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-17T10:34:34 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-17T11:14:48 < karlp> aww, that's a loss.
2024-01-17T11:15:05 < karlp> studionebula whatsit?
2024-01-17T11:15:41 -!- machinehum [~machinehu@213.55.224.113] has joined ##stm32
2024-01-17T11:17:00 < karlp> have sent him a message to ask if it has a new home..
2024-01-17T11:25:45 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-17T11:26:14 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-17T11:32:32 < Steffanx> He's here once in a while too. Mr emeb_mac
2024-01-17T11:51:02 -!- machinehum [~machinehu@213.55.224.113] has quit [Ping timeout: 256 seconds]
2024-01-17T12:15:53 -!- quinor [08c0f10716@2a03:6000:1812:100::dad] has joined ##stm32
2024-01-17T12:18:24 < jpa-> heh, the automatic image enhancement on my phone made an interesting interpretation on how the insulation on the third wire would go  https://jpa.kapsi.fi/stuff/pix/weird_insulation.png
2024-01-17T12:22:14 < qyx> stupid ai
2024-01-17T12:22:35 < qyx> that should be banned
2024-01-17T12:28:54 -!- machinehum [~machinehu@213.55.224.113] has joined ##stm32
2024-01-17T12:31:44 < jpa-> ah, actually not purely AI fault, looks like from a specific angle the solder joint just reflects like that
2024-01-17T12:31:58 < jpa-> second proto but same effect: https://jpa.kapsi.fi/stuff/pix/weird_insulation2.png
2024-01-17T12:32:51 < jpa-> then when it is on the edge of resolution / a bit shaky image, AI does what AI does
2024-01-17T12:42:09 < qyx> how is that possible a 10 bit I2C low end ADC with a couple of channels costs much more than a full featured stm32 with a 12 bit ADC
2024-01-17T12:42:22 < qyx> I am not paying 4€ for a 8 channel ADC
2024-01-17T12:52:40 < karlp> you're paying to not have to write another set of software..
2024-01-17T13:05:54 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 268 seconds]
2024-01-17T13:22:10 -!- machinehum [~machinehu@213.55.224.113] has quit [Ping timeout: 246 seconds]
2024-01-17T13:24:30 < jpa-> and something like attiny826 is less than a dollar, with 12 bits and PGA
2024-01-17T13:26:05 -!- machinehum [~machinehu@213.55.224.113] has joined ##stm32
2024-01-17T13:26:06 < ventYl> free time traveling experience included
2024-01-17T13:27:02 < jpa-> IMO using AVR doesn't feel much like time travel, it's C and registers just like STM32
2024-01-17T13:32:23 < qyx> C0 to the rescue
2024-01-17T13:34:02 < jpa-> more expensive and no PGA
2024-01-17T13:34:18 < qyx> but the same tools as the rest of the system
2024-01-17T13:34:25 < qyx> zero learning curve
2024-01-17T13:34:27 < jpa-> yeah, that's a bonus
2024-01-17T13:34:36 < ventYl> jpa-: probably except of less capable debugwire and extremely constrained resources
2024-01-17T13:35:24 < jpa-> also STM32C0 has I2C slave bootloader, which is nice if you don't want to preprogram it
2024-01-17T13:35:28 < qyx> STM32C031C6U6 is under dollar too
2024-01-17T13:35:42 < qyx> in bulk
2024-01-17T13:36:33 < qyx> nah now I have the feling I should do something with AVR
2024-01-17T13:36:35 < qyx> or 68hc11
2024-01-17T13:41:36 < karlp> fucking, jlink is failing to mass erase and unlock something that wasn't even meant to be locked.
2024-01-17T13:41:39 < karlp> fucking pro tools
2024-01-17T13:41:49 -!- qyx [~qyx@84.245.120.109] has quit [Ping timeout: 264 seconds]
2024-01-17T13:41:53 < jpa-> time to trace the orb
2024-01-17T13:42:37 < karlp> no, openocd doesn't support this fucking part as it is.  
2024-01-17T13:42:43 < karlp> I've started adding it, but bleh.
2024-01-17T13:42:49 < karlp> fuck knows what happened.
2024-01-17T13:42:52 < karlp> fucking computers.
2024-01-17T13:43:21 -!- qyx [~qyx@84.245.120.64] has joined ##stm32
2024-01-17T13:47:32 -!- machinehum [~machinehu@213.55.224.113] has quit [Ping timeout: 268 seconds]
2024-01-17T13:48:31 -!- machinehum [~machinehu@213.55.224.113] has joined ##stm32
2024-01-17T14:24:02 -!- machinehum2 [~machinehu@213.55.224.113] has joined ##stm32
2024-01-17T14:26:44 -!- machinehum [~machinehu@213.55.224.113] has quit [Ping timeout: 252 seconds]
2024-01-17T14:27:17 -!- HelloShi1ty [~user@bl22-255-167.dsl.telepac.pt] has quit [Ping timeout: 252 seconds]
2024-01-17T14:29:22 -!- HelloShi1ty [~user@bl22-255-167.dsl.telepac.pt] has joined ##stm32
2024-01-17T14:46:57 -!- c10ud [~c10ud@user/c10ud] has quit [Read error: Connection reset by peer]
2024-01-17T14:47:15 -!- c10ud [~c10ud@user/c10ud] has joined ##stm32
2024-01-17T15:04:21 -!- machinehum2 [~machinehu@213.55.224.113] has quit [Ping timeout: 260 seconds]
2024-01-17T15:12:33 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-17T15:50:42 -!- machinehum [~machinehu@213.55.224.113] has joined ##stm32
2024-01-17T15:55:22 -!- machinehum [~machinehu@213.55.224.113] has quit [Ping timeout: 276 seconds]
2024-01-17T16:11:33 -!- machinehum [~machinehu@213.55.224.113] has joined ##stm32
2024-01-17T16:20:01 -!- martinmoene_ [~martinmoe@132.229.46.129] has quit [Read error: Connection reset by peer]
2024-01-17T16:31:11 -!- martinmoene [~martinmoe@132.229.46.129] has joined ##stm32
2024-01-17T16:32:09 -!- martinmoene [~martinmoe@132.229.46.129] has left ##stm32 []
2024-01-17T16:44:47 -!- machinehum [~machinehu@213.55.224.113] has quit [Ping timeout: 252 seconds]
2024-01-17T16:45:49 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-17T16:45:55 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-17T16:54:07 -!- machinehum [~machinehu@213.55.224.113] has joined ##stm32
2024-01-17T17:07:37 -!- machinehum [~machinehu@213.55.224.113] has quit [Ping timeout: 264 seconds]
2024-01-17T17:08:30 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-17T17:09:33 -!- machinehum [~machinehu@213.55.224.113] has joined ##stm32
2024-01-17T17:15:50 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-17T17:24:37 -!- martinmoene_ [~martinmoe@132.229.46.129] has joined ##stm32
2024-01-17T17:26:00 < karlp> emeb says he put all the content at https://github.com/emeb/Old_Website
2024-01-17T17:36:46 -!- machinehum2 [~machinehu@213.55.225.125] has joined ##stm32
2024-01-17T17:38:41 -!- machinehum [~machinehu@213.55.224.113] has quit [Ping timeout: 252 seconds]
2024-01-17T17:40:40 < fenugrec> emeb is an OG hacker, he has kernel patches for 2.4.x in there hehe
2024-01-17T17:50:51 < englishman> nice karl thanks
2024-01-17T17:51:04 < englishman> i hope your house isn’t slowly consumed by lava while raging at stm32 hal
2024-01-17T17:51:46 < karlp> I'm fine, I don't live in grindavik.
2024-01-17T17:51:56 < englishman> i was looking for this https://github.com/emeb/Old_Website/tree/main/embedded/stm32f373breakout the one with factory mis-programmed chips
2024-01-17T17:52:40 < karlp> are you dealing with 10 year old f373 boards?
2024-01-17T17:53:31 < englishman> happily no, we were talking about chinese quality chips and i mentioned this one from superior european quality manufacturer
2024-01-17T17:53:56 < karlp> did you see me sharing a kinetis errata the other day? from rev _6_ of the datsheet, they dropped "USB HS PHY" entirely from the features... :)
2024-01-17T17:54:03 < karlp> qwaliteee
2024-01-17T17:54:04 < englishman> nice
2024-01-17T17:55:33 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-17T17:55:41 < ventYl> I did good deal of bitching unveiling unknown errata in kinetis part
2024-01-17T17:55:56 < ventYl> like if you do this, it will nuke all the peripheral RAM
2024-01-17T18:02:16 -!- c10ud [~c10ud@user/c10ud] has quit [Read error: Connection reset by peer]
2024-01-17T18:42:25 -!- machinehum2 [~machinehu@213.55.225.125] has quit [Ping timeout: 264 seconds]
2024-01-17T18:51:36 -!- c10ud [~c10ud@host-213-26-199-10.business.telecomitalia.it] has joined ##stm32
2024-01-17T18:51:36 -!- c10ud [~c10ud@host-213-26-199-10.business.telecomitalia.it] has quit [Changing host]
2024-01-17T18:51:36 -!- c10ud [~c10ud@user/c10ud] has joined ##stm32
2024-01-17T19:32:49 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 264 seconds]
2024-01-17T20:17:37 -!- josuah [~josuah@46.23.94.12] has joined ##stm32
2024-01-17T20:18:27 -!- josuah [~josuah@46.23.94.12] has quit [Client Quit]
2024-01-17T20:19:00 -!- josuah [~josuah@46.23.94.12] has joined ##stm32
2024-01-17T20:25:24 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-1c22-a68a-8cc3-4c37.fixed6.kpn.net] has joined ##stm32
2024-01-17T20:45:19 -!- drkow [~k\o\w@2607:fea8:1d00:89f0:95ac:8634:227b:bd9b] has joined ##stm32
2024-01-17T20:48:35 -!- drfff [~k\o\w@2607:fea8:1d00:89f0:c4af:c9eb:f18f:7248] has quit [Ping timeout: 260 seconds]
2024-01-17T21:11:18 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-17T21:11:47 < octorian> So I decided to actually order the "recommended" HSE crystal for the Nucleo-64 boards over the weekend.  Ordered from an Asian site, which was so badly written that I needed to use browser dev tools to even figure out which address field was actually what (they all rendered w/o labels).  But they processed the order, shipped via FedEx, and it just arrived!
2024-01-17T21:11:48 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-17T21:11:54 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-17T21:14:03 < Ecco> hahah, cool :)
2024-01-17T21:14:24 < Ecco> Are those crystal super specific?
2024-01-17T21:14:45 < octorian> I think they're thru-hole with an odd width.
2024-01-17T21:15:06 < octorian> You can use other crystals, but I figure I'll at least try to use the recommended one.
2024-01-17T21:15:34 < octorian> Of course I don't have the 20pf capacitors they're supposed to be added with, so I'll just need to order them whenever I'm placing another usual parts order.
2024-01-17T21:16:15 -!- nomorekaki81 [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-17T21:17:54 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-17T21:32:49 < nomorekaki81> https://www.youtube.com/watch?v=4LiP39gJuqE anything to make mario64 run faster
2024-01-17T21:33:11 < nomorekaki81> he has already improved fps >100%
2024-01-17T21:34:29 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:c4b1:e2dc:4121:9094] has quit [Ping timeout: 240 seconds]
2024-01-17T21:39:16 < nomorekaki81> how to use expect builtin?
2024-01-17T21:39:36 < nomorekaki81> when the statistical likelyhood is above 50%?
2024-01-17T21:42:42 < nomorekaki81> is there anything else to weight than the statistical likellyhood?
2024-01-17T22:00:04 < nomorekaki81> what is the default expection by compiler?
2024-01-17T22:00:06 < nomorekaki81> 0 ?
2024-01-17T22:01:33 -!- nomorekaki81 is now known as nomorekaki
2024-01-17T22:03:27 -!- CygniX [~CygniX@user/CygniX] has joined ##stm32
2024-01-17T22:52:13 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-17T23:03:42 < nomorekaki> hmm !!
2024-01-17T23:03:49 < nomorekaki> double inverse
2024-01-17T23:04:59 < nomorekaki> that's how to get boolean from integer :o
2024-01-17T23:10:23 < Steffanx> Your code running too slow nomorekaki? Need faster AVR?
2024-01-17T23:10:41 < nomorekaki> just autisming as I learned new thing
2024-01-17T23:11:00 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Quit: Client closed]
2024-01-17T23:13:56 < karlp> octorian: you can use ~any hse crytal...
2024-01-17T23:14:17 < karlp> pick say 3225 sized, and order by price....
2024-01-17T23:14:28 < karlp> (rational to stay with integer Mhz though)
2024-01-17T23:19:44 < fenugrec> 3.6864Mhz for those oldschool baud rates
2024-01-17T23:19:59 < fenugrec> or 3.579545 for NTSC street cred
2024-01-17T23:20:00 < ventYl> machinehum: I won't be at FOSDEM personally. on thurdsay I'll finish leading C++ course sometime around 4pm. and the only viable flight departs at 3am on friday
2024-01-17T23:21:35 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 245 seconds]
2024-01-17T23:24:52 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-17T23:26:27 < karlp> fenugrec: https://imgflip.com/i/8coutv
2024-01-17T23:28:53 < fenugrec> heh
2024-01-17T23:34:35 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-17T23:40:01 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 256 seconds]
2024-01-17T23:50:34 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-17T23:53:17 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
--- Day changed to tammi 18 2024
2024-01-18T00:00:33 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 260 seconds]
2024-01-18T00:13:54 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T00:19:37 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 264 seconds]
2024-01-18T00:22:48 < karlp> well, I successfully avoided workign on my keyboard project by working on locm3, that I'd sworn to stop working on.
2024-01-18T00:22:51 < karlp> success?
2024-01-18T00:24:19 < ventYl> operation failed successfully?
2024-01-18T00:31:37 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 264 seconds]
2024-01-18T00:32:50 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T00:38:25 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 268 seconds]
2024-01-18T00:50:46 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T00:53:13 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-1c22-a68a-8cc3-4c37.fixed6.kpn.net] has quit [Ping timeout: 264 seconds]
2024-01-18T00:59:16 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 256 seconds]
2024-01-18T01:22:53 < nomorekaki> karlp: yes
2024-01-18T01:23:14 < nomorekaki> you can get keyboard from anywhere
2024-01-18T01:54:10 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 255 seconds]
2024-01-18T01:58:50 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Quit: Client closed]
2024-01-18T01:59:02 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-18T02:08:26 < nomorekaki> I have small calc functions in my lib that are made to be inlined in an interrupt
2024-01-18T02:08:34 < nomorekaki> only for that
2024-01-18T02:09:03 < nomorekaki> definition goes to .h?
2024-01-18T02:16:49 < nomorekaki> and it needs to be static inline?
2024-01-18T02:23:01 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T02:28:14 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 256 seconds]
2024-01-18T02:28:41 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Quit: Client closed]
2024-01-18T02:29:56 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-18T02:44:47 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-18T02:48:32 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 268 seconds]
2024-01-18T02:56:22 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T02:56:54 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Quit: Client closed]
2024-01-18T03:00:28 < fenugrec> why not define it static just in the .c file of your ISR, compiler should inline it
2024-01-18T03:02:49 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 264 seconds]
2024-01-18T03:05:21 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-18T03:07:28 -!- flatmush [~benbrewer@82-69-13-96.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 276 seconds]
2024-01-18T03:17:42 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T03:23:05 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 260 seconds]
2024-01-18T03:27:18 -!- flatmush [~benbrewer@82-69-13-96.dsl.in-addr.zen.co.uk] has joined ##stm32
2024-01-18T03:35:02 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T03:40:23 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 252 seconds]
2024-01-18T03:50:50 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Quit: Client closed]
2024-01-18T03:55:05 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T03:59:38 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 252 seconds]
2024-01-18T04:12:55 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T04:17:14 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 252 seconds]
2024-01-18T04:18:56 < jadew> Ecco, did you figure out your shuffle problem?
2024-01-18T04:19:24 < jadew> I'm struggling with something similar.
2024-01-18T04:47:23 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T04:53:40 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 245 seconds]
2024-01-18T05:09:12 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T05:14:13 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 264 seconds]
2024-01-18T05:17:31 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Remote host closed the connection]
2024-01-18T05:37:57 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T05:42:29 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 252 seconds]
2024-01-18T05:44:23 -!- jmcgnh [~jmcgnh@wikipedia/jmcgnh] has quit [Ping timeout: 264 seconds]
2024-01-18T05:54:01 -!- jmcgnh [~jmcgnh@wikipedia/jmcgnh] has joined ##stm32
2024-01-18T05:56:17 -!- jmcgnh [~jmcgnh@wikipedia/jmcgnh] has quit [Excess Flood]
2024-01-18T06:03:16 -!- jmcgnh [~jmcgnh@wikipedia/jmcgnh] has joined ##stm32
2024-01-18T06:12:20 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T06:17:49 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 264 seconds]
2024-01-18T06:49:39 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T06:52:07 -!- PaulFertser [paul@paulfertser.info] has quit [Ping timeout: 268 seconds]
2024-01-18T06:52:16 -!- PaulFertser [paul@paulfertser.info] has joined ##stm32
2024-01-18T06:56:13 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 264 seconds]
2024-01-18T07:09:03 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T07:14:21 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 256 seconds]
2024-01-18T07:15:53 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-18T07:26:26 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T07:31:56 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 252 seconds]
2024-01-18T07:59:20 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T08:05:55 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 256 seconds]
2024-01-18T08:18:40 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T08:23:22 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 264 seconds]
2024-01-18T08:36:28 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T08:41:47 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 252 seconds]
2024-01-18T08:45:46 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T08:50:35 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 252 seconds]
2024-01-18T09:02:45 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T09:04:19 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Ping timeout: 276 seconds]
2024-01-18T09:07:05 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 252 seconds]
2024-01-18T09:19:34 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-18T09:21:04 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T09:24:06 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2024-01-18T09:25:47 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 264 seconds]
2024-01-18T09:35:08 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-fd55-8334-8982-cbe8.fixed6.kpn.net] has joined ##stm32
2024-01-18T09:38:10 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T09:43:31 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 255 seconds]
2024-01-18T09:48:05 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-fd55-8334-8982-cbe8.fixed6.kpn.net] has quit [Ping timeout: 260 seconds]
2024-01-18T09:56:25 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T10:02:05 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 260 seconds]
2024-01-18T10:10:18 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-fd55-8334-8982-cbe8.fixed6.kpn.net] has joined ##stm32
2024-01-18T10:10:58 -!- boB_K7IQ [~boB_K7IQ@184-98-66-243.phnx.qwest.net] has quit [Ping timeout: 246 seconds]
2024-01-18T10:13:59 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has joined ##stm32
2024-01-18T10:14:42 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T10:19:22 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-fd55-8334-8982-cbe8.fixed6.kpn.net] has quit [Ping timeout: 246 seconds]
2024-01-18T10:20:13 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 256 seconds]
2024-01-18T10:21:48 -!- blathijs_ is now known as blathijs
2024-01-18T10:26:39 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T10:44:32 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-18T11:02:13 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 264 seconds]
2024-01-18T11:06:51 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T11:07:08 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-fd55-8334-8982-cbe8.fixed6.kpn.net] has joined ##stm32
2024-01-18T11:18:35 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-fd55-8334-8982-cbe8.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-18T11:19:54 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has joined ##stm32
2024-01-18T11:20:39 < PlasmaHH> whats the most problematic things with the STM32 HAL you would like to change in a future version?
2024-01-18T11:21:19 < jpa-> const-correctness
2024-01-18T11:21:52 < jpa-> the overlapping but incompatible defines between HAL, LL and stm32xxxx.h
2024-01-18T11:22:25 < jpa-> inlining for simple stuff
2024-01-18T11:22:43 < karlp> yeah, having all those overlapping defines are gross.
2024-01-18T11:23:37 < jpa-> nuttx/chibios-style GPIO access would be cool (single uint32_t that defines both port and pin)
2024-01-18T11:24:23 < jpa-> and same for DMA channels, single uint32_t that would define which DMA controller, which stream and which channel
2024-01-18T11:25:37 < jpa-> abstraction for getting timer clock rates - the HAL already has e.g. HAL_RCC_GetPCLK1Freq() but you need to look up which timer goes to which bus
2024-01-18T11:28:36 < ventYl> very specific issue I have is that it is stateful
2024-01-18T11:30:05 < jpa-> (so far i have used STM32 HAL in just one project, those are the things that struck me as odd defiencies when i'm used to chibios and nuttx getting them right)
2024-01-18T11:35:12 < PlasmaHH> ventYl: in what way?
2024-01-18T11:41:35 < ventYl> PlasmaHH: HAL allocates data structures to describe state of peripherals. this does not play well with memory model of my creepy RTOS
2024-01-18T11:43:25 < PlasmaHH> ventYl: do you mean the structs you pass to initializtion functions or internally inside the HAL "invisible" to the caller ?
2024-01-18T11:45:00 < ventYl> PlasmaHH: in some cases, HAL holds its own data structures which are "invisible" to the caller
2024-01-18T11:45:52 < PlasmaHH> ventYl: ah ok, never really noticed/cared about... I would expect that to be stuff that ends up in the .bss section usually?
2024-01-18T11:46:52 < ventYl> yeah, vast majority of developers doesn't care about memory safety these days
2024-01-18T11:47:07 < ventYl> driver is driver, so whatevs
2024-01-18T11:47:40 < ventYl> creepy RTOS is a mikrokernel, so driver is just another "application". and it implements memory isolation.
2024-01-18T11:48:17 < ventYl> then it becomes increasingly complicated to give the HAL code access to these invisible structures
2024-01-18T11:48:53 < PlasmaHH> ah ok, but it would work to have these structures but giving you control over where they reside?
2024-01-18T11:49:48 < ventYl> well, if you want to really get messy with your linker file and examine the HAL structure, you have that control. just, its way too much work to care about it.
2024-01-18T11:50:42 < PlasmaHH> yeah, your own would make that unnecessary though... any specific example?
2024-01-18T11:51:26 -!- boB_K7IQ [~boB_K7IQ@184-98-66-243.phnx.qwest.net] has joined ##stm32
2024-01-18T11:51:52 < ventYl> you still have to mess with linker file due to how the MPU works. but it can be automated. so the whole presence of memory isolation is essentially transparent to you as long as you follow simple rules.
2024-01-18T11:53:26 < ventYl> the design decision I made was: all .data and .bss of one static library will get grouped together and one "application" will be given access to it.
2024-01-18T11:53:29 < karlp> if I want to restart an application from main(), but not with "run" from gdb, because that goes back to the bootlaoder and... stuff, what else do I need ebsides "set $pc = &main; continue" ?  that's hardfaulting, presumably on stack pointer problems?
2024-01-18T11:54:30 < qyx> reload .data?
2024-01-18T11:54:35 < ventYl> karlp: you probably want set the $sp to correct initial value and $pc to startup code rather than main. if you restart from main, you have random stack pointer and "uninitialized" .bss
2024-01-18T11:54:39 < ventYl> that too
2024-01-18T11:54:47 < ventYl> but startup could would do that
2024-01-18T11:55:32 < karlp> fuck I hate this system.
2024-01-18T11:57:09 < jpa-> karlp: i would do    "mon reset halt" "set $pc = *(uint32_t*)(APP_BASE + 4)" "set $sp = *(uint32_t*)(APP_BASE)" "continue"
2024-01-18T12:02:32 < ventYl> PlasmaHH: this constraint really is a design-specific issue
2024-01-18T12:21:23 < PlasmaHH> ventYl: well, it seems like it can pop up for any kind of design that tries to protect memory from other code
2024-01-18T12:23:52 < ventYl> PlasmaHH: sure, chibios can do that too, albeit only in much less granular fashion. so it probably won't exhibit there as much.
2024-01-18T12:23:58 -!- PaulFertser [paul@paulfertser.info] has quit [Ping timeout: 246 seconds]
2024-01-18T12:24:06 -!- PaulFertser [paul@paulfertser.info] has joined ##stm32
2024-01-18T12:24:51 < ventYl> zephyr as well. yet with zephyr, you're gonna make yourself far more troubles when you turn memory isolation on.
2024-01-18T12:31:36 -!- martinmoene__ [~Martin@2a02:a45a:96ba:1:fd55:8334:8982:cbe8] has joined ##stm32
2024-01-18T12:33:25 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 264 seconds]
2024-01-18T12:37:23 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T13:02:44 -!- martinmoene__ [~Martin@2a02:a45a:96ba:1:fd55:8334:8982:cbe8] has quit [Ping timeout: 268 seconds]
2024-01-18T13:09:31 < PlasmaHH> ventYl: we have some application on non-stm32 that would probably have similar problems too, though luckily its pretty unlikely it ever needs to be ported ...
2024-01-18T13:15:49 < ventYl> well, TBH, the introduction of memory isolation creates a lot of issuess, unless you are willing to change your thinking
2024-01-18T13:21:32 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-c1e7-33e8-9cdc-2714.fixed6.kpn.net] has joined ##stm32
2024-01-18T13:26:16 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-c1e7-33e8-9cdc-2714.fixed6.kpn.net] has quit [Ping timeout: 255 seconds]
2024-01-18T14:01:36 < jpa-> http://paste.dy.fi/15v/plain   i guess gdb really doesn't want to break there :D
2024-01-18T14:06:18 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2024-01-18T14:20:03 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-18T14:43:06 < PlasmaHH> jpa-: gdb can be a bit unstable at times, especially when you do all that crazy stuff that I do in my python plugins... ^^
2024-01-18T14:58:56 < jpa-> yeah, seems like the gdb-multiarch that comes with ubuntu 22.04 is not great
2024-01-18T15:00:25 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-c1e7-33e8-9cdc-2714.fixed6.kpn.net] has joined ##stm32
2024-01-18T15:01:25 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 256 seconds]
2024-01-18T15:04:39 < PlasmaHH> guess thats gdb 8 or so ;)
2024-01-18T15:05:13 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-c1e7-33e8-9cdc-2714.fixed6.kpn.net] has quit [Ping timeout: 264 seconds]
2024-01-18T15:06:10 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-3c7f-6c14-e96b-a3ac.fixed6.kpn.net] has joined ##stm32
2024-01-18T15:13:34 < jpa-> 12.1
2024-01-18T15:14:18 < qyx> how did you manage to run the broken 12.x gdb?
2024-01-18T15:14:24 < qyx> with hardcoded python 3.8
2024-01-18T15:14:31 < qyx> oh ubuntu
2024-01-18T15:16:26 < jpa-> how is 12.x broken?
2024-01-18T15:19:19 < qyx> gdb from the official toolchain from arm doesn't work unless you supply it python 3.8
2024-01-18T15:23:00 < jpa-> ah, well it works for me because i have python 3.8 also :)
2024-01-18T15:28:33 < qyx> I have 3.9.2 and that's on debian
2024-01-18T15:28:39 < qyx> what ancient distro are you using
2024-01-18T15:29:24 < jpa-> i have 2.7, 3.8 and 3.10
2024-01-18T15:29:50 < qyx> I dropped 2.x already
2024-01-18T15:41:58 < nomorekaki> do you have strict iteration maximum rules?
2024-01-18T15:42:22 < nomorekaki> only local counter will do type of thing
2024-01-18T15:47:25 -!- machinehum [~machinehu@213.55.225.125] has joined ##stm32
2024-01-18T15:48:48 < jpa-> i have no rules
2024-01-18T15:51:43 -!- machinehum [~machinehu@213.55.225.125] has quit [Ping timeout: 256 seconds]
2024-01-18T15:54:01 < PlasmaHH> jpa-: for various reasons I got used to running git gdb for years now
2024-01-18T15:56:20 < jpa-> when i run some "latest git version" stuff, i end up running years old build of some random version :)
2024-01-18T16:17:23 < qyx> what's flatpak and flathub
2024-01-18T16:17:27 < qyx> yet another packaging manager?
2024-01-18T16:19:13 < jpa-> yeah, and one that removes old versions from their repo & makes it difficult to install from outside the repo
2024-01-18T16:25:50 < qyx> trying new kikecad, it is super slow
2024-01-18T16:26:34 < qyx> after opening 3d view, it shows just the pcb itself and tries to load components, one at a time, now it is stuck on a M3 screw *.step file
2024-01-18T16:26:58 < karlp> hrm, thorn was saying that too.
2024-01-18T16:27:03 < karlp> I've not tried it yet.
2024-01-18T16:27:43 < PlasmaHH> jpa-: because you updated years ago? ^^
2024-01-18T16:27:43 < qyx> how should I install the 8.0.0 rc1
2024-01-18T16:29:10 < karlp> when you said "new" what did you mean? 7?
2024-01-18T16:29:12 < karlp> or 6?
2024-01-18T16:30:05 < qyx> 6 :>
2024-01-18T16:31:17 < jpa-> lol what :D
2024-01-18T16:32:13 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-18T16:32:39 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-18T16:54:44 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-18T17:01:01 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-3c7f-6c14-e96b-a3ac.fixed6.kpn.net] has quit [Ping timeout: 264 seconds]
2024-01-18T17:13:43  * karlp lols
2024-01-18T17:17:41 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-18T17:32:04 < karlp> what the hell is NVIC_DBG_DATA and why am I getting a hardfault bus error trying to access it when I reset.
2024-01-18T17:32:07 < karlp> blæeh.
2024-01-18T17:36:44 < karlp> let's try jpa's trick instead..
2024-01-18T17:43:28 -!- rob_w [~bob@2001:a61:6072:1f01:214:5405:9a71:cf1] has joined ##stm32
2024-01-18T17:49:33 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Quit: Client closed]
2024-01-18T17:53:36 < Ecco> jadew: yeah :)
2024-01-18T17:54:08 < Ecco> https://afnan.io/posts/2019-04-05-explaining-the-hashed-permutation/
2024-01-18T17:54:44 < Ecco> Dumb question: on my Rigol DHO800, I'm trying to do a single-shot capture
2024-01-18T17:54:52 < Ecco> For some reason, it doesn't, work *below* a certain speed?
2024-01-18T17:54:58 < Ecco> That seems… dumb?
2024-01-18T17:55:15 < Ecco> If I zoom in on the horizontal scale, then I can do a single shot
2024-01-18T17:55:18 < Ecco> that's super weird
2024-01-18T17:55:40 < Ecco> oh, ok found it
2024-01-18T17:55:45 < Ecco> sortof
2024-01-18T17:55:52 < Ecco> it's because the waveform view was switching to "roll"
2024-01-18T18:24:47 -!- qyx [~qyx@84.245.120.64] has quit [Ping timeout: 252 seconds]
2024-01-18T18:25:20 -!- qyx [~qyx@84.245.121.79] has joined ##stm32
2024-01-18T18:25:44 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-18T18:33:48 -!- rob_w [~bob@2001:a61:6072:1f01:214:5405:9a71:cf1] has quit [Remote host closed the connection]
2024-01-18T18:46:43 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 276 seconds]
2024-01-18T18:48:34 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-18T18:53:54 < karlp> goddamn, RTT can suck one.  SWO just works for me so much more reliably.
2024-01-18T18:54:17 < karlp> (I think I was absolutely trashing the RTT buffer by trying to stream too muhc, but I'm blaming RTT, not myself)
2024-01-18T18:56:42 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-18T18:57:50 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-18T19:04:18 -!- CygniX [~CygniX@user/CygniX] has quit [Ping timeout: 260 seconds]
2024-01-18T19:07:45 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-18T19:07:56 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-18T19:13:44 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 252 seconds]
2024-01-18T19:18:34 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 264 seconds]
2024-01-18T19:20:47 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-18T19:22:53 < qyx> https://paste.jvnv.net/view/C3mdy
2024-01-18T19:23:08 < qyx> what the hell, I am really supposed to get 2gig of sh*t just to install kikecad?
2024-01-18T19:25:17 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 240 seconds]
2024-01-18T19:28:21 < Steffanx> Only 2
2024-01-18T19:30:05 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-18T19:30:49 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-18T19:36:11 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-dd58-345-fef2-2a61.fixed6.kpn.net] has joined ##stm32
2024-01-18T19:44:29 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has quit [Ping timeout: 240 seconds]
2024-01-18T19:54:58 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Quit: Client closed]
2024-01-18T19:55:52 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-18T20:00:50 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 268 seconds]
2024-01-18T20:16:07 < Mangy_Dog> you can get the lite package without the symbols
2024-01-18T20:40:01 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-dd58-345-fef2-2a61.fixed6.kpn.net] has quit [Ping timeout: 260 seconds]
2024-01-18T20:44:32 < qyx> and I hope there is a converter for all my symbols/footprints
2024-01-18T20:45:13 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-18T20:46:05 < qyx> oh there is
2024-01-18T20:46:23 -!- MGF_Fabio [~MGF_Fabio@2a01:827:1a93:cf03:164b:4d13:99fd:27a1] has joined ##stm32
2024-01-18T20:50:47 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 268 seconds]
2024-01-18T20:50:57 < Ecco> qyx: you're migrating to KiCad ?
2024-01-18T20:55:28 < fenugrec> 2G might include 3d models, they are horribly inefficient
2024-01-18T20:55:36 < fenugrec> kicad + library here is ~ 500MB installed
2024-01-18T20:56:20 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-18T20:56:34 < fenugrec> you really need a flatshit package ? doesn't your distro have a native build
2024-01-18T20:57:05 < fenugrec> "org.freedesktop.Sdk 555MB" that's hardly kicad's fault...
2024-01-18T20:59:25 < qyx> no I am migrating from 5.1.x to 7.x, at leastI want
2024-01-18T20:59:33 < qyx> or better to 8.x-rc
2024-01-18T21:13:43 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has joined ##stm32
2024-01-18T21:32:12 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-dd58-345-fef2-2a61.fixed6.kpn.net] has joined ##stm32
2024-01-18T21:36:59 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-18T21:41:07 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Client Quit]
2024-01-18T21:43:53 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 252 seconds]
2024-01-18T21:51:35 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-18T21:55:37 -!- MGF_Fabio [~MGF_Fabio@2a01:827:1a93:cf03:164b:4d13:99fd:27a1] has quit [Ping timeout: 260 seconds]
2024-01-18T22:07:04 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 246 seconds]
2024-01-18T22:09:45 -!- pragmalin [~pragmalin@user/pragmalin] has joined ##stm32
2024-01-18T22:19:10 -!- qyx [~qyx@84.245.121.79] has quit [Ping timeout: 264 seconds]
2024-01-18T22:20:47 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-18T22:20:52 -!- qyx [~qyx@84.245.121.55] has joined ##stm32
2024-01-18T22:27:41 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-18T22:28:08 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-18T22:28:59 -!- qyx [~qyx@84.245.121.55] has quit [Ping timeout: 252 seconds]
2024-01-18T22:30:38 -!- qyx [~qyx@84.245.120.74] has joined ##stm32
2024-01-18T22:36:08 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 252 seconds]
2024-01-18T22:46:47 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-18T22:58:41 -!- qyx [~qyx@84.245.120.74] has quit [Ping timeout: 252 seconds]
2024-01-18T23:00:43 -!- qyx [~qyx@84.245.121.64] has joined ##stm32
2024-01-18T23:05:18 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-18T23:14:59 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 256 seconds]
2024-01-18T23:21:50 -!- pragmalin [~pragmalin@user/pragmalin] has quit [Quit: Leaving]
2024-01-18T23:26:34 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-18T23:34:37 -!- qyx [~qyx@84.245.121.64] has quit [Ping timeout: 264 seconds]
2024-01-18T23:35:01 -!- qyx [~qyx@84.245.121.87] has joined ##stm32
--- Day changed pe tammi 19 2024
2024-01-19T00:02:00 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-19T00:06:34 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 264 seconds]
2024-01-19T00:19:41 -!- Thorn [~Thorn@2001:8a0:dfe1:a200:49b4:7bb4:f15e:9a0d] has joined ##stm32
2024-01-19T00:19:41 -!- Thorn [~Thorn@2001:8a0:dfe1:a200:49b4:7bb4:f15e:9a0d] has quit [Changing host]
2024-01-19T00:19:41 -!- Thorn [~Thorn@user/thorn] has joined ##stm32
2024-01-19T00:50:22 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-19T00:54:43 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 246 seconds]
2024-01-19T01:01:07 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-dd58-345-fef2-2a61.fixed6.kpn.net] has quit [Ping timeout: 276 seconds]
2024-01-19T01:06:25 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 264 seconds]
2024-01-19T01:19:46 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has quit [Ping timeout: 264 seconds]
2024-01-19T01:23:47 -!- dobson [~dobson@static.38.6.217.95.clients.your-server.de] has quit [Quit: Leaving]
2024-01-19T01:26:31 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-19T01:27:28 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-19T01:36:47 -!- dobson [~dobson@static.38.6.217.95.clients.your-server.de] has joined ##stm32
2024-01-19T01:37:04 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 255 seconds]
2024-01-19T01:44:45 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-19T01:48:58 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 246 seconds]
2024-01-19T01:59:42 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-dd58-345-fef2-2a61.fixed6.kpn.net] has joined ##stm32
2024-01-19T02:00:55 -!- nuxil_ [~nuxil@141.195.51.41] has joined ##stm32
2024-01-19T02:01:52 -!- skz81_ [~skz81@vps-68d3ea17.vps.ovh.net] has joined ##stm32
2024-01-19T02:05:17 -!- Ecco_ [~user@user/Ecco] has joined ##stm32
2024-01-19T02:07:37 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-dd58-345-fef2-2a61.fixed6.kpn.net] has quit [Ping timeout: 264 seconds]
2024-01-19T02:07:44 -!- karlp1 [karlp@palmtreev6.beeroclock.net] has joined ##stm32
2024-01-19T02:09:49 -!- Netsplit *.net <-> *.split quits: jmcgnh, Ecco, nuxil, skz81, karlp
2024-01-19T02:12:17 -!- jmcgnh [~jmcgnh@wikipedia/jmcgnh] has joined ##stm32
2024-01-19T02:18:58 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-19T02:34:11 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-19T02:36:32 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-19T02:36:38 < Laurenceb_> >emdrive in orbit test is ""delayed""
2024-01-19T02:36:42 < Laurenceb_> imagine my shock
2024-01-19T02:37:20 < jbo> moin
2024-01-19T02:37:28 < jbo> holyshit Laurenceb_ talking about emdrive
2024-01-19T02:37:33 < jbo> I get 2009 vibes <3
2024-01-19T02:38:35 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 268 seconds]
2024-01-19T02:42:18 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Quit: Client closed]
2024-01-19T02:45:07 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-19T02:54:43 < specing> lol
2024-01-19T03:10:05 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-19T03:23:57 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-19T03:28:13 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 255 seconds]
2024-01-19T03:55:44 -!- nuxil_ is now known as nuxil
2024-01-19T04:12:58 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-19T04:17:01 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 246 seconds]
2024-01-19T05:02:33 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-19T05:06:29 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 240 seconds]
2024-01-19T05:10:00 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
2024-01-19T05:51:00 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-19T05:55:17 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 240 seconds]
2024-01-19T06:38:34 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-19T06:42:37 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 246 seconds]
2024-01-19T07:21:07 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-19T07:25:35 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 256 seconds]
2024-01-19T07:42:51 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Remote host closed the connection]
2024-01-19T08:06:19 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-19T08:09:15 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-19T08:14:03 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 268 seconds]
2024-01-19T08:31:04 -!- Thorn_ [~Thorn@2001:8a0:dfe1:a200:6415:2cb2:9200:20cb] has joined ##stm32
2024-01-19T08:32:09 -!- Thorn [~Thorn@user/thorn] has quit [Ping timeout: 260 seconds]
2024-01-19T08:45:25 -!- Spirit532 [~Spirit532@user/Spirit532] has quit [Quit: Ping timeout (120 seconds)]
2024-01-19T08:45:49 -!- Spirit532 [~Spirit532@user/Spirit532] has joined ##stm32
2024-01-19T08:57:27 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has joined ##stm32
2024-01-19T08:58:38 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-19T09:00:35 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-19T09:03:25 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 276 seconds]
2024-01-19T09:16:10 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-19T09:24:48 -!- PlasmaHH [~PlasmaHH@user/plasmahh] has quit []
2024-01-19T09:29:39 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2024-01-19T10:03:41 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-19T10:04:02 -!- MGF_Fabio [~MGF_Fabio@93-58-79-20.ip157.fastwebnet.it] has joined ##stm32
2024-01-19T10:17:40 -!- Thorn_ [~Thorn@2001:8a0:dfe1:a200:6415:2cb2:9200:20cb] has quit [Quit: Easy as 3.14159265358979323846...]
2024-01-19T10:19:14 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 268 seconds]
2024-01-19T10:27:09 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-19T10:44:57 < Steffanx> Didn't you know laurenceb is stuck in a time loop, jbo?
2024-01-19T10:45:45 < Steffanx> Emdrive worked, it defied physics. It messed up his world.
2024-01-19T10:46:40 < jpa-> i thought lb was stuck in hyperloop, which messed up his brains but there wasn't much to lose
2024-01-19T11:03:58 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-19T11:08:50 < karlp1> kinda https://www.youtube.com/watch?v=Wb-qwFGnvyY
2024-01-19T11:13:07 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-19T11:13:40 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-19T11:43:37 -!- HelloShi1ty [~user@bl22-255-167.dsl.telepac.pt] has quit [Quit: leaving]
2024-01-19T11:51:46 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 276 seconds]
2024-01-19T11:54:12 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-19T12:22:46 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2024-01-19T12:47:01 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 276 seconds]
2024-01-19T12:50:36 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-19T12:54:52 < jbo> heh
2024-01-19T12:57:51 < jpa-> https://jpa.kapsi.fi/stuff/other/stm32_bootloader_crystal_start.html   hmm, i seem to have some kind of crystal startup issue that only occurs in bootloader
2024-01-19T12:59:09 < jbo> is that jupyter?
2024-01-19T13:01:40 < jbo> jpa-, osc hardware would be pretty much agnostic to bootloader/normal mode, no?
2024-01-19T13:05:06 < jpa-> one would think so
2024-01-19T13:06:16 < jpa-> looks like it starts if i give a tiny bit of external assistance (8 MHz through 10x scope probe)
2024-01-19T13:08:06 < jbo> did you get crap quality parts? :D
2024-01-19T13:08:53 < jbo> or something stupid like SMPS not being "ready" yet on power-on?
2024-01-19T13:09:23 < jbo> when you have the oscillator running, then leave the board "running" (including firmware), turn the oscillator of, wait, then turn it back on - same result?
2024-01-19T13:13:32 < zyp> jpa-, I love all the weird issues you run into
2024-01-19T13:14:02 < jpa-> jbo: haven't done that test exactly, but restarting firmware from debugger when VDD stays on works fine
2024-01-19T13:14:41 < jbo> I guess that's what I would be doing right after quadruple-checking that the loading caps are the right ones on the PCB
2024-01-19T13:14:47 < zyp> how about resetting into bootloader?
2024-01-19T13:15:09 < jpa-> zyp: doesn't work
2024-01-19T13:16:23 < jpa-> I tried the crystal safety factor test from AN2867 on a working board, it works with 1kohm series so safety factor > 7
2024-01-19T13:17:09 < zyp> IIRC bootloader does some autodetect magic to work regardless of crystal freq, but that shouldn't really make a difference, that's just a matter of comparing HSE to HSI after it's started
2024-01-19T13:18:36 < jpa-> yeah, i also think that should affect it before oscillator starts
2024-01-19T13:18:45 < jpa-> *shouldn't
2024-01-19T13:25:02 < jpa-> hmm... STM32F103 specs oscillator transconductance of 25 mA/V, while STM32F417 specs just 5 mA/V and says Gm max for crystal is 1 mA/V.. and my calculated value is at 0.96 mA/V
2024-01-19T13:25:46 < jpa-> and 0.5 mA/V with the 15 pF caps when it works
2024-01-19T13:28:07 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-19T13:29:07 < jpa-> so looks like a 18 pF load capacitance 8 MHz crystal is not a good choice for STM32F4
2024-01-19T13:42:55 < jpa-> hmm, 20 pF caps don't work either, which should be well within Gm limits (0.7 mA/V); also changed the crystal to another one of the same model, no difference
2024-01-19T13:48:25 -!- MGF_Fabio [~MGF_Fabio@93-58-79-20.ip157.fastwebnet.it] has quit [Ping timeout: 264 seconds]
2024-01-19T13:50:09 < karlp1> hrm, freertos11 has SMP support, so esp32 can one day drop their fork.... :)
2024-01-19T13:50:15 < karlp1> I'd better not hold my breath though.
2024-01-19T13:50:54 < karlp1> example docs explicitly talk about the use case of networking on one core and application on another
2024-01-19T13:52:55 -!- quinor [08c0f10716@2a03:6000:1812:100::dad] has quit [Ping timeout: 268 seconds]
2024-01-19T13:53:02 -!- quinor [08c0f10716@2a03:6000:1812:100::dad] has joined ##stm32
2024-01-19T13:53:08 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-19T13:53:41 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-19T13:54:09 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-19T13:54:55 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-19T13:57:19 -!- quinor [08c0f10716@2a03:6000:1812:100::dad] has quit [Ping timeout: 255 seconds]
2024-01-19T13:59:17 -!- quinor [08c0f10716@2a03:6000:1812:100::dad] has joined ##stm32
2024-01-19T14:00:07 < jpa-> huh.. the working boards with revision 2 device have bootloader version 9.1, while the not-working board with revision 4 has 3.1
2024-01-19T14:00:22 < karlp1> wut
2024-01-19T14:01:57 < jpa-> the revision 2 parts also have date code week 11 of 2023, while the revision 4 part has date code week 4 of 2021
2024-01-19T14:02:37 < zyp> are they both the same variant otherwise?
2024-01-19T14:04:59 < jpa-> https://jpa.kapsi.fi/stuff/pix/stm32rev.png  yeah
2024-01-19T14:06:51 < jpa-> V9.1 change notes says "DFU interface robustness enhancement."
2024-01-19T14:11:46 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-19T14:12:18 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-19T14:16:11 < jpa-> heh, from AN2606: V3.1 bootloader has HSE timeout of 0.79 ms, while V9.1 has 96 ms
2024-01-19T14:17:17 < karlp1> that seeems.... needlessly short.
2024-01-19T14:38:54 < jpa-> https://jpa.kapsi.fi/stuff/other/stm32_bootloader_crystal_start.html    (updated)    so yeah, that is it
2024-01-19T14:39:03 < jpa-> larger caps push the startup time just beyond the limit
2024-01-19T15:16:08 < karlp1> taht startup time seems like an error sort of short...
2024-01-19T15:16:18 < karlp1> I'm still not sure why newer revs are older though...
2024-01-19T15:16:48 < karlp1> they just kept making old revs at a different plant?
2024-01-19T15:18:04 < karlp1> I'm impressed at you having the tmie to dig that far into it.
2024-01-19T15:18:06 < karlp1> well done.
2024-01-19T15:20:02 < jpa-> it would have bit my butt badly if i hadn't, because the customer uses the DFU for initial programming in manufacturing
2024-01-19T15:21:16 < jpa-> now i can just switch to a 8 pF crystal and be reasonably confident that it will work
2024-01-19T15:32:51 < zyp> another reason trusting the internal bootloader is not necessarily a good idea then
2024-01-19T15:33:47 < karlp1> oh shush.
2024-01-19T15:34:06  * karlp1 adds recursive semaphores to fix things.
2024-01-19T15:34:15 < karlp1> I'm not ... 100% sure this is the right idea...
2024-01-19T15:34:57 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 260 seconds]
2024-01-19T15:35:07 < ventYl> signs are strong
2024-01-19T15:36:45 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:583e:cda3:9382:e803] has joined ##stm32
2024-01-19T15:36:50 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-19T15:38:46 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-19T15:40:00 < jpa-> zyp: kind-of yeah, but on the other hand my custom-made bootloaders haven't always been entirely reliable either
2024-01-19T15:40:23 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 260 seconds]
2024-01-19T15:41:06 < nomorekaki> https://www.youtube.com/watch?v=YW2nvdDpoyA intro music for coding sessions
2024-01-19T15:41:33 < nomorekaki> get the pumps going
2024-01-19T15:42:25 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 264 seconds]
2024-01-19T15:43:37 < nomorekaki> need to get pumps on with code before starting to configure builds
2024-01-19T15:45:32 < zyp> jpa-, no, but something you can fix > something you'll have to cope with
2024-01-19T15:48:00 < jpa-> zyp: fixing bootloaders on devices that have already shipped is a bit scary
2024-01-19T15:48:33 < zyp> yup, been there, done that
2024-01-19T15:48:50 < jpa-> and before shipping, even this problem can be fixed easy enough - and in fact it helped me discover the marginal oscillation condition of the selected xtal
2024-01-19T15:49:51 < jpa-> what i really don't like about ST is how it is always random what revision you get from distributors
2024-01-19T15:55:49 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-19T15:59:19 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-19T16:01:05 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 260 seconds]
2024-01-19T16:07:56 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Quit: Client closed]
2024-01-19T16:12:07 -!- machinehum [~machinehu@213.55.226.162] has joined ##stm32
2024-01-19T17:06:28 -!- machinehum [~machinehu@213.55.226.162] has quit [Ping timeout: 256 seconds]
2024-01-19T17:12:47 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-19T18:00:32 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-19T18:00:43 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-19T18:18:01 < karlp1> lol https://community.arm.com/support-forums/f/compilers-and-libraries-forum/54033/arm-gnu-toolchain-12-2-rel1-x86_64-arm-none-eabi-gives-error-unknown-type-name-caddr_t
2024-01-19T18:22:49 < zyp> first time I hear about caddr_t
2024-01-19T18:23:01 < zyp> and from I understand, anything using it needs to be fixed
2024-01-19T18:23:05 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-19T18:24:27 < karlp1> that's my feeeling yes.
2024-01-19T18:24:45 < karlp1> but it looks like this has been causing pain in various places for _years_ as toolcahins update and run over it.
2024-01-19T18:24:56 < karlp1> I've filed abug on nxp to fix it.
2024-01-19T18:25:02 < karlp1> I'd never heard of it either :)
2024-01-19T18:25:31 < ventYl> every day I learn new piece of something old and useless
2024-01-19T18:25:46 < ventYl> I wonder how something from BSD made its way into embedded bare metal toolchain
2024-01-19T18:27:06 < qyx> welcome to strlcpy
2024-01-19T18:27:35 -!- c10ud [~c10ud@user/c10ud] has quit [Quit: Leaving]
2024-01-19T18:35:39 < karlp1> fucking openSDA jlink compiled in 2015.
2024-01-19T18:35:49 < karlp1> times out talking to openocd
2024-01-19T18:46:19 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has joined ##stm32
2024-01-19T18:47:03 < nuxil> why was caddr_t used in the 1st place. and has it not been replaced/superseded by void* since like forever. is it even in the posix standard
2024-01-19T18:47:19 < nuxil> ?
2024-01-19T18:47:45 < qyx> whoever cares about posix
2024-01-19T18:47:53 < nuxil> lol
2024-01-19T18:48:34 < nuxil> not nxp :p
2024-01-19T18:50:03 < karlp1> well, definitely not nxp, this is freescale code, so this is texans, thinking big...
2024-01-19T18:50:27 < karlp1> _probably_ stuff freescale had been carrying internally from moto since forever I'd guess
2024-01-19T19:03:24 < qyx> so, lawyer pros, what exact problems do we have with gplv2?
2024-01-19T19:04:08 < qyx> for framework and libraries
2024-01-19T19:05:07 < jpa-> qyx: evil company can take gplv2 code and use signed firmware upgrades or apply patents to restrict users
2024-01-19T19:05:26 < PaulFertser> see "tivoization"
2024-01-19T19:05:29 < nuxil> if they modified the code they need to share it.
2024-01-19T19:05:36 < nuxil> tivozation is a gplv3 thing
2024-01-19T19:05:39 < PaulFertser> nuxil: that's not a problem
2024-01-19T19:05:49 < PaulFertser> nuxil: no, tivoization is a thing that GPLv3 prevents
2024-01-19T19:06:33 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 256 seconds]
2024-01-19T19:06:43 < jpa-> of course if we wear the other hat, gplv2 and gplv3 have the problem that they are not welcomed by commercial customers
2024-01-19T19:07:17 < PaulFertser> And that's a problem too, see how locm3 struggled with commercial adoption even though it's _l_gpl :(
2024-01-19T19:11:42 < qyx> jpa-: is thatba problem? I know that part, I don't see it problematic
2024-01-19T19:12:41 < ventYl> dual licensing could deal with it
2024-01-19T19:12:58 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
2024-01-19T19:13:00 < ventYl> have paranoid legal department? your money are welcome here!
2024-01-19T19:13:19 < qyx> I mean, if they get the software, modify it, publish it, they are conforming
2024-01-19T19:13:48 < qyx> I don't really care if their hardware restricts usage of a software, that's their will
2024-01-19T19:14:12 < ventYl> the publish part is something they usually have problem with
2024-01-19T19:14:22 < nuxil> PaulFertser, yes. i stand corrected. i though gplv3 allowd tivoization. had to check the license :P
2024-01-19T19:14:37 < jpa-> qyx: yeah, i feel gpl2 is ok also, but some people feel like extra protection is needed
2024-01-19T19:14:57 < jpa-> though i wouldn't recommend gpl2-only on any new project, there is nothing to lose by making it gpl2+
2024-01-19T19:15:15 < qyx> I plan to tivo my hardware too, and I guess some gov bodies require you too
2024-01-19T19:15:26 < ventYl> isn't possibility of upgrade to higher GPL built into the license?
2024-01-19T19:15:27 < qyx> *require it too
2024-01-19T19:15:37 < jpa-> ventYl: no
2024-01-19T19:15:47 < qyx> yes by default
2024-01-19T19:15:54 < qyx> with the current wording
2024-01-19T19:16:02 < qyx> but it was not the case in the past
2024-01-19T19:16:11 < jpa-> qyx: ? i think it is only in the copyright declaration, not in the license
2024-01-19T19:16:17 < PaulFertser> No, only if you mention it yourself (version 2 or any later version)
2024-01-19T19:16:35 < qyx> yes thats what I am saying
2024-01-19T19:17:01 < qyx> the default recommended statement of gplv2 includes that wording "at your option, any later"
2024-01-19T19:17:24 < qyx> so if you copypaste that as recommended, it is "allowed by default"
2024-01-19T19:17:30 < qyx> you can delete it of course
2024-01-19T19:17:47 < jpa-> yeah
2024-01-19T19:18:25 < ventYl> FWIW the least hated license is MPL
2024-01-19T19:18:40 < ventYl> or maybe it is a combination of the license and software released under this license
2024-01-19T19:18:44 < qyx> so we have tivo, unwished upgrades
2024-01-19T19:19:08 < qyx> what's the exact problem with commercialisation?
2024-01-19T19:19:15 < qyx> static linking and derived works?
2024-01-19T19:19:44 < jpa-> fear of derived works, because no-one knows when GPL makes something else "derivative"
2024-01-19T19:20:02 < jpa-> if you don't care, might as well use MIT/BSD/zlib
2024-01-19T19:20:42 < qyx> so a clarification like "loadable modules are exempt and they are not considered a derived work" may help?
2024-01-19T19:21:00 < ventYl> that's what LGPL does
2024-01-19T19:21:03 < ventYl> kind of
2024-01-19T19:21:29 < jpa-> if that is only thing you want to allow and if it is important for you to forbid other ways to combine works
2024-01-19T19:22:14 < qyx> the important part for me is to keep the core part gpl-invasive
2024-01-19T19:22:29 < qyx> to not be able eg. to create a driver without pushing the chamges back
2024-01-19T19:22:38 < ventYl> MPL
2024-01-19T19:23:01 < qyx> but on he other hand, to give the manufacturer the possibility to create their own application, which could be closed sores
2024-01-19T19:23:03 < jpa-> qyx: why couldn't you create a driver and put important pieces of it into a loadable module?
2024-01-19T19:23:10 < jpa-> like what e.g. nvidia does?
2024-01-19T19:23:24 < ventYl> as I understand it, changes to the core itself or its enhancements are covered. whatever you write on top of its API is meh
2024-01-19T19:24:12 < qyx> jpa-: hm
2024-01-19T19:26:34 < qyx> that's really bad
2024-01-19T19:26:42 < qyx> ventYl: I'll check mpl too
2024-01-19T19:27:00 < jpa-> under MPL, writing proprietary drivers would be entirely allowed, as long as you put them into new files
2024-01-19T19:27:08 < ventYl> qyx: there is some OSS license helper web out there. it has a questionaire and spits out most-fitting license
2024-01-19T19:27:28 < PaulFertser> nvidia gpu driver is kind of grey zone, and Linus said he's ok with it because the driver is really multi-platform and not really derived from Linux by not having anything essential Linux-specific.
2024-01-19T19:28:41 < qyx> yeah I don't like the file idea
2024-01-19T19:30:24 < qyx> so we are still in the "if you do something new, it is hard to make you release it publicly"
2024-01-19T19:30:24 < PaulFertser> Some kind of protection from patents is supposed to be mandatory these days, so when GPLv3 is inappropriate and you have to use GPLv2 usually some additional mechanisms are added to provide protection from patents.
2024-01-19T19:30:54 < qyx> and it is somehow clear that if you modify anything existing, gpl/mpl/whatever applies
2024-01-19T19:31:21 < qyx> PaulFertser: hm I though gplv2 already has that
2024-01-19T19:31:41 < PaulFertser> qyx: no, GPLv2 has nothing about patents, it's purely Copyright-based.
2024-01-19T19:31:45 < jpa-> GPL is relatively effective at making you release everything new, as long as you don't add any exceptions
2024-01-19T19:32:06 < jpa-> but it is also very effective at pushing away commercial users
2024-01-19T19:32:14 < qyx> they are saying it has
2024-01-19T19:32:48 < PaulFertser> Who they?
2024-01-19T19:33:22 < qyx> PaulFertser: fsf, clause 7
2024-01-19T19:33:24 < qyx> also preamble
2024-01-19T19:33:30 < jpa-> https://wiki.endsoftwarepatents.org/wiki/GNU_General_Public_License_Version_2
2024-01-19T19:34:20 < jpa-> so, not quite as explicit as GPL3 but can be interpreted to give some patent permissions
2024-01-19T19:34:37 < PaulFertser> OK, I was inaccurate indeed
2024-01-19T19:34:50 < qyx> so if I plan to do a business with the software but also to gain some opensource community
2024-01-19T19:35:01 < PaulFertser> GPLv3 also adds patent retalliation which can be useful at preventing patent abuse.
2024-01-19T19:35:11 < qyx> and to push away others, gpl can still be fine
2024-01-19T19:35:19 < PaulFertser> And is explicit about patent grants etc
2024-01-19T19:35:41 < PaulFertser> qyx: what do you have against GPLv3 anyway?
2024-01-19T19:35:51 < jpa-> GPL + CLA can work, if you only want hobbyist contributors
2024-01-19T19:35:54 < qyx> I plan to tivoize myself
2024-01-19T19:35:56 < qyx> PaulFertser: ^
2024-01-19T19:36:08 < PaulFertser> qyx: no tivoization is bad
2024-01-19T19:36:28 < qyx> it is required because I do hardware where I am required to guarantee the results
2024-01-19T19:36:33 < jpa-> with GPL + CLA you can also leave open the option to sell commercial licenses, like chibios does
2024-01-19T19:36:36 < qyx> also they are chedked by calibration labs
2024-01-19T19:36:51 < qyx> so I am refusing any modified core software on my own hardware
2024-01-19T19:37:02 < ventYl> jpa-: I was planning for MPL + CLA, I find GPL way too restrictive. and creepy RTOS has very fine boundaries and very little room for changes in RTOS itself
2024-01-19T19:37:17 < ventYl> s/fine/clear/
2024-01-19T19:37:19 < qyx> PaulFertser: I can allow loadable plugins in sandboxes or scripts, but that's all
2024-01-19T19:37:51 < jpa-> ventYl: why not just BSD/MIT then? are you planning to make a business out of it or something?
2024-01-19T19:38:33 < ventYl> jpa-: BSD/MIT allow to withdraw changes, MPL does not
2024-01-19T19:38:38 < PaulFertser> qyx: if hardware is sold then it's not yours anymore, you're not supposed to control what the end user runs on it.
2024-01-19T19:38:45 < ventYl> I just want to avoid "GPL cancer" effect
2024-01-19T19:38:49 < jpa-> ventYl: yeah, but why do you care?
2024-01-19T19:38:58 < jpa-> people will contribute if they want to
2024-01-19T19:39:13 < jpa-> if people don't want to contribute, you'll have some crappy zip with uncommented changes without version control
2024-01-19T19:40:00 < jpa-> CLA is usually major pain in the ass for commercial users, because you need to get the company lawyers involved and they will say no
2024-01-19T19:40:31 < jpa-> so if you are then going to go with easy circumventible license like MPL, it seems like a lot of work for little benefit
2024-01-19T19:40:33 < qyx> PaulFertser: that's not how it works, ask FCC
2024-01-19T19:41:14 < qyx> if I have a law obligations to do some things, whether the hardware is mine or others, I must adhere to some requirements
2024-01-19T19:41:26 < ventYl> jpa-: does CLA stand here for commercial license agreement?
2024-01-19T19:41:30 < PaulFertser> qyx: we have plenty of FCC-approve equipment which we can run essentially anything we want on.
2024-01-19T19:41:33 < fenugrec> just tivoize and "accidentally" leak docs via a china VPN
2024-01-19T19:41:55 < jpa-> ventYl: no, contributor license agreement
2024-01-19T19:42:03 < jpa-> https://en.wikipedia.org/wiki/Contributor_License_Agreement
2024-01-19T19:42:25 < ventYl> jpa-: OK, well, for such companies commercial license would do the job
2024-01-19T19:42:43 < ventYl> if their lawyers are paranoid, money don't stink
2024-01-19T19:42:59 < jpa-> yeah, if your work is really revolutionary and great
2024-01-19T19:43:03 < ventYl> creey RTOS is a microkernel, to there's very little room for changes anyway
2024-01-19T19:43:05 < jpa-> otherwise i would just pick a different RTOS
2024-01-19T19:43:41 < ventYl> it is kind of revolutionary, I am just not sure this kind of revolution would be accepted :) not even adopted
2024-01-19T19:43:50 < qyx> PaulFertser: no, I sell hardware to make money and i am deciding how it can be used because it is a part of the whole business, I am also paid for long term service, I am using my software on it, it is my willing to provide the software as an open source too for the comunity and for others who want to use it in a different way
2024-01-19T19:44:23 < PaulFertser> qyx: you can't be deciding how hardware is used after you sold it, that's just wrong
2024-01-19T19:44:55 < qyx> PaulFertser: if the customer wants to use the hardware with a modified software, they simply clear all crypto keys, that means they can load anything, their calibration is void, and the manufacturer do not guarantee correct measurement results
2024-01-19T19:45:09 < qyx> thats all
2024-01-19T19:45:27 < PaulFertser> qyx: ok, GPLv3 doesn't prevent that way I think
2024-01-19T19:45:42 < qyx> I can, that's part of my rma/servicing conditions
2024-01-19T19:45:59 < qyx> also the lab guarantees results only for some set of parameters, those are protected too
2024-01-19T19:46:04 < PaulFertser> You can refuse servicing devices that you didn't calibrate.
2024-01-19T19:46:06 < qyx> and cannot be modified
2024-01-19T19:46:44 < ventYl> jpa-: the whole commercial license thing is meant to work as: OK, you want this but MPL bothers your lawyers, get a commercial license and have a good sleep. I would expect that licensing would gain very little income anyway.
2024-01-19T19:47:15 < qyx> ventYl: as I understand it you can do that after you have agreement with all contributing developers
2024-01-19T19:47:35 < qyx> if you don't you can't sell their modifications/code
2024-01-19T19:47:42 < ventYl> qyx: that's what CLA is for
2024-01-19T19:47:45 < qyx> yes
2024-01-19T19:48:18 < ventYl> that's what I wanted to talk about with wendyi last year
2024-01-19T19:49:29 < qyx> hm ok so I need to read that tivo thing again then
2024-01-19T19:51:40 < qyx>  The usual motive for tivoization is that the software has features the manufacturer knows people will want to change, and aims to stop people from changing them
2024-01-19T19:51:43 < qyx> ok lol
2024-01-19T19:52:37 < ventYl> i wonder if this TV is tivoized properly, or developers were so flaky one can circumvent it
2024-01-19T19:52:40 < qyx> somehow I really hate that stallman-biased speech
2024-01-19T19:52:51 < jpa-> ventYl: so if it doesn't give income, why bother with it?
2024-01-19T19:52:57 < qyx> "digital restrictions management"
2024-01-19T19:53:00 < qyx> "dvd conspiracy"
2024-01-19T19:53:24 < jpa-> qyx: i think if you provide a way to clear crypto keys (even if it is permanent hardware change), that is still perfectly acceptable for gplv3
2024-01-19T19:54:05 < qyx> hm it is a single resistor desoldering
2024-01-19T19:55:51 < jpa-> seems reasonable to me
2024-01-19T19:55:58 < ventYl> jpa-: with creepy RTOS? originally it was an experiment if intended set of features can be implemented into microcontroller RTOS still yielding a usable environment
2024-01-19T19:56:29 < jpa-> ventYl: so why not just BSD/MIT? then you have some real change of getting users, instead of it being just one man show
2024-01-19T19:56:32 < jpa-> *chance
2024-01-19T19:56:32 < ventYl> jpa-: it turned it can. I learned a LOT while doing it. and it still has potential for more learning. and maybe it will be adopted one day?
2024-01-19T19:57:11 < ventYl> jpa-: yeah, maybe you are right
2024-01-19T19:59:47 < ventYl> hm, MIT ceases need of CLA
2024-01-19T20:04:43 < qyx> jpa-: I also have another idea, how did you forced garmin showing the nanopb lic?
2024-01-19T20:06:18 < qyx> oh zlib
2024-01-19T20:28:51 -!- qyx [~qyx@84.245.121.87] has quit [Ping timeout: 256 seconds]
2024-01-19T20:30:25 -!- qyx [~qyx@84.245.120.142] has joined ##stm32
2024-01-19T20:59:49 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:583e:cda3:9382:e803] has quit [Ping timeout: 264 seconds]
2024-01-19T21:05:12 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-19T21:06:11 < jpa-> qyx: i didn't force anything, they did it out of free will
2024-01-19T21:06:36 < jpa-> (i actually chose zlib license just because it makes it explicit that it is entirely optional to mention the usage)
2024-01-19T21:29:17 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Quit: Client closed]
2024-01-19T21:42:08 < qyx> hm and bsd doesn't allow commercial licensing
2024-01-19T21:42:12 < qyx> but MIT does
2024-01-19T21:51:46 < Steffanx> You can use BSD in commercial closed sores just fine qyx  ... 
2024-01-19T21:52:22 < Steffanx> BSD-3-Clause-No-Nuclear-Warranty lol
2024-01-19T21:53:19 < qyx> they don't say I can sell bsd-licensed software
2024-01-19T22:03:43 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-ed94-cb94-b849-c0b3.fixed6.kpn.net] has joined ##stm32
2024-01-19T22:09:58 -!- machinehum [~machinehu@213.55.224.21] has joined ##stm32
2024-01-19T22:19:17 < qyx> Posterdati: checked those tivoizing conditions, apparently it is sufficient to provide a way to turn off the restriction and document it, it doesn't say the restriction is not allowed
2024-01-19T22:19:21 < qyx> sorry Posterdati 
2024-01-19T22:19:23 < qyx> PaulFertser: ^
2024-01-19T22:19:50 < Posterdati> ?
2024-01-19T22:20:03 < qyx> <tab> fail
2024-01-19T22:24:47 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-19T22:30:36 -!- machinehum [~machinehu@213.55.224.21] has quit [Ping timeout: 268 seconds]
2024-01-19T22:31:12 < nomorekaki> zyp: vscode has makefile extension
2024-01-19T22:31:48 < nomorekaki> immediatelly when I made makefile to my project example directory it said "hey install this extension"
2024-01-19T22:33:38 -!- machinehum [~machinehu@213.55.224.21] has joined ##stm32
2024-01-19T22:35:57 < nomorekaki> now quickly I need some project github to ape makefiles from
2024-01-19T22:36:54 < nomorekaki> let's find zyp's github
2024-01-19T22:37:53 < zyp> not sure you're gonna find any makefiles on my github
2024-01-19T22:38:15 < nomorekaki> already did
2024-01-19T22:38:29 < nomorekaki> hmm toplevel makefile
2024-01-19T22:39:34 < zyp> I've got like three repos on github that's not a fork of someone else's project and neither contains makefiles
2024-01-19T22:39:54 < nomorekaki> what is build_rules
2024-01-19T22:40:45 < zyp> that's the old scons stuff from laks v1
2024-01-19T22:41:26 < nomorekaki> I looked makefiles in blackmagic and that's way above my head
2024-01-19T22:42:26 < nomorekaki> I guess I need to sit and read makefiletutorial.com really slowly
2024-01-19T22:42:50 < zyp> I'd recommend not using makefiles
2024-01-19T22:42:59 < zyp> as in, use a modern replacement instead
2024-01-19T22:43:10 < nomorekaki> cmake?
2024-01-19T22:43:22 < zyp> no, I don't like cmake
2024-01-19T22:43:40 < zyp> I'd recommend meson for regular pc software
2024-01-19T22:43:56 < zyp> which to me feels like «cmake except with a sane design»
2024-01-19T22:44:10 < nomorekaki> literally first time hearing about meson
2024-01-19T22:44:32 < zyp> meson is nice
2024-01-19T22:44:36 < nomorekaki> how about cross compiling?
2024-01-19T22:45:15 < zyp> there's support for that, AIUI the blackmagic people are in the process of migrating to meson
2024-01-19T22:45:54 < zyp> but personally I like scons, since I do a ton of custom scripting in the laks build system
2024-01-19T22:46:49 < zyp> so my take on build systems is that I'd use meson if I want to do plain regular stuff, and scons if I want to do weird custom stuff
2024-01-19T22:47:53 < nomorekaki> good
2024-01-19T22:47:56 < nomorekaki> meson it is then
2024-01-19T22:48:30 < nomorekaki> what is "linting" ?
2024-01-19T22:48:42 < zyp> syntax cleanup
2024-01-19T22:48:44 < qyx> I wanted meson too but I don't know if my want is that strong
2024-01-19T22:51:00 < nomorekaki> I guess I need to install meson and ninja-build to my wsl:debian
2024-01-19T22:51:05 < zyp> I switched orbuculum from make to meson when the makefile stuff didn't know how to build a dynamic library on macos, and writing a meson.build seemed easier than fixing the makefile
2024-01-19T22:53:01 < nomorekaki> zyp: can you show any repos with meson in use?
2024-01-19T22:53:16 < zyp> https://github.com/orbcode/orbuculum
2024-01-19T22:55:21 < nomorekaki> very nice
2024-01-19T22:56:42 < zyp> like, if you're doing something common in a modern system, you just have to go «I need libx, liby, libz, here's my input files, build me an executable» and the build system handles the rest across different platforms
2024-01-19T22:57:16 < nomorekaki> I see
2024-01-19T22:57:21 < nomorekaki> it's beautiful
2024-01-19T22:57:26 -!- machinehum [~machinehu@213.55.224.21] has quit [Ping timeout: 268 seconds]
2024-01-19T22:57:27 < karlp1> ventYl: what do yuou mean by "allow to withdraw changes"?
2024-01-19T22:57:58 < nomorekaki> zyp: what is the syntax?
2024-01-19T22:58:09 < nomorekaki> their own syntax or something more common?
2024-01-19T22:58:15 < zyp> their own AFAIK
2024-01-19T22:59:52 < karlp1> qyx: with bsd, you just.... sell it, you don't need permission in the license... that's the whole point
2024-01-19T23:00:02 < ventYl> karlp1: ship binaries without disclosing source code
2024-01-19T23:00:08 < ventYl> or even relicense software
2024-01-19T23:00:41 -!- machinehum [~machinehu@213.55.224.21] has joined ##stm32
2024-01-19T23:01:00 < karlp1> I'm not sure I follow with MPL then?
2024-01-19T23:01:21 < karlp1> qyx: we have similar issues with calibrated scales at new job.
2024-01-19T23:01:43 < ventYl> if I understand it correctly, MPL forces you to publish changes to MPLed software but not to whatever you added around it
2024-01-19T23:01:53 < karlp1> their current procedure is a) closed source, b) extremely reluctant to make firmware updates and c) obscenely arcane procedures to do so.
2024-01-19T23:02:18 < karlp1> I hardly ever see MPL
2024-01-19T23:02:26 < karlp1> seems like it's trying to draw the lgpl line then?
2024-01-19T23:02:55 < karlp1> I want to go over the OIML r76 docs myself and make my own interpretation, 
2024-01-19T23:03:08 < karlp1> I want to make it easier for updates as long as they're "our" certified ones.
2024-01-19T23:03:38 < ventYl> MPL is kinda like LGPL but with slightly different conditions
2024-01-19T23:04:02 < ventYl> I guess MPL is even more permissive than LGPL on how you link MPLed component
2024-01-19T23:11:32 < qyx> karlp1: and that's sad and I don't see any feasible way to solve it
2024-01-19T23:11:51 < qyx> unless you outsource the whole measurement to a dedicated chip incl. timing
2024-01-19T23:11:56 < nomorekaki> zyp: can I make meson do multiple targets?
2024-01-19T23:12:06 < nomorekaki> just use different cross-file?
2024-01-19T23:12:13 < ventYl> probably
2024-01-19T23:12:18 < ventYl> I assume it works similarly to CMake
2024-01-19T23:12:41 -!- machinehum2 [~machinehu@213.55.224.21] has joined ##stm32
2024-01-19T23:13:10 -!- machinehum [~machinehu@213.55.224.21] has quit [Ping timeout: 264 seconds]
2024-01-19T23:19:02 < karlp1> qyx: yeah, I feel their pain, but I want to try and make it as good as we can, I'm sure it can be _better_ at least.
2024-01-19T23:19:24 < karlp1> I want to do a pseudo secure boot sort of thing, so it at least breaks teh "seals" if it's not one our released images
2024-01-19T23:19:57 < karlp1> these certification agencies are... special, apparently, far far worse than CE emi/safety stuff
2024-01-19T23:19:58 < PaulFertser> qyx: if you provide a way to turn off it's not really a restriction
2024-01-19T23:20:18 < qyx> this is an interesting read too https://fossa.com/blog/complying-gpl-v3s-user-product-clause/
2024-01-19T23:21:13 < qyx> karlp1: for CE you don't really need to do anything and ime nobody seriously bothers
2024-01-19T23:21:28 < qyx> unless asked of course and even then it depends on who asks
2024-01-19T23:22:10 < qyx> the worst thing that can happen here is that if you are running a device causing interference, you may be ordered to shut it down
2024-01-19T23:22:53 < qyx> of course selling devices in bulk is a bit different thing
2024-01-19T23:22:53 -!- machinehum2 [~machinehu@213.55.224.21] has quit [Ping timeout: 240 seconds]
2024-01-19T23:23:58 < Steffanx> Or when you design a vehicle to move around kids, which gets fucked up by some interference and it moves under a train.
2024-01-19T23:24:08 < Steffanx> True story 
2024-01-19T23:24:58 < qyx> how can it move under a train
2024-01-19T23:25:24 < qyx> was it a kid-to-train-automatic-seating-wobat?
2024-01-19T23:25:50 < nomorekaki> what is Steffanx talking about? automated trolley dilema?
2024-01-19T23:26:59 < Steffanx> It was supposed to stop for a train at the railroad crossing, it didn't.
2024-01-19T23:27:01 < qyx> controlled by the output of a sigma delta modulator fed with trolley wires
2024-01-19T23:27:12 < nomorekaki> I wonder if Steffanx is accused from manslaughter
2024-01-19T23:27:15 < nomorekaki> *for
2024-01-19T23:27:24 < qyx> wat
2024-01-19T23:27:35 < karlp1> qyx: I'm well aware of CE lax/ease
2024-01-19T23:27:59 < karlp1> this is the certified scales part, because they're used for .... MONEY 
2024-01-19T23:28:29 < qyx> for money and public good
2024-01-19T23:28:36 < Steffanx> Lol wasn't my doing, nomorekaki 
2024-01-19T23:28:55 < ventYl> Steffanx: was it fully featured car, or was it some other kind of moving device?
2024-01-19T23:28:57 < Steffanx> The company is bankrupt now.
2024-01-19T23:28:58 < nomorekaki> Steffanx: don't make machines that try to move kids across railroad
2024-01-19T23:29:34 < nomorekaki> damn
2024-01-19T23:29:47 < nomorekaki> bound to fail
2024-01-19T23:30:03 < Steffanx> This https://images0.persgroep.net/rcs/ctQKmZaBjG2B3gE6Y_SsG2zhIOo/diocontent/133461022/_fill/1507/900/?appId=21791a8992982cd8da851550a453bd7f&quality=0.9
2024-01-19T23:30:28 < nomorekaki> extended invamobile
2024-01-19T23:30:44 < qyx> Steffanx: no mechanical brakes?
2024-01-19T23:31:54 < qyx> that's actually more sad than karl's scales
2024-01-19T23:32:25 < nomorekaki> Steffanx: did that invamobile kill kids?
2024-01-19T23:32:41 < Steffanx> Yes nomorekaki 
2024-01-19T23:32:52 < nomorekaki> shieet
2024-01-19T23:33:26  * qyx adding a mechanical brake to his tractor
2024-01-19T23:34:09 < karlp1> qyx: from what I hear, we are one of the _few_ that offers certified scales (in the applicable markets) because of these reasons, and it's a serious thing they deal with.
2024-01-19T23:34:42 < karlp1> all the more reason for me to spend a few days reading the docs myself... :)
2024-01-19T23:35:03 < karlp1> but next week is fun usb host on kinetis project week, no certifiucation docs.
2024-01-19T23:35:17 < qyx> doing weekly sprints?
2024-01-19T23:35:43 < englishman> karl are you working in metrology nowÉ
2024-01-19T23:35:48 < englishman> ?
2024-01-19T23:37:15 < nomorekaki> qyx: drove silage mixer cart to wall one day. -30C and oil pump apparently pulled vacuum after getting the thing moving. didn't feel good when I inverted direction pedal and it kept going
2024-01-19T23:37:33 < Steffanx> I'm not sure about this model qyx. Some older model didn't have mechanical brakes. Some newer models had it, but they weren't strong enough 😮‍💨
2024-01-19T23:38:29 < nomorekaki> qyx: note if there is no fluid in hydraulic system the actuators actually start moving freely
2024-01-19T23:38:54 < nomorekaki> motors freewheeling etc.
2024-01-19T23:38:57 < PaulFertser> When I needed to cross a freight train I was never getting under, I just walked along the train until seeing a suitable car for hopping and I climbed it the normal way and exited on the other side. Never did https://www.axios.com/2023/04/28/norfolk-southern-rail-crossings-safety-risks-children
2024-01-19T23:39:02 < qyx> nomorekaki: yeah I am planning on using a proportional blocking valves to brake using hydromotors, apparently not that good idea
2024-01-19T23:39:27 < nomorekaki> best case it will creep
2024-01-19T23:39:38 < nomorekaki> worst case it will creep too fast down the hill to tree
2024-01-19T23:40:02 < qyx> have you seen those emergency digging stoppers?
2024-01-19T23:40:22 < nomorekaki> ? shovel brake?
2024-01-19T23:40:22 < qyx> pushing a steel bar into the ground after pressing the emergency anti-slip brake button?
2024-01-19T23:40:42 < nomorekaki> yes in sleds
2024-01-19T23:40:48 < nomorekaki> snow mobiles
2024-01-19T23:40:59 < ventYl> Steffanx: ah, I would never build such thing without V2X infrastructure in place
2024-01-19T23:41:00 < nomorekaki> "alppijarru"
2024-01-19T23:41:12 < ventYl> AD is damn hard
2024-01-19T23:41:28 < karlp1> englishman: yeah, scales and weighing modules at Marel.
2024-01-19T23:41:41 < karlp1> qyx: sprints lol.
2024-01-19T23:41:43 < englishman> cool
2024-01-19T23:41:52 < qyx> wat werent you in the energy distribution market?
2024-01-19T23:41:54 < karlp1> englishman: eh, sounds like englishman corp actually :)
2024-01-19T23:42:08 < englishman> yes very old and slow
2024-01-19T23:42:10 < karlp1> etactica closed it's doors man, laid me off.
2024-01-19T23:42:38 < englishman> and somehow growing every year despite awful uncompetitive products
2024-01-19T23:42:50 < karlp1> it is _wild_ how bad things are.
2024-01-19T23:43:01 < karlp1> but don't worry! we offer a 7 year guarantee that no-one else does.
2024-01-19T23:43:01 < qyx> karlp1: I know but for some reason I remember you were entering some big company in the same market
2024-01-19T23:43:08 < ventYl> it works because they are equally bad everywhere
2024-01-19T23:43:46 < karlp1> me and the other new guy discovered yesterday that they don't hve TVS diodes, or well, _any_ input protection on their can connectors, on any of the products.
2024-01-19T23:43:49 < englishman> he is probably still working as a pro irc ee
2024-01-19T23:43:52 < englishman> but different market
2024-01-19T23:43:56 < qyx> don't worry I remember the day you announced you are officially job free and sent ventYl the probably-last product
2024-01-19T23:44:05 < karlp1> but they _do_ have them on the pin headers for the developer uart....
2024-01-19T23:44:11 < englishman> hahaha
2024-01-19T23:44:33 < nomorekaki> qyx: https://www.brppac.fi/brp-860200716.html
2024-01-19T23:44:39 < ventYl> that powerbar still proudly sits on my desk
2024-01-19T23:44:48 < qyx> not installed yet?
2024-01-19T23:45:00 < karlp1> englishman: did you hear I found a prior developer had helpfulyl removed a volatile keyword from the cortex_cm4.h headers? :)
2024-01-19T23:45:16 < ventYl> I will be digging in main electronic box soon, so no hurry
2024-01-19T23:45:29 < ventYl> and no device to talk to it yet
2024-01-19T23:45:34 < englishman> just enough knowledge to be dangerous
2024-01-19T23:45:36 < englishman> reminds me of me
2024-01-19T23:45:49 < karlp1> qyx: oh, I did apply to Laki Power, I thought I would be a shoo-in for the job, but they didn't even reply.
2024-01-19T23:46:38 < karlp1> I got precisely one reply to all my job applications, so jsut  took it.
2024-01-19T23:47:17 -!- qyx_ [~qyx@84.245.120.219] has joined ##stm32
2024-01-19T23:47:28 < qyx_> I really hate the internet
2024-01-19T23:48:04 < nomorekaki> yes
2024-01-19T23:48:25 < nomorekaki> as in internet service?
2024-01-19T23:48:51 < qyx_> the interner should have been designed in a way to not fail
2024-01-19T23:49:14 < nomorekaki> you are LTE enjoyer?
2024-01-19T23:49:19 -!- qyx [~qyx@84.245.120.142] has quit [Ping timeout: 256 seconds]
2024-01-19T23:49:45 < nomorekaki> fellow LTE enjoyer*
2024-01-19T23:51:17 < qyx_> yeah
2024-01-19T23:51:33 < qyx_> the speed goes between 0.2 and 30 mbit/s
2024-01-19T23:52:11 < nomorekaki> have a pair of Iskra yagis
2024-01-19T23:52:41 < qyx_> yes I have a yagi, dual polarised
2024-01-19T23:52:56 < qyx_> but the network is probably congested by youtubez
2024-01-19T23:53:16 < nomorekaki> 5g availability?
2024-01-19T23:53:58 < qyx_> yes but no sane programs
2024-01-19T23:54:01 < qyx_> yet
2024-01-19T23:55:46 < nomorekaki> have you looked signal attributes carefully?
2024-01-19T23:56:07 < nomorekaki> if there is something wrong
2024-01-19T23:56:33 < qyx_> not that carefully, I just rotated the yagi until I found a cell with the best signal
2024-01-19T23:56:36 < qyx_> 3 years ago
2024-01-19T23:57:43 < nomorekaki> using the signal leds on the box?
2024-01-19T23:58:41 < qyx_> nope, some mikrotik interface lte lte0 info
2024-01-19T23:58:53 < nomorekaki> check again
2024-01-19T23:59:09 < qyx_> easier to say than to do
2024-01-19T23:59:19 < nomorekaki> have you locked the band?
2024-01-19T23:59:41 < nomorekaki> you need to block the band otherwise the modem starts doing stupid stuff
2024-01-19T23:59:44 < qyx_> the console is 2 clicks away and the antenna is outside and it is dark and the tooling is in the basement, you know
2024-01-19T23:59:46 < nomorekaki> *lock
--- Day changed la tammi 20 2024
2024-01-20T00:04:29 < nomorekaki> before locking band the box captured some 1800mhz carrier from way behind the station I wanted to use for 800mhz
2024-01-20T00:04:42 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-20T00:05:52 < nomorekaki> it favored some -93db signal over -53db
2024-01-20T00:08:35 < nomorekaki> qyx_: ping
2024-01-20T00:10:54 < qyx_> I'll check, uhm, idk
2024-01-20T00:10:59 < qyx_> tomorrow maybe
2024-01-20T00:12:22 < nomorekaki> if your internets speed starts with 0. then it's most likelly user error
2024-01-20T00:21:54 < Steffanx> It's never user error with mikrotik 
2024-01-20T00:22:44 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 252 seconds]
2024-01-20T00:23:51 < qyx_> it is, I reflashed it with openwrt
2024-01-20T00:25:25 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-20T00:30:17 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-20T00:34:08 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 256 seconds]
2024-01-20T01:12:03 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 256 seconds]
2024-01-20T01:53:39 < ds2> '
2024-01-20T01:56:29 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 240 seconds]
2024-01-20T02:19:19 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-ed94-cb94-b849-c0b3.fixed6.kpn.net] has quit [Ping timeout: 246 seconds]
2024-01-20T02:34:10 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-20T02:38:56 -!- nuxil [~nuxil@141.195.51.41] has quit [Read error: Connection reset by peer]
2024-01-20T02:39:01 -!- nuxil_ [~nuxil@141.195.51.41] has joined ##stm32
2024-01-20T03:11:42 -!- boB_K7IQ [~boB_K7IQ@184-98-66-243.phnx.qwest.net] has quit [Read error: Connection reset by peer]
2024-01-20T03:28:17 -!- CygniX [~CygniX@user/CygniX] has joined ##stm32
2024-01-20T03:30:07 -!- _nuxil_ [~nuxil@141.195.51.41] has joined ##stm32
2024-01-20T03:33:34 -!- nuxil_ [~nuxil@141.195.51.41] has quit [Ping timeout: 264 seconds]
2024-01-20T03:42:35 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-20T04:25:39 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-20T08:14:32 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-20T09:03:06 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-20T10:10:46 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Remote host closed the connection]
2024-01-20T10:32:26 -!- ferdna_ [~ferdna@user/ferdna] has joined ##stm32
2024-01-20T10:35:13 -!- ferdna [~ferdna@user/ferdna] has quit [Ping timeout: 264 seconds]
2024-01-20T10:52:02 -!- ferdna__ [~ferdna@user/ferdna] has joined ##stm32
2024-01-20T10:54:37 -!- ferdna_ [~ferdna@user/ferdna] has quit [Ping timeout: 268 seconds]
2024-01-20T11:19:33 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-ac74-a9f8-4805-9658.fixed6.kpn.net] has joined ##stm32
2024-01-20T11:23:41 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-ac74-a9f8-4805-9658.fixed6.kpn.net] has quit [Ping timeout: 240 seconds]
2024-01-20T11:23:54 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-e111-a5ec-a556-20aa.fixed6.kpn.net] has joined ##stm32
2024-01-20T11:25:19 < jpa-> qyx_: so, about leaf springs, do you think you'd have time to do it? if not, just say and i'll pay up to the filthy rich .be people
2024-01-20T12:24:26 -!- ferdna_ [~ferdna@user/ferdna] has joined ##stm32
2024-01-20T12:25:20 -!- ferdna_ [~ferdna@user/ferdna] has quit [Remote host closed the connection]
2024-01-20T12:27:25 -!- ferdna__ [~ferdna@user/ferdna] has quit [Ping timeout: 268 seconds]
2024-01-20T12:36:59 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:65c3:b751:364d:35b5] has joined ##stm32
2024-01-20T12:51:37 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-e111-a5ec-a556-20aa.fixed6.kpn.net] has quit [Read error: Connection reset by peer]
2024-01-20T13:02:09 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-20T13:16:17 < qyx_> jpa-: yeah, I'll order today
2024-01-20T13:16:35 < qyx_> just mail me the link again pls
2024-01-20T13:16:40 < qyx_> and how many
2024-01-20T14:05:39 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-20T14:12:34 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 276 seconds]
2024-01-20T14:14:34 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-20T14:19:39 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 268 seconds]
2024-01-20T14:22:56 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-20T14:25:06 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-20T14:26:00 -!- ferdna_ [~ferdna@user/ferdna] has joined ##stm32
2024-01-20T14:40:00 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 268 seconds]
2024-01-20T14:42:09 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-20T14:58:58 < nomorekaki> zyp: should I consider the examples as meson projects and the lib part not?
2024-01-20T15:05:31 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 260 seconds]
2024-01-20T15:13:55 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-20T16:22:02 < nomorekaki> https://paste.debian.net/hidden/f14dab1f/
2024-01-20T16:23:02 < nomorekaki> let's say I want to build bsduart locally hosted
2024-01-20T16:49:37 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 264 seconds]
2024-01-20T16:51:55 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-20T17:01:13 < nomorekaki> ERROR: No host machine compiler for '../../src/bsdtransceiver.c'
2024-01-20T17:03:15 < nomorekaki> https://paste.debian.net/hidden/f3b8738e/
2024-01-20T17:03:26 < nomorekaki> let's see if there is #meson
2024-01-20T17:06:39 < nomorekaki> #mesonbuild actually
2024-01-20T17:14:26 < ventYl> how can anyone say that CMake has awful syntax and meson does look better?
2024-01-20T17:15:09 < ventYl> nomorekaki: if you were on windows, i'd ask if you have compiler in your path
2024-01-20T17:15:34 < nomorekaki> not in windows
2024-01-20T17:25:53 < nomorekaki> https://paste.debian.net/hidden/7793f267/
2024-01-20T17:26:17 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 256 seconds]
2024-01-20T17:27:25 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-20T17:27:58 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-20T17:28:51 < ventYl> everything seems ok
2024-01-20T17:57:05 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 252 seconds]
2024-01-20T17:59:32 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-20T18:22:44 < nomorekaki> zyp: give n00b a push please
2024-01-20T18:22:52 -!- ferdna_ [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-20T18:26:21 < nomorekaki> ghosted
2024-01-20T18:26:56 < nomorekaki> it's saturday - maybe a pause from grind is allowed bbl>
2024-01-20T18:49:03 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 260 seconds]
2024-01-20T19:25:19 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-20T19:25:32 < Laurenceb_> anyone used CAN on stm32f1  ?
2024-01-20T19:25:48 < Laurenceb_> I'm using the stm32tarduino lib and it works but its being weird
2024-01-20T19:26:21 < Laurenceb_> enabling auto bus off recovery causes it to lock up in bus off state after a bus off condition, disabling auto recovery and it works fine
2024-01-20T19:26:41 < Laurenceb_> maybe hardware recovery is clashing with some sort of software recovery somewhere...
2024-01-20T19:41:47 -!- machinehum [~machinehu@213.55.226.62] has joined ##stm32
2024-01-20T19:56:33 -!- machinehum2 [~machinehu@213.55.225.105] has joined ##stm32
2024-01-20T19:56:40 -!- machinehum [~machinehu@213.55.226.62] has quit [Ping timeout: 268 seconds]
2024-01-20T20:13:03 -!- machinehum2 [~machinehu@213.55.225.105] has quit [Ping timeout: 260 seconds]
2024-01-20T20:15:35 -!- machinehum [~machinehu@213.55.225.105] has joined ##stm32
2024-01-20T20:24:33 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Quit: Client closed]
2024-01-20T20:31:30 -!- machinehum [~machinehu@213.55.225.105] has quit [Ping timeout: 268 seconds]
2024-01-20T20:40:39 < qyx_> yes it worked but 10y ago
2024-01-20T20:40:51 < qyx_> when f1 was current
2024-01-20T20:45:52 < jbo> going to use CAN-FD on G4 soon
2024-01-20T20:49:17 -!- machinehum [~machinehu@213.55.225.105] has joined ##stm32
2024-01-20T21:04:01 < Steffanx> Will you be alright jbo ?
2024-01-20T21:05:44 -!- machinehum [~machinehu@213.55.225.105] has quit [Ping timeout: 252 seconds]
2024-01-20T21:08:56 < jbo> dunno
2024-01-20T21:14:43 < Steffanx> Hm
2024-01-20T21:14:53 < Steffanx> Luckily there's always ##stm32 for moral support
2024-01-20T21:20:11 < jbo> indeed :)
2024-01-20T21:23:44 -!- machinehum [~machinehu@213.55.225.105] has joined ##stm32
2024-01-20T21:32:44 -!- dkc [~dkc@user/dkc] has joined ##stm32
2024-01-20T21:38:19 -!- machinehum [~machinehu@213.55.225.105] has quit [Ping timeout: 256 seconds]
2024-01-20T21:53:42 -!- qyx [~qyx@84.245.121.23] has joined ##stm32
2024-01-20T21:53:58 -!- qyx_ [~qyx@84.245.120.219] has quit [Ping timeout: 260 seconds]
2024-01-20T21:55:34 -!- machinehum [~machinehu@213.55.225.105] has joined ##stm32
2024-01-20T22:07:50 -!- machinehum [~machinehu@213.55.225.105] has quit [Ping timeout: 256 seconds]
2024-01-20T22:27:38 -!- machinehum [~machinehu@213.55.225.105] has joined ##stm32
2024-01-20T22:42:02 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-8c1a-d618-f3dd-789e.fixed6.kpn.net] has joined ##stm32
2024-01-20T22:50:59 -!- machinehum [~machinehu@213.55.225.105] has quit [Ping timeout: 264 seconds]
2024-01-20T22:58:20 -!- machinehum [~machinehu@213.55.225.105] has joined ##stm32
2024-01-20T23:07:01 -!- machinehum [~machinehu@213.55.225.105] has quit [Ping timeout: 264 seconds]
2024-01-20T23:21:45 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 260 seconds]
2024-01-20T23:24:44 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-8c1a-d618-f3dd-789e.fixed6.kpn.net] has quit [Read error: Connection reset by peer]
2024-01-20T23:25:01 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-8c1a-d618-f3dd-789e.fixed6.kpn.net] has joined ##stm32
--- Day changed su tammi 21 2024
2024-01-21T00:08:19 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-21T00:42:19 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 260 seconds]
2024-01-21T01:00:51 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-21T01:01:53 -!- Spirit532 [~Spirit532@user/Spirit532] has quit [Killed (NickServ (GHOST command used by Spirit5323))]
2024-01-21T01:01:58 -!- Spirit532 [~Spirit532@user/Spirit532] has joined ##stm32
2024-01-21T01:05:27 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Quit: Client closed]
2024-01-21T01:10:01 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 264 seconds]
2024-01-21T01:24:49 < fenugrec> fresh '95 beats  https://www.youtube.com/watch?v=d_Hw_UC314M
2024-01-21T01:24:54 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-8c1a-d618-f3dd-789e.fixed6.kpn.net] has quit [Ping timeout: 260 seconds]
2024-01-21T01:39:41 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-21T01:40:17 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-21T01:44:13 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 264 seconds]
2024-01-21T01:56:19 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has joined ##stm32
2024-01-21T02:01:16 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2024-01-21T02:43:10 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 264 seconds]
2024-01-21T03:26:07 -!- dkc [~dkc@user/dkc] has quit [Ping timeout: 260 seconds]
2024-01-21T05:11:00 -!- nomorekaki [~nomorekak@37-136-177-110.rev.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-21T05:32:55 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Remote host closed the connection]
2024-01-21T06:20:00 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-21T08:26:53 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-21T09:34:19 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-21T09:41:54 -!- ferdna [~ferdna@user/ferdna] has quit [Ping timeout: 260 seconds]
2024-01-21T10:03:55 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-21T10:28:05 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:65c3:b751:364d:35b5] has quit [Ping timeout: 240 seconds]
2024-01-21T10:38:34 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-f87d-829d-ca03-ecce.fixed6.kpn.net] has joined ##stm32
2024-01-21T11:46:26 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-21T11:59:11 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:fd84:32af:8619:b2f3] has joined ##stm32
2024-01-21T13:11:35 -!- flom84 [~flom84@user/flom84] has joined ##stm32
2024-01-21T13:13:28 -!- flom84 [~flom84@user/flom84] has quit [Remote host closed the connection]
2024-01-21T13:26:12 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-21T15:02:35 -!- pragmalin [~pragmalin@user/pragmalin] has joined ##stm32
2024-01-21T15:16:07 -!- pragmalin [~pragmalin@user/pragmalin] has quit [Quit: Leaving]
2024-01-21T15:41:23 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has joined ##stm32
2024-01-21T15:43:54 < nomorekaki> zyp:
2024-01-21T16:13:36 < Steffanx> nomorekaki:
2024-01-21T16:21:21 < nomorekaki> hello fren
2024-01-21T16:22:03 < zyp> sup?
2024-01-21T16:22:22 < zyp> karlp1, which calipers did you end up getting, and how do you like them?
2024-01-21T16:23:38 < zyp> my old shit seems to be broken, so I'm considering whether I should buy some cheap shit, or put a bit more money into it and get some nice mitutoyos or something
2024-01-21T16:25:26 < nomorekaki> zyp: im going with autotools
2024-01-21T16:29:07 < zyp> enjoy
2024-01-21T16:45:02 < Steffanx> What happened between yesterday and now that made you come to this decision mr nomorekaki ?
2024-01-21T16:55:04 < nomorekaki> documentation, support, examples, peer opinions
2024-01-21T16:56:20 < fenugrec> zyp get a proper one, will outlast you
2024-01-21T16:56:49 < fenugrec> I have starett and mitut's, bought used locally or on ebay
2024-01-21T17:00:38 -!- nomorekaki33 [~nomorekak@176-93-92-158.bb.dnainternet.fi] has joined ##stm32
2024-01-21T17:01:40 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-21T17:04:46 -!- nomorekaki33 is now known as nomorekaki
2024-01-21T17:19:53 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-21T17:22:37 < zyp> I'm considering gettin these: https://no.farnell.com/mitutoyo/500-184-30/digital-caliper-150mm-0-01mm/dp/2831718
2024-01-21T17:45:21 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-21T17:45:25 < fenugrec> I like my dial calipers for their lack of battery, but digital sure is nice
2024-01-21T17:46:20 < jpa-> i like my lidl calipers in that if parts i make turn out to be wrong side, i can just measure again and eventually it will match
2024-01-21T17:46:56 < fenugrec> heh
2024-01-21T17:47:12 < emeb_mac> I've got a couple different digital calipers. Readout is nice but it seems that I don't use them often enough and the batteries need replacing half the time I go to use them.
2024-01-21T17:47:47 < emeb_mac> Be nice if they had an actual mechanical switch.
2024-01-21T17:47:51 < jpa-> yeah, some calipers leak like crazy
2024-01-21T17:54:01 -!- flom84 [~flom84@user/flom84] has joined ##stm32
2024-01-21T18:19:37 < englishman> those primary cells leak after a couple years anyway
2024-01-21T18:30:39 -!- flom84 [~flom84@user/flom84] has quit [Ping timeout: 256 seconds]
2024-01-21T19:12:12 < jpa-> yeah, LR44 is pretty bad
2024-01-21T19:12:18 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-21T19:12:18 < jpa-> i don't understand why they don't put CR2032
2024-01-21T19:12:21 < Laurenceb_> https://news.slashdot.org/story/24/01/21/008219/hans-reiser-sends-a-letter-from-prison
2024-01-21T19:12:24 < Laurenceb_> lolwut
2024-01-21T19:12:30 < Laurenceb_> >Fredrick Brennan
2024-01-21T19:12:33 < Laurenceb_> double lol
2024-01-21T19:15:36 < Laurenceb_> >I thank Richard Stallman for his inspiration
2024-01-21T19:15:46 < Laurenceb_> 11.1kms^{-1}
2024-01-21T19:17:06 < jpa-> if they ever catch me and i end up in jail, i'll be sending letters to be published on ##stm32
2024-01-21T19:18:39 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 268 seconds]
2024-01-21T19:22:59 < Laurenceb_> lmao
2024-01-21T19:24:00 < jpa-> Laurenceb_: we won't publish your letters, though
2024-01-21T19:24:16 < jpa-> and it's not like anyone on 4chan would give you their address
2024-01-21T19:30:41 < Steffanx> Ill deny knowing you jpa- . 
2024-01-21T19:31:07 < jpa-> Steffanx: yes, it will give more credence when i blame it all on you
2024-01-21T19:49:34 < Steffanx> :(
2024-01-21T20:22:15 -!- pragmalin [~pragmalin@user/pragmalin] has joined ##stm32
2024-01-21T20:27:56 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Ping timeout: 250 seconds]
2024-01-21T20:47:00 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-21T20:52:23 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-f87d-829d-ca03-ecce.fixed6.kpn.net] has quit [Ping timeout: 259 seconds]
2024-01-21T21:14:05 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-f87d-829d-ca03-ecce.fixed6.kpn.net] has joined ##stm32
2024-01-21T21:19:55 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has joined ##stm32
2024-01-21T21:22:25 < nomorekaki> having ##stm32 by mail?
2024-01-21T21:22:52 < nomorekaki> sounds like a youtube video idea
2024-01-21T21:23:30 < nomorekaki> "I made automatic via mail bouncer to IRC from prison"
2024-01-21T21:28:24 < Steffanx> Pigeon mail nomorekaki 
2024-01-21T21:29:34 < nomorekaki> "This is how I received irc backlogs in microfilm and tar heroine in prison via prison pocket mail"
2024-01-21T21:38:51 < nomorekaki> where do you install(make) static libraries in embedded projects?
2024-01-21T21:39:42 < qyx> jpa-: fighting my bank now
2024-01-21T21:50:59 -!- pragmalin [~pragmalin@user/pragmalin] has quit [Quit: Leaving]
2024-01-21T21:52:05 < jpa-> qyx: if it gets into a big fight, i can also try to pay myself and ship to your address
2024-01-21T21:52:37 < jpa-> ah, or are you fighting how i can pay you?
2024-01-21T21:53:24 < nomorekaki> qyx: did you check your internets?
2024-01-21T21:53:41 -!- machinehum [~machinehu@213.55.225.115] has joined ##stm32
2024-01-21T21:55:04 < qyx> jpa-: all done
2024-01-21T21:55:21 < qyx> I had to do iban because they don't offer card pay
2024-01-21T21:55:44 < jpa-> nice, thanks :)
2024-01-21T21:55:47 < qyx> which means receiving 4 SMS's from my bank because of a broken 2FA
2024-01-21T21:55:54 < qyx> to send one payment
2024-01-21T21:55:58 < qyx> welcome to 2024
2024-01-21T21:56:05 < jpa-> oh, that is worse than my bank
2024-01-21T21:56:38 < jpa-> when year changed they decided to forget all the places i usually pay to, so now for each one i get 3x 2FA requests the first time i pay
2024-01-21T21:58:17 < qyx> yeah I lost all my "secure devices" too
2024-01-21T22:00:27 < qyx> now when I am being fluent with it I can order my CO2 regulator too
2024-01-21T22:06:10 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 276 seconds]
2024-01-21T22:08:15 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:fd84:32af:8619:b2f3] has quit [Ping timeout: 256 seconds]
2024-01-21T22:39:53 -!- machinehum [~machinehu@213.55.225.115] has quit [Ping timeout: 260 seconds]
2024-01-21T22:55:39 -!- machinehum [~machinehu@213.55.225.115] has joined ##stm32
2024-01-21T23:08:22 -!- machinehum [~machinehu@213.55.225.115] has quit [Ping timeout: 264 seconds]
2024-01-21T23:15:40 < karlp1> zyp: I chose to put it off a bit longer.
2024-01-21T23:16:07 < karlp1> have a basket on ali with two super cheap ones, and a Shahe one that is meant to be decent.  /me shrugs
2024-01-21T23:17:11 < karlp1> but yeah, as discuessed, the only cheap ones I've been considereing have been ones that use cr2032 batteries, lr44 ones can just fucking die. I'm tired of the leakage and having to keep the battery out of the tool
2024-01-21T23:17:57 < fenugrec> asimeto makes decent mid-range stuff IIRC. Less outrageous prices than mitut / starrett / B&S
2024-01-21T23:20:46 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-21T23:20:48 < zyp> karlp1, yeah, the battery is the issue with mine too
2024-01-21T23:21:07 < zyp> it's not turning on and I'm not sure why
2024-01-21T23:46:20 < qyx> I have lidl one and it is semi-good
2024-01-21T23:46:29 -!- machinehum [~machinehu@213.55.225.115] has joined ##stm32
2024-01-21T23:46:39 < qyx> I am using it regularly and I have changed the battery maybe twice
2024-01-21T23:46:47 < qyx> in uhm, 5 years or so
2024-01-21T23:47:20 < qyx> I don't like the buttons though
2024-01-21T23:47:24 < zyp> the mitutoyo datasheet said it'll come with a sr44 with an expected lifetime of five years
2024-01-21T23:47:49 < zyp> which is good enough for me if it's true
2024-01-21T23:48:15 < qyx> hm it looks like mine is either a weird lidl or not lidl at all
2024-01-21T23:49:48 < qyx> it has a neon green battery cover
2024-01-21T23:51:13 -!- machinehum [~machinehu@213.55.225.115] has quit [Ping timeout: 268 seconds]
2024-01-21T23:51:21 < qyx> also, is SR still a thing?
2024-01-21T23:51:38 < zyp> why wouldn't it be?
2024-01-21T23:51:57 < zyp> hmm, looks like my old calipers also specs SR44, maybe they don't like my LR44s
2024-01-21T23:53:07 < qyx> idk I haven't see them lately, LR44 all the way
2024-01-21T23:53:25 < zyp> I see both are available at my usual place
2024-01-21T23:56:48 < zyp> I think I'm just gonna get the mitutoyos, it'll get me free shipping from farnell and I have a couple other things I want that I've been waiting to tack onto an order anyway
--- Day changed ma tammi 22 2024
2024-01-22T00:18:35 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-22T00:28:08 < jadew> zyp, I have that exact caliper, it's exactly what you'd expect it to be.
2024-01-22T00:28:31 < zyp> i.e. worth it?
2024-01-22T00:28:42 < jadew> Absolutely, it's a tool you can actually trust.
2024-01-22T00:28:52 < zyp> great
2024-01-22T00:31:14 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8e90:b2e6:b779:d44e:6f58] has joined ##stm32
2024-01-22T00:32:40 < jadew> I wanted to get one for my dad too, but he keeps pissing me off around his birthday, so I don't.
2024-01-22T00:32:53 < zyp> haha
2024-01-22T00:35:54 -!- machinehum [~machinehu@213.55.225.115] has joined ##stm32
2024-01-22T00:37:55 < Steffanx> So gift it him when it's not his birthday, jadew :)
2024-01-22T00:39:30 < jadew> Good idea, maybe when we'll be back on good terms.
2024-01-22T00:40:08 -!- machinehum [~machinehu@213.55.225.115] has quit [Ping timeout: 252 seconds]
2024-01-22T00:51:47 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 260 seconds]
2024-01-22T01:05:45 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8e90:b2e6:b779:d44e:6f58] has quit [Ping timeout: 256 seconds]
2024-01-22T01:06:11 < Ecco_> ok, fun problem
2024-01-22T01:06:17 < Ecco_> I bought a WiFi bedside lamp
2024-01-22T01:06:25 < Ecco_> I'm writing a custom firmware using ESPHome
2024-01-22T01:06:37 < Ecco_> The lamp has a touch sensor
2024-01-22T01:06:51 < Ecco_> that is connected to an I2C IC
2024-01-22T01:07:05 < Ecco_> and the I2C IC speaks to the ESP8266 MCU
2024-01-22T01:07:13 < Ecco_> I wrote a driver for this IC (the protocol is dead simple)
2024-01-22T01:07:23 < Ecco_> problem: when the RGB LEDS are past a certain power
2024-01-22T01:07:40 < Ecco_> the touch sensor stops reporting touches (it sees no touch event)
2024-01-22T01:07:47 < Ecco_> but as soon as I lower the power to the RGB LEDs
2024-01-22T01:07:57 < Ecco_> the IC resumes reporting touch events correctly
2024-01-22T01:08:06 < Ecco_> thats… super weird
2024-01-22T01:08:13 < Ecco_> do you guys have any idea what might be going on?
2024-01-22T01:08:42 < jadew> brown out detect?
2024-01-22T01:10:10 < jadew> Time to put it on the scope.
2024-01-22T01:11:20 < Ecco_> Well, I guess
2024-01-22T01:11:31 < Ecco_> Oh, so would that mean my USB power is too weak?
2024-01-22T01:11:42 < Ecco_> Let me try with a different USB PSU
2024-01-22T01:11:43 < Ecco_> that's smart
2024-01-22T01:14:05 -!- machinehum [~machinehu@213.55.225.115] has joined ##stm32
2024-01-22T01:15:13 < Ecco_> Damn jadew you're good
2024-01-22T01:15:23 < Ecco_> Switched to a beefier USB port, problem gone!
2024-01-22T01:15:45 < jadew> Heh, lucky guess. Glad it worked.
2024-01-22T01:18:33 -!- machinehum [~machinehu@213.55.225.115] has quit [Ping timeout: 260 seconds]
2024-01-22T01:18:46 < jadew> You might want to confirm that tho.
2024-01-22T01:23:31 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2024-01-22T01:47:41 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-f87d-829d-ca03-ecce.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-22T02:04:03 -!- machinehum [~machinehu@213.55.225.115] has joined ##stm32
2024-01-22T02:08:26 -!- machinehum [~machinehu@213.55.225.115] has quit [Ping timeout: 268 seconds]
2024-01-22T02:56:16 -!- machinehum [~machinehu@213.55.225.115] has joined ##stm32
2024-01-22T03:01:01 -!- machinehum [~machinehu@213.55.225.115] has quit [Ping timeout: 264 seconds]
2024-01-22T03:47:26 -!- machinehum [~machinehu@213.55.225.115] has joined ##stm32
2024-01-22T03:51:55 -!- machinehum [~machinehu@213.55.225.115] has quit [Ping timeout: 260 seconds]
2024-01-22T04:34:17 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Remote host closed the connection]
2024-01-22T04:38:51 -!- machinehum [~machinehu@213.55.225.115] has joined ##stm32
2024-01-22T04:43:50 -!- machinehum [~machinehu@213.55.225.115] has quit [Ping timeout: 268 seconds]
2024-01-22T05:28:35 -!- machinehum [~machinehu@213.55.225.115] has joined ##stm32
2024-01-22T05:33:08 -!- machinehum [~machinehu@213.55.225.115] has quit [Ping timeout: 256 seconds]
2024-01-22T06:17:30 -!- machinehum [~machinehu@213.55.225.115] has joined ##stm32
2024-01-22T06:21:41 -!- machinehum [~machinehu@213.55.225.115] has quit [Ping timeout: 252 seconds]
2024-01-22T07:03:01 -!- machinehum [~machinehu@213.55.225.115] has joined ##stm32
2024-01-22T07:07:20 -!- machinehum [~machinehu@213.55.225.115] has quit [Ping timeout: 252 seconds]
2024-01-22T07:33:44 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-22T07:53:42 -!- machinehum [~machinehu@213.55.225.115] has joined ##stm32
2024-01-22T07:57:41 -!- machinehum [~machinehu@213.55.225.115] has quit [Ping timeout: 240 seconds]
2024-01-22T08:01:52 < jpa-> Ecco_: heh, my guess would have been EMI from the PWM
2024-01-22T08:10:27 < qyx> yeah same here
2024-01-22T08:10:34 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-22T08:15:07 < jpa-> i had a lamp with touch sensor once, it would go on and off randomly
2024-01-22T08:43:30 -!- machinehum [~machinehu@213.55.225.115] has joined ##stm32
2024-01-22T08:48:20 -!- machinehum [~machinehu@213.55.225.115] has quit [Ping timeout: 268 seconds]
2024-01-22T09:07:16 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-22T09:14:40 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-58df-af06-3b2d-8fe8.fixed6.kpn.net] has joined ##stm32
2024-01-22T09:21:27 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2024-01-22T09:31:05 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has joined ##stm32
2024-01-22T09:33:41 -!- c10ud [~c10ud@user/c10ud] has joined ##stm32
2024-01-22T09:36:08 -!- machinehum [~machinehu@213.55.225.115] has joined ##stm32
2024-01-22T09:40:28 -!- machinehum [~machinehu@213.55.225.115] has quit [Ping timeout: 246 seconds]
2024-01-22T10:20:05 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-58df-af06-3b2d-8fe8.fixed6.kpn.net] has quit [Ping timeout: 240 seconds]
2024-01-22T10:25:22 -!- machinehum [~machinehu@213.55.225.115] has joined ##stm32
2024-01-22T10:48:50 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-22T11:03:14 -!- m5zs7k [aquares@web10.mydevil.net] has quit [Ping timeout: 260 seconds]
2024-01-22T11:05:02 -!- m5zs7k [aquares@web10.mydevil.net] has joined ##stm32
2024-01-22T11:25:36 -!- machinehum [~machinehu@213.55.225.115] has quit [Ping timeout: 256 seconds]
2024-01-22T11:30:48 -!- machinehum [~machinehu@213.55.225.115] has joined ##stm32
2024-01-22T12:26:38 -!- machinehum [~machinehu@213.55.225.115] has quit [Ping timeout: 268 seconds]
2024-01-22T12:55:42 -!- machinehum [~machinehu@213.55.225.195] has joined ##stm32
2024-01-22T13:13:19 -!- machinehum [~machinehu@213.55.225.195] has quit [Ping timeout: 260 seconds]
2024-01-22T13:14:45 < Steffanx> Yeah, you should totally go to jail for that. Damn you jpa- 
2024-01-22T13:21:26 -!- machinehum [~machinehu@213.55.225.195] has joined ##stm32
2024-01-22T13:32:53 -!- machinehum [~machinehu@213.55.225.195] has quit [Ping timeout: 252 seconds]
2024-01-22T13:51:35 -!- HelloShitty [~psysc0rpi@bl21-251-151.dsl.telepac.pt] has quit [Ping timeout: 264 seconds]
2024-01-22T14:03:41 < qyx> https://stackoverflow.com/questions/77326321/fix-elf-segment-address-on-an-objcopy-output-binary
2024-01-22T14:03:47 < qyx> I remember someone talking about this here
2024-01-22T14:04:50 < qyx> anyway, gcc pros, any idea how to move a specific segment of an ELF to a constant offset? (in the ELF file)
2024-01-22T14:05:46 < jpa-> in fully linked elf? or before linking?
2024-01-22T14:07:10 < qyx> what I am trying to achieve is to have ELF as a bootloader payload
2024-01-22T14:07:26 < qyx> but in order to be XIP-able, I need to match ELF offsets with physical memory offsets
2024-01-22T14:07:45 < qyx> (considering no PIC code at this point)
2024-01-22T14:08:24 < qyx> so the header is 52 bytes, program headers are a couple of bytes, let's allocate 0x1000 for the whole header
2024-01-22T14:08:27 < jpa-> i would just adjust linker script so that main application is linked at the expected offset
2024-01-22T14:08:33 < qyx> yes
2024-01-22T14:08:45 < qyx> link the application to be loaded at 0x08001000 for example
2024-01-22T14:08:57 < qyx> but I want to load the ELF at 0x08000000
2024-01-22T14:09:26 < qyx> so the segment should be offset 0x1000 in the ELF
2024-01-22T14:09:33 < jpa-> so you want to include some extra data in front? just put it first in linker script and then use ALIGN() or similar to pad it to 0x1000
2024-01-22T14:10:02 < qyx> yeah that's ok but then the linker chooses to assemble the ELF arbitrarily
2024-01-22T14:10:37 < qyx> doing the math it is ok, load offset 0xa0 at 0x08000000
2024-01-22T14:10:51 < qyx> but I have it loaded elsewhere
2024-01-22T14:11:28 < qyx> the physical ordering/segment alignment in the *elf* matters, not in the memory
2024-01-22T14:11:37 < qyx> and that§s what I cannot achieve
2024-01-22T14:17:46 < qyx> https://paste.jvnv.net/view/iU6ad
2024-01-22T14:36:37 < jpa-> what does your linker script look like?
2024-01-22T14:36:55 < jpa-> ah
2024-01-22T14:37:06 < jpa-> now i get it, you want to influence location of data in the .elf file itself
2024-01-22T14:39:34 < qyx> yeah
2024-01-22T14:40:14 < qyx> I just found SIZEOF_HEADERS but I cannot offset flash just by adding to it, it prints wrong memory region error
2024-01-22T14:41:52 < qyx> it indeed returns 0x94, I need to align it to get 0xaé
2024-01-22T14:41:55 < qyx> oh wait, align..
2024-01-22T14:43:57 < jpa-> what command is that in your paste?
2024-01-22T14:44:29 < qyx> readelf --headers
2024-01-22T14:44:34 < qyx> https://developer.arm.com/documentation/100748/0621/Mapping-Code-and-Data-to-the-Target/Alignment-of-regions-to-page-boundaries
2024-01-22T14:44:45 < qyx> this looks promising too, the very last sentence
2024-01-22T14:45:22 < jpa-> heh, i now tried to make a test project to test this and it gives offset = 0x1000 even before i tried to do anything..
2024-01-22T14:45:56 < qyx> pagesize is the default
2024-01-22T14:47:01 < jpa-> so wouldn't setting pagesize of 0x1000 work?
2024-01-22T14:53:35 < qyx> nope
2024-01-22T14:53:55 < qyx> common-page-size no worky, setting max-page-size to whatever value causes trouble
2024-01-22T14:54:51 < qyx> without it the offset is 0x10000 (64K), with it the offset is the required minimum aligned to 16, that is 52+3*32 = 148, align 16 = 160 = 0xa0
2024-01-22T14:58:15 < jpa-> hmm, for me the offset directly follows the max-page-size setting
2024-01-22T14:59:41 < jpa-> https://jpa.kapsi.fi/stuff/other/elf_pos/
2024-01-22T15:02:04 < qyx> but your PhysAddr shoud be 0x08001000 in that case
2024-01-22T15:02:58 < qyx> and it should be achievable with . = 0x08000000 + SIZEOF_HEADERS; . = ALIGN(0x1000);
2024-01-22T15:03:05 < qyx> but it doesn't work
2024-01-22T15:03:33 < jpa-> changed the memory region start now
2024-01-22T15:04:24 < qyx> so now https://jpa.kapsi.fi/stuff/other/elf_pos/readelf.txt gives the correct output
2024-01-22T15:04:58 < qyx> yeah that's the only way to achieve it
2024-01-22T15:06:01 < qyx> k, rinse, repeat
2024-01-22T15:10:16 < karlp1> that's a nice mini stm32 template there jpa
2024-01-22T15:10:49 < jpa-> karlp1: basically just STM32_Trace_Example stripped of the example :)
2024-01-22T15:12:03 < qyx> call me dumb
2024-01-22T15:13:42 < jpa-> i don't have your number
2024-01-22T15:18:26 < qyx> guess what '-n' does (https://linux.die.net/man/1/ld)
2024-01-22T15:22:02 < c10ud> i usually do this with iar, but cant you just define a memory region within the ld script
2024-01-22T15:22:26 < c10ud> so you can put the origin for your header stuff
2024-01-22T15:22:43 < c10ud> and then the real flash at flash+offset
2024-01-22T15:23:09 < c10ud> then you place the .regions accordinly
2024-01-22T15:23:58 < qyx> the problem is I don't know the header size, it depends on the linker will
2024-01-22T15:24:25 < qyx> there is the SIZEOF_HEADER variable which I could use to generate the header memory region
2024-01-22T15:24:33 < qyx> but it is unaligned
2024-01-22T15:24:52 < c10ud> oh
2024-01-22T15:25:17 < qyx> usually the size is 52 bytes + the number of segments, 32 bytes each
2024-01-22T15:25:52 < qyx> /opt/gcc-arm-none-eabi-10-2020-q4-major/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: invalid origin for memory region rom
2024-01-22T15:26:49 < qyx> the other approach is what jpa- did, set page size, assume the header is less than the page size
2024-01-22T15:26:57 < qyx> and allow it to align to page size
2024-01-22T15:28:38 < c10ud> or you just make the header a footer
2024-01-22T15:28:48 < qyx> I can't, it is an ELF
2024-01-22T15:28:57 < qyx> the ELF itself
2024-01-22T15:29:08 < c10ud> ah right
2024-01-22T15:30:24 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-22T15:34:54 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2024-01-22T15:34:57 < Laurenceb_> supp
2024-01-22T15:35:07  * Laurenceb_ is trying to get serial ports working on lunix
2024-01-22T15:35:34 < jadew> jpa-, qyx, I thought about EMI too, and it would have been my 3rd guess.
2024-01-22T15:35:40 < Laurenceb_> I've got a weird issue where read starts returning zero and will never give me any more data from the port
2024-01-22T15:35:58 < Laurenceb_> any ideas what could cause this? It occurs randomly after quite a bit of data has exchanged
2024-01-22T15:37:26 < jadew> My second guess was that the power lines are improperly decoupled, and the supply line to that IC fluctuates with the PWM to the LEDs.
2024-01-22T15:37:48 < jadew> Which would technically still be a brown out condition.
2024-01-22T15:40:47 < jadew> Laurenceb_, bad baudrate?
2024-01-22T15:41:07 < Laurenceb_> its a usb serial device using stm32
2024-01-22T15:41:14 < Laurenceb_> baudrate should not matter
2024-01-22T15:41:24 < jadew> Ah
2024-01-22T15:41:52 < jadew> Try wireshark, it does USB IIRC
2024-01-22T15:42:03 < Laurenceb_> hmm ok
2024-01-22T15:42:18 < Laurenceb_> it works ok with a terminal emulator
2024-01-22T15:43:01 < jadew> Ah, maybe it relies on the handshake signals and you're not setting that?
2024-01-22T15:43:22 < qyx> Laurenceb_: are you setting baudrate at all?
2024-01-22T15:43:39 -!- machinehum [~machinehu@213.55.225.195] has joined ##stm32
2024-01-22T15:43:52 < jadew> qyx, if the data comes straight from the USB device registering as a serial port, baudrate doesn't matter
2024-01-22T15:44:22 < qyx> he probably must set B_OTHER or how is it called
2024-01-22T15:44:31 < qyx> at least that's what interwebs suggested
2024-01-22T15:44:41 < qyx> he can't set nothing
2024-01-22T15:45:27 < jadew> It's probably going with the default settings that the OS has set to the port.
2024-01-22T15:45:30 < qyx> also there are timeouts
2024-01-22T15:45:47 < qyx> read() returning zero is valid
2024-01-22T15:46:07 < Laurenceb_> ok
2024-01-22T15:46:17 < Laurenceb_> I found the issue: stm32 serial driver locks up
2024-01-22T15:46:31 < Laurenceb_> then lunix removes the device and stm32 recovers
2024-01-22T15:46:47 < jadew> But you said it works in the terminal emulator
2024-01-22T15:46:52 < Laurenceb_> yeah
2024-01-22T15:46:56 < jadew> So it must be something you do
2024-01-22T15:47:42 < Laurenceb_> I should probably not have used usb-cdc from stm32duino
2024-01-22T15:48:09 < jadew> Look into whether the handshake stuff is under your control, from the user code side.
2024-01-22T15:48:27 < jadew> If you're not ACKing the data, it will fill the STM32's buffer and it will lock up.
2024-01-22T15:48:40 < Laurenceb_> ok
2024-01-22T15:48:42 < jadew> I would expect this to be handled directly by the USB driver tho...
2024-01-22T15:48:54 < Laurenceb_> looks like I'll have to read through the usb driver code :S
2024-01-22T15:49:14 < jadew> Just use wireshark and compare
2024-01-22T15:49:46 < Laurenceb_> ok
2024-01-22T15:53:37 < Laurenceb_> I think the best bet is to jtag the stm32
2024-01-22T15:57:38 < Laurenceb_> I think it should be possible to breakpoint the stm32 when its locked up and find the error
2024-01-22T15:57:55 < Laurenceb_> I'm going to guess its stuck here https://github.com/stm32duino/Arduino_Core_STM32/blob/main/cores/arduino/USBSerial.cpp#L70
2024-01-22T15:59:54 < Laurenceb_> wait wtf
2024-01-22T15:59:56 < Laurenceb_> https://github.com/stm32duino/Arduino_Core_STM32/blob/1863c25025441c8c6dbcea5b8ed496db21c12785/cores/arduino/stm32/usb/cdc/cdc_queue.c#L51
2024-01-22T16:00:20 < Laurenceb_> as soon as that fills up its going to lock up?
2024-01-22T16:00:47 < jpa-> if by "locking up" you mean "blocking writes will block"?
2024-01-22T16:01:22 < jpa-> unless you are doing something stupid like calling .write() with interrupts blocked, it should still respond to USB
2024-01-22T16:01:45 < Laurenceb_> yeah
2024-01-22T16:05:15 < qyx> hah, .text works, .data no
2024-01-22T16:05:16 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Read error: Connection reset by peer]
2024-01-22T16:06:53 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2024-01-22T16:08:03 < qyx> https://paste.jvnv.net/view/5QnIY
2024-01-22T16:09:05 < jpa-> put some ALIGN() stuff at end of .text so that .data AT will begin there?
2024-01-22T16:09:55 < qyx> doesn't work, I need to align LMA
2024-01-22T16:10:01 < qyx> oh at the end
2024-01-22T16:10:05 < qyx> let's tr
2024-01-22T16:11:43 < Laurenceb_> hmm now visual studio has broken
2024-01-22T16:11:45 < Laurenceb_> #error "No STM32 core verison"
2024-01-22T16:13:06 -!- machinehum [~machinehu@213.55.225.195] has quit [Ping timeout: 260 seconds]
2024-01-22T16:16:51 < qyx> jpa-: works, I should send you 2 more leaf springs
2024-01-22T16:21:48 < qyx> but the code doesn't run
2024-01-22T16:24:49 < c10ud> can you post your ld file?
2024-01-22T16:27:08 < qyx> vector table relocation is wrong
2024-01-22T16:29:03 -!- machinehum [~machinehu@213.55.225.195] has joined ##stm32
2024-01-22T16:38:40 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Ping timeout: 250 seconds]
2024-01-22T16:39:47 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has joined ##stm32
2024-01-22T16:41:51 < qyx> k, vector table is allright, now freertos fails
2024-01-22T16:42:48 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-22T16:44:49 < karlp1> huh, nxp has a "scales" demo using PHDC usb class that I'd never heard of.
2024-01-22T16:45:00 < karlp1> most scales seem to use the "scales" report in HID
2024-01-22T16:49:33 < qyx> whoa works
2024-01-22T16:49:43 < qyx> thanks jpa- and karlp1 
2024-01-22T16:50:59 < qyx> now I can flash a raw and stripped elf directly and let the bootloader handle it
2024-01-22T16:51:27 < karlp1> I didn't do anything...
2024-01-22T16:51:30 -!- karlp1 is now known as karlp
2024-01-22T16:51:42 < qyx> you did, you asked how to run main() again, it came handy
2024-01-22T16:52:13 < karlp> oh. didn't work for me though :)
2024-01-22T16:52:26 < karlp> but that's because of the wild wild wild bootloader/monstrosity on this platform.
2024-01-22T16:55:27 < qyx> now i just need to reinvent some elf parsing and elf signatures
2024-01-22T16:56:41 < qyx> oh elfsign does x509 only, what a shameň
2024-01-22T16:56:43 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2024-01-22T16:56:52 < Laurenceb_> hmm visual studio code is not playing nice
2024-01-22T16:56:55 < Laurenceb_> every line is an error
2024-01-22T16:56:59 < Laurenceb_> nothing is including
2024-01-22T16:58:17 < nomorekaki> intellisense needs to learn
2024-01-22T16:58:31 < Laurenceb_> how do I turn that on?
2024-01-22T16:58:47 < nomorekaki> are you doing C?
2024-01-22T16:58:47 < karlp> vschode winning
2024-01-22T16:59:05 < Laurenceb_> yeah c
2024-01-22T16:59:49 < nomorekaki> you have installed c/c++ extension and maybe wsl extension?
2024-01-22T17:00:18 < Laurenceb_> yeah, it used to compile fine, then I upgraded core libraries
2024-01-22T17:00:58 < Laurenceb_> I've changed the file paths in c_cpp_properties.json
2024-01-22T17:02:12 < Laurenceb_> #error "No STM32 core verison"
2024-01-22T17:02:23 < Laurenceb_> its not finding any of the included paths
2024-01-22T17:04:11 < Laurenceb_> ooh I selected the wrong board type maybe....
2024-01-22T17:11:29 < Laurenceb_> hmm something has changed
2024-01-22T17:11:56 < Laurenceb_> "fqbn": "STMicroelectronics:stm32:GenF1:pnum=GENERIC_F103RBTX,upload_method=dfuoMethod,xserial=none,usb=CDCgen,xusb=FS,opt=ogstd,dbg=enable_sym,rtlib=nanofp",
2024-01-22T17:12:11 < Laurenceb_> that line used to exist and now it is gone
2024-01-22T17:15:01 < Laurenceb_> yeah I'm out of ideas
2024-01-22T17:18:19 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-22T17:21:07 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2024-01-22T17:28:37 < Laurenceb_> anyone here ever used vs code?
2024-01-22T17:28:56 < Laurenceb_> I'm out of ideas for whats gone wrong, but it cant find anything, every line of code is an error atm
2024-01-22T17:30:32 < specing> lol
2024-01-22T17:30:53  * specing hasn't and doesen't plan to
2024-01-22T17:31:10 < Laurenceb_> it seems to have forgotten where _everything_ is
2024-01-22T17:31:14 < Laurenceb_> literally everything
2024-01-22T17:33:35 < nomorekaki> you got some files open that make intellisense confused?
2024-01-22T17:39:07 < Laurenceb_> maybe
2024-01-22T17:39:21 < Laurenceb_> oh I have the project open in arduino gui at same time...
2024-01-22T17:41:01 < Laurenceb_> arduino extension is asking for me to select the board type
2024-01-22T17:41:31 < Laurenceb_> but I have this in arduino.json     "board": "STMicroelectronics:stm32:GenF1:pnum=GENERIC_F103RBTX",
2024-01-22T17:48:40 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Quit: Client closed]
2024-01-22T17:54:13 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2024-01-22T17:54:24 < Laurenceb_> anyone got any ideas? I've run out of ideas
2024-01-22T17:57:45 < karlp> hrm, I'm guessing nxp's audio demo is as bad as their other demos: retire_capture_urb: 930 callbacks suppressed
2024-01-22T18:32:20 < jadew> specing, why don't you like vs code?
2024-01-22T18:32:46 < Laurenceb_> looks like my issue is within the board/variant config menu in vs code
2024-01-22T18:33:12 < Laurenceb_> that overwrites the options json file that I've edited, it will only let me use libmaple at the moment
2024-01-22T18:36:14 < Laurenceb_> I need      STMicroelectronics:stm32:GenF1:pnum=GENERIC_F103RBTX
2024-01-22T18:36:37 < specing> jadew: because it has microsoft smeared all over
2024-01-22T18:36:54 < jadew> specing, you mean high quality programming/design?
2024-01-22T18:36:54 < Laurenceb_> lol
2024-01-22T18:37:14 < specing> jadew: I've got GNU Emacs for that, tyvm
2024-01-22T18:38:45 < jadew> I have yet to understand the appeal of text-mode editors...
2024-01-22T18:39:45 < jadew> Don't get me wrong, the Borland IDEs were pretty cool for their time, but why would you punish yourself like that today?
2024-01-22T18:39:53 < specing> GNU Emacs has a GUI btw
2024-01-22T18:39:58 < jadew> I use vim on a daily basis and still hate it.
2024-01-22T18:40:34 < jadew> Is it still not text based? Got a video or something that shows it being used by a pro?
2024-01-22T18:41:24 < specing> I don't
2024-01-22T18:41:35 < specing> also, I mostly use GPS for stm32
2024-01-22T18:42:17 < jadew> What's GPS?
2024-01-22T18:45:00 < specing> jadew: GNAT Programming Studio
2024-01-22T18:46:28 < jadew> Looking at a video, are they using the scintilla editor control?
2024-01-22T18:47:37 < specing> no idea what scintilla is
2024-01-22T18:47:38 < jadew> (same shit notepad++ and geany are using)
2024-01-22T18:50:16 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has quit [Ping timeout: 276 seconds]
2024-01-22T18:57:19 -!- machinehum [~machinehu@213.55.225.195] has quit [Ping timeout: 256 seconds]
2024-01-22T18:59:19 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Quit: Client closed]
2024-01-22T19:18:35 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 264 seconds]
2024-01-22T19:59:25 < octorian> So looking at crystals, as part of switching from an F411 to an F446 for a project.  I'm noticing that the Kyocera IC Matching Search tool is recommending different crystals for those two parts, even though their HSE/pin specs appear to be equivalent.
2024-01-22T19:59:28 < octorian> Am I missing something here?
2024-01-22T20:12:07 < jpa-> so what are they recommending?
2024-01-22T20:13:30 < octorian> Assuming both are 16MHz, here are the two recommendations:
2024-01-22T20:13:33 < octorian> https://prdct-search.kyocera.co.jp/crystal-ic/?p=en_search/detail/00000000670/
2024-01-22T20:13:38 < octorian> https://prdct-search.kyocera.co.jp/crystal-ic/?p=en_search/detail/00000001578/
2024-01-22T20:14:58 < qyx> why are you even consulting kyocera regarding crystals?
2024-01-22T20:15:20 < jpa-> octorian: to me it looks like it is recommending newer crystal for newer STM32, so they probably just don't update old entries
2024-01-22T20:15:24 < qyx> honestly I would never even try to search for anything like that
2024-01-22T20:15:51 < jpa-> qyx: yeah, me neither, and then i ended up with unsuitable crystal ;)
2024-01-22T20:17:23 < octorian> Crystals are one place where I'd much prefer to go with some sort of "authoritative recommendation" than to try and figure it all out myself by crunching formulas, guessing variables, and hoping for the best.
2024-01-22T20:17:57 < octorian> Though I am tempted to just stick with the same crystal I'm using now, unless I have a real reason to switch (part availability or a reason to switch frequencies)
2024-01-22T20:27:55 < qyx> I have no crystal fail ever
2024-01-22T20:28:12 < qyx> except one when I routed a high power trace underneath and HSE stopped when the current was > 1A
2024-01-22T20:28:22 < qyx> s/have/had
2024-01-22T20:31:30 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-14c2-d2fd-27af-12d2.fixed6.kpn.net] has joined ##stm32
2024-01-22T20:40:57 < qyx> so, how to find out where the vector table resides in the ELF without finding the .text section
2024-01-22T21:02:57 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:5413:39d9:fb92:45ef] has joined ##stm32
2024-01-22T21:09:53 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-22T21:29:44 < jpa-> find first instance of hex string ....0020....0008
2024-01-22T21:30:55 < qyx> tried looking for a segment whose second uint32_t equals to the ELF's entry point
2024-01-22T21:31:12 < qyx> seems to be working
2024-01-22T21:35:25 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-22T21:35:39 < Laurenceb_> Microsoft has recently dropped support for the Arduino IDE and that means you need to install Arduino-CLI to get the extension to work
2024-01-22T21:35:40 < Laurenceb_> wut
2024-01-22T21:38:18 < specing> EEE?
2024-01-22T21:38:41 < Laurenceb_> ah - tarduino 1.8 still works with vs code
2024-01-22T21:38:49 < Laurenceb_> so thats not the source of my issue
2024-01-22T21:39:27 < Laurenceb_> it seems that the board config menu is malfunctioning when I try to load the stmicro package json file
2024-01-22T21:39:56 < Laurenceb_> and as a result it falls back to libmaple and everything breaks during compilation
2024-01-22T21:40:12 < Laurenceb_> rather than using ST HAL
2024-01-22T21:54:29 -!- qyx [~qyx@84.245.121.23] has quit [Ping timeout: 252 seconds]
2024-01-22T21:56:16 -!- qyx [~qyx@84.245.121.97] has joined ##stm32
2024-01-22T22:16:25 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-22T22:32:59 -!- BrainDamage [~BrainDama@user/BrainDamage] has quit [Ping timeout: 252 seconds]
2024-01-22T22:46:25 -!- machinehum [~machinehu@213.55.225.195] has joined ##stm32
2024-01-22T23:07:39 -!- jadew [~rcc@5.12.146.135] has quit [Ping timeout: 256 seconds]
2024-01-22T23:10:26 -!- qyx [~qyx@84.245.121.97] has quit [Ping timeout: 268 seconds]
2024-01-22T23:11:21 < Laurenceb_> hmm
2024-01-22T23:11:22 < Laurenceb_> https://pastes.io/svjwkvb7m6
2024-01-22T23:11:37 < Laurenceb_> not my code but thats whats running on pc side
2024-01-22T23:12:08 -!- qyx [~qyx@84.245.121.89] has joined ##stm32
2024-01-22T23:13:06 < qyx> what else can I do to disable everything before jumping to the app? I set all ICER and ISPR
2024-01-22T23:13:24 < qyx> call vTaskSuspendAll before
2024-01-22T23:16:10 -!- machinehum [~machinehu@213.55.225.195] has quit [Ping timeout: 264 seconds]
2024-01-22T23:20:43 -!- jadew [~rcc@5.12.146.135] has joined ##stm32
2024-01-22T23:23:24 < Laurenceb_> looks like tarduino Serial.flush() locks up
2024-01-22T23:24:08 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-22T23:35:14 -!- machinehum [~machinehu@213.55.225.195] has joined ##stm32
2024-01-22T23:43:55 -!- machinehum [~machinehu@213.55.225.195] has quit [Ping timeout: 256 seconds]
2024-01-22T23:53:51 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Quit: Client closed]
--- Day changed ti tammi 23 2024
2024-01-23T00:01:37 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-14c2-d2fd-27af-12d2.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-23T00:17:43 < qyx> ok found the problem, when in thread mode, psp is used, I have to change that to msp before loading msp
2024-01-23T00:30:41 < Ecco_> octorian: Why do you want to stick to "recommended" crystals so bad?
2024-01-23T00:30:47 < Ecco_> I mean, aren't they somewhat interchangeable?
2024-01-23T00:30:50 -!- Ecco_ is now known as Ecco
2024-01-23T00:31:37 -!- machinehum [~machinehu@213.55.225.195] has joined ##stm32
2024-01-23T00:31:49 < qyx> found another problem, once the flash is unlocked, it cannot be unlocked again
2024-01-23T00:32:06 < qyx> it is not mentioned in the RM, the only thing mentioned is that a wrong sequence causes bus fault
2024-01-23T00:32:10 < qyx> which indeed happens
2024-01-23T00:32:29 < qyx> I hate computers
2024-01-23T00:36:25 -!- machinehum [~machinehu@213.55.225.195] has quit [Ping timeout: 264 seconds]
2024-01-23T00:47:50 < octorian> Meanwhile, after spending way too much time today with two side-by-side CubeMX windows, I think I'm finally almost done with the first pass of figuring out all the updated peripheral settings/assignments for the F411->F446 switch.  (though I expect a bit more fiddling once I'm actually routing traces)
2024-01-23T00:59:13 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:5413:39d9:fb92:45ef] has quit [Ping timeout: 264 seconds]
2024-01-23T00:59:54 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 268 seconds]
2024-01-23T01:06:54 < Ecco> How is F446 better than F411?
2024-01-23T01:07:29 < octorian> In my particular case, it has a better USB peripheral /w DMA, and thus is supported host-side by CherryUSB.
2024-01-23T01:07:36 < Ecco> Apparently, faster clock + adressable QSPI
2024-01-23T01:07:48 < octorian> But it can also run at a higher clock speed, has more timer channels, and yes has all those other features I'm not using.
2024-01-23T01:08:07 < Ecco> Is CherryUSB any good?
2024-01-23T01:08:30 < octorian> It seems to be a lot more complete on the host-side than TinyUSB or ST's USB stack.
2024-01-23T01:22:06 -!- machinehum [~machinehu@213.55.225.195] has joined ##stm32
2024-01-23T01:26:14 -!- machinehum [~machinehu@213.55.225.195] has quit [Ping timeout: 252 seconds]
2024-01-23T01:46:56 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has joined ##stm32
2024-01-23T02:07:10 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 260 seconds]
2024-01-23T02:13:01 -!- machinehum [~machinehu@213.55.225.195] has joined ##stm32
2024-01-23T02:17:49 -!- machinehum [~machinehu@213.55.225.195] has quit [Ping timeout: 264 seconds]
2024-01-23T02:21:37 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2024-01-23T03:03:15 -!- machinehum [~machinehu@213.55.225.195] has joined ##stm32
2024-01-23T03:07:46 -!- machinehum [~machinehu@213.55.225.195] has quit [Ping timeout: 264 seconds]
2024-01-23T03:51:42 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-23T03:52:59 -!- machinehum [~machinehu@213.55.225.195] has joined ##stm32
2024-01-23T03:57:48 -!- machinehum [~machinehu@213.55.225.195] has quit [Ping timeout: 268 seconds]
2024-01-23T04:42:32 -!- machinehum [~machinehu@213.55.225.195] has joined ##stm32
2024-01-23T04:47:08 -!- machinehum [~machinehu@213.55.225.195] has quit [Ping timeout: 268 seconds]
2024-01-23T05:22:10 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Remote host closed the connection]
2024-01-23T05:34:41 -!- machinehum [~machinehu@213.55.225.195] has joined ##stm32
2024-01-23T05:39:05 -!- machinehum [~machinehu@213.55.225.195] has quit [Ping timeout: 260 seconds]
2024-01-23T06:23:14 -!- machinehum [~machinehu@213.55.225.195] has joined ##stm32
2024-01-23T06:28:22 -!- machinehum [~machinehu@213.55.225.195] has quit [Ping timeout: 276 seconds]
2024-01-23T07:13:26 -!- machinehum [~machinehu@213.55.225.195] has joined ##stm32
2024-01-23T07:17:41 -!- machinehum [~machinehu@213.55.225.195] has quit [Ping timeout: 252 seconds]
2024-01-23T07:30:23 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-23T07:36:29 -!- boB_K7IQ [~boB_K7IQ@152.44.147.180] has joined ##stm32
2024-01-23T07:57:23 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-641a-8427-9d2e-2fec.fixed6.kpn.net] has joined ##stm32
2024-01-23T07:58:38 -!- machinehum [~machinehu@213.55.225.195] has joined ##stm32
2024-01-23T08:01:35 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-641a-8427-9d2e-2fec.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-23T08:02:42 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-4940-9087-4374-c328.fixed6.kpn.net] has joined ##stm32
2024-01-23T08:02:53 -!- machinehum [~machinehu@213.55.225.195] has quit [Ping timeout: 240 seconds]
2024-01-23T08:38:25 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-4940-9087-4374-c328.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-23T08:47:46 -!- machinehum [~machinehu@213.55.225.195] has joined ##stm32
2024-01-23T08:58:26 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-23T09:04:46 -!- machinehum [~machinehu@213.55.225.195] has quit [Ping timeout: 264 seconds]
2024-01-23T09:18:32 -!- machinehum [~machinehu@213.55.225.195] has joined ##stm32
2024-01-23T09:43:47 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2024-01-23T10:00:21 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has joined ##stm32
2024-01-23T10:59:46 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-23T11:38:08 -!- machinehum2 [~machinehu@213.55.225.195] has joined ##stm32
2024-01-23T11:38:23 -!- machinehum [~machinehu@213.55.225.195] has quit [Ping timeout: 264 seconds]
2024-01-23T11:39:30 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
2024-01-23T11:43:16 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2024-01-23T11:49:05 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2024-01-23T12:01:01 < karlp> qyx: hah, yeah, that double unlock I got into before with a bootloader on L1 iirc.
2024-01-23T12:02:14 < jpa-> on H7 i somehow forgot entirely about cache.. even verify went fine because it read back from cache, but then on next boot parts of data was gone :)
2024-01-23T12:11:56 -!- machinehum2 [~machinehu@213.55.225.195] has quit [Ping timeout: 252 seconds]
2024-01-23T12:14:15 -!- machinehum [~machinehu@213.55.225.195] has joined ##stm32
2024-01-23T12:14:16 < karlp> oops.
2024-01-23T12:14:25 < karlp> heard nothign but pain stories from h7.
2024-01-23T12:16:21 < qyx> https://paste.jvnv.net/view/rt9Uj
2024-01-23T12:16:25 < qyx> works great
2024-01-23T12:16:34 < qyx> the last piece of the puzzle is to get PIC working
2024-01-23T12:16:43 < qyx> so I can load ELF from an arbitrary location
2024-01-23T12:16:53 < qyx> even without a defined layout
2024-01-23T12:35:55 -!- machinehum2 [~machinehu@213.55.224.73] has joined ##stm32
2024-01-23T12:38:33 -!- machinehum [~machinehu@213.55.225.195] has quit [Ping timeout: 256 seconds]
2024-01-23T12:57:45 -!- BrainDamage [~BrainDama@user/BrainDamage] has joined ##stm32
2024-01-23T13:09:18 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2024-01-23T13:13:44 < Laurenceb_> moar fun trying to force visual studio to work
2024-01-23T13:13:58 < Laurenceb_> I have uninstalled all board packages, but I still see boards appearing under the board config menu
2024-01-23T13:29:03 < Laurenceb_> gah typical microshart
2024-01-23T13:29:13 < Laurenceb_> uninstalling everything then reinstalling and it works
2024-01-23T13:36:13 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Quit: Client closed]
2024-01-23T13:44:05 < zyp> qyx, that's cute
2024-01-23T13:44:25 < zyp> hmm, wtf is farnell doing
2024-01-23T13:45:08 < zyp> I ordered the mitutoyo calipers I mentioned the other day, expected I could have them today, order shows as backordered
2024-01-23T13:45:15 < zyp> product page still shows 28 in stock
2024-01-23T13:49:45 < jpa-> farnell is a mess
2024-01-23T13:52:50 < zyp> true, that's not new
2024-01-23T13:53:20 < zyp> IIRC first time I ordered from them, they sent me the order and invoiced some other company for it
2024-01-23T13:55:40 < zyp> > Please be advised that the stocks which you see on the website is in Liege warehouse.
2024-01-23T13:55:43 < zyp> > As the liege warehouse is no longer functioning the orders are not dispatched from it. We are working to remove the stocks details on website which are in liege warehouse.
2024-01-23T13:55:49 < zyp> > The part is on back order and will be dispatched from our UK warehouse.
2024-01-23T13:55:58 < zyp> wtf
2024-01-23T13:57:56 < jpa-> farnell insists on having a bazillion warehouses, but having a "non-functioning warehouse" and showing it as stock is new :D
2024-01-23T14:00:18 < jpa-> some google results suggest that because of brexit they have trouble shipping to non-EU from EU warehouses and to EU from non-EU warehouses :)
2024-01-23T14:01:11 < zyp> > Unfortunately, the delivery date is not yet updated on our system.
2024-01-23T14:01:12 < zyp> > The general lead time is 4-6 weeks.
2024-01-23T14:01:22 < zyp> so I'm telling them to fuck off and cancel my order
2024-01-23T14:04:23 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has joined ##stm32
2024-01-23T14:06:09 < qyx> oh great so farnell is a no-go anymore
2024-01-23T14:06:18 < qyx> when is brundo happening?
2024-01-23T14:08:39 -!- machinehum2 [~machinehu@213.55.224.73] has quit [Ping timeout: 256 seconds]
2024-01-23T14:10:53 -!- machinehum [~machinehu@213.55.224.73] has joined ##stm32
2024-01-23T14:55:16 < karlp> qyx: system looks very nice now!
2024-01-23T14:55:21 -!- machinehum [~machinehu@213.55.224.73] has quit [Ping timeout: 260 seconds]
2024-01-23T14:55:28 < karlp> more dedication to the idea that I think i might have done...
2024-01-23T15:02:26 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has quit [Ping timeout: 252 seconds]
2024-01-23T15:09:07 < qyx> now reinvent the wheel with signing ELFs
2024-01-23T15:16:15 < jpa-> https://github.com/orlp/ed25519   i have used this for firmware signing
2024-01-23T15:17:03 < jpa-> it does take some 60kB so not very small
2024-01-23T15:17:56 < qyx> yeah I used ed25519 back in 2015
2024-01-23T15:18:05 < qyx> but I had a 29K impl
2024-01-23T15:18:08 < jpa-> i'm not sure if the "precomp_data.h" could be converted to runtime computation instead
2024-01-23T15:18:25 < qyx> and there is also a twitter-version of that code
2024-01-23T15:18:27 < qyx> official
2024-01-23T15:18:38 < qyx> which should be even smaller, although a bit slower
2024-01-23T15:18:51 < qyx> mine did 4 verifications per second on a 16 MHz F4
2024-01-23T15:20:03 < qyx> https://tweetnacl.cr.yp.to/20140427/tweetnacl.c
2024-01-23T15:20:37 < jpa-> yeah, looks like tweetnacl is 8kB
2024-01-23T15:20:51 < qyx> did you try?
2024-01-23T15:21:19 < jpa-> just compiled
2024-01-23T15:21:35 < jpa-> i wonder if there is a commented proper version of it somewhere
2024-01-23T15:21:46 < jpa-> instead of this laurenceb-tier crap
2024-01-23T15:21:49 < qyx> I did one and then someone else did too
2024-01-23T15:23:57 < qyx> https://github.com/iqyx/curve25519-meh/tree/master
2024-01-23T15:25:21 < jpa-> nice
2024-01-23T15:25:50 < jpa-> so only 1.5 kB for that
2024-01-23T15:26:18 < jpa-> though need to add hashing etc.
2024-01-23T15:27:21 < qyx> yeah but curve25519 is not very usable for signing
2024-01-23T15:27:42 < qyx> for hashing I am using blake2s
2024-01-23T15:30:27 < jpa-> i don't really understand much about crypto, so i just randomly throw stuff together and hope that it is secure enough
2024-01-23T15:31:55 < qyx> https://github.com/aykevl/blake2s-micro
2024-01-23T15:32:05 < qyx> this is super small and fast
2024-01-23T15:32:11 < qyx> can has th whole firmware in milliseconds
2024-01-23T15:32:14 < qyx> *hash
2024-01-23T15:35:17 < jpa-> at this point i'm pretty much locked into ed25519
2024-01-23T15:35:43 < qyx> that's good, it is a defacto standard no
2024-01-23T15:35:46 < qyx> *now
2024-01-23T15:36:31 < jpa-> yeah, and if i ever run out of flash, i can make random changes until it is smaller :)
2024-01-23T15:36:32 < qyx> nobody sane is using rsa anymore
2024-01-23T15:47:30 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-23T15:53:26 < jbo> +1 for ed25519
2024-01-23T15:53:39 < jbo> qyx, microsoft azure devops is forcing use of RSA
2024-01-23T15:53:48 < jbo> can't  have ED25519 SSH keys to access the git repos :D
2024-01-23T15:54:41 < qyx> that's probably because they are in the usa
2024-01-23T15:54:55 < jbo> jup
2024-01-23T16:06:44 < karlp> lol, nxp commit in their examplexs repo: "Showing 9,236 changed files with 519 additions and 2,627,185 deletions."
2024-01-23T16:11:37 -!- specing [~specing@user/specing] has quit [Ping timeout: 256 seconds]
2024-01-23T16:12:05 -!- specing [~specing@user/specing] has joined ##stm32
2024-01-23T16:19:11 < qyx> arm-none-eabi-objcopy: bin/st6Mtedz: can't add section '.sign.ed25519': file format not recognized
2024-01-23T16:19:26 < qyx> so this means oh hey there is already a section with this name
2024-01-23T16:20:27 < qyx> https://bug-binutils.gnu.narkive.com/MOw9On0g/objcopy-add-section-doubt
2024-01-23T16:31:05 < karlp> 18 years and they haven't fixed the error message?
2024-01-23T16:47:34 -!- leptonix [~leptonix@134.122.103.122] has quit [Quit: leaving]
2024-01-23T16:49:22 -!- leptonix [~leptonix@134.122.103.122] has joined ##stm32
2024-01-23T17:04:31 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2024-01-23T17:11:38 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2024-01-23T17:11:40 < Laurenceb_> supp
2024-01-23T17:11:53  * Laurenceb_ got visual studio to compile by reinstalling all the add ons
2024-01-23T17:12:24 < Laurenceb_> but now it wont debug properly as its looking in the wrong folders for source code when debugging
2024-01-23T17:12:43 < Laurenceb_> looks like its out of date - looking at old library locations
2024-01-23T17:13:02 < Laurenceb_> which is weird as the elf file has been rebuilt
2024-01-23T17:13:49 < Laurenceb_> wait wtf
2024-01-23T17:13:55 < Laurenceb_> elf file is 2 months old
2024-01-23T17:20:27 -!- Laurenceb_86 [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2024-01-23T17:20:43 < Laurenceb_86> looks like codevs has decided not to generate elf files
2024-01-23T17:20:55 -!- Laurenceb_86 [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Client Quit]
2024-01-23T17:26:00 < mawk> I just wrote the 1000th unit test for our embedded codebase
2024-01-23T17:26:01 < mawk> wooo
2024-01-23T17:27:20 < Laurenceb_> this is really weird - code compiles ok but I dont know where the elf is going to
2024-01-23T17:27:24 -!- machinehum [~machinehu@213.55.224.73] has joined ##stm32
2024-01-23T17:30:01 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Quit: Client closed]
2024-01-23T17:30:05 < mawk> lol
2024-01-23T17:35:00 < karlp> phew, this cw/iar conversion is not pretty. I think itll be simpler to replace the startup with a "normal" cortex startup, and try and rehook the vectors in tahn untangling this :|
2024-01-23T17:37:29 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2024-01-23T17:37:46 < Laurenceb_> looks like microshart have made visual studio start saving elf files to %temp%
2024-01-23T17:39:51 < Laurenceb_> https://stm32world.com/wiki/STM32_development_and_debugging_using_VSCode
2024-01-23T17:40:04 < Laurenceb_> this assumes the elf is in the /build/ directory
2024-01-23T17:44:53 < Laurenceb_> looks like I need to somehow configure vs to user the /build/ folder again
2024-01-23T17:44:57 < Laurenceb_> *to use
2024-01-23T17:48:44 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-23T17:53:16 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Quit: Client closed]
2024-01-23T17:53:32 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2024-01-23T17:54:22 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Client Quit]
2024-01-23T18:01:20 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2024-01-23T18:02:00 -!- martinmoene1 [~martinmoe@132.229.46.129] has joined ##stm32
2024-01-23T18:02:35 -!- Spirit532 [~Spirit532@user/Spirit532] has quit [Killed (NickServ (GHOST command used by Spirit5324))]
2024-01-23T18:02:40 -!- Spirit532 [~Spirit532@user/Spirit532] has joined ##stm32
2024-01-23T18:03:32 -!- skz81 [~skz81@vps-68d3ea17.vps.ovh.net] has joined ##stm32
2024-01-23T18:05:30 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-23T18:05:58 -!- karlp1 [karlp@palmtreev6.beeroclock.net] has joined ##stm32
2024-01-23T18:06:07 -!- mid-kid1 [~mid-kid@2a01:7c8:aac8:1e8:5054:ff:fe5e:cd48] has joined ##stm32
2024-01-23T18:06:20 -!- Ecco_ [~user@user/Ecco] has joined ##stm32
2024-01-23T18:06:27 -!- martinmoene1 [~martinmoe@132.229.46.129] has left ##stm32 []
2024-01-23T18:08:35 -!- skz81_ [~skz81@vps-68d3ea17.vps.ovh.net] has quit [Ping timeout: 264 seconds]
2024-01-23T18:08:35 -!- jtj [~jtj@212.66.207.170] has quit [Ping timeout: 264 seconds]
2024-01-23T18:08:35 -!- karlp [karlp@palmtreev6.beeroclock.net] has quit [Ping timeout: 264 seconds]
2024-01-23T18:08:35 -!- Ecco [~user@user/Ecco] has quit [Ping timeout: 264 seconds]
2024-01-23T18:08:35 -!- mid-kid [~mid-kid@2a01:7c8:aac8:1e8:5054:ff:fe5e:cd48] has quit [Ping timeout: 264 seconds]
2024-01-23T18:08:35 -!- jmcgnh [~jmcgnh@wikipedia/jmcgnh] has quit [Ping timeout: 264 seconds]
2024-01-23T18:09:49 -!- jtj [~jtj@212.66.207.170] has joined ##stm32
2024-01-23T18:14:52 -!- jmcgnh [~jmcgnh@wikipedia/jmcgnh] has joined ##stm32
2024-01-23T18:21:23 -!- machinehum [~machinehu@213.55.224.73] has quit [Ping timeout: 256 seconds]
2024-01-23T18:22:38 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Ping timeout: 250 seconds]
2024-01-23T18:30:45 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2024-01-23T18:31:03 < Laurenceb_> visual studio works... finally
2024-01-23T18:31:12 < Laurenceb_> now I can debug st usb codez
2024-01-23T18:31:21 < Laurenceb_> looks like its stuck in USB_ReadPMA forever
2024-01-23T18:33:21 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Client Quit]
2024-01-23T18:34:03 < qyx> hm I am using mkstemp in python and then using the resulting file as a parameter in a subprocess.run()
2024-01-23T18:34:14 < qyx> and the command says the file cannot be found
2024-01-23T18:34:21 < qyx> despite I can cat it afterwards
2024-01-23T18:35:00 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2024-01-23T18:35:03 < Laurenceb_> https://github.com/stm32duino/Arduino_Core_STM32/blob/de1e1c5d5092244727d98e4ac5848ff4d3a81550/system/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_pcd.c#L2207
2024-01-23T18:35:10 < Laurenceb_> looks like maybe its looping forever here
2024-01-23T18:45:34 -!- machinehum [~machinehu@213.55.224.73] has joined ##stm32
2024-01-23T18:48:12 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Ping timeout: 250 seconds]
2024-01-23T18:51:16 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 246 seconds]
2024-01-23T18:51:38 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2024-01-23T18:51:47 < Laurenceb_> aha no its a fault due to uninitialised pointer I think
2024-01-23T18:59:31 < Laurenceb_> annoying too much stuff is optimised out
2024-01-23T18:59:57 < Laurenceb_> HAL_PCD_EP_DB_Receive is calling USB_ReadPMA(hpcd->Instance, ep->xfer_buff, ep->pmaaddr1, count);
2024-01-23T19:07:15 -!- hexo_ [~hexo@user/hexo] has joined ##stm32
2024-01-23T19:16:32 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Quit: Client closed]
2024-01-23T19:26:25 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2024-01-23T19:33:05 -!- boB_K7IQ [~boB_K7IQ@152.44.147.180] has quit []
2024-01-23T19:55:15 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has joined ##stm32
2024-01-23T20:10:48 -!- machinehum [~machinehu@213.55.224.73] has quit [Ping timeout: 256 seconds]
2024-01-23T20:29:10 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-23T20:33:13 -!- machinehum [~machinehu@5.226.148.123] has joined ##stm32
2024-01-23T21:00:49 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has joined ##stm32
2024-01-23T21:04:37 -!- machinehum [~machinehu@5.226.148.123] has quit [Ping timeout: 264 seconds]
2024-01-23T21:15:33 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-23T21:15:50 < Laurenceb_> jtag working again with visual studio :D
2024-01-23T21:15:56 < Laurenceb_> now I can debug usb
2024-01-23T21:17:30 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-23T21:22:54 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-23T21:30:15 -!- machinehum [~machinehu@5.226.148.123] has joined ##stm32
2024-01-23T21:36:20 < Laurenceb_> looks like its hardfaulting
2024-01-23T21:39:47 < qyx> metoo
2024-01-23T21:43:16 < Laurenceb_> can't find anyone describing this on internets, annoying
2024-01-23T21:44:23 < jpa-> haa anyone tried ondsel yet (freecad derivative)
2024-01-23T21:44:30 < jpa-> *has
2024-01-23T21:47:06 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-11ad-f49e-dc8e-df30.fixed6.kpn.net] has joined ##stm32
2024-01-23T21:48:03 < Laurenceb_> https://github.com/stm32duino/Arduino_Core_STM32/blob/main/system/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_pcd.c#L2538
2024-01-23T21:48:04 -!- martinmoene [~Martin@2a02-a45a-96ba-1-41f5-5e80-8a6b-882e.fixed6.kpn.net] has joined ##stm32
2024-01-23T21:49:19 < qyx> jpa-: no, as you?
2024-01-23T21:51:45 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-11ad-f49e-dc8e-df30.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-23T22:01:01 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 264 seconds]
2024-01-23T22:03:26 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-23T22:04:55 < Laurenceb_> annoyingly I'm getting variables optimised out
2024-01-23T22:05:34 < Laurenceb_> looks like either ep->xfer_buff or ep->pmaaddr1 is zero
2024-01-23T22:05:40 < Laurenceb_> I'm guess xfer_buff
2024-01-23T22:08:47 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has joined ##stm32
2024-01-23T22:08:56 < nomorekaki> procpp
2024-01-23T22:10:26 < jpa-> qyx: no, only just saw it
2024-01-23T22:10:27 < nomorekaki> https://paste.debian.net/hidden/58032aa0/ why did it stop working when I changed it to c->cpp source file
2024-01-23T22:10:54 < nomorekaki> even with "C" linkage it says too many initializers
2024-01-23T22:14:20 -!- nomorekaki46 [~nomorekak@176-93-92-158.bb.dnainternet.fi] has joined ##stm32
2024-01-23T22:15:25 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 264 seconds]
2024-01-23T22:17:42 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-23T22:17:56 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-23T22:18:21 -!- nomorekaki46 is now known as nomorekaki
2024-01-23T22:19:14 < nomorekaki> tried [100] no worki
2024-01-23T22:26:16 -!- HelloShitty [~psysc0rpi@bl21-251-151.dsl.telepac.pt] has joined ##stm32
2024-01-23T22:31:28 < Steffanx> Do you use C++20++ nomorekaki?
2024-01-23T22:31:56 < nomorekaki> CXXFLAGS="-std=c++11"
2024-01-23T22:32:05 < zyp> why so old?
2024-01-23T22:32:21 < zyp> doesn't compilers default to c++17 nowadays?
2024-01-23T22:32:29 < nomorekaki> hmm
2024-01-23T22:32:43 < nomorekaki> it was in configure.ac example
2024-01-23T22:32:53 < nomorekaki> is it a problem?
2024-01-23T22:33:44 < nomorekaki> yeah it wasn't
2024-01-23T22:33:46 < zyp> why are you asking me? you're the developer
2024-01-23T22:34:15 < zyp> I wouldn't want to be restricted to c++11 features, but you do you
2024-01-23T22:35:05 < qyx> ok it took me 2 hours to actually get the fact wireguard keys are curve25519 and not ed25519
2024-01-23T22:35:57 < nomorekaki> only line I need cpp for "    Serial.begin(F_CPU/8);    //2000000 should be valid baudrate with F_CPU==16000000"
2024-01-23T22:36:20 < nomorekaki> it's easiest to replace that now and convert to c
2024-01-23T22:37:57 < Steffanx> mawk: your Rigol might need some new calibration, this one is rather old  https://usercontent.irccloud-cdn.com/file/bSrG4WwM/1000017543.jpg
2024-01-23T22:49:01 -!- machinehum [~machinehu@5.226.148.123] has quit [Ping timeout: 264 seconds]
2024-01-23T22:49:06 < Laurenceb_> hmm somehow I doubt st have screwed usb this badly
2024-01-23T22:49:13 < Laurenceb_> maybe stm32duino screwed up
2024-01-23T22:49:28 < Laurenceb_> the weird thing is that usb works fine with terraterm etc
2024-01-23T22:54:36 -!- machinehum [~machinehu@5.226.148.123] has joined ##stm32
2024-01-23T23:00:04 -!- mid-kid1 is now known as mid-kid
2024-01-23T23:01:20 < Laurenceb_> anyone here ever used CDC with ST HAL  ?
2024-01-23T23:05:48 < nomorekaki> very likelly. haven't you?
2024-01-23T23:08:10 < Laurenceb_> yeah and its hardfaulting
2024-01-23T23:10:59 < Laurenceb_> its might actually be an issue with raspberry pi - only ever seen the issue with a raspberry pi as the host, it works fine with a windows pc
2024-01-23T23:11:17 < Laurenceb_> looks like its getting a single byte on a unconfigured endpoint
2024-01-23T23:12:43 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 246 seconds]
2024-01-23T23:15:35 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-23T23:20:38 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 256 seconds]
2024-01-23T23:22:19 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-23T23:31:37 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 264 seconds]
2024-01-23T23:32:07 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-23T23:35:22 -!- machinehum [~machinehu@5.226.148.123] has quit [Ping timeout: 276 seconds]
2024-01-23T23:43:23 < Laurenceb_> hmm I have a plan
2024-01-23T23:43:46 < Laurenceb_> I could probably modify the usb HAL library to identify and ignore invalid USB situations
2024-01-23T23:43:56 < Laurenceb_> just add handler code to identify the situation and do nothing
2024-01-23T23:52:43 < zyp> what's the issue?
2024-01-23T23:57:58 < Laurenceb_> hardfaults inside HAL usb code
2024-01-23T23:58:14 < zyp> that's a pretty shitty USB stack
2024-01-23T23:58:16 < Laurenceb_> here  https://github.com/stm32duino/Arduino_Core_STM32/blob/main/system/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_ll_usb.c#L2880
2024-01-23T23:58:37 < Laurenceb_> looks like pbUsrBuf is passed as NULL
2024-01-23T23:58:52 < karlp1> (lolrecen is probably almost definitely not telling you what else he broke hacking shit though)
2024-01-23T23:59:13 < zyp> karlp1, yeah, garbage in, garbage out
2024-01-23T23:59:29 < zyp> still, I don't trust vendor code that much more than Laurenceb_ 
2024-01-23T23:59:33 < Laurenceb_> called from here https://github.com/stm32duino/Arduino_Core_STM32/blob/main/system/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_pcd.c#L2538
2024-01-23T23:59:55 < Laurenceb_> its weird - looks like a single byte arrives, thats not expected to happen
--- Day changed ke tammi 24 2024
2024-01-24T00:00:28 < Laurenceb_> and ep->xfer_buff is null, apparently as the endpoint either isnt configured or isnt properly configured
2024-01-24T00:00:45 < zyp> if it's not configured, it shouldn't be able to receive anything
2024-01-24T00:00:49 < Laurenceb_> ah ok
2024-01-24T00:00:52 < Laurenceb_> hmm
2024-01-24T00:01:20 < zyp> usb has flow control, it'll only receive once the stack tells the peripheral that it should
2024-01-24T00:01:21 < Laurenceb_> I'll do some more debugging tomorrow - need to set breakpoints and wait for the failure in the pcd.c file
2024-01-24T00:01:48 < Laurenceb_> I was wondering if the issue could be with Rpi USB stack, as I've tried it with multiple laptops and never seen the issue
2024-01-24T00:01:53 < zyp> any endpoint without state set to valid will drop or nak transfers
2024-01-24T00:02:04 < Laurenceb_> it occurs on Rpi reliably within a minute or so
2024-01-24T00:02:23 < Laurenceb_> ok thanks for that
2024-01-24T00:02:32 < zyp> a misbehaving host shouldn't be able to crash a usb device in any case
2024-01-24T00:03:02 < zyp> I mean, in practice lots of devices are probably vulnerable to malicious hosts, but still
2024-01-24T00:03:10 < Laurenceb_> I could add a check for NULL ep->xfer_buff in pcd.c if nothing else works
2024-01-24T00:06:07 < Laurenceb_> looks like the buffer address is set in HAL_PCD_EP_Receive but I cant see where that is called from
2024-01-24T00:07:27 < karlp1> jpa-: in chibios, how can I find out what my clock speed is?  I'm inside this qmk keyboard firwmare, have never looked at any of the chibios stuff before
2024-01-24T00:11:49 < Laurenceb_> https://github.com/stm32duino/Arduino_Core_STM32/blob/de1e1c5d5092244727d98e4ac5848ff4d3a81550/cores/arduino/stm32/usb/cdc/usbd_cdc.c#L552
2024-01-24T00:11:59 < Laurenceb_> found it, logic on previous lines is weird tho
2024-01-24T00:13:04 < Laurenceb_> sets NULL then checks for not NULL, wtf
2024-01-24T00:32:08 < zyp> so I ended up ordering another mitutoyo caliper from RS instead, and they sent me a «despatch notification» a couple of hours later
2024-01-24T00:32:30 < zyp> but it had no tracking number, and when I check the order status now, it still doesn't say it's despatched…
2024-01-24T00:51:25 -!- martinmoene [~Martin@2a02-a45a-96ba-1-41f5-5e80-8a6b-882e.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-24T00:56:58 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 264 seconds]
2024-01-24T01:09:01 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Quit: Client closed]
2024-01-24T01:19:43 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 256 seconds]
2024-01-24T01:22:23 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-24T01:37:58 -!- jadew [~rcc@5.12.146.135] has quit [Ping timeout: 246 seconds]
2024-01-24T01:51:25 -!- jadew [~rcc@5.12.146.135] has joined ##stm32
2024-01-24T01:56:44 -!- nuxil_ [~nuxil@141.195.51.41] has joined ##stm32
2024-01-24T01:57:07 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2024-01-24T01:57:17 -!- nuxil_ [~nuxil@141.195.51.41] has quit [Read error: Connection reset by peer]
2024-01-24T01:57:23 -!- nuxil_ [~nuxil@141.195.51.41] has joined ##stm32
2024-01-24T02:00:01 -!- _nuxil_ [~nuxil@141.195.51.41] has quit [Ping timeout: 246 seconds]
2024-01-24T02:08:46 < qyx> jpa-: that blake2s-micro doesn't for on G4 for some reason, it generates wrong results, on G0 it works
2024-01-24T02:08:52 < qyx> *doesn't work
2024-01-24T02:19:41 < qyx> sorry on L0 works
2024-01-24T02:19:44 < qyx> weird
2024-01-24T02:56:41 -!- CygniX [~CygniX@user/CygniX] has left ##stm32 [Konversation terminated!]
2024-01-24T03:01:45 -!- CygniX [~CygniX@user/CygniX] has joined ##stm32
2024-01-24T03:32:39 < fenugrec> qyx what ? that is... not supposed to happen
2024-01-24T03:59:13 -!- jadew [~rcc@5.12.146.135] has quit [Ping timeout: 264 seconds]
2024-01-24T04:12:15 -!- jadew [~rcc@5.12.146.135] has joined ##stm32
2024-01-24T04:19:01 -!- jadew [~rcc@5.12.146.135] has quit [Ping timeout: 264 seconds]
2024-01-24T04:32:03 -!- jadew [~rcc@5.12.146.135] has joined ##stm32
2024-01-24T04:47:30 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-24T07:33:06 -!- martinmoene [~Martin@2a02-a45a-96ba-1-edc8-f804-e3a6-de0b.fixed6.kpn.net] has joined ##stm32
2024-01-24T08:01:47 < jpa-> karlp1: you usually have defines for that in board.h
2024-01-24T08:02:12 < jpa-> STM32_SYSCLK
2024-01-24T08:02:41 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-24T08:02:45 < jpa-> sorry, no, not in board.h
2024-01-24T08:02:49 < jpa-> but STM32_SYSCLK in any case
2024-01-24T08:03:42 < jpa-> and mcuconf.h is what determines the PLL settings
2024-01-24T08:03:51 < jpa-> board.h has just the crystal freq
2024-01-24T08:04:18 -!- kow__ [~k\o\w@2607:fea8:1d00:89f0:a9f5:3dea:eea9:8b33] has joined ##stm32
2024-01-24T08:08:05 -!- drkow [~k\o\w@2607:fea8:1d00:89f0:95ac:8634:227b:bd9b] has quit [Ping timeout: 268 seconds]
2024-01-24T08:13:23 -!- martinmoene [~Martin@2a02-a45a-96ba-1-edc8-f804-e3a6-de0b.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-24T08:41:28 < qyx> fenugrec: I'll investigate later, it does produce bad result even for an empty string
2024-01-24T08:42:20 < qyx> I replaced it with the ref impl I was using in this project before and that one gives expected results
2024-01-24T08:59:55 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-24T09:32:34 < jpa-> c code with undefined behavior? unbelievable! ;)
2024-01-24T09:34:01 -!- machinehum [~machinehu@213.55.224.73] has joined ##stm32
2024-01-24T09:38:58 -!- machinehum [~machinehu@213.55.224.73] has quit [Ping timeout: 264 seconds]
2024-01-24T09:41:00 -!- machinehum [~machinehu@213.55.224.73] has joined ##stm32
2024-01-24T10:00:25 -!- machinehum [~machinehu@213.55.224.73] has quit [Ping timeout: 264 seconds]
2024-01-24T10:01:14 -!- machinehum [~machinehu@213.55.224.73] has joined ##stm32
2024-01-24T10:12:20 -!- machinehum2 [~machinehu@213.55.224.73] has joined ##stm32
2024-01-24T10:12:37 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
2024-01-24T10:14:59 -!- machinehum [~machinehu@213.55.224.73] has quit [Ping timeout: 264 seconds]
2024-01-24T10:16:01 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2024-01-24T10:29:49 -!- machinehum2 [~machinehu@213.55.224.73] has quit [Ping timeout: 264 seconds]
2024-01-24T10:35:52 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-24T11:06:10 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has joined ##stm32
2024-01-24T11:33:17 < karlp1> meh, OSBDM on this old k70 twr board has a usb serial connector to the target,
2024-01-24T11:33:24 < karlp1> but it's some proprietary thing
2024-01-24T11:34:07 < karlp1> https://paste.jvnv.net/view/mjai7
2024-01-24T11:34:18 < karlp1> I can't find out the version of mine, but I'm guessing it's 30 or lower :)
2024-01-24T11:37:32 < karlp1> and, of course, PE has discontinued support for osbdm, so it just removed all the files from the web
2024-01-24T12:07:01 < karlp1> fuckign, I just need the damn file, I don't need their support
2024-01-24T12:11:14 < qyx> k ed25519 works
2024-01-24T12:18:10 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-24T12:23:16 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-24T12:39:43 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-24T12:43:59 < karlp1> phew, wayback machine found me the url, and pemicro still had the files, they just dropped all links to it.
2024-01-24T12:44:27 < karlp1> then... because of how flaky the original firmware was, I couldn't connect the bootloader to a windows virtual machine.
2024-01-24T12:45:01 < karlp1> borrowed a colleagues hard windows install, installed the old pemicro files, got it updated and.... I now hve a cdc-acm serial port!
2024-01-24T12:47:28 -!- machinehum [~machinehu@213.55.221.41] has joined ##stm32
2024-01-24T13:08:39 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2024-01-24T13:08:42 < Laurenceb_> hmm this is actually a bit weird
2024-01-24T13:08:44 < Laurenceb_> https://pastes.io/wzbayiovrd
2024-01-24T13:14:00 < Laurenceb_> ok, I was getting confused by the interrupt name
2024-01-24T13:14:15 < Laurenceb_> void USB_H_IRQHandler(void) is the actual name, is there only a single interrupt for usb on F1?
2024-01-24T13:14:58 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has joined ##stm32
2024-01-24T13:52:34 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Quit: Client closed]
2024-01-24T14:22:43 < zyp> karlp1, I'm looking at energy metering solutions for a project, any opinions on what's decent? three phase mains, onboard sensing, galvanic isolation in some form required
2024-01-24T14:38:49 -!- machinehum [~machinehu@213.55.221.41] has quit [Ping timeout: 264 seconds]
2024-01-24T14:40:01 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 264 seconds]
2024-01-24T14:46:40 -!- machinehum [~machinehu@213.55.221.41] has joined ##stm32
2024-01-24T15:02:18 < qyx> so wife was debugging a toy airplane
2024-01-24T15:02:28 < qyx> I gave her a dmm in a continuity test mode, all ok
2024-01-24T15:02:57 < qyx> 30 minutes later she says everything is good and the thing still doesn't work
2024-01-24T15:03:46 < qyx> so checking if there is any power coming, 4.7 V positive on the red wire, looks suspicious
2024-01-24T15:04:07 < qyx> so the +/- drawing in the battery compartment was reversed
2024-01-24T15:04:51 < qyx> *4.7 V positive on the black wire
2024-01-24T15:07:25 < specing> hah
2024-01-24T15:09:26 < specing> qyx: one of the DC jacks I bought in a kit from a local store a decade ago has the polarity markers reversed.. ever since then I'm always continuity testing everything
2024-01-24T15:13:19 < karlp1> isolation for what?
2024-01-24T15:13:39 < karlp1> just buy any china din rail meter with a modbus/mbus/whatever interface?
2024-01-24T15:13:46 < karlp1> eastron sell a bunch cheap,
2024-01-24T15:13:57 < karlp1> gavazzi has cheap "western" ones if you prefer.
2024-01-24T15:14:12 < zyp> no, I'm talking about parts to go onto a PCB
2024-01-24T15:14:29 < karlp1> oh.
2024-01-24T15:14:51 < karlp1> I think atm90e36 is still the best/cheapest, but we never launched with that.  where do you want to put th eisolation?
2024-01-24T15:15:08 < karlp1> there's a few styles that do PDM shits to another metrology part, so your isolation goes there,
2024-01-24T15:15:19 < zyp> yeah atm90e32 is what I've used before, I figure one solution is that plus onboard CTs
2024-01-24T15:15:23 < karlp1> we always just used soic wide isolators.
2024-01-24T15:15:57 < zyp> and yeah, I have a board on my desk using something like MAX78615/MAX78700
2024-01-24T15:18:20 < zyp> hmm, what's the difference between ATM90E32 and E36?
2024-01-24T15:19:23 < karlp1> 1 vs 3 phase
2024-01-24T15:19:36 < karlp1> or is that e23 or somethign?
2024-01-24T15:19:52 < karlp1> e32 vs e36 is then whether it has non-linear CT correction registers, or FFT analysis
2024-01-24T15:19:54 < zyp> ah, no, they're both 3-phase, 36 also has N current sensing
2024-01-24T15:19:54 < karlp1> iirc,
2024-01-24T15:22:50 < zyp> hmm, 36 says it can sample voltage from potential transformer
2024-01-24T15:29:01 < karlp1> well, they all can, you just don't tell them...
2024-01-24T15:29:13 < karlp1> I never ever used PTs in any setup, only ever saw them in docs here and there.
2024-01-24T15:29:14 < zyp> true
2024-01-24T15:29:48 < zyp> wonder if that's mainly relevant for higher voltage shit
2024-01-24T15:29:53 < karlp1> I kinda would like to try some of the china measuring chips, but the three phase ones I've found on lcsc aren't meaningfully cheaper than atm90e32, and with wayyyyy less docs
2024-01-24T15:30:03 < karlp1> yeah, I only normally saw it for 1000v and up stuff.
2024-01-24T15:31:06 < karlp1> we used an analog part on early revisions, but it was expensive and not any better.
2024-01-24T15:31:33 < karlp1> maxim had their own parts, from a teridian acquisition, no idea what AD is doing with the future.
2024-01-24T15:32:00 < karlp1> both those max parts you mentioned are obsolete though, so I guess it's ADxxx only for enerrgy monitoring
2024-01-24T15:32:18 < karlp1> the atm90e parts were an accquisition too, I don't know what mchp will do with them.
2024-01-24T15:45:38 < zyp> the chip on the board I've got here is labelled «iEMP 2152», which google knows *nothing* about
2024-01-24T15:45:58 < zyp> but pinout seems to match MAX78615 at a glance
2024-01-24T15:46:14 < karlp1> that sounds like a schneider meter product..
2024-01-24T15:46:43 < karlp1> nah, not quite.
2024-01-24T15:47:04 -!- karlp1 is now known as karlp
2024-01-24T15:49:01 < zyp> https://bin.jvnv.net/file/ZD1xJ.jpg
2024-01-24T15:50:42 < zyp> oh
2024-01-24T15:51:20 < zyp> it *is* MAX78615, 2152 is YYWW datecode
2024-01-24T15:52:00 < karlp> personally, I don't really like that design, with front ends, isolation per channel, then analog, 
2024-01-24T15:52:05 < karlp> just seems.... wildly unnecessary
2024-01-24T15:52:17 < karlp> but, it seems popular, I guess it has some appeal for some fields or something
2024-01-24T15:52:31 < zyp> I kinda like it
2024-01-24T15:52:41 < karlp> just sticking CTs or rocoils straight onto a single chip, and then a spi isolator...
2024-01-24T15:52:51 < karlp> two parts, instead of what, 10.
2024-01-24T15:52:54 < karlp> no big transformers.
2024-01-24T15:53:00 < zyp> CTs are big transformers :)
2024-01-24T15:53:41 < karlp> are you using this with shunts?
2024-01-24T15:53:44 < karlp> I guess that would do it.
2024-01-24T15:53:55 < zyp> yeah, this board has shunts
2024-01-24T15:53:58 < karlp> we always used external CTs,
2024-01-24T15:54:13 < karlp> and most of the din rail meters I pulled apart just had CTs inside anyway
2024-01-24T15:54:18 < karlp> even "direct wired" ones.
2024-01-24T15:54:50 < karlp> I guess that split style lets you ahve shunts with all sorts of different common voltages then
2024-01-24T15:54:55  * karlp shrugs
2024-01-24T15:55:08 < zyp> sure, but once you're putting the CT on the board, it comes from the same area budget as the other isolation stuff
2024-01-24T15:55:10 < karlp> what would I know, we never made any money...
2024-01-24T15:55:29 < karlp> yeah, but then you don't need a split front and back analog section either :)
2024-01-24T15:55:31 < karlp> (IMO)
2024-01-24T15:55:32 < zyp> so three signal transformers doesn't necessarily look any worse than three CTs
2024-01-24T15:55:51 < zyp> of course
2024-01-24T15:56:14 < zyp> just saying the tradeoffs are fairly even
2024-01-24T15:56:37 < karlp> so 3 cts+ 1 atm90e3x, or 3 cts, three PDM frontends and one multichannel backend...
2024-01-24T15:56:46 < karlp> the later remains unappealing ot me...
2024-01-24T15:56:59 < karlp> but again, we failed... so.. YMMV :)
2024-01-24T15:57:07 < zyp> and then I've got pictures of another board that uses three ACS770…
2024-01-24T15:57:15 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2024-01-24T15:57:17 < zyp> but I really don't want to do the DSP myself
2024-01-24T15:57:18 < karlp> is that for DC though?
2024-01-24T15:57:24 < zyp> no, just line AC
2024-01-24T15:57:27  * Laurenceb_ got some more info on usb error
2024-01-24T15:57:40 < Laurenceb_> looks like Rpi echos back serial data by default
2024-01-24T15:58:10 < Laurenceb_> error comes after the serial buffer wraps around, looks like arduino CDC serial wrapper has an error on received data
2024-01-24T15:59:32 < Laurenceb_> buffer size is 198bytes, but it wraps around after 134bytes, then write pointer gets corrupted after 198bytes
2024-01-24T16:03:04 < Laurenceb_> I think tarduino buffer code is faulty
2024-01-24T16:09:48 < karlp> meh, tried using meson to build this iar/codewarrior tree.  it's trying to use native host CC to compile assembly
2024-01-24T16:14:18 < karlp> oh no, I forgot to tell it a cross file after doin ga clean build
2024-01-24T16:14:20 < karlp> meh
2024-01-24T16:37:18 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Ping timeout: 250 seconds]
2024-01-24T17:12:31 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-24T17:22:49 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has joined ##stm32
2024-01-24T17:23:22 < Laurenceb_> I think the hardfault may have actually been coming from GPIO controller - tarduino kept fidding with the clock config, then if it got interrupted mid way bad things could happen
2024-01-24T17:23:36 < Laurenceb_> I've rewritten the tarduino bitbanged i2c lib
2024-01-24T17:25:05 -!- Laurenceb_ [~Laurenceb@cust226-dsl93-89-135.idnet.net] has quit [Client Quit]
2024-01-24T17:30:15 -!- machinehum [~machinehu@213.55.221.41] has quit [Read error: Connection reset by peer]
2024-01-24T17:30:23 -!- machinehum [~machinehu@213.55.221.41] has joined ##stm32
2024-01-24T17:41:37 -!- machinehum [~machinehu@213.55.221.41] has quit [Ping timeout: 256 seconds]
2024-01-24T17:48:47 -!- machinehum [~machinehu@213.55.221.41] has joined ##stm32
2024-01-24T17:50:22 -!- Ecco_ [~user@user/Ecco] has quit [Read error: Connection reset by peer]
2024-01-24T17:54:23 -!- Ecco [~user@user/Ecco] has joined ##stm32
2024-01-24T18:24:25 -!- machinehum [~machinehu@213.55.221.41] has quit [Ping timeout: 264 seconds]
2024-01-24T18:25:10 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-24T18:33:09 -!- machinehum [~machinehu@213.55.221.41] has joined ##stm32
2024-01-24T18:37:27 < qyx> isn't it 2024 lolrence
2024-01-24T18:40:27 < fenugrec>                                                 
2024-01-24T18:45:35 -!- machinehum [~machinehu@213.55.221.41] has quit [Ping timeout: 264 seconds]
2024-01-24T19:16:33 < Ecco> Are you guys familiar with ST's "NVM Manager" library?
2024-01-24T19:16:40 < Ecco> I have a hard time figuring out what it really does
2024-01-24T19:16:46 < Ecco> I understand that it stores stuff in Flash
2024-01-24T19:16:53 < Ecco> but I don't quite understand the API
2024-01-24T19:18:20 < Ecco> e.g. int NVM_Add( uint8_t type, const uint8_t* data, uint16_t size, const uint8_t* extra_data, uint16_t extra_size );
2024-01-24T19:19:55 -!- fenugrec [~f@192.214.232.39] has quit [Quit: fenugrec]
2024-01-24T19:22:01 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 264 seconds]
2024-01-24T19:25:36 < jpa-> Ecco: do you have a link?
2024-01-24T19:28:26 -!- fenugrec [~f@192.214.232.39] has joined ##stm32
2024-01-24T19:34:17 < qyx> the api sounds legit
2024-01-24T19:39:25 < jpa-> yeah, i would be interested to see what it does, but google didn't find the library
2024-01-24T19:40:17 < qyx> I did a similar nvm thing in the past but afaik I never used it
2024-01-24T19:40:26 < qyx> I plan to do it again and fail again
2024-01-24T19:40:51 < jpa-> i remember qyx talking about it a few weeks ago and i think i'll fail at it too at some point
2024-01-24T19:53:26 < fenugrec> is there a defacto standard for usb-smbus/pmbus/i2c interfaces ? or is it total chaos as it appears to be at first glance
2024-01-24T20:36:02 -!- martinmoene [~Martin@2a02-a45a-96ba-1-e9e8-f1b8-915f-e872.fixed6.kpn.net] has joined ##stm32
2024-01-24T20:59:17 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 252 seconds]
2024-01-24T21:24:35 < jpa-> fenugrec: i2c-tiny-usb has reasonably sane protocol and drivers for many platforms (and included in linux mainstream)
2024-01-24T21:28:01 < jpa-> ftdi is pretty common too but the quality of drivers varies.. some are very slow, and smbus timeout can be an issue
2024-01-24T21:28:14 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-24T21:28:53 -!- qyx [~qyx@84.245.121.89] has quit [Ping timeout: 260 seconds]
2024-01-24T21:30:29 -!- qyx [~qyx@84.245.121.70] has joined ##stm32
2024-01-24T21:43:09 -!- martinmoene [~Martin@2a02-a45a-96ba-1-e9e8-f1b8-915f-e872.fixed6.kpn.net] has quit [Quit: Leaving]
2024-01-24T21:52:09 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has joined ##stm32
2024-01-24T22:25:15 < fenugrec> jpa- thanks, noted
2024-01-24T22:28:57 -!- machinehum [~machinehu@213.55.221.41] has joined ##stm32
2024-01-24T22:29:29 -!- qyx [~qyx@84.245.121.70] has quit [Ping timeout: 256 seconds]
2024-01-24T22:31:05 -!- qyx [~qyx@84.245.121.62] has joined ##stm32
2024-01-24T22:32:21 < qyx> I am genuinely saddened by printf
2024-01-24T22:41:21 < Steffanx> What did printf do this time qyx?
2024-01-24T22:45:13 -!- martinmoene [~Martin@2a02-a45a-96ba-1-d916-c863-c994-1a67.fixed6.kpn.net] has joined ##stm32
2024-01-24T22:48:38 < Ecco> jpa-: Here's where I found this: https://github.com/STMicroelectronics/STM32CubeWBA/tree/main/Projects/NUCLEO-WBA55CG/Applications/BLE/BLE_HeartRate/System/Modules/Nvm
2024-01-24T22:48:59 < Ecco> There's a header file, and a "fake" implementation that stores stuff in RAM
2024-01-24T22:49:26 < Ecco> I don't really understand what the functions are supposed to be doing just from their signature
2024-01-24T22:54:06 < qyx> it takes precious space Steffanx 
2024-01-24T23:00:25 -!- machinehum [~machinehu@213.55.221.41] has quit [Ping timeout: 264 seconds]
2024-01-24T23:17:53 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-24T23:21:17 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 240 seconds]
2024-01-24T23:38:53 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-24T23:43:52 -!- machinehum [~machinehu@213.55.221.41] has joined ##stm32
2024-01-24T23:47:04 < PaulFertser> BTW, sometimes when looking for weird stuff being logged in on Github and searching through the code gives useful hints, in this case one could do https://github.com/search?q=%22int+NVM_Add%28%22&type=code
2024-01-24T23:48:25 -!- machinehum [~machinehu@213.55.221.41] has quit [Ping timeout: 264 seconds]
--- Day changed to tammi 25 2024
2024-01-25T00:00:51 < karlp> Ecco: iirc, that nvm stuff is just part of the btle stack, as they need a method of storing pairing stuff.
2024-01-25T00:00:57 < karlp> and it's just a stub?
2024-01-25T00:21:09 < Ecco> karlp: yeah, you're spot on
2024-01-25T00:21:16 < Ecco> so AFAIK they only provide a stub
2024-01-25T00:21:25 < Ecco> honestly, I don't reallt care
2024-01-25T00:21:29 < Ecco> but I wish I understood the API
2024-01-25T00:21:42 < Ecco> how am I supposed to implement it if I don't even know how it's supposed to behave?
2024-01-25T00:29:42 -!- machinehum [~machinehu@213.55.221.41] has joined ##stm32
2024-01-25T00:34:12 -!- machinehum [~machinehu@213.55.221.41] has quit [Ping timeout: 256 seconds]
2024-01-25T00:48:56 -!- martinmoene [~Martin@2a02-a45a-96ba-1-d916-c863-c994-1a67.fixed6.kpn.net] has quit [Ping timeout: 268 seconds]
2024-01-25T01:03:31 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 276 seconds]
2024-01-25T01:14:19 -!- machinehum [~machinehu@213.55.221.41] has joined ##stm32
2024-01-25T01:19:01 -!- machinehum [~machinehu@213.55.221.41] has quit [Ping timeout: 264 seconds]
2024-01-25T01:34:50 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2024-01-25T02:01:32 -!- machinehum [~machinehu@213.55.221.41] has joined ##stm32
2024-01-25T02:03:52 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-25T02:03:56 < Laurenceb_> >This is 10x scarier than some square jawed chad who looks like he can handle himself, it's just some fucking perverted lunatic sitting in his drone pilot seat with a butt plug in his ass dressed as a basset hound
2024-01-25T02:04:17 < Laurenceb_> my sides are in orbit
2024-01-25T02:05:57 -!- machinehum [~machinehu@213.55.221.41] has quit [Ping timeout: 256 seconds]
2024-01-25T02:21:48 < jbo> yo o/
2024-01-25T02:27:00 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Quit: Client closed]
2024-01-25T02:52:18 -!- machinehum [~machinehu@213.55.221.41] has joined ##stm32
2024-01-25T02:56:49 -!- machinehum [~machinehu@213.55.221.41] has quit [Ping timeout: 264 seconds]
2024-01-25T03:14:56 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-25T03:43:29 -!- machinehum [~machinehu@213.55.221.41] has joined ##stm32
2024-01-25T03:47:23 -!- jadew [~rcc@5.12.146.135] has quit [Ping timeout: 264 seconds]
2024-01-25T03:47:49 -!- machinehum [~machinehu@213.55.221.41] has quit [Ping timeout: 264 seconds]
2024-01-25T04:00:07 -!- jadew [~rcc@5.12.180.134] has joined ##stm32
2024-01-25T04:19:53 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Remote host closed the connection]
2024-01-25T04:34:31 -!- machinehum [~machinehu@213.55.221.41] has joined ##stm32
2024-01-25T04:39:25 -!- machinehum [~machinehu@213.55.221.41] has quit [Ping timeout: 264 seconds]
2024-01-25T05:29:20 -!- machinehum [~machinehu@213.55.221.41] has joined ##stm32
2024-01-25T05:34:01 -!- machinehum [~machinehu@213.55.221.41] has quit [Ping timeout: 264 seconds]
2024-01-25T06:22:11 -!- machinehum [~machinehu@213.55.221.41] has joined ##stm32
2024-01-25T06:26:49 -!- machinehum [~machinehu@213.55.221.41] has quit [Ping timeout: 264 seconds]
2024-01-25T06:56:40 -!- Guest55 [~Guest55@ec2-13-239-136-157.ap-southeast-2.compute.amazonaws.com] has joined ##stm32
2024-01-25T07:11:23 -!- machinehum [~machinehu@213.55.221.41] has joined ##stm32
2024-01-25T07:16:01 -!- machinehum [~machinehu@213.55.221.41] has quit [Ping timeout: 264 seconds]
2024-01-25T07:43:26 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-25T07:56:19 -!- machinehum [~machinehu@213.55.221.41] has joined ##stm32
2024-01-25T08:00:56 -!- machinehum [~machinehu@213.55.221.41] has quit [Ping timeout: 252 seconds]
2024-01-25T08:01:47 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 264 seconds]
2024-01-25T08:02:28 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-25T08:10:03 -!- nuxil_ [~nuxil@141.195.51.41] has quit [Read error: Connection reset by peer]
2024-01-25T08:10:13 -!- nuxil [~nuxil@141.195.51.41] has joined ##stm32
2024-01-25T08:21:37 -!- nuxil_ [~nuxil@141.195.51.41] has joined ##stm32
2024-01-25T08:22:01 -!- nuxil [~nuxil@141.195.51.41] has quit [Ping timeout: 264 seconds]
2024-01-25T08:32:39 < jpa-> Ecco: API seems relatively straighforward to me: NVMCB_Store you are supposed to provide for writing to flash, NVM_buffer provided to init should be a RAM copy of the flash block
2024-01-25T08:33:24 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-25T08:35:38 < jpa-> it stores a list of values, each list identified by "type", NVM_Add is used to add new item to stored list, NVM_Get is used to read out items from the list, NVM_Discard can remove entries from the list
2024-01-25T08:36:06 < jpa-> funnily the API is stateful, i.e. if you use NVM_Get() to get entry, then NVM_Discard(NVM_CURRENT) is used to remove it
2024-01-25T08:37:51 < jpa-> i don't quite see how flash erase is supposed to happen
2024-01-25T08:38:17 < jpa-> i guess NVMCB_Store is supposed to do that, or possibly it is supposed to run with eeprom that can be erased per-word
2024-01-25T08:39:12 < jpa-> the "data" and "extra_data" provided to NVM_Add are just concatenated, i think it is a simplified version of multi-buffer gather-scatter mechanism
2024-01-25T08:42:43 -!- machinehum [~machinehu@213.55.221.41] has joined ##stm32
2024-01-25T08:47:25 -!- machinehum [~machinehu@213.55.221.41] has quit [Ping timeout: 260 seconds]
2024-01-25T09:00:40 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-25T09:09:30 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-25T09:09:56 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-25T09:29:13 -!- Guest55 [~Guest55@ec2-13-239-136-157.ap-southeast-2.compute.amazonaws.com] has quit [Quit: Client closed]
2024-01-25T09:30:18 -!- machinehum [~machinehu@213.55.221.41] has joined ##stm32
2024-01-25T09:52:38 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2024-01-25T09:52:56 -!- machinehum [~machinehu@213.55.221.41] has quit [Ping timeout: 256 seconds]
2024-01-25T10:03:47 -!- specing [~specing@user/specing] has quit [Quit: ZNC - https://znc.in]
2024-01-25T10:05:38 -!- specing [~specing@user/specing] has joined ##stm32
2024-01-25T10:05:41 -!- machinehum [~machinehu@213.55.221.41] has joined ##stm32
2024-01-25T10:14:01 -!- martinmoene [~Martin@2a02-a45a-96ba-1-c183-197e-7b46-42de.fixed6.kpn.net] has joined ##stm32
2024-01-25T10:35:57 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-25T11:17:58 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-25T11:18:25 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-25T11:21:24 -!- machinehum2 [~machinehu@213.55.221.57] has joined ##stm32
2024-01-25T11:24:25 -!- machinehum [~machinehu@213.55.221.41] has quit [Ping timeout: 264 seconds]
2024-01-25T11:55:22 -!- martinmoene [~Martin@2a02-a45a-96ba-1-c183-197e-7b46-42de.fixed6.kpn.net] has quit [Ping timeout: 255 seconds]
2024-01-25T12:00:44 -!- machinehum2 [~machinehu@213.55.221.57] has quit [Ping timeout: 252 seconds]
2024-01-25T12:02:03 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-25T12:02:36 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-25T12:03:18 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-25T12:15:16 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-25T12:24:36 -!- machinehum [~machinehu@213.55.221.57] has joined ##stm32
2024-01-25T12:53:14 -!- martinmoene [~Martin@2a02-a45a-96ba-1-c183-197e-7b46-42de.fixed6.kpn.net] has joined ##stm32
2024-01-25T12:53:30 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-509f-d7d2-e5fb-8e71.fixed6.kpn.net] has joined ##stm32
2024-01-25T12:57:33 -!- martinmoene [~Martin@2a02-a45a-96ba-1-c183-197e-7b46-42de.fixed6.kpn.net] has quit [Ping timeout: 260 seconds]
2024-01-25T13:11:08 -!- machinehum [~machinehu@213.55.221.57] has quit [Ping timeout: 252 seconds]
2024-01-25T13:27:25 -!- machinehum [~machinehu@213.55.221.57] has joined ##stm32
2024-01-25T13:42:49 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-509f-d7d2-e5fb-8e71.fixed6.kpn.net] has quit [Ping timeout: 260 seconds]
2024-01-25T13:52:42 < karlp> if I want to put constant data into a section, can't I just mark it with an attribute, and then KEEP() it in the linker?
2024-01-25T13:55:03 < karlp> I compile as https://paste.jvnv.net/view/PDm1A
2024-01-25T13:55:23 < karlp> but I get  no discarded sections, but objdump -D or -x or whatever never shows my ".fopt" section anywhere.
2024-01-25T13:56:17 < karlp> linker just looks like this https://paste.jvnv.net/view/sbHun
2024-01-25T13:57:44 < jpa-> with data sections, your .fopt might be called .fopt.1234
2024-01-25T13:57:56 < jpa-> so maybe try .fopt* in linker script
2024-01-25T13:58:19 < karlp> objdump -D and -x should show the .fopt first though?
2024-01-25T13:58:32 < jpa-> dunno
2024-01-25T13:58:39 < jpa-> does it show up for intermediate .o?
2024-01-25T13:58:52 < karlp> no. that's what I'm looking at to see if it's working at all
2024-01-25T13:59:04 < karlp> ah, it needed "used" attribute to get into the .o
2024-01-25T13:59:56 < karlp> ok, it's in the .elf now.
2024-01-25T14:00:02 < karlp> let's try and flash this shit again...
2024-01-25T14:00:58 < jpa-> funny that it doesn't get into .o without used, considering it is not static
2024-01-25T14:11:31 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-25T14:12:00 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-25T14:25:14 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-509f-d7d2-e5fb-8e71.fixed6.kpn.net] has joined ##stm32
2024-01-25T14:27:06 -!- machinehum [~machinehu@213.55.221.57] has quit [Ping timeout: 260 seconds]
2024-01-25T14:27:21 < PaulFertser> nxp reference manual download asks me to "(1) treat the Documentation as confidential information, and use reasonable measures to protect the Documentation from misappropriation or misuse;"
2024-01-25T14:27:33 < PaulFertser> Confidential for real?!
2024-01-25T14:33:40 < karlp> yeah, nxp is fucking weird as shit
2024-01-25T14:34:03 < qyx> so you can read it but not tell anybody?
2024-01-25T14:35:00 < karlp> fucking no wonder I have such pain.
2024-01-25T14:35:16 < karlp> when it's locked/protected hell, one of the memory regions is reading as zero,
2024-01-25T14:35:25 < karlp> and there's a K10 part with a 0 part number apparently.
2024-01-25T14:35:33  * karlp hacks on oocd some more
2024-01-25T14:44:07 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-509f-d7d2-e5fb-8e71.fixed6.kpn.net] has quit [Ping timeout: 255 seconds]
2024-01-25T14:53:07 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-25T14:53:59 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-25T15:04:10 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has joined ##stm32
2024-01-25T15:24:27 -!- machinehum [~machinehu@213.55.221.57] has joined ##stm32
2024-01-25T15:48:52 -!- machinehum2 [~machinehu@67.240.0.85.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-25T15:50:22 -!- machinehum [~machinehu@213.55.221.57] has quit [Ping timeout: 264 seconds]
2024-01-25T15:54:12 -!- machinehum [~machinehu@67.240.0.85.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-25T15:54:25 -!- machinehum2 [~machinehu@67.240.0.85.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 264 seconds]
2024-01-25T16:02:59 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-25T16:03:07 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2024-01-25T16:04:01 -!- machinehum [~machinehu@67.240.0.85.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 264 seconds]
2024-01-25T16:05:32 -!- machinehum [~machinehu@67.240.0.85.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-25T16:06:27 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-25T16:08:55 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-25T16:19:47 -!- machinehum [~machinehu@67.240.0.85.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 264 seconds]
2024-01-25T16:20:27 -!- machinehum [~machinehu@2a02:1210:4e1a:b000:9bd:5bfa:6833:8de] has joined ##stm32
2024-01-25T16:22:01 -!- machinehum2 [~machinehu@2a02:1210:4e1a:b000:6084:cee3:5f4:d5fc] has joined ##stm32
2024-01-25T16:25:04 -!- machinehum [~machinehu@2a02:1210:4e1a:b000:9bd:5bfa:6833:8de] has quit [Ping timeout: 256 seconds]
2024-01-25T16:26:47 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-25T16:27:15 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-25T16:30:56 -!- machinehum [~machinehu@67.240.0.85.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-25T16:31:15 -!- machinehum2 [~machinehu@2a02:1210:4e1a:b000:6084:cee3:5f4:d5fc] has quit [Ping timeout: 256 seconds]
2024-01-25T16:33:09 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-25T16:33:42 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-25T16:35:15 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-25T16:35:59 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-25T16:36:25 -!- machinehum [~machinehu@67.240.0.85.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 264 seconds]
2024-01-25T16:37:22 -!- jadew [~rcc@5.12.180.134] has quit [Quit: WeeChat 2.8]
2024-01-25T16:53:57 -!- machinehum [~machinehu@67.240.0.85.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-25T16:54:03 -!- nuxil_ [~nuxil@141.195.51.41] has quit [Read error: Connection reset by peer]
2024-01-25T16:58:09 -!- machinehum [~machinehu@67.240.0.85.dynamic.wline.res.cust.swisscom.ch] has quit [Read error: Connection reset by peer]
2024-01-25T16:58:19 -!- machinehum [~machinehu@67.240.0.85.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-25T16:58:23 -!- nuxil [~nuxil@141.195.51.41] has joined ##stm32
2024-01-25T17:02:43 -!- machinehum [~machinehu@67.240.0.85.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 255 seconds]
2024-01-25T17:05:01 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-25T17:05:26 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-25T17:16:55 < karlp> look at this shit: https://paste.jvnv.net/view/SAMqh  what fanstically legible tripe
2024-01-25T17:20:19 -!- machinehum [~machinehu@2a02:1210:4e1a:b000:9001:7a4c:784b:3678] has joined ##stm32
2024-01-25T17:22:37 < fenugrec> fanstically ?
2024-01-25T17:28:01 -!- machinehum [~machinehu@2a02:1210:4e1a:b000:9001:7a4c:784b:3678] has quit [Ping timeout: 264 seconds]
2024-01-25T17:29:56 -!- machinehum [~machinehu@213.55.221.57] has joined ##stm32
2024-01-25T17:34:43 -!- machinehum [~machinehu@213.55.221.57] has quit [Ping timeout: 256 seconds]
2024-01-25T17:42:32 -!- machinehum [~machinehu@213.55.221.57] has joined ##stm32
2024-01-25T18:02:16 < karlp> imagine it said fantastically instead.
2024-01-25T18:04:52 < fenugrec> I don't know if I have enough imgatination
2024-01-25T18:07:46 < karlp> (the defines do nothing.
2024-01-25T18:07:55 < karlp> it's x shifted by zero, anded with all 32bits.
2024-01-25T18:08:00 < fenugrec> heh
2024-01-25T18:08:20 < karlp> I presume it's generated code, but... who knows.
2024-01-25T18:08:33 < karlp> anyway, laks startup code for kinetis k70 works...
2024-01-25T18:09:03 < karlp> traps for the unwary: kinetis watchdog is enabled from power on reset....
2024-01-25T18:09:54 -!- machinehum [~machinehu@213.55.221.57] has quit [Ping timeout: 256 seconds]
2024-01-25T18:12:32 -!- machinehum [~machinehu@213.55.221.57] has joined ##stm32
2024-01-25T18:18:55 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-25T18:19:21 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-25T18:21:40 -!- machinehum [~machinehu@213.55.221.57] has quit [Ping timeout: 246 seconds]
2024-01-25T18:22:19 < qyx> lol
2024-01-25T18:29:44 -!- qyx [~qyx@84.245.121.62] has quit [Ping timeout: 256 seconds]
2024-01-25T18:30:13 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-4eb-76bb-96f4-d5d8.fixed6.kpn.net] has joined ##stm32
2024-01-25T18:30:20 -!- qyx [~qyx@84.245.120.104] has joined ##stm32
2024-01-25T18:35:32 < karlp> is my 15 year old debugger working? is my flash option section programming working? who knows?!
2024-01-25T18:37:16 < jpa-> neither of them is working
2024-01-25T18:38:10 < jpa-> in addition, there are 6 unrelated bugs in your tools that you will hit before figuring out the simple mistake in your code
2024-01-25T18:38:22 < karlp> correct!
2024-01-25T19:03:19 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-4eb-76bb-96f4-d5d8.fixed6.kpn.net] has quit [Ping timeout: 246 seconds]
2024-01-25T19:32:27 -!- jerkey [~jerkey@artsf1.spaz.org] has quit [Read error: Connection reset by peer]
2024-01-25T19:37:57 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-25T20:15:07 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 260 seconds]
2024-01-25T20:42:08 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-4eb-76bb-96f4-d5d8.fixed6.kpn.net] has joined ##stm32
2024-01-25T20:47:00 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-25T20:52:31 -!- jdelmore [~jdelmore@12.206.45.226] has joined ##stm32
2024-01-25T21:14:38 -!- sugarbeet [~barbas@81.4.123.134] has quit [Ping timeout: 256 seconds]
2024-01-25T21:15:01 -!- sugarbeet [~barbas@81.4.123.134] has joined ##stm32
2024-01-25T21:54:56 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-25T22:07:22 -!- pragmalin [~pragmalin@user/pragmalin] has joined ##stm32
2024-01-25T22:12:35 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 264 seconds]
2024-01-25T22:34:36 -!- machinehum [~machinehu@0.58.77.83.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-25T22:48:47 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-25T22:54:26 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-25T23:01:49 -!- machinehum [~machinehu@0.58.77.83.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 256 seconds]
2024-01-25T23:03:31 -!- pragmalin [~pragmalin@user/pragmalin] has quit [Quit: Leaving]
2024-01-25T23:16:02 < jdelmore> does anyone have a good portable C reference they like for ymodem transfer?
2024-01-25T23:17:58 < karlp> do you _need_ to use ymodem?
2024-01-25T23:19:28 < qyx> I don't think we have anything usable for any *modem
2024-01-25T23:23:02 < ventYl> '80s have left the building
2024-01-25T23:27:06 < karlp> what's the trendy way of doing chunked file transfer over serial these days?
2024-01-25T23:28:08 < ventYl> HTTP3 over TCP over IP over serial?
2024-01-25T23:28:16 < qyx> I don't have anything
2024-01-25T23:28:23 < qyx> and I need something
2024-01-25T23:28:39 < qyx> preferably something driverless, hassleless, softwareless
2024-01-25T23:30:03 < qyx> probably soemthing with python-fuse could be hacked together and some stateless protocol, could work on windows too
2024-01-25T23:30:09 < karlp> I'm going to have to do a custom bootloader over serial soon, and it's the same channel used for board2board comms already (what? yu think we should have done the bootloader first? hahhhahaaha)
2024-01-25T23:30:23 < karlp> and the current comms are a wild mix of binary and json interspersed,
2024-01-25T23:30:37 < karlp> I was thinking of ppp or slip or hdlc and get some framing and channels,
2024-01-25T23:30:47 < karlp> but sounds gross too.
2024-01-25T23:30:53 < qyx> I would never touch ppp nor hdlc
2024-01-25T23:30:57 < karlp> why not?
2024-01-25T23:31:03  * ventYl used can-over-serial
2024-01-25T23:31:08 < karlp> cant you use "just the good bits" ?
2024-01-25T23:31:22 < qyx> it sounds more complex than my brian can handle
2024-01-25T23:31:26 < karlp> or should we just use ymodem?
2024-01-25T23:31:34 < qyx> tbh I don't know
2024-01-25T23:31:39 < qyx> it makes me sad
2024-01-25T23:31:51 < qyx> I hacked up some xmodem in the past to work under freertos
2024-01-25T23:31:58 < karlp> https://github.com/mengguang/minihdlc
2024-01-25T23:32:02 < qyx> but single direction only (pc -> mcu)
2024-01-25T23:33:59 < qyx> fuk that contextless lib
2024-01-25T23:34:06 < qyx> it just made me angr
2024-01-25T23:34:09 < karlp> hahah
2024-01-25T23:34:11 < karlp> first one I found.
2024-01-25T23:34:17 < karlp> not normally hard to expand...
2024-01-25T23:34:19 < qyx> https://github.com/mengguang/minihdlc/blob/master/minihdlc.c#L58
2024-01-25T23:34:52 < karlp> just change init to hve the context, not a huge deal.
2024-01-25T23:34:58 < qyx> how on earth can anyone program this, he must have been singleton-poisoned
2024-01-25T23:35:05 < karlp> it was arduino absteraction.
2024-01-25T23:35:12 < karlp> it works jsut fine when you onyl have one of anything ever....
2024-01-25T23:35:32 < qyx> yeah that's what I call singleton-poisoning and java programmers are full of that
2024-01-25T23:35:52 < karlp> still, super easy to convert to instance based.
2024-01-25T23:36:39 < karlp> I mean, the bigger issue is that it sends a buffer out byte by byte,
2024-01-25T23:36:40 < qyx> and now I am being sad because ppp sounds really as the only feasible option to get a more reasonable protocol stack
2024-01-25T23:36:48 < karlp> which is goign to be grossssss perf wise.
2024-01-25T23:36:59 < karlp> jdelmore: so.... what are you doing?
2024-01-25T23:38:12 < qyx> but I just recall LCP, those IDs for pairing messages, ping requests, compression, packet header compression, IP/DNS/etc ngotiation
2024-01-25T23:38:24 < qyx> MPPE, fuk MPPE
2024-01-25T23:38:34 < qyx> I know I can disable all this
2024-01-25T23:40:23 < karlp> I want something that basically gives me multiple channels over a serial link, without me doing it myself...
2024-01-25T23:42:35 < karlp> https://github.com/bang-olufsen/hdlcpp ?
2024-01-25T23:42:57 < qyx> hm, I am reading about SLIP and it looks super easy
2024-01-25T23:43:05 < karlp> yeah, but slip is only one channel isn't it?
2024-01-25T23:43:10 < karlp> slip is meant to be super easy, yeah
2024-01-25T23:43:24 < qyx> slip is basically IP put into a serial + framed
2024-01-25T23:43:33 < qyx> you can get multiple channels over IP
2024-01-25T23:43:35 < qyx> on top of it
2024-01-25T23:43:52 < qyx> do you mean multiple *serial* channels, one of them being IP?
2024-01-25T23:44:50 < karlp> no, more like i have multiple "applications" running, and want them all to have their own path to the other board.
2024-01-25T23:44:52 < qyx> Exploring SLIP Networking Over UART with Zephyr and Linux: A Quick Guide
2024-01-25T23:44:59 < qyx> https://swedishembedded.com/insights-slip-networking/
2024-01-25T23:45:04 < karlp> yeah, fuck this, I need to do this on company time...
2024-01-25T23:45:33 < karlp> loko at jdelmore just throwing out a nerdsnipe and leaving...
2024-01-25T23:46:43 < karlp> oh right, yeah, slip just is an greedment on framing. 
2024-01-25T23:47:47 < karlp> so, like cobs, jsut... not.
2024-01-25T23:48:27 < karlp> I want the  bit on top done for me as well, but I guess i'm not really going to get that, that's "my app"
2024-01-25T23:50:54 < karlp> heh, the bang olufsen hdlcpp uses nanopb as a reference of what you put inside...
2024-01-25T23:51:27 < qyx> ok closing works stuff now too
2024-01-25T23:51:31 < karlp> hahah
2024-01-25T23:51:58 < qyx> today I managed to work 3.5 hours net time
2024-01-25T23:52:15 < jdelmore> karlp: I'm trying to put together a reliable means to side-load a binary image. The nice part about x/ymodem is that it is small for an MCU. The biggest advantage is there are plenty of off the shelf client applications that support the protocol. 
2024-01-25T23:52:18 < qyx> I need to order a budget dmm for fieldwork
2024-01-25T23:52:20 < karlp> I got bare metal blink working on k70, I'm quite pleased really, even if it took a lot longer htan expected.
2024-01-25T23:53:38 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Ping timeout: 250 seconds]
2024-01-25T23:59:33 < karlp> heh, st uses ymodem for the sbsfu shit on wb/wl?
--- Day changed pe tammi 26 2024
2024-01-26T00:00:45 < jdelmore> just because it is old doesn't mean it isn't useful. crc16, 128/1K block size. It's pretty solid for transferring binary blobs over serial. 
2024-01-26T00:02:57 < karlp> why not zmodem then?
2024-01-26T00:03:15 < karlp> instead of just the xmodem with bandaids?
2024-01-26T00:03:23 < karlp> picocom can do it inline, 
2024-01-26T00:03:45 < karlp> sz and rz shits.
2024-01-26T00:04:40 < jdelmore> size mostly. I looked a few zmodem implementations and it looks like a decent amount of code for something that would rarely be used on field devices that typically receive updates OTA
2024-01-26T00:04:52 < karlp> fair enough.
2024-01-26T00:05:09 < karlp> I've done it over modbus before...
2024-01-26T00:05:31 < karlp> though that's more useful if you are already using modbus...
2024-01-26T00:18:34 < qyx> k ordering https://eleshop.eu/owon-ow18b-mv.html
2024-01-26T00:18:44 < qyx> as a cheap tool
2024-01-26T00:19:18 < qyx> with bluetooth, I hope the auto-off function can be switched off
2024-01-26T00:19:30 < qyx> otherwise it is unusable as a simple daq for large battery packs
2024-01-26T00:36:54 -!- boB_K7IQ [~boB_K7IQ@184-98-66-243.phnx.qwest.net] has joined ##stm32
2024-01-26T00:50:04 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has joined ##stm32
2024-01-26T00:51:05 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-4eb-76bb-96f4-d5d8.fixed6.kpn.net] has quit [Ping timeout: 260 seconds]
2024-01-26T00:59:41 < qyx> how would you place a lcd/oled display to a alu front panel, 2 mm thick?
2024-01-26T00:59:58 < qyx> would you cover it with a plexiglass or just nothing and yolo?
2024-01-26T01:02:03 -!- Spirit532 [~Spirit532@user/Spirit532] has quit [Killed (NickServ (GHOST command used by Spirit5325))]
2024-01-26T01:02:08 -!- Spirit532 [~Spirit532@user/Spirit532] has joined ##stm32
2024-01-26T01:08:23 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-26T01:09:10 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-26T01:17:48 < nomorekaki> for superior readability nothing
2024-01-26T01:23:19 < nomorekaki> and common size lcds might have panel mount bezels made for them
2024-01-26T01:23:23 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 268 seconds]
2024-01-26T01:33:04 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-26T02:19:58 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 276 seconds]
2024-01-26T02:33:34 -!- nomorekaki [~nomorekak@176-93-92-158.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-26T03:08:09 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-26T03:49:01 -!- jdelmore [~jdelmore@12.206.45.226] has quit [Ping timeout: 276 seconds]
2024-01-26T05:16:19 -!- GenTooMan [~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883] has quit [Read error: Connection reset by peer]
2024-01-26T05:46:57 -!- cybernaut [~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883] has joined ##stm32
2024-01-26T07:47:47 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-e856-648e-972-6dc2.fixed6.kpn.net] has joined ##stm32
2024-01-26T07:56:13 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-e856-648e-972-6dc2.fixed6.kpn.net] has quit [Ping timeout: 264 seconds]
2024-01-26T08:01:27 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-26T08:14:54 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-26T08:50:16 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-26T08:50:42 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-26T09:00:19 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-26T09:19:32 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2024-01-26T09:36:30 -!- jtj [~jtj@212.66.207.170] has quit [Ping timeout: 260 seconds]
2024-01-26T09:37:09 -!- jtj [~jtj@212.66.207.170] has joined ##stm32
2024-01-26T09:41:58 -!- jtj [~jtj@212.66.207.170] has quit [Ping timeout: 276 seconds]
2024-01-26T10:27:25 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-26T10:27:52 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-26T10:31:13 -!- machinehum [~machinehu@0.58.77.83.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-26T10:43:56 -!- machinehum [~machinehu@0.58.77.83.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 268 seconds]
2024-01-26T10:45:06 -!- machinehum [~machinehu@0.58.77.83.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-26T10:47:49 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-26T11:06:38 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-26T12:30:31 -!- machinehum [~machinehu@0.58.77.83.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 246 seconds]
2024-01-26T12:32:35 -!- machinehum [~machinehu@0.58.77.83.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-26T12:44:05 -!- machinehum [~machinehu@0.58.77.83.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 252 seconds]
2024-01-26T12:45:57 -!- machinehum [~machinehu@0.58.77.83.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-26T13:08:42 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-26T13:09:17 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-26T13:09:21 -!- machinehum [~machinehu@0.58.77.83.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 260 seconds]
2024-01-26T13:11:06 -!- pragmalin [~pragmalin@user/pragmalin] has joined ##stm32
2024-01-26T13:14:42 < mawk> is it realist to use openocd to extract stuff from the eeprom of a running device 
2024-01-26T13:14:45 < mawk> external eeprom
2024-01-26T13:14:51 < mawk> so have to use I2C or whatever
2024-01-26T13:14:54 < mawk> sounds annoying
2024-01-26T13:16:48 < qyx> I would use usb-i2c bridge instead
2024-01-26T13:17:13 < qyx> idk how openocd fits into this scenario
2024-01-26T13:18:59 < jpa-> if you have a function for i2c access in the running firmware, you could just break into gdb and call that function
2024-01-26T13:19:10 < mawk> right
2024-01-26T13:19:13 < mawk> yeah there is one
2024-01-26T13:19:27 < mawk> but I lost the .elf for the running firmware so I can't debug 
2024-01-26T13:19:30 < mawk> or I can, but in assembly
2024-01-26T13:19:33 < jpa-> lol
2024-01-26T13:20:07 < jpa-> it's not like uploading new firmware will change the eeprom contents, so you could just read out the old firmware and switch to new build
2024-01-26T13:20:36 < jpa-> but usb-i2c can indeed be easier
2024-01-26T13:22:58 < mawk> I waited like a whole month for the firmware to trigger some weird bug, if I reset the device it will be gone
2024-01-26T13:23:20 < jpa-> ok, time to poke i2c registers then :)
2024-01-26T13:23:21 < mawk> but I guess since I don't have the .elf there's not much I can do anyway
2024-01-26T13:23:32 < jpa-> you know the register addresses, so it is doable
2024-01-26T13:23:34 < mawk> yeah
2024-01-26T13:23:39 < jpa-> just annoying
2024-01-26T13:24:06 < jpa-> i like to do stuff like that from gdb rather than openocd directly, but either works
2024-01-26T13:25:06 < mawk> ah it's SPI, I don't know if that's better or worse
2024-01-26T13:25:11 < mawk> yeah from gdb is better I guess
2024-01-26T13:25:25 -!- boB_K7IQ [~boB_K7IQ@184-98-66-243.phnx.qwest.net] has quit [Ping timeout: 256 seconds]
2024-01-26T13:27:33 < mawk> I lost the elf because I made a slight typo in a rsync invocation in a script
2024-01-26T13:27:37 < mawk> which delete my entire home folder
2024-01-26T13:27:49 < mawk> cool stuff
2024-01-26T13:28:02 < mawk> now I added a safety to the script, if it detects it's about to delete more than 10 files it prompts the user
2024-01-26T13:28:57 -!- boB_K7IQ [~boB_K7IQ@184-98-171-178.phnx.qwest.net] has joined ##stm32
2024-01-26T13:33:30 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-26T13:36:35 < jpa-> time to enable filesystem snapshots
2024-01-26T13:37:11 < mawk> yeah
2024-01-26T13:37:37 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 264 seconds]
2024-01-26T13:59:22 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2024-01-26T14:12:36 -!- nuxil_ [~nuxil@141.195.51.41] has joined ##stm32
2024-01-26T14:16:10 -!- nuxil [~nuxil@141.195.51.41] has quit [Ping timeout: 264 seconds]
2024-01-26T14:23:15 < karlp> zyp: have a fun laks ... concern?
2024-01-26T14:24:05 < karlp> I hve https://github.com/karlp/laks/blob/wip/kinetis1/nxp_kx/nxp_sim_k70.h#L9
2024-01-26T14:24:36 < karlp> so.. if you do: source laks/gdb_plugins/mmio.py, 
2024-01-26T14:24:49 < karlp> then `p /x *$mmio_ptr(SIM)`
2024-01-26T14:24:53 < karlp> you get all zeros...
2024-01-26T14:25:15 < karlp> (if you pay attention,  you get an error in the openocd window about failed to read memory at ... (corresponding to the reserved section)
2024-01-26T14:25:39 < karlp> so if you read something out directly, like `(gdb) p /x (*$mmio_ptr(SIM))->SDID`  you get the "correct" values...
2024-01-26T14:26:18 < karlp> but only for each field at a time...
2024-01-26T14:26:52 < karlp> given the way the mmio plugin is  just passing poiners back to gdb, I'mguessing it can't be "fixed" there,
2024-01-26T14:27:08 < karlp> it would need to be ... gluing two structs together some other way to avoid the inaccesible memory or something.
2024-01-26T14:27:42 < karlp> it's probably minor in practice.  just having weird resets, and I _thought_ I'd figured out this watchdog entirely yesterday.
2024-01-26T14:31:14 < karlp> but I have the same problem there, even without any reserved words.
2024-01-26T14:31:34 < karlp> it has 16bit accesses, and it'ðs like gdb just tries to do 32bit reads and the kinetis gets upset?
2024-01-26T14:32:25 < karlp> like this: https://paste.jvnv.net/view/ZCPQf
2024-01-26T14:32:42 < karlp> the values that are non zero are "correct" (reset values)
2024-01-26T14:43:39 -!- nuxil_ is now known as nuxil
2024-01-26T14:44:34 -!- pragmalin [~pragmalin@user/pragmalin] has quit [Remote host closed the connection]
2024-01-26T14:49:13 < zyp> karlp, side note: $mmio_ref is more convenient than $mmio_ptr (but won't solve what you're asking about)
2024-01-26T14:50:47 < zyp> and yeah, you're telling gdb to print the whole struct, and so gdb is telling the gdbserver to read the whole memory area in one go, which fails
2024-01-26T14:54:03 < jpa-> i guess this is gitlab's way of saying "well done"? https://jpa.kapsi.fi/stuff/pix/gitlab_complete.png
2024-01-26T14:54:19 < zyp> could potentially be solved by adding a pretty printer to gdb that hooks the struct read and issues field by field reads instead, skipping reserved fields
2024-01-26T15:06:44 < karlp> not just reserved either, seems to be a problem with this wdog as well: https://github.com/karlp/laks/blob/wip/kinetis1/nxp_kx/nxp_wdog_k70.h
2024-01-26T15:06:54 < karlp> no reserved, but all 16bit access?
2024-01-26T15:07:23 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-26T15:08:00 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-26T15:09:39 -!- machinehum [~machinehu@213.55.220.47] has joined ##stm32
2024-01-26T15:12:49 < zyp> yeah, when you read a struct, just issues one read of the whole thing, not field by field
2024-01-26T15:13:00 < zyp> but a pretty printer could go field by field and do 16-bit reads
2024-01-26T15:15:58 < karlp> anyway, I wanted to spend the afternoon on this, but damn people keep interrupting with other bugs they want looked at.
2024-01-26T15:16:44 < ventYl> you becoming random oracle?
2024-01-26T15:24:31 < karlp> hrm?
2024-01-26T15:26:32 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Quit: Konversation terminated!]
2024-01-26T15:28:19 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-26T15:29:26 -!- machinehum [~machinehu@213.55.220.47] has quit [Ping timeout: 256 seconds]
2024-01-26T15:29:40 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-26T15:30:06 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-26T15:31:31 < karlp> bleh, something's not complete yet, if I flash it, and run, it works, but not from power cycle. 
2024-01-26T15:31:37 < karlp> I hate this aspect :)
2024-01-26T15:31:37 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-26T15:35:24 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Quit: Konversation terminated!]
2024-01-26T15:37:05 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-26T15:48:35 -!- haritz [~hrtz@user/haritz] has quit [Remote host closed the connection]
2024-01-26T15:48:56 -!- haritz [~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220] has joined ##stm32
2024-01-26T15:49:02 -!- haritz [~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220] has quit [Changing host]
2024-01-26T15:49:02 -!- haritz [~hrtz@user/haritz] has joined ##stm32
2024-01-26T15:52:21 < mawk> his royal highness Narendra Modi with his valet Emmanuel Macron https://www.reddit.com/r/rance/s/Hsm13gtRnQ
2024-01-26T16:09:05 -!- machinehum [~machinehu@213.55.220.47] has joined ##stm32
2024-01-26T16:22:17 < qyx> I have been bitten with the empty device detection check on g0 recently again
2024-01-26T16:22:48 < qyx> I have been debugging nearly an hour why the hell is the device still entering th system bootloader despite being flashed with a known working firmware
2024-01-26T16:23:01 < qyx> then I accidentally power cycled it
2024-01-26T16:25:37 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 264 seconds]
2024-01-26T16:31:57 < Ecco> oh, I just read about this yesterday actually
2024-01-26T16:32:11 < Ecco> Did someone mention it in this channel, or did I read this elsewhere?
2024-01-26T16:32:15 < Ecco> I think I read it elsewhere
2024-01-26T16:32:46 < Ecco> yes, there: https://github.com/cbiffle/stm32c0-metapac-example/tree/main
2024-01-26T16:32:47 < qyx> it is pretty common
2024-01-26T16:32:56 < Ecco> "The C0 series picked up the same odd behavior from the G0 series, where the EMPTY bit in the flash controller -- used to determine if there's code worth booting in the flash -- seems not to get re-evaluated at reset, and only at power-on. This means the very first time you program an STM32C0, if you reset it, it will bounce right back into the ROM like it's not programmed. To fix this, power cycle it. This 
2024-01-26T16:33:03 < Ecco> is only necessary when starting with a factory-fresh part."
2024-01-26T16:35:43 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-26T16:46:01 -!- machinehum [~machinehu@213.55.220.47] has quit [Ping timeout: 264 seconds]
2024-01-26T16:46:23 -!- machinehum [~machinehu@213.55.225.46] has joined ##stm32
2024-01-26T16:58:15 -!- nohit [sid334887@id-334887.tinside.irccloud.com] has quit [Ping timeout: 268 seconds]
2024-01-26T17:00:42 -!- nohit [sid334887@id-334887.tinside.irccloud.com] has joined ##stm32
2024-01-26T17:08:17 < Ecco>   * @brief Get the 2.4 GHz RADIO bus clock readiness.
2024-01-26T17:08:17 < Ecco>   * @note  Indicate that the 2.4 GHz RADIO bus clock is ready and the 2.4 GHz RADIO registers can be accessed.
2024-01-26T17:08:20 < Ecco>   * @note  The output can be one of the following values :
2024-01-26T17:08:22 < Ecco>   *         @arg RCC_RADIO_BUS_CLOCK_NOT_READY  : 2.4 GHz RADIO bus clock not ready.
2024-01-26T17:08:25 < Ecco>   *         @arg RCC_RADIO_BUS_CLOCK_READY :  2.4 GHz RADIO bus clock ready.
2024-01-26T17:08:27 < Ecco> Damn, maybe they'll hear about boolean values someday?
2024-01-26T17:08:42 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-26T17:09:11 -!- machinehum [~machinehu@213.55.225.46] has quit [Ping timeout: 252 seconds]
2024-01-26T17:13:31 < qyx> maybe there is also a half-ready state
2024-01-26T17:13:37 < qyx> (reserved)
2024-01-26T17:22:08 < Ecco> Well :-D
2024-01-26T17:22:19 < Ecco> The implementation of this function is "  return READ_BIT(RCC->RADIOENR, RCC_RADIOENR_RADIOCLKRDY);"
2024-01-26T17:35:56 < Ecco> Dumb question: what flashing speed should I expect when sending a firmware over a debug probe?
2024-01-26T17:36:14 < jpa-> 20-40 kB/s, depending on how good probe
2024-01-26T17:36:21 < Ecco> I'm getting about 32 KiB/sec, and that doesn't seem very fast
2024-01-26T17:36:22 < Ecco> oh, ok
2024-01-26T17:36:30 < Ecco> Why so slow though?
2024-01-26T17:36:39 < Ecco> What's the bottlenecK?
2024-01-26T17:38:16 < jpa-> good question, that's just what i usually see in practice
2024-01-26T17:39:25 < jpa-> i think most STM32s have flash programming speed of around 200 kB/s, though erase speed may be 50-100 kB/s depending on what size sectors the device uses
2024-01-26T17:39:30 < fenugrec> mass erase is usually pretty fast
2024-01-26T17:39:43 < fenugrec> unless programmer does a per-page erase
2024-01-26T17:41:42 < jpa-> generally they do per-page erase, because you might have stuff you don't want to erase
2024-01-26T17:42:09 < fenugrec> you would think so, but it seems everytime I reflash anything it's not even bothering, just rewrites everything
2024-01-26T17:42:28 < jpa-> what are you using? openocd erases only programmed sectors for me
2024-01-26T17:42:32 < fenugrec> writing is not instant either, just checked on F0 and tprog is "40-60 us per 16 bit"
2024-01-26T17:42:42 < fenugrec> dfu-util
2024-01-26T17:43:18 < jpa-> then it depends on the dfu bootloader you use
2024-01-26T17:43:26 < jpa-> IIRC the stm32 rom bootloader had a way to select erase mode
2024-01-26T17:43:32 < fenugrec> yes - and the factory DFU firmware doesn't have the best reputation
2024-01-26T17:51:47 < Ecco> Isn't the flash programming speed dependent on voltage too?
2024-01-26T17:52:05 < Ecco> So maybe everyone errs on the side of caution, ending in slower-than-ideal write speeds?
2024-01-26T17:58:45 -!- machinehum [~machinehu@213.55.225.46] has joined ##stm32
2024-01-26T18:03:25 -!- machinehum [~machinehu@213.55.225.46] has quit [Ping timeout: 264 seconds]
2024-01-26T18:17:09 < karlp> orbtrace or jlink to an esp32 via jtag flashs in ~150-200KB/sec+, to a tm4c, at 20Mhz, with workarea expanded, I cang et up to 800/900KB/sec
2024-01-26T18:21:23 < karlp> meh, I have a random old C crc16 that I think is very slow,
2024-01-26T18:21:35 < karlp> and the comments say it's a itu v42.  which is a crc32, 
2024-01-26T18:21:53 < karlp> and I can't make it match _any_ thing from any of the online crc calcualtors...
2024-01-26T18:22:04 < karlp> stupid distractions
2024-01-26T18:22:32 < qyx> have yoh tried inverse and other start values too?
2024-01-26T18:23:47 < karlp> well, https://crccalc.com/ seems to cover it all.
2024-01-26T18:23:58 < karlp> ok, so, if I dump the table that it calculates,
2024-01-26T18:24:32 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Ping timeout: 256 seconds]
2024-01-26T18:24:55 < karlp> I get a set of constants taht really look like this table though https://github.com/boundary/wireshark/blob/master/wsutil/crc16.c#L78-L112
2024-01-26T18:24:57 < zyp> want me to work it out?
2024-01-26T18:24:59 < karlp> so I guess that's an answer.
2024-01-26T18:25:38 < karlp> it takes ~700 cycles per iteration for 600k flash entries right now, I'm prtty sure using the crc peripheral _should_ be faster than 700 cycles.
2024-01-26T18:26:56 < fenugrec> no contest, but crc periph is CRC32 usually ?, so not dropin for a crc16
2024-01-26T18:28:11 < karlp> well, both the tm4c and the k70 that I need to work on both can do crc16 stuff too.
2024-01-26T18:28:31 < fenugrec> oh right you've gone to the dark side
2024-01-26T18:29:09 < karlp> g4's crc peripheral seems to support multiple widths too...
2024-01-26T18:29:24 < karlp> yeah, we don't use ST parts because my crazy colleague "doesn't trust french people"
2024-01-26T18:31:01 -!- c10ud [~c10ud@user/c10ud] has quit [Quit: Leaving]
2024-01-26T18:31:47 < mawk> qyx what's the empty device detection business?
2024-01-26T18:33:32 < qyx> it detects the device is empty and goes to the bootloader
2024-01-26T18:33:52 < qyx> but it fails to detect when you unempty it
2024-01-26T18:42:51 < karlp> lol, i think they just have a broken implementation of it...
2024-01-26T18:50:00 < karlp> well, this was a fucking waste of time distraction anyway.
2024-01-26T18:53:08 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 252 seconds]
2024-01-26T18:57:10 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2024-01-26T18:59:27 < qyx> broken crc?
2024-01-26T20:08:20 < karlp> I think it still may be, but it was just a distraction on a distraction.  bootup time is really slow, and I got myself distracted looking at fixing it, instead of just working on the usb host I'm meant to be doing.
2024-01-26T20:25:30 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-26T20:45:54 -!- jtj [~jtj@212.66.207.170] has joined ##stm32
2024-01-26T20:56:38 -!- cybernaut [~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883] has quit [Quit: Leaving]
2024-01-26T20:57:24 -!- GenTooMan [~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883] has joined ##stm32
2024-01-26T21:22:15 < qyx> rabbit hole driven programming
2024-01-26T21:22:42 < fenugrec> yes, I recognize that as a branch of fractal project management
2024-01-26T21:24:31 < qyx> what's that
2024-01-26T21:25:28 < fenugrec> you know when you look closer at a part, then notice a detail and start looking into it...  https://www.youtube.com/watch?v=0jGaio87u3A
2024-01-26T21:25:34 < qyx> anyway, what firmware size and boot time are wetalking about, just a ballpark figure?
2024-01-26T21:26:39 < qyx> yeah I know what a fractal is but I fail to apply it to management
2024-01-26T21:29:55 < fenugrec> it was a joke re 'rabbit hole programming'. RIP
2024-01-26T21:32:26 -!- machinehum [~machinehu@77.74.87.188] has joined ##stm32
2024-01-26T21:36:41 < qyx> sorry I fail at jokes
2024-01-26T21:42:06 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has joined ##stm32
2024-01-26T21:44:58 -!- machinehum [~machinehu@77.74.87.188] has quit [Ping timeout: 264 seconds]
2024-01-26T21:48:35 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-2078-6fc4-e803-21f9.fixed6.kpn.net] has joined ##stm32
2024-01-26T21:57:07 -!- jtj [~jtj@212.66.207.170] has quit [Ping timeout: 276 seconds]
2024-01-26T21:57:24 -!- jtj [~jtj@212.66.207.170] has joined ##stm32
2024-01-26T22:41:13 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-2078-6fc4-e803-21f9.fixed6.kpn.net] has quit [Ping timeout: 264 seconds]
2024-01-26T22:46:03 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-26T22:46:30 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-26T22:47:33 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Ping timeout: 260 seconds]
2024-01-26T22:47:35 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-26T22:48:07 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-26T22:59:11 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2024-01-26T23:40:52 < Ecco> karlp: so out of curiosity, what nationalities does your crazy colleague trust?
2024-01-26T23:43:11 < Ecco> Does he trust the Germans that make the silicon waffers? Does he trust the Taiwanese that etch them? Does he trust the Filipino that work the ship that brings those chips back from Asia?
2024-01-26T23:52:23 < qyx> *eat them
--- Day changed la tammi 27 2024
2024-01-27T00:03:13 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 276 seconds]
2024-01-27T00:42:54 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-27T00:43:24 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Client Quit]
2024-01-27T00:43:37 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-27T00:43:41 < Laurenceb_> https://nitter.net/pic/media%2FGErI1y9bEAA1znq.jpg%3Fname%3Dsmall%26format%3Dwebp
2024-01-27T01:09:26 < qyx> if I want to pass STM32 USART over a cap/isolation, enabling manchester is sufficient?
2024-01-27T01:12:08 < qyx> (the other idea is set 1 start, 6 data, 1 stop and transmit 1 as 11110000, 0 as 11001100, that is as 0x38/0x26)
2024-01-27T01:12:08 < zyp> mmm, silicon waffles
2024-01-27T01:12:54 < zyp> STM32 usarts does manchester?
2024-01-27T01:13:09 < qyx> that's indeed a very interesting question
2024-01-27T01:13:34 < zyp> I figure the problem here isn't really sending, it's receiving
2024-01-27T01:14:26 < qyx> hm, yeah, but a comparator + lpf should do
2024-01-27T01:14:40 < qyx> maybe even the internal one
2024-01-27T01:17:01 < qyx> ok no manchester at least for G4
2024-01-27T01:17:17 < qyx> no 6 bit mode either
2024-01-27T01:17:36 < qyx> but it has 7, 8 and 9 bit word, so 1 start + 9 data + 2 stop would do too
2024-01-27T01:34:02 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-27T01:37:37 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 264 seconds]
2024-01-27T01:40:54 < Laurenceb_> maybe you could precode the data so its balanced 0 and 1
2024-01-27T02:44:54 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 256 seconds]
2024-01-27T02:45:12 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Ping timeout: 250 seconds]
2024-01-27T04:05:40 -!- jadew [~rcc@user/rcc] has joined ##stm32
2024-01-27T06:41:15 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-27T07:52:25 < jpa-> qyx: you could do 4-bit fake manchester as 8N1 by sending 4 bits per byte, with every other bit being the inverse of prior
2024-01-27T07:53:33 < jpa-> though not sure that the cap + comparator is really any cheaper than optoisolator or digital isolator chip
2024-01-27T08:04:20 < fenugrec> wonder if can you use SPI pins with a xor gate to produce manchester
2024-01-27T08:06:45 < jpa-> you can use SPI pins even without XOR gate to transmit, but reception is more difficult
2024-01-27T08:07:29 < jpa-> i guess you could use an RC delay and XOR to generate reception clock for SPI
2024-01-27T08:18:28 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-27T08:25:05 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-27T08:25:34 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-27T08:26:11 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-27T08:27:18 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-27T08:27:52 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-27T09:06:50 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-27T09:30:40 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
2024-01-27T09:42:37 -!- Posterdati [~Posterdat@user/Posterdati] has quit [Remote host closed the connection]
2024-01-27T09:43:39 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-27T09:44:06 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-27T09:48:07 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-27T09:48:15 -!- Posterdati [~Posterdat@user/Posterdati] has joined ##stm32
2024-01-27T09:48:34 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-27T09:49:35 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-27T09:50:02 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-27T09:50:49 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-343d-f53c-8d96-bcbc.fixed6.kpn.net] has joined ##stm32
2024-01-27T10:12:03 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-27T10:12:29 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-27T10:27:50 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-27T10:28:17 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-27T11:02:26 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-343d-f53c-8d96-bcbc.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-27T11:28:45 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-27T11:29:32 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-27T11:36:20 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-27T11:42:41 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-27T11:43:07 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-27T12:24:33 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-27T12:36:27 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-27T13:34:30 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-27T13:37:47 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 260 seconds]
2024-01-27T13:38:13 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 264 seconds]
2024-01-27T13:56:12 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-27T14:11:47 -!- martinmoene__ [~martinmoe@132.229.46.129] has joined ##stm32
2024-01-27T14:15:34 -!- martinmoene_ [~martinmoe@132.229.46.129] has quit [Ping timeout: 264 seconds]
2024-01-27T14:31:59 < karlp> Ecco: I'm not going to try and understand this colleague, I just have to live with teh situation on the ground.
2024-01-27T14:47:28 -!- martinmoene_ [~Martin@2a02-a45a-96ba-1-cd42-1f1a-dd0b-5258.fixed6.kpn.net] has joined ##stm32
2024-01-27T15:28:05 -!- martinmoene_ [~Martin@2a02-a45a-96ba-1-cd42-1f1a-dd0b-5258.fixed6.kpn.net] has quit [Ping timeout: 240 seconds]
2024-01-27T16:02:45 -!- grindhold [~quassel@mail.skarphed.org] has quit [Read error: Connection reset by peer]
2024-01-27T16:03:22 -!- grindhold [~quassel@mail.skarphed.org] has joined ##stm32
2024-01-27T16:13:41 < jbo> hi
2024-01-27T16:14:55 < Steffanx> lo
2024-01-27T16:15:18 < jpa-> so we are big endian today?
2024-01-27T16:15:34 < jbo> depends on whether zyp joins us
2024-01-27T16:16:00 < jpa-> (jbo << 8) | Steffanx    there, joined
2024-01-27T16:16:24 < jbo> :D
2024-01-27T16:16:56 < Steffanx> That kind of bad humor gets you in jail, jpa- 
2024-01-27T16:17:18 < jbo> I have bigger problems than that right now
2024-01-27T16:17:48 < Steffanx> You're already in jail?
2024-01-27T16:17:57 < jbo> almost
2024-01-27T16:18:08 < jbo> received a phone call yesteray from $customer. I have to go to california ASAP
2024-01-27T16:18:19 < Steffanx> So better pack your bags.
2024-01-27T16:18:38 < jpa-> i hope you are getting a lot of money for it
2024-01-27T16:18:46 < jbo> I won't
2024-01-27T16:18:52 < jbo> machinehum was super hyped tho lol
2024-01-27T16:18:55 < Steffanx> You can always hire jpa-  to do for you. 
2024-01-27T16:19:00 < jbo> not sure why everybody is pretending like going to california is awesome
2024-01-27T16:19:00 < jpa-> why you won't?
2024-01-27T16:19:02 < jpa-> just ask more
2024-01-27T16:19:13 < Steffanx> *go
2024-01-27T16:19:18 < jbo> that's not how I do business, jpa
2024-01-27T16:19:24 < jpa-> weirdo
2024-01-27T16:19:34 < jbo> says the guy with a kid
2024-01-27T16:19:42 < jbo> it literally came out of another person
2024-01-27T16:19:44 < Steffanx> A swisser that doesnt want money?!
2024-01-27T16:19:47 < jpa-> hey, someone has to keep mankind alive
2024-01-27T16:20:04 < jbo> I don't mind getting the money, I just don't like asking for it
2024-01-27T16:20:04 < jpa-> not everyone can be born out of cheese like swiss people
2024-01-27T16:20:15 < jpa-> i can ask for you
2024-01-27T16:20:18 < jbo> I don't even know how to tell $customer that I don't feel like flying economy because I'm 6"6
2024-01-27T16:20:33 < Steffanx> You fly business class ..
2024-01-27T16:20:47 < jbo> that is like 3k USD or something
2024-01-27T16:20:57 < Steffanx> $customer pays
2024-01-27T16:20:58 < jpa-> client pays if they really need you
2024-01-27T16:21:10 < jbo> they don't need me
2024-01-27T16:21:11 < jpa-> if it turns out they don't really need you, all the better
2024-01-27T16:21:21 < jbo> everything I can tell them I told them already via e-mails and zoom meetings over months
2024-01-27T16:21:30 < jbo> they just have that one contractor that is being difficult to work with
2024-01-27T16:21:32 < Steffanx> They just WANT you, like jpa- ?
2024-01-27T16:21:56 < jbo> heh
2024-01-27T16:22:01 < jbo> anybody from california here?
2024-01-27T16:22:18 < jpa-> i've started to refuse ridiculous on-site meetings.. one client took 1.5 years until they could send me a wireshark capture, just because i refused to go and take it for them
2024-01-27T16:22:27 < Steffanx> California is still asleep
2024-01-27T16:22:50 < jbo> what happened to just take the money, jpa?
2024-01-27T16:23:03 < Steffanx> They still paid extra for wasting your time, jpa- ?
2024-01-27T16:23:17 < Steffanx> being a PITA-tax?
2024-01-27T16:23:19 < jpa-> jbo: i realized it didn't really compensate for being annoyed
2024-01-27T16:23:43 < jpa-> Steffanx: i did hike the hourly rate by 10%
2024-01-27T16:23:51 < Steffanx> :)
2024-01-27T16:24:37 < jpa-> nowadays i try to work less hours so that i have more time left over to feel sad
2024-01-27T16:24:48 < jbo> that's what I am trying to achieve again too
2024-01-27T16:24:56 < jbo> and now I need to go to california...
2024-01-27T16:25:04 < jpa-> maybe you can feel sad on the plane
2024-01-27T16:25:17 < jpa-> like snakes on the plane, but not as fun
2024-01-27T16:25:21 < jbo> I already see the discussion with TSA
2024-01-27T16:25:27 < jbo> "Sir, you can't bring a razor blade on the plane"
2024-01-27T16:25:37 < jbo> "why not? what am I going to do? loosen some bolts?"
2024-01-27T16:27:27 < Steffanx> Anyway, you're free to say no mr jbo ?
2024-01-27T16:27:33 < Steffanx> -?
2024-01-27T16:27:41 < jpa-> so will you be attending any pool parties while there? isn't that the thing you do in california?
2024-01-27T16:28:12 < jbo> business wise it would be very wise for me to do this
2024-01-27T16:28:37 < Steffanx> Who wants pool parties without you, jpa- ?
2024-01-27T16:29:13 < jpa-> jbo: is it business-wise wise to show that you are easy to boss around to go on useless trips?
2024-01-27T16:29:31 < jbo> jpa-, I did decline this trip since August ;)
2024-01-27T16:29:52 < jpa-> Steffanx: i can be on zoom, it's not like i would fly to some useless party
2024-01-27T16:30:00 < Steffanx> They have this issue since August? That it's not a real issue.
2024-01-27T16:30:04 < jpa-> jbo: well that's at least something!
2024-01-27T16:30:04 < jbo> how are we interfacing with your genitals then, jpa- ?
2024-01-27T16:30:06 < Steffanx> *than
2024-01-27T16:30:09 < jbo> with "we" I mean bikini girls
2024-01-27T16:30:10 < ventYl> jbo: if you're gonna fly with boeing, bolts may loosen themselves without added assistance
2024-01-27T16:30:26 < jpa-> jbo: hey hey hey, you seem to have some dirty thoughts, cut it off!
2024-01-27T16:30:32 < jpa-> (not the genitals i mean)
2024-01-27T16:30:55 < qyx> jbo: just tell them gtfo
2024-01-27T16:31:16 < jpa-> ventYl: better pick the seat behind the plug door row, there is a good chance to get more leg space mid-flight
2024-01-27T16:31:16 -!- grindhold [~quassel@mail.skarphed.org] has quit [Read error: Connection reset by peer]
2024-01-27T16:31:32 < Steffanx> Secretly jbo really wants to go. A true holiday would be good for him
2024-01-27T16:31:35 < jpa-> instant business class upgrade, with excellent views
2024-01-27T16:31:54 -!- grindhold [~quassel@mail.skarphed.org] has joined ##stm32
2024-01-27T16:32:25 < ventYl> jbo: is it a problem that traces to you, or just plain $customer incompetence?
2024-01-27T16:32:52 < jbo> ventYl, the latter. I have warned them about this stuff for months now
2024-01-27T16:33:52 < jbo> I just checked online - they have sunlight in california. that's the worst part so far :D
2024-01-27T16:34:27 < Steffanx> Yeah we all know your place doesnt have sunlight :P
2024-01-27T16:35:16 < jpa-> https://images.cdn.yle.fi/image/upload/v1702893422/39-121695465800cf865386  so who do you think is going to be our next president?
2024-01-27T16:36:06 < jbo> bottom left
2024-01-27T16:36:56 < ventYl> jbo: aaand I guess your contract doesn't contain any specifics regarding business trips
2024-01-27T16:36:57 < jpa-> putin would immediately think "young woman, let's conquer .fi"
2024-01-27T16:37:22 < jbo> ventYl, there's hardly any contract other than "time & material, work as much as you can".
2024-01-27T16:38:07 < Steffanx> Yeah you have a thing with "young" women as president, so bottom left it is, jpa-  
2024-01-27T16:38:33 < Steffanx> They can have parties, do drugs and .. resign
2024-01-27T16:38:40 < jpa-> that was prime minister
2024-01-27T16:38:50 < jpa-> but yeah, would work
2024-01-27T16:39:33 < Steffanx> I was going for the guy on the top row 2nd from the right though.
2024-01-27T16:39:45 < jpa-> current president has been stubborn, he didn't resign even when people didn't like his dog's snot
2024-01-27T16:40:12 < jpa-> Steffanx: he does have kind of suspicious expression
2024-01-27T16:41:52 < Steffanx> But is he from "the good side"?
2024-01-27T16:42:26 < jpa-> we only have good candidates in .fi
2024-01-27T16:42:36 < jpa-> it would be ridiculous to put bad candidates for presidency
2024-01-27T16:42:53 < Steffanx> All far-right?
2024-01-27T16:43:13 < jpa-> no-one would vote for anyone that didn't have moderate, majority-approved opinions
2024-01-27T16:44:51 < jpa-> one might say "the poor will suffer!" and another "the rich will leave!" but in .fi president only has power in international politics
2024-01-27T16:45:35 < Steffanx> So as useless as our king and queen
2024-01-27T16:46:02 < jpa-> at least we get to vote on it!
2024-01-27T16:47:27 < Steffanx> Yeah you get to vote which clown gets the position \o/
2024-01-27T16:48:32 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-27T16:48:35 < jpa-> we get to vote who we can blame when putin comes
2024-01-27T16:51:48 -!- nomorekaki [~nomorekak@n85jfehonentsclsnb0-1.v6.elisa-mobile.fi] has joined ##stm32
2024-01-27T16:52:21 < ventYl> regarding politics. one of our idiot MPs is running for president
2024-01-27T16:52:54 < ventYl> he has a transparent bank account with donations to support his campaign
2024-01-27T16:53:05 < ventYl> it is full of gems
2024-01-27T16:53:11 < ventYl> and also full of 0,01 eur donations
2024-01-27T16:54:24 < ventYl> https://i.imgur.com/qWXB05l.png
2024-01-27T16:55:47 < jbo> lol that donation/transaction text
2024-01-27T16:55:59 < jbo> > "The dildo of consequences rarely comes lubed"
2024-01-27T16:56:02 < ventYl> :)
2024-01-27T16:56:24 < ventYl> there are many donations of 0,01 with text: "i am donating one rouble"
2024-01-27T16:56:39 < ventYl> if you'll wait long enough, i'll become two roubles
2024-01-27T17:00:26 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-27T17:01:28 -!- nomorekaki [~nomorekak@n85jfehonentsclsnb0-1.v6.elisa-mobile.fi] has quit [Ping timeout: 250 seconds]
2024-01-27T17:04:12 < qyx> oh the captain Danko
2024-01-27T17:04:40 < qyx> poor him, he lost a tooth in a car accident with a semaphore pole recently
2024-01-27T17:04:51 < qyx> he states he was not drunk
2024-01-27T17:05:26 < qyx> he left the scene immediately though
2024-01-27T17:06:04 -!- martinmoene_ [~Martin@2a02-a45a-96ba-1-cd42-1f1a-dd0b-5258.fixed6.kpn.net] has joined ##stm32
2024-01-27T17:06:38 < Steffanx> Youre so judgy qyx  
2024-01-27T17:07:45 < qyx> I am not doing any judgements, that's all official info
2024-01-27T17:08:35 < ventYl> some chit chat leaked from police says that the truth and what Captain says are two deliberately different things
2024-01-27T17:11:08 -!- martinmoene [~Martin@2a02-a45a-96ba-1-29e7-9cad-efab-d516.fixed6.kpn.net] has joined ##stm32
2024-01-27T17:14:15 -!- martinmoene_ [~Martin@2a02-a45a-96ba-1-cd42-1f1a-dd0b-5258.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-27T17:34:14 -!- ferdna_ [~ferdna@user/ferdna] has joined ##stm32
2024-01-27T17:36:47 -!- ferdna [~ferdna@user/ferdna] has quit [Ping timeout: 256 seconds]
2024-01-27T18:29:58 -!- qyx [~qyx@84.245.120.104] has quit [Ping timeout: 264 seconds]
2024-01-27T18:31:22 -!- qyx [~qyx@84.245.120.54] has joined ##stm32
2024-01-27T18:36:59 -!- martinmoene [~Martin@2a02-a45a-96ba-1-29e7-9cad-efab-d516.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-27T18:41:25 -!- jdelmore [~jdelmore@67-221-109-36.unassigned.ntelos.net] has joined ##stm32
2024-01-27T18:47:19 -!- ferdna_ [~ferdna@user/ferdna] has quit [Ping timeout: 268 seconds]
2024-01-27T19:04:32 < Steffanx> packing yet jbo ?
2024-01-27T19:33:09 -!- martinmoene [~Martin@2a02:a45a:96ba:1:29e7:9cad:efab:d516] has joined ##stm32
2024-01-27T19:55:24 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has joined ##stm32
2024-01-27T20:00:40 < Steffanx> isnt bitmask from somewhere california?
2024-01-27T20:00:51 < bitmask> other coast
2024-01-27T20:01:33 < Steffanx> Florida?
2024-01-27T20:01:47 < bitmask> new jersey
2024-01-27T20:01:50 < jpa-> bitmask is the florida man?
2024-01-27T20:04:07 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 256 seconds]
2024-01-27T20:04:49 < Steffanx> no spoilers, jpa- 
2024-01-27T21:41:10 -!- machinehum [~machinehu@0.58.77.83.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-27T21:43:33 < zyp> hmm, if I want a soldering iron compatible with ts100 tips, which should I get? ts101 or pinecil v2?
2024-01-27T21:44:48 < zyp> I'm considering getting some shit for heatset inserts, and this looks like possibly the nicest solution available: https://cnckitchen.store/products/ts100-101-adapter-tips-set-m2-x-m3-m4-m5-m6-1-4-m8-100-lead-and-cadmium-free
2024-01-27T21:48:52 < zyp> I've already got a m3 insert tool that I've modified to fit my old weller iron, but I absolutely don't want to keep the whole weller station around just for that
2024-01-27T21:49:26 < zyp> ideally I'd get a tool with a jbc c210 cartridge, but that doesn't exist as far as I'm aware :)
2024-01-27T21:49:52 < zyp> so the second best thing would be a USB-PD iron dedicated for insert tools
2024-01-27T22:29:38 -!- qyx [~qyx@84.245.120.54] has quit [Ping timeout: 268 seconds]
2024-01-27T22:30:55 -!- qyx [~qyx@84.245.120.144] has joined ##stm32
2024-01-27T22:49:01 -!- qyx [~qyx@84.245.120.144] has quit [Ping timeout: 264 seconds]
2024-01-27T22:50:43 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 256 seconds]
2024-01-27T22:50:54 -!- qyx [~qyx@84.245.120.77] has joined ##stm32
2024-01-27T23:08:36 < Steffanx> I was looking at something similar. You now make me wonder if can modify one of my china jbc tips to a tip with a m5 thread or something
2024-01-27T23:27:18 < Steffanx> or maybe just have someone turn a copper "sleeve" that fits over the tip of an existing c210 or 245 tip. Ill ask jlc3dp what it would cost.
2024-01-27T23:42:42 -!- machinehum [~machinehu@0.58.77.83.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 260 seconds]
--- Day changed su tammi 28 2024
2024-01-28T00:11:35 -!- grindhold [~quassel@mail.skarphed.org] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
2024-01-28T00:12:18 < zyp> Steffanx, I've also thought about doing that
2024-01-28T00:13:45 < zyp> I've already got a c210 cartridge with a broken tip, so a M5 threaded brass sleeve should do nicely
2024-01-28T00:14:11 < zyp> but I'm not sure how to get it to stay on the cartridge
2024-01-28T00:15:22 < zyp> something press fit would be nice, but then thermal expansion might fuck that up when it heats up
2024-01-28T00:15:59 < Steffanx> AliExpress has some copper tips that fit over an existing tip, the idea is the same. 
2024-01-28T00:17:57 -!- quinor [08c0f10716@2a03:6000:1812:100::dad] has quit [Remote host closed the connection]
2024-01-28T00:18:06 -!- quinor [08c0f10716@2a03:6000:1812:100::dad] has joined ##stm32
2024-01-28T00:29:11 < Steffanx> Oh we just need jbo. He has the tools.
2024-01-28T00:45:50 < zyp> but still, it's tempting to just buy that ts100 cartridge and a suitable iron for it and throw it in the box with the inserts
2024-01-28T00:47:23 -!- grindhold [~quassel@mail.skarphed.org] has joined ##stm32
2024-01-28T00:50:50 < Steffanx> Absolutely 
2024-01-28T01:04:50 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2024-01-28T01:08:59 -!- martinmoene [~Martin@2a02:a45a:96ba:1:29e7:9cad:efab:d516] has quit [Ping timeout: 256 seconds]
2024-01-28T01:35:03 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-28T01:38:57 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 260 seconds]
2024-01-28T01:48:04 < zyp> I concluded pinecil was the cheaper option of the two, so I ordered one and the insert tools
2024-01-28T01:51:19 < qyx> pinecil is gud but it doesn't fit in my hand
2024-01-28T01:53:38 < zyp> that's okay, I'm not planning to solder with it
2024-01-28T02:42:53 -!- Thorn [~Thorn@2001:8a0:dfe1:a200:dce1:ac0c:cb78:a43c] has joined ##stm32
2024-01-28T02:42:53 -!- Thorn [~Thorn@2001:8a0:dfe1:a200:dce1:ac0c:cb78:a43c] has quit [Changing host]
2024-01-28T02:42:53 -!- Thorn [~Thorn@user/thorn] has joined ##stm32
2024-01-28T03:31:40 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-28T03:58:33 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 256 seconds]
2024-01-28T03:59:24 -!- drkow [~k\o\w@2607:fea8:1d00:89f0:3857:f026:849b:7e2f] has joined ##stm32
2024-01-28T04:02:59 -!- kow__ [~k\o\w@2607:fea8:1d00:89f0:a9f5:3dea:eea9:8b33] has quit [Ping timeout: 260 seconds]
2024-01-28T04:25:09 -!- GenTooMan [~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883] has quit [Read error: Connection reset by peer]
2024-01-28T05:01:13 -!- Thorn_ [~Thorn@2001:8a0:dfe1:a200:4841:e3d4:628b:332] has joined ##stm32
2024-01-28T05:01:26 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-28T05:02:01 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-28T05:02:53 -!- Thorn [~Thorn@user/thorn] has quit [Ping timeout: 260 seconds]
2024-01-28T05:20:10 -!- ferdna_ [~ferdna@user/ferdna] has joined ##stm32
2024-01-28T05:21:55 -!- ferdna [~ferdna@user/ferdna] has quit [Ping timeout: 246 seconds]
2024-01-28T05:33:12 -!- cybernaut [~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883] has joined ##stm32
2024-01-28T05:33:37 -!- cybernaut [~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883] has quit [Read error: Connection reset by peer]
2024-01-28T05:34:11 -!- GenTooMan [~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883] has joined ##stm32
2024-01-28T05:59:37 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Remote host closed the connection]
2024-01-28T06:40:52 -!- kow__ [~k\o\w@cpee0dbd1bd5280-cme0dbd1bd527e.cpe.net.cable.rogers.com] has joined ##stm32
2024-01-28T06:44:55 -!- drkow [~k\o\w@2607:fea8:1d00:89f0:3857:f026:849b:7e2f] has quit [Ping timeout: 260 seconds]
2024-01-28T08:38:13 < jpa-> having two irons is handy anyway for that time you need to remove 2512 or something
2024-01-28T09:00:23 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-28T09:04:24 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-28T09:21:44 -!- martinmoene [~Martin@2a02-a45a-96ba-1-b9ef-82f1-2ed2-85ea.fixed6.kpn.net] has joined ##stm32
2024-01-28T10:01:44 -!- machinehum [~machinehu@0.58.77.83.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-28T10:06:49 -!- machinehum [~machinehu@0.58.77.83.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 276 seconds]
2024-01-28T10:18:58 -!- machinehum [~machinehu@0.58.77.83.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-28T10:19:20 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
2024-01-28T10:31:20 -!- machinehum [~machinehu@0.58.77.83.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 252 seconds]
2024-01-28T10:52:47 -!- martinmoene [~Martin@2a02-a45a-96ba-1-b9ef-82f1-2ed2-85ea.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-28T11:04:04 -!- ferdna_ [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-28T12:46:34 -!- machinehum [~machinehu@0.58.77.83.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-28T12:52:21 -!- machinehum [~machinehu@0.58.77.83.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 268 seconds]
2024-01-28T12:54:30 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-28T13:03:47 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-28T13:05:00 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-28T13:23:40 -!- machinehum [~machinehu@213.55.225.209] has joined ##stm32
2024-01-28T13:30:53 -!- machinehum [~machinehu@213.55.225.209] has quit [Ping timeout: 256 seconds]
2024-01-28T13:40:11 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 264 seconds]
2024-01-28T13:42:35 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-28T13:51:41 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 240 seconds]
2024-01-28T13:54:23 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-28T14:01:17 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 240 seconds]
2024-01-28T14:04:19 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-28T14:09:01 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 255 seconds]
2024-01-28T14:10:18 -!- machinehum [~machinehu@187.197.2.85.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-28T14:10:56 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-28T14:43:50 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 260 seconds]
2024-01-28T14:46:22 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-28T14:51:22 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 268 seconds]
2024-01-28T14:52:57 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-28T14:57:50 -!- jadew [~rcc@user/rcc] has quit [Ping timeout: 268 seconds]
2024-01-28T14:58:58 -!- machinehum [~machinehu@187.197.2.85.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 255 seconds]
2024-01-28T15:02:28 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 268 seconds]
2024-01-28T15:03:58 < zyp> jpa-, already have ts80p and I'm considering getting a sequre s60
2024-01-28T15:08:39 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-28T15:08:50 < jpa-> yeah, s60 looks nice
2024-01-28T15:09:41 < zyp> I installed ironos on the ts80p yesterday, seems a lot more convenient than the original firmware
2024-01-28T15:10:10 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 264 seconds]
2024-01-28T15:11:25 -!- jadew [~rcc@5.12.180.134] has joined ##stm32
2024-01-28T15:12:21 < jpa-> yeah, it was a nice upgrade on TS100
2024-01-28T15:12:28 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-28T15:13:57 -!- machinehum [~machinehu@187.197.2.85.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-28T15:19:17 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 240 seconds]
2024-01-28T15:22:13 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-28T16:12:23 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 256 seconds]
2024-01-28T16:15:04 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-28T16:15:04 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Ping timeout: 250 seconds]
2024-01-28T16:49:17 -!- machinehum [~machinehu@187.197.2.85.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 240 seconds]
2024-01-28T17:06:42 -!- nomorekaki [~nomorekak@2001:2003:f4dc:8b01:a943:452c:cf76:98b2] has joined ##stm32
2024-01-28T17:08:38 -!- nomorekaki [~nomorekak@2001:2003:f4dc:8b01:a943:452c:cf76:98b2] has quit [Client Quit]
2024-01-28T17:23:37 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-28T17:28:43 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8e90:ef73:6aa1:7c51:632e] has joined ##stm32
2024-01-28T17:31:12 -!- Thorn [~Thorn@user/thorn] has joined ##stm32
2024-01-28T17:32:52 -!- Thorn_ [~Thorn@2001:8a0:dfe1:a200:4841:e3d4:628b:332] has quit [Ping timeout: 255 seconds]
2024-01-28T17:33:39 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-28T17:38:55 -!- nomorekaki [~nomorekak@2001:2003:f4dc:8b01:a943:452c:cf76:98b2] has joined ##stm32
2024-01-28T17:41:49 -!- jadew [~rcc@5.12.180.134] has quit [Changing host]
2024-01-28T17:41:49 -!- jadew [~rcc@user/rcc] has joined ##stm32
2024-01-28T17:48:21 -!- nomorekaki [~nomorekak@2001:2003:f4dc:8b01:a943:452c:cf76:98b2] has quit [Quit: Client closed]
2024-01-28T19:21:56 -!- machinehum [~machinehu@187.197.2.85.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-28T19:30:25 -!- machinehum [~machinehu@187.197.2.85.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 260 seconds]
2024-01-28T19:52:44 -!- machinehum [~machinehu@187.197.2.85.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-28T19:57:47 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 260 seconds]
2024-01-28T20:04:25 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has joined ##stm32
2024-01-28T20:29:55 -!- machinehum [~machinehu@187.197.2.85.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 268 seconds]
2024-01-28T20:45:11 -!- martinmoene [~Martin@2a02-a45a-96ba-1-7c09-70b2-18bb-b75f.fixed6.kpn.net] has joined ##stm32
2024-01-28T20:48:55 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8e90:ef73:6aa1:7c51:632e] has quit [Ping timeout: 256 seconds]
2024-01-28T20:51:40 -!- flom84 [~flom84@user/flom84] has joined ##stm32
2024-01-28T21:14:15 -!- machinehum [~machinehu@187.197.2.85.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-28T21:16:08 < Laurenceb_> https://www.youtube.com/watch?v=hzoN2MFkCXI
2024-01-28T21:19:31 -!- machinehum [~machinehu@187.197.2.85.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 246 seconds]
2024-01-28T21:31:11 -!- flom84 [~flom84@user/flom84] has quit [Ping timeout: 264 seconds]
2024-01-28T21:42:25 -!- machinehum [~machinehu@187.197.2.85.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-28T21:47:09 -!- machinehum [~machinehu@187.197.2.85.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 260 seconds]
2024-01-28T21:50:41 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 256 seconds]
2024-01-28T21:53:14 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-28T22:14:13 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 260 seconds]
2024-01-28T22:18:13 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has joined ##stm32
2024-01-28T22:20:22 -!- Laurenceb_ [~Laurenceb@44.177.208.46.dyn.plus.net] has quit [Ping timeout: 250 seconds]
2024-01-28T22:22:56 -!- machinehum [~machinehu@187.197.2.85.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-28T22:31:03 -!- alan_o [~alan_o@2600:1700:1902:210f:22a9:73f7:2f7a:950a] has quit [Remote host closed the connection]
2024-01-28T22:41:22 -!- machinehum [~machinehu@187.197.2.85.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 264 seconds]
2024-01-28T22:45:04 -!- alan_o [~alan_o@2600:1700:1902:210f:e477:442b:61c9:e1d4] has joined ##stm32
2024-01-28T22:49:41 -!- alan_o [~alan_o@2600:1700:1902:210f:e477:442b:61c9:e1d4] has quit [Ping timeout: 260 seconds]
2024-01-28T22:58:37 -!- alan_o [~alan_o@2600:1700:1902:210f:ece8:d22e:aab9:cabb] has joined ##stm32
2024-01-28T23:00:46 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:2efd:2040:24cb:d055] has joined ##stm32
2024-01-28T23:15:14 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-28T23:22:09 < qyx> zyp: any quick quide using/assembling those phoenix contact M12 pin inserts & screws you used in that work proj in the past?
2024-01-28T23:22:18 < qyx> or no idea at all about the hw part?
2024-01-28T23:26:27 < qyx> I cannot see any right angle, all are vertical
2024-01-28T23:40:18 < zyp> we used some pcb mount vertical ones, pcb-mount insert, shell screwed into housing
2024-01-28T23:40:24 < zyp> and then we used some with wires
2024-01-28T23:41:32 < ventYl> speedreading: "and then we used some with tyres"
2024-01-28T23:48:20 < Ecco> Do you guys like the TS100? I have a T12-compatible station (Kseger) and I kind of like it :)
2024-01-28T23:48:25 < Ecco> Never tried the TS100 tho
2024-01-28T23:48:49 < zyp> never tried it, tips looks too huge
2024-01-28T23:49:51 < zyp> but the ts100 insert tool cartridge I linked yesterday looks like the most convenient solution for heatset inserts, so I'm getting a pinecil just for that
2024-01-28T23:50:50 < zyp> also have a ts80p which is so so
2024-01-28T23:51:17 < zyp> for soldering, rather get a sequre s60
2024-01-28T23:51:30 < zyp> or if you don't want portable, get an aixun t3b
2024-01-28T23:54:44 < fenugrec> have a TS100 for "travel". Longer than Hakko 936 I've been using for 20 years, almost never use the TS
2024-01-28T23:55:29 < Ecco> I've seen on YouTube a review of a "chinese clone" 200W station that apparently was prettyg ood
2024-01-28T23:55:35 < Ecco> Don't remember the name tho
2024-01-28T23:55:54 < zyp> if you're gonna solder smt, just get aixun t3b, don't bother with other shit
2024-01-28T23:56:53 < Ecco> lol
2024-01-28T23:57:05 < Ecco> The review I saw was… for an aixun t3a :-)
2024-01-28T23:57:43 < Ecco> So I guess everyone agrees :)
2024-01-28T23:58:43 < zyp> t3a is older and for larger cartridges
2024-01-28T23:59:43 < Ecco> what's a cartridge?
2024-01-28T23:59:53 < zyp> tip with integrated heater
--- Day changed ma tammi 29 2024
2024-01-29T00:01:23 < Ecco> Is this what T12 tips do already? Or are they different?
2024-01-29T00:01:59 < zyp> I'm not familiar with T12, but google shows me photos of cartridges, yes
2024-01-29T00:02:09 < Ecco> cool
2024-01-29T00:02:25 < Ecco> Yeah, I had an FX888D, this one you definitely would change just the tip
2024-01-29T00:02:34 < qyx> is there any reason I should use cartridges instead of tips?
2024-01-29T00:02:36 < Ecco> the T12 thing you replace is much larger, kind of like a pencil
2024-01-29T00:02:53 < Ecco> qyx: The one benefit I found is that it's much quicker
2024-01-29T00:03:02 < Ecco> you don't need to wait for the whole thing to cool down
2024-01-29T00:03:03 < qyx> uh?
2024-01-29T00:03:07 < zyp> yeah, heater gets much closer to the actual tip
2024-01-29T00:03:25 < Ecco> my hakko FX888D you'd need to wait until the tip had cooled off so you could remove it and replace with another one
2024-01-29T00:03:28 < zyp> and with stuff like c210 cartridges, there's way less thermal mass too
2024-01-29T00:03:31 < qyx> wellers have heaters at the tip
2024-01-29T00:03:39 < qyx> also, I can change weller hot
2024-01-29T00:03:45 < zyp> sure
2024-01-29T00:03:46 < qyx> *while still hot
2024-01-29T00:03:55 < Ecco> I guess it depends on the mechanism to hold the tip in place
2024-01-29T00:03:56 < zyp> I've hot changed my weller ws80 plenty of times
2024-01-29T00:04:05 < qyx> I am not saying weller is the best, just curious
2024-01-29T00:04:06 < zyp> but it's slow compared to a c210 cartridge
2024-01-29T00:04:37 < Ecco> I guess you only really need to supply current to a cartridge, so it doesn't need to be strongly held in place
2024-01-29T00:04:54 < Ecco> whereas you probably want to make sure the tip is well attached to the heating element
2024-01-29T00:05:12 < Ecco> (but again, this is just from my small experience with a 888d and a T12)
2024-01-29T00:10:09 < zyp> qyx, https://bin.jvnv.net/file/srwZB.mp4
2024-01-29T00:11:31 < Ecco> Dumb question: why does CMSIS have __disable_irq and __set_primask?
2024-01-29T00:12:15 < qyx> zyp: O_o
2024-01-29T00:12:29 < Ecco> In other words, is there any difference between calling "cpsie i" (__enable_irq) and "msr primask, 1" (__set_primask)
2024-01-29T00:12:37 < zyp> Ecco, because disabling irqs means setting primask to mask everything, reenabling them means setting it back to the previous value
2024-01-29T00:12:55 < Ecco> zyp: Holy shit, those are *fast*
2024-01-29T00:13:09 < zyp> yeah, that's why I say don't bother with other shit
2024-01-29T00:13:20 < Ecco> I mean, my T12 probably takes like 15 seconds to warm up 
2024-01-29T00:13:24 < Ecco> not really an issue
2024-01-29T00:13:25 < Ecco> but this
2024-01-29T00:13:27 < Ecco> holy shit
2024-01-29T00:13:28 < Ecco> :)
2024-01-29T00:14:06 < Ecco> ok, but then is there any functional difference between those two instructions?
2024-01-29T00:14:18 < Ecco> I understand that it's cleaner to have a pair of getter/setter
2024-01-29T00:14:25 < Ecco> but technically, is it redundant?
2024-01-29T00:14:35 < Ecco> or does one of them have a different behavior?
2024-01-29T00:14:38 < zyp> doesn't __set_primask take an argument?
2024-01-29T00:15:03 < Ecco> yes of course
2024-01-29T00:15:06 < Ecco> it takes the primask value
2024-01-29T00:15:25 < Ecco> which is an uint32_t, but with only one meaningful bit…
2024-01-29T00:16:12 < zyp> like I said, it's about nested stuff
2024-01-29T00:16:31 < zyp> you don't just set it to 1, you set it to the value it used to have
2024-01-29T00:16:50 -!- dkc [~dan@user/dkc] has joined ##stm32
2024-01-29T00:17:36 < Ecco> but it really only can have two values, right?
2024-01-29T00:17:50 < zyp> I don't use cmsis, so I'm not familiar with the exact syntax, but here's my RAII style handlers: https://github.com/zyp/laks/blob/dev_v2/interrupt/critical_section.h
2024-01-29T00:18:31 < Ecco> ok, interesting
2024-01-29T00:18:41 < zyp> so, consider something like this…
2024-01-29T00:19:04 < Ecco> you're indeed going for something symmetrical, where you read primask, keep it, and restore it afterwards
2024-01-29T00:19:09 < Ecco> that's clean, perfect
2024-01-29T00:19:22 < Ecco> but my question is: would it be equivalent to store a bool
2024-01-29T00:19:36 < zyp> https://paste.jvnv.net/view/jBi0v
2024-01-29T00:19:45 < Ecco> and, when restoring, call either cpsid i or cpsie i ?
2024-01-29T00:20:23 < zyp> probably, but why would you test and branch when you can just write the value?
2024-01-29T00:20:36 < Ecco> (your use of RAII is kind of cool BTW)
2024-01-29T00:21:02 < Ecco> Well, you're right
2024-01-29T00:21:13 < Ecco> In my case, the HAL I'm using only exposes cpsie/cpsid
2024-01-29T00:21:17 < zyp> the point is, if interrupts are already disabled at the entry of a critical section, you want to leave them disabled as you leave it
2024-01-29T00:21:21 < Ecco> but it's a 100% an edge case
2024-01-29T00:21:28 < Ecco> yes absolutely
2024-01-29T00:21:53 < Ecco> But I just think it's weird that there would be two assembly instructions to do the exact same thing
2024-01-29T00:22:19 < zyp> if you always just blindly reenable them, you'll get weird bugs once you nest two critical sections by accident
2024-01-29T00:22:35 < zyp> so it's better not to :)
2024-01-29T00:24:14 < Ecco> yes this I agree with a 100%
2024-01-29T00:24:32 < Ecco> and I also agree that it's easier to restore a raw value than to test-and-branch
2024-01-29T00:24:49 < Ecco> I'm just curious why the designers of the instruction set gave us two different ways to achieve the same thing
2024-01-29T00:25:08 < Ecco> Like why did they even bother with a cpsie instruction?
2024-01-29T00:53:35 < ventYl> what two ways to achieve the same thing?
2024-01-29T00:54:35 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-29T00:57:55 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 246 seconds]
2024-01-29T01:12:53 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2024-01-29T01:22:45 -!- martinmoene [~Martin@2a02-a45a-96ba-1-7c09-70b2-18bb-b75f.fixed6.kpn.net] has quit [Ping timeout: 260 seconds]
2024-01-29T01:29:25 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:2efd:2040:24cb:d055] has quit [Ping timeout: 256 seconds]
2024-01-29T01:36:37 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 255 seconds]
2024-01-29T02:00:19 -!- dkc [~dan@user/dkc] has quit [Remote host closed the connection]
2024-01-29T02:24:57 -!- nuxil [~nuxil@141.195.51.41] has quit [Read error: Connection reset by peer]
2024-01-29T02:30:01 -!- nuxil [~nuxil@141.195.51.41] has joined ##stm32
2024-01-29T02:34:55 -!- nuxil [~nuxil@141.195.51.41] has quit [Read error: Connection reset by peer]
2024-01-29T02:36:42 -!- nuxil [~nuxil@141.195.51.41] has joined ##stm32
2024-01-29T02:53:50 -!- nuxil [~nuxil@141.195.51.41] has quit [Read error: Connection reset by peer]
2024-01-29T02:55:55 -!- nuxil [~nuxil@141.195.51.41] has joined ##stm32
2024-01-29T03:08:25 < jadew> C++20 is fucking awesome.
2024-01-29T03:15:03 < zyp> it is
2024-01-29T03:15:26 < zyp> and there's some cool stuff on the way in the next ones too
2024-01-29T03:15:36 < jadew> Like what?
2024-01-29T03:15:50 < zyp> like the reflection proposal for c++26
2024-01-29T03:16:04 < jadew> That's going to be interesting, yes.
2024-01-29T03:17:22 < jadew> But we'll probably be using those features in 2030, I just now got access to better consteval support by installing clang-17, which is not available by default on my system.
2024-01-29T03:17:27 < zyp> also looking forward to start using std::expect from C++23, although that's not so revolutionary, just a lib addition without new language features
2024-01-29T03:18:38 < zyp> actually not sure what other stuff is in c++23
2024-01-29T03:19:49 < zyp> 23 seems like one of the minor ones, like 14 and 17
2024-01-29T03:20:32 < jadew> Compilers are still catching up with 20, so it might have been on purpose.
2024-01-29T03:23:25 < zyp> I should get back to doing C++ at some point, been quite a while since last time
2024-01-29T03:23:41 < jadew> What have you been doing instead?
2024-01-29T03:24:18 < zyp> fpga stuff
2024-01-29T03:24:30 < jadew> Still fun :)
2024-01-29T03:24:44 < zyp> sure
2024-01-29T03:25:01 < zyp> also C for work
2024-01-29T03:25:10 < zyp> but lately more python than C
2024-01-29T03:25:15 < jadew> Why C?
2024-01-29T03:25:21 < jadew> kernel stuff?
2024-01-29T03:26:01 < zyp> because the embedded stuff we use for most projects at work is a C codebase
2024-01-29T03:26:59 < jadew> I can't even remember when was the last time I wrote C.
2024-01-29T03:27:24 < zyp> and python because I've been working on production test stuff
2024-01-29T03:32:32 < zyp> made a pretty nice reusable test framework where I in python can issue commands to run both on the jig controller board or on the DUT microcontroller(s)
2024-01-29T03:33:16 < zyp> and then I've got a test spec in yaml describing the target and the test sequence to run, so the python functions can be entirely reusable
2024-01-29T03:33:41 < jadew> Does sound nice, yeah.
2024-01-29T03:33:58 < zyp> e.g. when testing nrf91, I can issue AT commands directly to the modem
2024-01-29T03:34:41 < jadew> How is it running stuff on the DUT's MCU?
2024-01-29T03:34:58 < jadew> Via the debug interface?
2024-01-29T03:35:07 < jadew> Or is some client code in the MCU?
2024-01-29T03:35:42 < zyp> both
2024-01-29T03:36:43 < zyp> there's a test stub built into the firmware that doesn't normally run, test controller includes a debugger
2024-01-29T03:37:15 < zyp> so test controller sets a breakpoint on main, redirects it into the test stub and issues calls that way
2024-01-29T03:37:32 < jadew> Oh, that is extra cool.
2024-01-29T03:37:36 < zyp> push arguments directly into registers, let it run, once it hits a bkpt instruction it's done
2024-01-29T03:38:13 < jadew> You wrote this for them?
2024-01-29T03:38:23 < zyp> one of my coworkers made that stuff for another project a couple of years ago
2024-01-29T03:38:54 < zyp> I reused it for another project around a year ago
2024-01-29T03:39:16 < jadew> Must be a good company, they're clearly hiring smart people.
2024-01-29T03:39:26 < zyp> except the whole testsuite on those projects ran in the firmware of the test controller
2024-01-29T03:39:37 < zyp> which made it a pain to work with
2024-01-29T03:40:26 < jadew> I see, so you took all that out and exposed it as an API, right?
2024-01-29T03:41:32 < zyp> yes, the old stuff effectively had a tcp api that was like «run test sequence x», and then it returned results from each tests
2024-01-29T03:41:58 < zyp> I threw that out and replaced it with a rpc interface
2024-01-29T03:42:37 < zyp> so the individual tests are now python functions and the sequences are now yaml
2024-01-29T03:43:03 < zyp> and when something is misbehaving, I can just open interactive python and call the rpc directly
2024-01-29T03:43:56 < jadew> Is testing a big part of your job, or did they just allow you to invest the time in getting this done?
2024-01-29T03:44:13 < zyp> it's for a customer
2024-01-29T03:45:40 < zyp> the project I'm doing tests for now consists of nine different DUTs
2024-01-29T03:45:51 < zyp> hence the need for more flexibility than the older stuff had
2024-01-29T03:47:14 < zyp> it's a gateway and various devices sort of thing
2024-01-29T03:47:31 < zyp> so they're all based around nrf52 with different stuff hooked up
2024-01-29T03:48:16 < zyp> I've more or less finished the test suite for the gateway, just waiting for hardware for all the other DUTs
2024-01-29T03:48:35 < zyp> should be a bunch of copypaste
2024-01-29T03:52:28 < zyp> most time consuming part left is probably gonna be working out the remaining pass/fail threshold
2024-01-29T03:52:31 < zyp> s
2024-01-29T03:52:59 < jadew> Maybe you can automate that too?
2024-01-29T03:53:35 < zyp> the hardware guys wrote a test spec with sequences and values, which I wrote the yaml from
2024-01-29T03:54:03 < zyp> it's just that once you actually try it in practice, there's always a bunch of stuff that doesn't behave exactly like expected
2024-01-29T03:56:13 < zyp> e.g. rise/fall times that needs longer delays
2024-01-29T03:56:38 < zyp> or power leaking into something that should be unpowered
2024-01-29T03:57:26 < jadew> That sounds more like a bug than margin of error kind of thing :)
2024-01-29T03:58:00 < zyp> or a 3.9V zener not being accurate enough to emulate a battery that's being charged…
2024-01-29T03:58:38 < jadew> Don't you use a programmable load for that?
2024-01-29T03:59:00 < zyp> nah, just a switchable zener
2024-01-29T03:59:29 < jadew> Ah, the test is super simple, not actually following the curve.
2024-01-29T03:59:45 < jadew> "Is this circuit working?"
2024-01-29T04:00:03 < zyp> yeah, there's a charge chip with charge enable and charge status signals
2024-01-29T04:00:49 < zyp> so test spec said feed battery rail with 3.6V, and have a switchable clamp at 3.9V
2024-01-29T04:01:27 < zyp> but in practice the clamp didn't go low enough that I could reliably distinguish it from unclamped at 4.2V or whatever
2024-01-29T04:01:45 < zyp> ended up switching to 3.3V supply and 3.6V zener
2024-01-29T04:03:36 < zyp> easy enough stuff, just takes time
2024-01-29T04:05:31 < jadew> Yeah, it still not boring.
2024-01-29T04:06:13 < jadew> I think I remained scarred from my last job, because now I use that experience as a lens when thinking about what people or myself, do for a living.
2024-01-29T05:19:01 -!- nuxil [~nuxil@141.195.51.41] has quit [Ping timeout: 268 seconds]
2024-01-29T05:31:01 -!- codehampster [~codehamps@2400:a845:8a6d:0:4514:2b6b:5b7f:6a65] has joined ##stm32
2024-01-29T05:41:02 -!- codehampster [~codehamps@2400:a845:8a6d:0:4514:2b6b:5b7f:6a65] has quit [Quit: Textual IRC Client: www.textualapp.com]
2024-01-29T06:01:16 -!- Thorn_ [~Thorn@bl18-149-68.dsl.telepac.pt] has joined ##stm32
2024-01-29T06:03:41 -!- Thorn [~Thorn@user/thorn] has quit [Ping timeout: 256 seconds]
2024-01-29T06:08:58 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has quit [Ping timeout: 264 seconds]
2024-01-29T06:09:15 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Remote host closed the connection]
2024-01-29T08:06:14 -!- ferdna_ [~ferdna@user/ferdna] has joined ##stm32
2024-01-29T08:07:05 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-29T08:10:02 -!- martinmoene [~Martin@2a02-a45a-96ba-1-49af-c13c-437d-2073.fixed6.kpn.net] has joined ##stm32
2024-01-29T08:44:13 -!- martinmoene [~Martin@2a02-a45a-96ba-1-49af-c13c-437d-2073.fixed6.kpn.net] has quit [Ping timeout: 264 seconds]
2024-01-29T08:48:51 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2024-01-29T08:59:45 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-29T09:33:26 -!- c10ud [~c10ud@host-213-26-199-10.business.telecomitalia.it] has joined ##stm32
2024-01-29T09:33:26 -!- c10ud [~c10ud@host-213-26-199-10.business.telecomitalia.it] has quit [Changing host]
2024-01-29T09:33:26 -!- c10ud [~c10ud@user/c10ud] has joined ##stm32
2024-01-29T09:55:59 -!- nuxil [~nuxil@141.195.51.41] has joined ##stm32
2024-01-29T10:08:46 -!- rkta [~rkta@user/rkta] has quit [Remote host closed the connection]
2024-01-29T10:10:35 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has joined ##stm32
2024-01-29T10:16:46 < ventYl> jadew: I tend to assess jobs by "how much can I learn here?"
2024-01-29T10:17:13 < ventYl> or more frequently: "are there any opportunities I can create for myself to learn?"
2024-01-29T10:22:45 < jpa-> my head is already full so i select jobs by "do i have to learn something"
2024-01-29T10:23:43 < ventYl> universe constantly expands. your head is gaining new room every second
2024-01-29T10:25:24 < jpa-> nah, it is bound by forces
2024-01-29T10:25:33 < jpa-> only the empty space expands
2024-01-29T10:26:00 < qyx> welcome sunshines
2024-01-29T10:26:12 < ventYl> > give me the bat
2024-01-29T10:26:22 < qyx> I hope you are positively motivated
2024-01-29T10:27:13 < ventYl> jpa-: another factor is, that in this industry, on average, knowledge is outdated after 5 years and obsolete after 10
2024-01-29T10:27:21 < ventYl> maybe in embedded it lasts a bit longer
2024-01-29T10:27:37 < ventYl> and automotive, there is zero concern with obsoleteness
2024-01-29T10:30:45 < jpa-> people say that but i still use most of the knowledge i learned 20+ years ago
2024-01-29T10:31:42 < jpa-> i have forgotten PHP and Visual Basic, but forgetting stuff is easy
2024-01-29T10:32:04 < jpa-> there is just so much active knowledge i need that i feel like i can't learn much more
2024-01-29T10:35:43 < qyx> thank god I forgot php
2024-01-29T10:36:38 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-29T10:44:35 < ventYl> jpa-: I guess you upgraded most of it of new knowledge and you are effectively using different knowledge than 20 years ago
2024-01-29T10:50:20 -!- machinehum [~machinehu@187.197.2.85.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-29T11:06:13 < zyp> I feel like everytime I need to do something web, everything I knew is obsolete and replaced with something new
2024-01-29T11:08:02 < zyp> then again, a few weeks ago I had to update some simple stuff that uses some traditional javascript stuff, none of the new fancy stuff, and that was also annoying
2024-01-29T11:09:28 < zyp> (I was adding bearer token authentication to some stuff that was still using traditional http digest authentication)
2024-01-29T11:13:17 -!- machinehum [~machinehu@187.197.2.85.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 240 seconds]
2024-01-29T11:14:37 < c10ud> wrt auth and stuff, a few months (?) ago I read an interesting blogpost about a guy implementing some sort of IoT enabled smart device, like a watch or something, along with the challenges he encountered, his data gathering process, etc. since I was planning to learn more about this stuff, do any of you read that? I cannot seem to find it anymore..
2024-01-29T11:18:25 < qyx> no I am avoiding IoT
2024-01-29T11:25:22 < qyx> how do you calculate UVP/UVLO 3-resistor dividers?
2024-01-29T11:27:46 -!- machinehum [~machinehu@187.197.2.85.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-29T11:27:46 < zyp> if you know the voltages you want and that you can assume zero current in the branch, it's easy
2024-01-29T11:28:22 < zyp> just add the top two resistors together and treat them as one when calculating the bottom tap, and other way around for the top tap
2024-01-29T11:30:28 < qyx> yeah but I am tempted to brute-force script E-something values to get the result
2024-01-29T11:30:43 < qyx> you cannot just place arbitrary values there
2024-01-29T11:31:15 < jpa-> you can first do UVP divider as normal, and then split the lower resistor in two
2024-01-29T11:31:54 < zyp> qyx, so in that sense it's an optimization problem
2024-01-29T11:32:33 < zyp> doubt it's worth making a script for, unless it's something you're planning to recalculate often
2024-01-29T11:34:12 < qyx> I am doing 24-28.8 battery range, so 23.8-29 V
2024-01-29T11:34:16 < qyx> Vref is 0.5 V
2024-01-29T11:34:37 < qyx> I managed to get 10k - 2k - 560k
2024-01-29T11:34:54 < qyx> but that shifted it a bit, so I must start from the beginning
2024-01-29T11:35:07 -!- AwsomeTofu [~AwsomeTof@240e:3a4:560a:d1b0:b9a7:f51b:1204:9916] has joined ##stm32
2024-01-29T11:35:16 < qyx> for the third time..
2024-01-29T11:36:14 < AwsomeTofu> is it really worth bringing C++ into a existing C project?
2024-01-29T11:36:30 < zyp> depends what your goal is
2024-01-29T11:36:59 < AwsomeTofu> overall coding efficiency
2024-01-29T11:37:35 < AwsomeTofu> and maybe some C++ only libraries?
2024-01-29T11:37:38 < zyp> C and C++ can coexist fine, but calling C from C++ is easier than the other way around
2024-01-29T11:37:54 < AwsomeTofu> got it
2024-01-29T11:38:22 < AwsomeTofu> so like if i really want c++ i should just start fresh and bring old c code in if necessary
2024-01-29T11:38:32 < zyp> so if you've got a C codebase and would like to migrate to C++, you can do so gradually by starting from the top
2024-01-29T11:39:15 < zyp> or the bottom for that matter, as long as you're working under a C-compatible API
2024-01-29T11:42:02 < AwsomeTofu> What about stuff like rewriting application layer protocols into C++?
2024-01-29T11:42:50 < zyp> sure
2024-01-29T11:43:11 < zyp> also, for a bunch of code you can just rename .c to .cpp and you've got valid C++
2024-01-29T11:43:22 < AwsomeTofu> lol
2024-01-29T11:43:39 < AwsomeTofu> What about speed/memory usage though?
2024-01-29T11:43:46 < qyx> may i rename c to exe to compile it?
2024-01-29T11:44:21 < AwsomeTofu> If let's say I'm not paying much attention to the memory management during rewriting
2024-01-29T11:44:27 < qyx> but to be ontopic, I would fail immediately on designated initialisers
2024-01-29T11:45:02 < zyp> C++ has designated initializers now
2024-01-29T11:45:08 < zyp> more restricted than C, but still
2024-01-29T11:45:18 < qyx> that's the catch
2024-01-29T11:45:36 < zyp> but yeah
2024-01-29T11:45:37  * qyx reordering stuff until it works
2024-01-29T11:46:08 < zyp> C++ is stricter than C on a lot of stuff, so most unmodified C would probably error out somewhere
2024-01-29T11:46:19 < AwsomeTofu> May I ask why designated initializers?
2024-01-29T11:46:32 < AwsomeTofu> Clean code?
2024-01-29T11:46:41 < zyp> C got them in C99, C++ didn't get them until way later
2024-01-29T11:47:21 < zyp> and C++ has rules about ordering, for consistency with initialization order
2024-01-29T11:47:42 < zyp> in C, initialization order doesn't really matter
2024-01-29T11:48:01 < zyp> in C++, initialization includes constructors that can have side effects where order is important
2024-01-29T11:48:20 < AwsomeTofu> >:o
2024-01-29T11:48:31 < AwsomeTofu> note taken
2024-01-29T11:49:05 < zyp> speed/memory shouldn't depend on the code being C or C++
2024-01-29T11:49:41 < zyp> code that's doing the same should take the same amount of time and require the same amount of memory to do it regardless of whether it's originally C or C++
2024-01-29T11:50:35 < zyp> C++ features are «pay as you go», they don't really cost you anything before you use them
2024-01-29T11:52:44 < zyp> from a «resource use per source line» perspective, C++ code typically requires more resources per source line
2024-01-29T11:53:02 < zyp> but that's just because it takes fewer source lines to achieve the same result as in C
2024-01-29T11:57:59 < ventYl> zyp: fun fact: Visual C++ doesn't care
2024-01-29T11:58:38 < ventYl> I recently pushed chunk of /W4 /WX (equivalent of -Wall -Werr) C++17 code through clang-tidy and it found hundreds of errors
2024-01-29T12:03:02 -!- Guest36 [~Guest36@14.141.123.162] has joined ##stm32
2024-01-29T12:08:45 < jpa-> meh, NXP and their refmans.. 1. register, 2. login form doesn't work 3. login finally works, need to fill in extra info 4. extra info form doesn't work 5. finally get to download the pdf
2024-01-29T12:11:23 -!- Alexer [~alexer@alexer.net] has quit [Ping timeout: 264 seconds]
2024-01-29T12:23:20 -!- rkta [~rkta@user/rkta] has joined ##stm32
2024-01-29T12:28:05 < ventYl> if it isn't watermarked, then it is boring
2024-01-29T12:31:08 -!- jmcgnh [~jmcgnh@wikipedia/jmcgnh] has quit [Ping timeout: 252 seconds]
2024-01-29T12:36:27 < zyp> 6. the refman has references to pinout tables and stuff as «attached files»
2024-01-29T12:36:50 < zyp> 7. go back and search the website for those
2024-01-29T12:37:02 < zyp> 8. give up
2024-01-29T12:37:08 < zyp> 9. ??? wtf?
2024-01-29T12:37:18 < zyp> 10. learn that pdf files can have file attachments
2024-01-29T12:37:46 -!- AwsomeTofu [~AwsomeTof@240e:3a4:560a:d1b0:b9a7:f51b:1204:9916] has quit [Ping timeout: 268 seconds]
2024-01-29T12:37:59 < qyx> reminds me what siemens did, zip of an excel (!) with specification as tables and included pdf files
2024-01-29T13:11:17 -!- nuxil [~nuxil@141.195.51.41] has quit [Read error: Connection reset by peer]
2024-01-29T13:13:08 -!- nuxil [~nuxil@141.195.51.41] has joined ##stm32
2024-01-29T13:35:29 < karlp> this usb host demo code for k70 I'm trying to port has commented out code from where it's obviously been ported from one of their older processors.
2024-01-29T13:35:42 < karlp> nxp is awesome...
2024-01-29T13:35:47 < karlp> makes ST look super pro
2024-01-29T13:45:08 < ventYl> :>
2024-01-29T13:53:53 -!- machinehum [~machinehu@187.197.2.85.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 256 seconds]
2024-01-29T14:07:39 -!- machinehum [~machinehu@187.197.2.85.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-29T14:55:50 < karlp> any experts in attribute syntax? https://paste.jvnv.net/view/GPAGN
2024-01-29T14:56:23 < karlp> using the __attribute__((weak)) works, but not the [[gnu:weak]] which I was led to believe was the "correct" c++ form?
2024-01-29T14:57:07 < karlp> it' show zyp handles plain interrupts? https://github.com/karlp/laks/blob/wip/kinetis1/interrupt/default_handlers.cpp.j2#L12
2024-01-29T14:57:44 < qyx> is the :: ok
2024-01-29T14:58:32 < qyx> yeah it is
2024-01-29T14:59:02 < qyx> but why is weak prefixed? it is not a gnu specific attribute
2024-01-29T14:59:48 < karlp> GCC provides two different ways to specify attributes: the traditional GNU syntax using ‘__attribute__ ((...))’ annotations, and the newer standard C and C++ syntax using ‘[[...]]’ with the ‘gnu::’ prefix on attribute names.
2024-01-29T15:01:31 -!- nomorekaki [~nomorekak@37-219-126-217.nat.bb.dnainternet.fi] has joined ##stm32
2024-01-29T15:03:16 < qyx> ok TIL weak is not a standard c/cpp attribute
2024-01-29T15:03:36 < karlp> i don't think any attributes are standard?
2024-01-29T15:03:52 < qyx> I do
2024-01-29T15:04:08 < qyx> eg. this thinks that too https://en.cppreference.com/w/cpp/language/attributes
2024-01-29T15:04:14 < karlp> since c23....
2024-01-29T15:04:22 -!- nomorekaki [~nomorekak@37-219-126-217.nat.bb.dnainternet.fi] has quit [Client Quit]
2024-01-29T15:04:34 < karlp> and only those five or so https://en.cppreference.com/w/c/language/attributes
2024-01-29T15:04:38 < karlp> so... basically nothing
2024-01-29T15:04:46 < qyx> what are you reading
2024-01-29T15:04:53 < qyx> there is a list containing attributes since c++11
2024-01-29T15:05:23 -!- nomorekaki [~nomorekak@37-219-126-217.nat.bb.dnainternet.fi] has joined ##stm32
2024-01-29T15:05:36 < nomorekaki> new computer who dis?
2024-01-29T15:05:42 < qyx> you were asking for c++, not c
2024-01-29T15:05:55 < karlp> ok, trues, I was asking for c++
2024-01-29T15:06:09 < karlp> still, verrrry few standard attributes
2024-01-29T15:06:16 < qyx> yeah
2024-01-29T15:06:38 < karlp> doesnt' change my underlying problem, the [[gnu::weak]] is _meant_ to be equivalent to __attribute__((weak)) but... isn't... somehow.
2024-01-29T15:07:15 < karlp> but I've fixed my resets, I was only trying to turn off the watchdog after clearing ram and shit, and that was too late most of the time...
2024-01-29T15:32:40 < zyp> karlp, are you having issue with this in laks or in other code?
2024-01-29T15:34:36 < karlp> in laks, 
2024-01-29T15:34:55 < karlp> but now i've cleaned and rebuilt and it's no longer giving me the warning?!
2024-01-29T15:35:18 < karlp> the __attribute__ form worked anyway, which is what I needed.
2024-01-29T15:35:53 -!- machinehum [~machinehu@187.197.2.85.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 256 seconds]
2024-01-29T15:35:56 < zyp> where are you putting it?
2024-01-29T15:36:11 < karlp> https://paste.jvnv.net/view/0O1jo I needed to do this...
2024-01-29T15:37:00 < karlp> ahhh
2024-01-29T15:37:02 < karlp> hahah
2024-01-29T15:37:03 < zyp> I suggest doing something like this instead: https://github.com/karlp/laks/blob/wip/kinetis1/interrupt/dispatch_clic.cpp#L21
2024-01-29T15:37:08 < karlp> problem was "gcc::weak"
2024-01-29T15:37:12 < karlp> instead of "gnu::weak"
2024-01-29T15:37:48 < karlp> I'm not sure it's early enough,
2024-01-29T15:37:58 < karlp> constructors are after all ram has been zeroed
2024-01-29T15:38:02 < qyx> lolkarl
2024-01-29T15:38:10 < karlp> kinetis startup code turns off watchdog before init bss.
2024-01-29T15:38:37 < qyx> but you wrote [[gnu:weak]]
2024-01-29T15:39:08 < karlp> qyx: when I hand typed in irc, I used gnu:: in my paste with the error I had gcc:: https://paste.jvnv.net/view/GPAGN
2024-01-29T15:40:23 < qyx> fuk online calculators, increasing number of turns decreases the inductance
2024-01-29T15:40:25 < qyx> what about no
2024-01-29T15:53:51 -!- machinehum [~machinehu@187.197.2.85.dynamic.wline.res.cust.swisscom.ch] has joined ##stm32
2024-01-29T16:44:53 -!- ferdna_ [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-29T16:47:32 -!- nomorekaki [~nomorekak@37-219-126-217.nat.bb.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-29T16:48:58 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-29T16:50:31 -!- jmcgnh [~jmcgnh@wikipedia/jmcgnh] has joined ##stm32
2024-01-29T17:27:20 -!- rkta [~rkta@user/rkta] has quit [Remote host closed the connection]
2024-01-29T17:32:56 < qyx> eleship shipping is definitely slower than anyting other
2024-01-29T17:33:37 < qyx> the parcel ordered thursday evening has not left .nl yet
2024-01-29T17:35:04 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2024-01-29T17:43:33 -!- Alexer [~alexer@alexer.net] has joined ##stm32
2024-01-29T17:59:28 < karlp> holy fuck this kinetis demo code is wild.  I've got close to zero faith it actually works, originally, let alone with my massaging to make it try and run.
2024-01-29T18:00:12 < karlp> huge chunks of commented out code, with gems like ``//TimerInit(); <next line> printf("timer init ok!");``
2024-01-29T18:00:53 < zyp> karlp, you're running laks on kinetis?
2024-01-29T18:01:04 < karlp> two functions, lptmr_init and LPTMR_init with the same signature, the only difference is that one of them attempts to enable an irq, others don't
2024-01-29T18:01:09 < karlp> zyp: yeah, works "good"
2024-01-29T18:01:12 < zyp> :)
2024-01-29T18:01:47 < karlp> I'm only using it right now to give me a sane startup environment to paste this existing codewarrior/IAR project file into, 
2024-01-29T18:01:57 < karlp> but I'm currently doubnting that the demo code ever worked 
2024-01-29T18:02:16 < karlp> but currently unravalling wehther irqs should be -16 or not, 
2024-01-29T18:02:24 < karlp> there's... wildly inconsistent stuff in this code.
2024-01-29T18:07:44 < karlp> hrm, I suspect my clock is not... what is expected.
2024-01-29T18:14:53 -!- machinehum [~machinehu@187.197.2.85.dynamic.wline.res.cust.swisscom.ch] has quit [Quit: WeeChat 4.1.2]
2024-01-29T18:37:13 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 256 seconds]
2024-01-29T18:58:51 < karlp> bus fault precise accessing the last word of ram?
2024-01-29T18:58:57 < karlp> why can't I access the last word of ram...
2024-01-29T19:03:19 < jpa-> what is the fault address?
2024-01-29T19:03:24 < jpa-> (BFAR)?
2024-01-29T19:04:15 < karlp> BusFault: (precise) accessing 0x20010000 I guess that was decoding BFAR
2024-01-29T19:04:21 < karlp> I just turned the memory down to half, 
2024-01-29T19:04:39 < karlp> I don't trust kinetis and it's "upper" and "lower" sram, so just avoided it. 
2024-01-29T19:04:55 < karlp> i'm getting usb interrupts, and it's doing setup a few times, so it's... getting further.
2024-01-29T19:05:56 < jpa-> so isn't that the address past the end of memory?
2024-01-29T19:06:15 < jpa-> last word starting at 0x2000FFFF and the word past it starting at 0x20010000?
2024-01-29T19:06:56 < jpa-> (last byte at 0x2000FFFF, last word at 0x2000FFFC)
2024-01-29T19:08:05 < karlp> I guess...
2024-01-29T19:08:16 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has quit [Ping timeout: 255 seconds]
2024-01-29T19:19:21 < karlp> hrm, free() is doing an infinite loop?
2024-01-29T19:19:27 < karlp> I guess this means it's time to go home...
2024-01-29T19:38:26 -!- nuxil [~nuxil@141.195.51.41] has quit [Ping timeout: 260 seconds]
2024-01-29T20:29:42 -!- rkta [~rkta@user/rkta] has joined ##stm32
2024-01-29T20:34:10 < Ecco> ok, weird, weird thing
2024-01-29T20:34:18 < Ecco> I'm looking at STM32WBA's reference manual
2024-01-29T20:34:25 < Ecco> more specifically, the interrupt vector table
2024-01-29T20:34:39 < Ecco> (Table 129 from the manual)
2024-01-29T20:35:25 < Ecco> blob:https://imgur.com/d3ce556f-5baf-4ddc-86f9-199ce3a9bfc6
2024-01-29T20:35:32 < Ecco> https://i.imgur.com/ihxcoxC.png
2024-01-29T20:35:48 < Ecco> See the offset for EXTI13? Is it completely messed up??
2024-01-29T20:35:54 < Ecco> (and so what about those after it?)
2024-01-29T20:37:36 < Ecco> Then what about TIM3? https://i.imgur.com/j2a0b5E.png
2024-01-29T20:45:00 -!- martinmoene [~Martin@2a02-a45a-96ba-1-15ce-a950-468-70a1.fixed6.kpn.net] has joined ##stm32
2024-01-29T20:45:15 -!- martinmoene_ [~Martin@2a02-a45a-96ba-1-79fc-270-1263-c47f.fixed6.kpn.net] has joined ##stm32
2024-01-29T20:49:15 -!- martinmoene [~Martin@2a02-a45a-96ba-1-15ce-a950-468-70a1.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-29T20:50:59 -!- Guest36 [~Guest36@14.141.123.162] has quit [Quit: Client closed]
2024-01-29T20:51:39 -!- nomorekaki [~nomorekak@37-219-126-217.nat.bb.dnainternet.fi] has joined ##stm32
2024-01-29T21:01:02 -!- nomorekaki [~nomorekak@37-219-126-217.nat.bb.dnainternet.fi] has quit [Ping timeout: 250 seconds]
2024-01-29T21:15:37 < qyx> Ecco: what's wrong with tim3?
2024-01-29T21:16:24 < Ecco> Well, both handlers have the same addres??
2024-01-29T21:17:09 < Ecco> It's not just WBA btw
2024-01-29T21:17:17 < Ecco> Here's H563: https://i.imgur.com/nxfBRT8.png
2024-01-29T21:18:54 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-29T21:21:54 -!- nomorekaki [~nomorekak@37-219-126-217.nat.bb.dnainternet.fi] has joined ##stm32
2024-01-29T21:23:14 < jpa-> Ecco: ST just copypasting stuff wrong :)
2024-01-29T21:23:50 < Ecco> do you think that's a typo?
2024-01-29T21:25:20 < jpa-> yes, i'm pretty sure it is
2024-01-29T21:25:44 < jpa-> AFAIK the vector table order in NVIC always matches the interrupt numbering
2024-01-29T21:26:16 < jpa-> it seems they just selected one row too low when copypasting in excel and the 0xA0 should be where 0xE4 is and all addressed below it are wrong
2024-01-29T21:26:26 < Ecco> Oh ok
2024-01-29T21:26:27 < Ecco> https://github.com/STMicroelectronics/STM32CubeWBA/blob/b133f49dcbe824220d8c0de834b3cc95ea5feeeb/Projects/NUCLEO-WBA52CG/Applications/TFM/TFM_Loader/Secure/Src/startup_stm32wbaxx.c#L225
2024-01-29T21:26:32 < Ecco> This seems to agree with you
2024-01-29T21:26:33 < Ecco> Damn
2024-01-29T21:33:32 < Ecco> It's funny tho because they have a similar mistake in a bunch of M33 chips
2024-01-29T21:33:37 < Ecco> (everys single chip I looked at, actually)
2024-01-29T21:36:44 < Ecco> Ok, so back to square one: I wonder why my RADIO interrupt handler is not being called at all
2024-01-29T21:37:29 < ventYl> at least you know where they copy-pasted the refman from
2024-01-29T21:38:47 < jpa-> i think they made the mistake when they fixed the silly EXTI misorder present in earlier devices
2024-01-29T21:39:08 < jpa-> e.g. STM32F4 vector table order is a total mess
2024-01-29T21:39:25 < Ecco> is there someone we should notify?
2024-01-29T21:39:35 < Ecco> I mean, it's not a huge problem, but they may want to fix it?
2024-01-29T21:40:05 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 240 seconds]
2024-01-29T21:43:48 -!- nuxil [~nuxil@141.195.51.41] has joined ##stm32
2024-01-29T22:05:28 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-29T22:24:02 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:8b1a:65cf:e02e:37f8] has joined ##stm32
2024-01-29T22:34:27 -!- rkta [~rkta@user/rkta] has quit [Remote host closed the connection]
2024-01-29T22:37:01 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 264 seconds]
2024-01-29T22:39:04 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-29T22:49:21 -!- qyx [~qyx@84.245.120.77] has quit [Ping timeout: 260 seconds]
2024-01-29T22:51:10 -!- qyx [~qyx@84.245.121.146] has joined ##stm32
2024-01-29T23:57:41 < nomorekaki> https://www.youtube.com/watch?v=Vciw6AAz4uY
--- Day changed ti tammi 30 2024
2024-01-30T00:17:52 -!- yukam [~yukam@user/yukam] has quit [Ping timeout: 255 seconds]
2024-01-30T00:23:06 -!- yukam [~yukam@user/yukam] has joined ##stm32
2024-01-30T00:58:01 -!- martinmoene_ [~Martin@2a02-a45a-96ba-1-79fc-270-1263-c47f.fixed6.kpn.net] has quit [Ping timeout: 256 seconds]
2024-01-30T01:00:53 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2024-01-30T01:28:45 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:8b1a:65cf:e02e:37f8] has quit [Ping timeout: 256 seconds]
2024-01-30T01:30:36 -!- phryk [~totallyno@user/phryk] has quit [Quit: ZNC 1.8.2 - https://znc.in]
2024-01-30T01:31:24 -!- phryk [~totallyno@user/phryk] has joined ##stm32
2024-01-30T01:36:32 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 252 seconds]
2024-01-30T02:52:37 -!- AwsomeTofu [~AwsomeTof@240e:3a4:560a:9b80:2809:174d:e99e:b3ab] has joined ##stm32
2024-01-30T02:58:44 -!- AwsomeTofu [~AwsomeTof@240e:3a4:560a:9b80:2809:174d:e99e:b3ab] has left ##stm32 []
2024-01-30T03:03:36 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-30T03:34:18 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-30T03:37:52 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Ping timeout: 256 seconds]
2024-01-30T04:07:23 < jadew> I found a type of function that cannot be split in such a way where the result is more readable than keeping it 300 lines long.
2024-01-30T04:07:34 < jadew> Been staring at it for 10 minutes and I just can't...
2024-01-30T04:09:41 < jadew> There are several stages of optimizations that rely on the previous stage, and there are massive, several layers deep data structures being created as the link between the stages. Making functions out of that would mean defining those structures somewhere else, but their structure is tightly related to the code so it makes no sense that they're somewhere else, because that makes it more difficult
2024-01-30T04:09:42 < jadew> to understand :/
2024-01-30T04:46:54 < lemmi> then don't split it. the next best thing is to add some extra { ... } blocks
2024-01-30T04:48:11 < jadew> Ah, it's already very readable... just long and an awkward mental exercise if you try to split it up.
2024-01-30T05:19:13 -!- impulse [~impulse@cpea84e3fe992d3-cma84e3fe992d0.sdns.net.rogers.com] has joined ##stm32
2024-01-30T05:35:55 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has joined ##stm32
2024-01-30T05:36:44 < bitmask> damn you PBR
2024-01-30T05:36:44 < bitmask> https://imgur.com/a/iyA6Ejx
2024-01-30T06:15:46 -!- nomorekaki [~nomorekak@37-219-126-217.nat.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-30T06:41:25 -!- nuxil [~nuxil@141.195.51.41] has quit [Ping timeout: 256 seconds]
2024-01-30T06:44:52 -!- nuxil [~nuxil@141.195.51.41] has joined ##stm32
2024-01-30T06:45:45 -!- nuxil_ [~nuxil@141.195.51.41] has joined ##stm32
2024-01-30T06:46:09 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-30T06:49:51 -!- nuxil [~nuxil@141.195.51.41] has quit [Ping timeout: 260 seconds]
2024-01-30T06:51:43 -!- nuxil_ [~nuxil@141.195.51.41] has quit [Ping timeout: 260 seconds]
2024-01-30T07:22:42 -!- ferdna_ [~ferdna@user/ferdna] has joined ##stm32
2024-01-30T08:03:00 -!- Guest36 [~Guest36@14.141.123.162] has joined ##stm32
2024-01-30T08:24:23 -!- [_] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Remote host closed the connection]
2024-01-30T08:37:51 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
2024-01-30T08:59:54 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-30T09:11:58 -!- martinmoene_ [~Martin@2a02-a45a-96ba-1-1851-7ebc-da87-758.fixed6.kpn.net] has joined ##stm32
2024-01-30T09:20:12 -!- rkta [~rkta@user/rkta] has joined ##stm32
2024-01-30T09:29:34 -!- martinmoene_ [~Martin@2a02-a45a-96ba-1-1851-7ebc-da87-758.fixed6.kpn.net] has quit [Ping timeout: 255 seconds]
2024-01-30T09:53:30 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2024-01-30T10:06:39 -!- jdelmore_ [~jdelmore@67-221-109-36.unassigned.ntelos.net] has joined ##stm32
2024-01-30T10:08:49 -!- jdelmore [~jdelmore@67-221-109-36.unassigned.ntelos.net] has quit [Ping timeout: 264 seconds]
2024-01-30T10:20:12 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has joined ##stm32
2024-01-30T10:44:18 -!- machinehum [~machinehu@2a02:1210:4e1a:b000:1bf0:29de:e881:b69d] has joined ##stm32
2024-01-30T10:45:23 < machinehum> I contribute to open source
2024-01-30T10:45:25 < machinehum> https://github.com/jkwill87/mnamer/pull/291
2024-01-30T10:58:17 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-30T11:44:10 -!- Guest36 [~Guest36@14.141.123.162] has quit [Quit: Client closed]
2024-01-30T12:06:25 < karlp> karl: hey nxp, you should stop using this stuypid caddr_t type hey?  nxp: hold my beer: https://github.com/nxp-mcuxpresso/mcux-sdk/commit/197fbf8122ca960ad7517056ec938ea5871c13e5
2024-01-30T12:07:53 < jpa-> i wish nuttx would drop the FAR* nonsense.. i doubt it even really runs on segmented platforms correctly because all contributors are just throwing FAR randomly in pointers :)
2024-01-30T12:14:32 < ventYl> are there any segmented platforms anymore?
2024-01-30T12:14:49 < ventYl> karlp: you can't deny it actually did fix the bug!!!!1
2024-01-30T12:25:02 < jpa-> ventYl: 8051 will be with us until the end of times
2024-01-30T12:25:19 < ventYl> 8051 is segmented? wat?
2024-01-30T12:25:33 < ventYl> i lived in a lie my whole life!!
2024-01-30T12:25:39 < jpa-> isn't it? or at least i think i remember it having FAR* separately
2024-01-30T12:26:01 < ventYl> isn't that for distinction between IP-relative and absolute jump?
2024-01-30T12:26:11 < jpa-> i mean FAR* for data
2024-01-30T12:26:33 < jpa-> https://developer.arm.com/documentation/101655/0961/Cx51-User-s-Guide/Advanced-Programming/Data-Storage-Formats/Generic-and-Far-Pointers  maybe it is only 80C51 etc. extended versions
2024-01-30T12:26:47 < ventYl> i don't see a reason why crappy shit from pleistocene which is barely able to hold 8kB of memory would have segmentation
2024-01-30T12:27:02 -!- ferdna__ [~ferdna@user/ferdna] has joined ##stm32
2024-01-30T12:30:15 < ventYl> ah ok, so the reason is that it has overlapping address ranges and allows orthogonal accesss
2024-01-30T12:30:29 -!- ferdna_ [~ferdna@user/ferdna] has quit [Ping timeout: 256 seconds]
2024-01-30T12:31:24 < jpa-> looks like 8051-derivatives and Zilog Z16 are the only nuttx-supported platforms using separate far and near pointers
2024-01-30T12:31:58 < jpa-> and AVR in some cases
2024-01-30T12:32:39 < mawk> isn't far and near just relative vs absolute?
2024-01-30T12:33:01 < mawk> like on x86
2024-01-30T12:33:03 < mawk> https://c9x.me/x86/html/file_module_x86_id_147.html
2024-01-30T12:33:11 < mawk> and not related to segmenting
2024-01-30T12:33:45 < mawk> ah no nevermind
2024-01-30T12:34:29 < jpa-> "segmented" in the sense that same pointer value can mean different things in code, data and extended data segments
2024-01-30T12:34:42 < jpa-> https://github.com/apache/nuttx/pull/10428   apparently someone still cares
2024-01-30T12:34:47 < mawk> right
2024-01-30T12:34:52 < ventYl> jpa-: why I don't wonder intel was able to come up with such a shitty design?
2024-01-30T12:37:34 < ventYl> mawk: x86 has short, near and far. short is relative, near is segment-less absolute, far is segment:offset
2024-01-30T13:03:18 < karlp> I'm pretty sure I had to do some region/length related fixes for cortex too.
2024-01-30T13:03:57 < karlp> I'm pretty sure running a flash algorithm had to hve thigns in the right regions, it couldn't reach from ...somewhere
2024-01-30T13:05:29 -!- ferdna__ [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-30T13:06:31 < karlp> ahh, no, it was __attribute__((long_call))
2024-01-30T13:07:46 < karlp> so not segmented, but... pretty similar really?
2024-01-30T13:08:52 < karlp> https://github.com/libopencm3/libopencm3/blob/master/lib/stm32/common/flash_common_l01.c#L110
2024-01-30T13:10:51 < ventYl> isn't it just enforcing absolute address?
2024-01-30T13:11:27 < ventYl> and it is copied there by program, co compiler/linker cannot deduce that itself
2024-01-30T13:14:22 < karlp> yeah, I was just mixing up this FAR segmented stuff, but it's much the same issue is't it? 
2024-01-30T13:14:41 < karlp> nuttx is dropping long_calls / similar over everything "just in case"
2024-01-30T13:25:10 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-30T13:54:51 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-30T14:51:08 < ventYl> karlp: I'd say that the "must force it to be long call explicitly" is far less frequent than if you have to use segment:offset addressing. the former will happen under some rare circumstances where your project layout exceeds capabilities of linker/compiler
2024-01-30T14:51:20 < ventYl> once you have segmented architecture, you are cursed forever
2024-01-30T15:09:53 < qyx> I am happy to find out I just did the whole schematic for G491 based on the G031 datasheet
2024-01-30T15:29:26 < karlp> luck you!
2024-01-30T15:29:28 < karlp> future proofed!
2024-01-30T15:29:33 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has joined ##stm32
2024-01-30T15:35:10 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2024-01-30T15:38:59 -!- Steffanx [sid97872@user/steffanx] has quit [Ping timeout: 268 seconds]
2024-01-30T15:39:09 -!- Steffanx [sid97872@user/steffanx] has joined ##stm32
2024-01-30T15:39:48 -!- CygniX_ [~CygniX@2a01:8740:1:727:4e:80:7f:2d] has joined ##stm32
2024-01-30T15:40:13 -!- PaulFertser [paul@paulfertser.info] has quit [Ping timeout: 268 seconds]
2024-01-30T15:40:22 -!- PaulFertser [paul@paulfertser.info] has joined ##stm32
2024-01-30T15:41:27 -!- CygniX [~CygniX@user/CygniX] has quit [Ping timeout: 268 seconds]
2024-01-30T16:08:12 < karlp> meh, k70 demo code fails to enumerate as a device too, let alone host.
2024-01-30T16:15:13 < Mangy_Dog> are their any stm32s that have built in csi to video porcessing engines? with h264 bit streams out?
2024-01-30T16:16:10 < specing> That's...
2024-01-30T16:16:17 < specing> a bit much for a mcu
2024-01-30T16:16:26 < Mangy_Dog> sure
2024-01-30T16:16:31 < Mangy_Dog> thought so :p
2024-01-30T16:16:39 < Mangy_Dog> but wondered if there was something
2024-01-30T16:18:34 < specing> also from my experience it seems the bigger stm32 are more expensive than just going with a cortex-a from some other manufacturer
2024-01-30T16:19:08 < specing> though the application processors often contain heaps of undocumented peripherals and unsupported crap vendor blobs
2024-01-30T16:19:29 < Mangy_Dog> well it needs to be something i can work with :p
2024-01-30T16:19:33  * specing suspects such peripherals would also be blobbed / undocumented in stm32s, but haven't looked
2024-01-30T16:19:35 < Mangy_Dog> thats why i wanted to avoid a full soc
2024-01-30T16:20:08 < zyp> there's stm32 with mipi dsi, but I haven't seen anything with csi
2024-01-30T16:20:33 < Mangy_Dog> yeah some of the bigger opnes have mpip out and even basic 3d accelirators
2024-01-30T16:20:39 < Mangy_Dog> mipip
2024-01-30T16:20:42 < Mangy_Dog> christ
2024-01-30T16:20:44 < Mangy_Dog> mipi
2024-01-30T16:21:18 < zyp> if you're effectively building a webcam then pick a chip designed for that, there should be plenty
2024-01-30T16:21:45 < Mangy_Dog> security camera... but yeah
2024-01-30T16:22:12 < zyp> have you considered using a rpi cm?
2024-01-30T16:22:31 < Mangy_Dog> yes but not on the camera directly
2024-01-30T16:22:48 < Mangy_Dog> id rather not have the soc on the camera
2024-01-30T16:23:12 < Mangy_Dog> tbh im half minded to look at usb camera interfaces
2024-01-30T16:23:16 < Mangy_Dog> that might solve some issues
2024-01-30T16:23:20 < Mangy_Dog> esp with bandiwdth
2024-01-30T16:23:23 < zyp> something that could do CSI to h264 would effectively be a SoC/SoM anyway
2024-01-30T16:23:30 < Mangy_Dog> i mean yes
2024-01-30T16:23:36 < Mangy_Dog> but i dont want to use up a raspberry pi
2024-01-30T16:23:57 < Mangy_Dog> id rather have a single chip that does it efficeiantly 
2024-01-30T16:24:03 < Mangy_Dog> unlike my spelling
2024-01-30T16:24:49 < zyp> which efficiency are you thinking of? power efficiency? cost efficiency? time of development efficiency? size efficiency?
2024-01-30T16:24:58 < Mangy_Dog> all the above 
2024-01-30T16:25:00 < Mangy_Dog> :p
2024-01-30T16:25:05 < Mangy_Dog> power being a key one
2024-01-30T16:25:10 < Mangy_Dog> then cost and size
2024-01-30T16:25:27 < Ecco> I'm trying to figure out why using ST's bluetooth library doesn't work
2024-01-30T16:25:34 < Ecco> I'm using GDB to step in their code
2024-01-30T16:25:40 < Ecco> I don't understand this code tho:
2024-01-30T16:25:41 < Ecco> https://i.imgur.com/vQ6iUnU.png
2024-01-30T16:25:54 < zyp> a rpi cm4 is small and easy (and means you can prototype on a regular rpi and just port everything to a cm4 on a custom board)
2024-01-30T16:25:59 < Ecco> Why would they pass the stack pointer to a bunch of functions, sequentially?
2024-01-30T16:26:23 < Mangy_Dog> zyp but it also needs to run in software and we need sub 1 second wake up times
2024-01-30T16:26:52 < zyp> is this a work projects that's going to be made thousands or more of?
2024-01-30T16:27:13 < zyp> wake up or power on?
2024-01-30T16:27:19 < Mangy_Dog> not sure about thousands
2024-01-30T16:27:35 < Mangy_Dog> certainly hundreds if not a couple of thousand...
2024-01-30T16:27:58 < Mangy_Dog> i really dont know its super early in this project heck... im speculating v2 here... we havent built the v1 prototype yet
2024-01-30T16:28:02 < Mangy_Dog> which is still images
2024-01-30T16:28:48 < zyp> I worked a bit on a security camera sort of thing for a previous employer eight years or so ago, don't remember exactly what chip it was based on, but it was some linux-capable sort of thing
2024-01-30T16:29:06 < jbo> TI had some offerings there AFAIK
2024-01-30T16:29:15 < zyp> I suspect if you want a h264 encoder, most suitable chips will be something you'd run linux on
2024-01-30T16:29:41 < Mangy_Dog> was hoping thered be a hardware h264 encoder/streamer... would make sense if there was
2024-01-30T16:29:43 < zyp> which means you're not too far away from a cm4 anyway
2024-01-30T16:29:49 < Mangy_Dog> thats true
2024-01-30T16:29:58 < Mangy_Dog> but still want to see if its something i can avoid
2024-01-30T16:30:10 < zyp> isn't there a hardware h264 encoder in the broadcom socs rpi use?
2024-01-30T16:30:33 < Mangy_Dog> im sure
2024-01-30T16:31:01 < Mangy_Dog> I just dont want a full fledge pi on every camera
2024-01-30T16:31:10 < Mangy_Dog> the boss wont aprove that
2024-01-30T16:31:12 < zyp> I'm not sure there's a big market for standalone h264 chips, would think most are peripherals in application SoCs
2024-01-30T16:31:14 < Mangy_Dog> approve
2024-01-30T16:31:22 < jbo> Mangy_Dog, OpenMV?
2024-01-30T16:31:26 < jbo> https://openmv.io/
2024-01-30T16:31:37 < Mangy_Dog> TBH without buying a few and tearing them down... im wondering what nature camera traps use
2024-01-30T16:32:19 < Mangy_Dog> hehe 
2024-01-30T16:32:19 < Mangy_Dog> ok
2024-01-30T16:32:22 < zyp> ah, is that what you're making?
2024-01-30T16:32:26 < Mangy_Dog> its using an imx cpu
2024-01-30T16:32:35 < zyp> that explains power budget and wakeup times
2024-01-30T16:32:36 < Mangy_Dog> zyp not quite
2024-01-30T16:32:39 < Mangy_Dog> but yes
2024-01-30T16:32:43 < Mangy_Dog> simular setup
2024-01-30T16:32:48 < Mangy_Dog> needs sleep and cost budget
2024-01-30T16:33:02 < jbo> Mangy_Dog, did some "similar" work with a SAMA5D lately - might want to check if that fits your needs
2024-01-30T16:33:36  * Mangy_Dog looks
2024-01-30T16:33:47 < jbo> it's similar to imx tho
2024-01-30T16:34:00 < jbo> i.e. cortex-a
2024-01-30T16:34:03 < Mangy_Dog> nods
2024-01-30T16:34:17 < Mangy_Dog> im not against it and if it must have linux, something really stripped small and fast
2024-01-30T16:34:26 < Mangy_Dog> like i say sub 1 second wake up
2024-01-30T16:34:31 < jbo> I did a yocto based system - was small and fast
2024-01-30T16:34:32 < Mangy_Dog> ideally sub 500ms
2024-01-30T16:34:38 < jbo> it did have sub-1sec wakeup for sure
2024-01-30T16:34:41 < jbo> was like 100ms or something
2024-01-30T16:34:45 < Mangy_Dog> nice
2024-01-30T16:34:54 < zyp> boot or wakeup from sleep?
2024-01-30T16:34:58 < jbo> wakeup from sleep
2024-01-30T16:35:04 < Mangy_Dog> thats a point whats boot time?
2024-01-30T16:35:13 < jbo> boot was a few seconds
2024-01-30T16:35:32 < jbo> I had slow I/O on the disc interface
2024-01-30T16:35:39 < zyp> if it's battery powered and low power sleep gets low enough, boot time doesn't really matter because you can just keep it in low power sleep all the time
2024-01-30T16:35:41 < jbo> if I recall correctly it was like 5 seconds or something
2024-01-30T16:36:54 < jbo> Mangy_Dog, SAMA5D has a SiP where DDR memory is integrated into the same chip. that was nice. they have some SoMs too
2024-01-30T16:37:11 < Mangy_Dog> nods
2024-01-30T16:37:13 < Mangy_Dog> looking at the site now
2024-01-30T16:37:42 < karlp> rv1103/rv1106 or the ssd parts are _literaly_ designed for this.
2024-01-30T16:37:52 < karlp> if you want to go down that path.
2024-01-30T16:38:04 < jbo> Mangy_Dog, the yocto build was very easy to get done right/properly compared to some "chinese stuff". microchip maintains stuff well from what I can tell
2024-01-30T16:38:14 < Mangy_Dog> nods
2024-01-30T16:38:21  * qyx approves
2024-01-30T16:38:36 < qyx> I am using both sama5d27 SoMs and myir imx6 SoM
2024-01-30T16:38:39 < karlp> rv110x boards are cheap 
2024-01-30T16:38:41 < qyx> both run openwrt and debian too
2024-01-30T16:38:53 < Mangy_Dog> yeah kalp
2024-01-30T16:38:57 < Mangy_Dog> just googled
2024-01-30T16:38:57 < Mangy_Dog> :d
2024-01-30T16:39:10 < Mangy_Dog> only 1 issue quick looking over 
2024-01-30T16:39:13 < Mangy_Dog> its 2 lane csi
2024-01-30T16:39:16 < Mangy_Dog> i need 4 for 4k
2024-01-30T16:39:22 < karlp> you didn't say that.
2024-01-30T16:39:25 < Mangy_Dog> its ok
2024-01-30T16:39:27 < jbo> that's new info :D
2024-01-30T16:39:28 < qyx> oh you need mipi csi?
2024-01-30T16:39:32 < karlp> 4k is a different category :)
2024-01-30T16:39:43 < Mangy_Dog> i might have said 4 lane before but yeah 
2024-01-30T16:39:44 < jbo> 4k makes anything even remotely stm32 impractical to begin with
2024-01-30T16:39:46 < Mangy_Dog> well actually
2024-01-30T16:39:47 < Mangy_Dog> its 2k
2024-01-30T16:39:48 < jbo> if not straight out impossible
2024-01-30T16:39:49 < Mangy_Dog> i think
2024-01-30T16:39:54 < Mangy_Dog> but same thing 4 lane
2024-01-30T16:45:25 < jpa-> if mjpeg was enough, you could use a camera module with built-in encoding; but that will still limit to 30 FPS or so for 2k resolution
2024-01-30T16:46:22 < Mangy_Dog> i think h254 is pretty much the benchmark they want
2024-01-30T16:46:30 < Mangy_Dog> also mjpegs always been a bit rough
2024-01-30T16:47:19 < jpa-> what kind of latency are you aiming for?
2024-01-30T16:47:27 < jpa-> and fps
2024-01-30T16:47:31 < Mangy_Dog> well
2024-01-30T16:47:45 < Mangy_Dog> latency is a bit... up in the air
2024-01-30T16:47:53 < Mangy_Dog> fps will be 25fps+
2024-01-30T16:48:08 < jpa-> why not just rpi?
2024-01-30T16:48:11 < Mangy_Dog> though likely 30
2024-01-30T16:48:47 < Mangy_Dog> Cost will be too pohibitive 
2024-01-30T16:48:56 < Mangy_Dog> prohibitive 
2024-01-30T16:49:09 < qyx> there is a myir SoM with some mobile phone processor and lpddr4
2024-01-30T16:49:12 < qyx> for about $20
2024-01-30T16:49:20 < qyx> check if it has 4 lane csi
2024-01-30T16:49:31 < jpa-> if rpi is too expensive, you'll need a quite big batch to get cheaper than that (at least 100 units, probably 1000)
2024-01-30T16:49:51 < Mangy_Dog> the batch size wont be an issue
2024-01-30T16:49:52 < Mangy_Dog> just
2024-01-30T16:50:19 < Mangy_Dog> if the soc is going to be £50 + just for the soc
2024-01-30T16:50:23 < Mangy_Dog> and the camera is 20
2024-01-30T16:50:31 < Mangy_Dog> thats not going to be popular
2024-01-30T16:50:39 < qyx> ok not $20 anymore https://www.mouser.sk/ProductDetail/MYIR/MYC-YT507H-8E2D-150-I?qs=vvQtp7zwQdNNPdjOhDBRIQ%3D%3D
2024-01-30T16:51:11 < qyx> you could get quote directly from them, they even have prices on their web
2024-01-30T16:51:20 < Mangy_Dog> we do already
2024-01-30T16:51:28 < Mangy_Dog> the company has a relationship with them
2024-01-30T16:51:46 < Mangy_Dog> but its still not going to be popular having a cm4 on each camera
2024-01-30T16:52:03 < qyx> I mean myir
2024-01-30T16:52:07 < qyx> not rpi, fuk rpi
2024-01-30T16:52:10 < Mangy_Dog> oh
2024-01-30T16:52:15 < qyx> ceck the link
2024-01-30T16:52:19 < qyx> it has 4 lane csi
2024-01-30T16:52:28 < qyx> and capable of encoding 8MP @ 30fps
2024-01-30T16:52:28 < Mangy_Dog> looking
2024-01-30T16:52:56 < qyx> oh thats for capturing, h264 encoder is 30 fps fhd
2024-01-30T16:52:59 < Mangy_Dog> oh its an allwinner module
2024-01-30T16:53:02 < qyx> sorry 30 fps 4K
2024-01-30T16:53:10 < jpa-> looks nice
2024-01-30T16:53:34 < jpa-> 4K@25fps for encoder, but anyway
2024-01-30T16:54:19 < qyx> why did I read 30 fps
2024-01-30T16:54:27 < qyx> I guess I am over-something-worked now
2024-01-30T16:54:53 < Mangy_Dog> i said both
2024-01-30T16:54:54 < Mangy_Dog> its ok
2024-01-30T16:55:08 < Mangy_Dog> 25 is uk but we have american clients so 30fps would be wanted to
2024-01-30T16:55:38 < qyx> you can't catch them all
2024-01-30T16:56:09 < jpa-> 2k will be faster
2024-01-30T17:19:08 < Ecco> Ghidra is pretty good :)
2024-01-30T17:20:22 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-30T17:33:42 < karlp> hisilicn or sigmastart might have options too.  or openipc.org...
2024-01-30T17:33:50 < karlp> ot at least pointers to more of the chips...
2024-01-30T18:09:50 < Mangy_Dog> ohh thanks
2024-01-30T18:40:58 -!- nomorekaki [~nomorekak@37-219-126-217.nat.bb.dnainternet.fi] has joined ##stm32
2024-01-30T18:53:45 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
2024-01-30T19:04:25 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-30T19:11:49 -!- martinmoene_ [~martinmoe@132.229.46.129] has joined ##stm32
2024-01-30T19:12:33 < hsv> Mangy_Dog: i dodn't read the full discussion... what's your artionale for not wanting a SoC on the camera itself?
2024-01-30T19:12:43 < hsv> *rationale
2024-01-30T19:15:24 -!- martinmoene__ [~martinmoe@132.229.46.129] has quit [Ping timeout: 252 seconds]
2024-01-30T19:16:34 -!- boB_K7IQ [~boB_K7IQ@184-98-171-178.phnx.qwest.net] has quit [Ping timeout: 252 seconds]
2024-01-30T19:18:00 -!- nomorekaki [~nomorekak@37-219-126-217.nat.bb.dnainternet.fi] has quit [Quit: Ping timeout (120 seconds)]
2024-01-30T19:22:21 < jbo> machinehum, ping
2024-01-30T19:36:35 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 264 seconds]
2024-01-30T19:37:41 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has quit [Ping timeout: 260 seconds]
2024-01-30T20:05:25 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-8d99-7cb-6b85-54fc.fixed6.kpn.net] has joined ##stm32
2024-01-30T20:37:54 < karlp> ok, 20Mhz out means one of the clocks is 120Mhz, so... looking reasonable.
2024-01-30T20:38:57 < jbo> where does one get SVD files for STM32 MCUs these day from?
2024-01-30T20:39:09 < jbo> didn't ST have those on their product website?
2024-01-30T20:41:24 < fenugrec> id check where  https://github.com/cmsis-svd/cmsis-svd get theirs
2024-01-30T20:42:01 < fenugrec> oops wrong link
2024-01-30T20:42:12 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-30T20:42:51 < fenugrec> https://github.com/cmsis-svd/cmsis-svd-data
2024-01-30T20:47:20 < qyx> stm32-rs has them too
2024-01-30T20:47:32 < qyx> they say with some corrections and fixes
2024-01-30T20:48:53 < fenugrec> heh fixing st's SVD for them
2024-01-30T20:59:31 < qyx> cmsis-svd lacks u5/h5 hm
2024-01-30T21:16:51 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-30T21:39:12 < Ecco> From arm's website
2024-01-30T21:39:31 < Ecco> (I think they call it cmsis device pack)
2024-01-30T21:40:24 < Ecco> Which one are you looking for?
2024-01-30T21:41:22 < Ecco> Anyway, just look them up there jbo: https://www.keil.arm.com/devices/
2024-01-30T21:43:23 < jbo> finally found them from ST: https://www.st.com/en/microcontrollers-microprocessors/stm32g4-series.html#cad-resources
2024-01-30T21:43:28 < jbo> thanks guys! :)
2024-01-30T21:50:14 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has joined ##stm32
2024-01-30T22:18:59 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 252 seconds]
2024-01-30T22:21:40 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-30T22:23:39 < qyx> den bosch, utrecht, neuenstein, budapest
2024-01-30T22:23:46 < qyx> what the hell gls
2024-01-30T22:24:08 < qyx> it is 5th day now and still not delivered
2024-01-30T22:24:49 < qyx> every day the parcel hops a single country
2024-01-30T22:44:06 -!- inca [~jhg@130.41.224.64] has joined ##stm32
2024-01-30T22:51:09 < inca> O brother dongs, where art thou?
2024-01-30T23:03:15 -!- nomorekaki [~nomorekak@37-219-126-217.nat.bb.dnainternet.fi] has joined ##stm32
2024-01-30T23:07:25 < nomorekaki> Steffanx: musics https://www.youtube.com/watch?v=X2mqrzKHb3w
2024-01-30T23:57:41 < karlp> hacked the shit out of a tinyusb tree to get it to compile, and... it fails to enumerate as well.
2024-01-30T23:57:50 < karlp> that was a bit of a hail mary though :)
2024-01-30T23:58:17 < karlp> ok, wayyyy overdone for today
--- Day changed ke tammi 31 2024
2024-01-31T00:04:43 < qyx> TIL computer ecology
2024-01-31T00:14:16 < karlp> ahah! pretending to be a different cpu means teh irq numbers are wrong!
2024-01-31T00:15:14 < Steffanx> Fuck no, nomorekaki 
2024-01-31T00:15:46 < nomorekaki> Steffanx: https://www.youtube.com/watch?v=GEDzDk-a6Sw then try this musics
2024-01-31T00:16:43 < karlp> ahh, interrupts!
2024-01-31T00:17:10 < karlp> we're making progress: https://paste.jvnv.net/view/3TPNo
2024-01-31T00:40:20 < Ecco> In the context of Bluetooth Low Energy, do you guys know what these constant could mean? HCI_TX_PHY_LE_1M / HCI_TX_PHY_LE_2M / HCI_TX_PHY_LE_CODED ?
2024-01-31T00:40:35 < Ecco> I get the "HCI_TX_PHY" part, but "1M", "2M", "CODED"? Not at all
2024-01-31T00:40:46 < karlp> just set it to 1M and forget it about it for now.
2024-01-31T00:40:48 < zyp> it's the different air protocols
2024-01-31T00:40:53 < karlp> there should be an option for auto or default
2024-01-31T00:41:01 < zyp> 1Mb/s vs 2Mb/s vs whatever the coded one was
2024-01-31T00:41:20 < karlp> 125k iirc. but it scales too iirc.
2024-01-31T00:41:27 < karlp> either way, ifyou don't know what they are, you want 1M.
2024-01-31T00:41:35 < zyp> agreed
2024-01-31T00:41:58 < Ecco> Cool, thanks!
2024-01-31T00:42:30 < Ecco> weird
2024-01-31T00:42:34 < Ecco> in ST's sample code
2024-01-31T00:42:36 < Ecco> they do this:   ret = hci_le_set_default_phy(0x00, HCI_TX_PHYS_LE_2M_PREF, HCI_RX_PHYS_LE_2M_PREF);
2024-01-31T00:42:43 < karlp> do that then.
2024-01-31T00:42:50 < karlp> probably preference for 2M
2024-01-31T00:42:56 < karlp> not all radios have that option
2024-01-31T00:43:05 < Ecco> ok
2024-01-31T00:43:09 < karlp> the 1 and 2M are somewhat compatible fallback
2024-01-31T00:43:13 < karlp> the coded is totally not,
2024-01-31T00:43:16 < Ecco> I guess I need to read about tis
2024-01-31T00:43:18 < Ecco> ok :)
2024-01-31T00:43:19 < karlp> and only for people doing long range bt stuff
2024-01-31T00:43:22 < Ecco> Thanks for the help!
2024-01-31T00:43:29 < Ecco> By the way
2024-01-31T00:43:35 < Ecco> I have *no idea* about the typical range of BLE
2024-01-31T00:43:37 < Ecco> What is it like?
2024-01-31T00:43:45 < karlp> as long as a ball of string.
2024-01-31T00:43:48 < Ecco> (I realize this is a vague question)
2024-01-31T00:43:53 < Ecco> well, yeah, ofc
2024-01-31T00:44:11 < Ecco> but I mean, I have litteraly no idea. Are we talking 1 meter ? More like 10 ? Maybe 100 ?
2024-01-31T00:44:16 < Ecco> Is it "kinda like WiFi"?
2024-01-31T00:44:21 < Ecco> Or much lower usually?
2024-01-31T00:44:29 < karlp> you should not be asking yourself this question this late in the game
2024-01-31T00:44:30 < Ecco> (I'd assumer the latter)
2024-01-31T00:44:45 < Ecco> Oh, well, I don't need the range for my application anyway
2024-01-31T00:44:49 < Ecco> it's going to be <1m
2024-01-31T00:45:02 < Ecco> I *assume* it's well within the capabilities of BLE
2024-01-31T00:45:05 < Ecco> I'm just being curious
2024-01-31T00:47:08 < zyp> I actually asked my boss today about BLE range, he said «probably fine within 50m or so»
2024-01-31T00:48:22 < Ecco> oh, ok
2024-01-31T00:48:22 < karlp> very much depends on what you want tobe doing with it.
2024-01-31T00:48:28 < Ecco> I expected way less
2024-01-31T00:48:43 < zyp> yes, this was with a particular application in mind
2024-01-31T00:48:46 < qyx> I can certainly say victron chargers have range ~5m
2024-01-31T00:52:28 -!- nomorekaki [~nomorekak@37-219-126-217.nat.bb.dnainternet.fi] has quit [Quit: Client closed]
2024-01-31T00:53:25 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-8d99-7cb-6b85-54fc.fixed6.kpn.net] has quit [Ping timeout: 255 seconds]
2024-01-31T01:00:19 -!- Spirit532 [~Spirit532@user/Spirit532] has quit [Read error: Connection reset by peer]
2024-01-31T01:02:06 -!- Spirit532 [~Spirit532@user/Spirit532] has joined ##stm32
2024-01-31T01:30:59 < fenugrec> I've seen 16m but that was probaly regular BT not BLE
2024-01-31T01:33:40 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has quit [Ping timeout: 256 seconds]
2024-01-31T01:46:29 -!- jadew [~rcc@user/rcc] has quit [Ping timeout: 240 seconds]
2024-01-31T02:00:40 -!- jadew [~rcc@5.12.175.110] has joined ##stm32
2024-01-31T02:00:54 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Quit: Bye]
2024-01-31T03:21:58 -!- drkow [~k\o\w@2607:fea8:1d00:89f0:7087:67b5:15b5:2657] has joined ##stm32
2024-01-31T03:25:31 -!- kow__ [~k\o\w@cpee0dbd1bd5280-cme0dbd1bd527e.cpe.net.cable.rogers.com] has quit [Ping timeout: 255 seconds]
2024-01-31T03:27:03 < Ecco> lol
2024-01-31T03:27:17 < Ecco> My gas meter emits the power usage over 900 MHz radio
2024-01-31T03:27:25 < Ecco> turns out, I had a cheap RTL-SDR dongle lying around
2024-01-31T03:27:30 < Ecco> That can totally decode this
2024-01-31T03:27:35 < Ecco> fun!
2024-01-31T03:45:59 < specing> mmm nice
2024-01-31T04:01:40 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-31T04:03:41 -!- inca [~jhg@130.41.224.64] has quit [Quit: Client closed]
2024-01-31T04:31:00 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has joined ##stm32
2024-01-31T04:44:45 < ColdKeyboard> If I'm making for example 10-20 ADC measurements. What is the best value to get the "real" value? RMS or average?
2024-01-31T04:45:15 < ColdKeyboard> Briefly; I have a hall sensor on one side and magnet on the other. Using it to measure diameter via ADC
2024-01-31T05:27:48 -!- jhg [~jhg@130.41.224.64] has joined ##stm32
2024-01-31T05:32:25 -!- yukam [~yukam@user/yukam] has quit [Ping timeout: 276 seconds]
2024-01-31T05:38:00 -!- [itchyjunk] [~itchyjunk@user/itchyjunk/x-7353470] has quit [Remote host closed the connection]
2024-01-31T06:03:58 -!- jhg [~jhg@130.41.224.64] has quit [Ping timeout: 250 seconds]
2024-01-31T07:27:06 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-31T07:36:17 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
2024-01-31T08:00:53 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-31T08:03:14 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-9c04-9bba-81d2-bb3d.fixed6.kpn.net] has joined ##stm32
2024-01-31T08:29:30 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-9c04-9bba-81d2-bb3d.fixed6.kpn.net] has quit [Ping timeout: 260 seconds]
2024-01-31T08:33:24 < jpa-> ColdKeyboard: what is your signal like? if the signal is stable and you just want to remove ADC noise, then trimmed mean is probably the best
2024-01-31T08:33:45 < jpa-> normal average/mean is next ebst
2024-01-31T08:33:48 < jpa-> *best
2024-01-31T08:41:48 < qyx> don't forget hysteretic behaviour if applies
2024-01-31T08:44:18 < jpa-> ColdKeyboard: for hall sensors, 50Hz/60Hz mains noise could be an issue, in which case you want to average over a whole cycle (16.7 ms or 20 ms, or to catch 'em all, 100 ms)
2024-01-31T09:08:03 -!- ferdna [~ferdna@user/ferdna] has joined ##stm32
2024-01-31T09:08:54 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-31T09:17:03 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-8d31-bd97-24ff-4cb2.fixed6.kpn.net] has joined ##stm32
2024-01-31T09:32:49 -!- martinmoene__ [~Martin@2a02-a45a-96ba-1-8d31-bd97-24ff-4cb2.fixed6.kpn.net] has quit [Ping timeout: 264 seconds]
2024-01-31T09:42:38 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has joined ##stm32
2024-01-31T10:04:54 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has joined ##stm32
2024-01-31T11:01:57 -!- Mangy_Dog [Mangy_Dog@user/mangy-dog/x-7397214] has joined ##stm32
2024-01-31T11:02:37 -!- Thorn_ [~Thorn@bl18-149-68.dsl.telepac.pt] has quit [Quit: Not that there is anything wrong with that]
2024-01-31T11:16:30 < karlp> what's "trimmed mean"?
2024-01-31T11:17:02 < Mangy_Dog> the state of my brain?
2024-01-31T11:26:01 < karlp> hum, fuck I just sent a mass email thinking it was a management team.
2024-01-31T11:26:09 < karlp> fucking office365 hiding all details of everything
2024-01-31T11:27:41 < qyx> I got a value of 1.629 quadrillions instead of about 1000
2024-01-31T11:27:47 < qyx> how could that even happen
2024-01-31T11:28:15 < Mangy_Dog> bad rounding? ;p
2024-01-31T11:28:19 < qyx> all computation is made in float32
2024-01-31T11:28:43 < qyx> maybe a single bit error in th exponent?
2024-01-31T11:33:30 < jpa-> karlp: sort samples, remove X largest and smallest, average rest
2024-01-31T11:33:47 < jpa-> eliminates outliers better than normal average
2024-01-31T11:34:27 < jpa-> i usually find max & min value index and skip those for averaging, avoids doing a full sort and still reasonably good
2024-01-31T11:35:44 < zyp> so a trimmed average is effectively something in between a plain average and a median
2024-01-31T11:36:17 < jpa-> yeah
2024-01-31T11:36:29 < jpa-> eliminates both spot noise and gaussian noise
2024-01-31T11:39:10 < jpa-> for longer or sliding window averaging, a median filter of each 3 samples and then averaging after that is a good alternative
2024-01-31T11:42:08 < zyp> I tried this sort of stuff on a project once: https://en.wikipedia.org/wiki/Lulu_smoothing
2024-01-31T11:44:15 < zyp> (they seem nice, but ended up not being suitable for the particular signal I had and filtering I needed)
2024-01-31T11:45:09 < zyp> I know my coworker (who recommended that to me) uses them in a couple of other projects with success
2024-01-31T11:46:46 < Mangy_Dog> would putting in a function to disregard value differences greater than X be a good way to remove noise? Assuming you know that values above x will just be noise and not just strange high data readings
2024-01-31T11:47:24 < Mangy_Dog> ie value between last and current sample
2024-01-31T11:48:55 < jpa-> only if you are fine with passing noise of x-1 unchanged
2024-01-31T11:50:17 < Mangy_Dog> nods
2024-01-31T12:01:45 < karlp> I feel I am forgetting somethign form digikey, but ... oh well.
2024-01-31T12:07:24 < Mangy_Dog> today im really forgetting something... my brain
2024-01-31T12:07:31 < Mangy_Dog> it really is a mess today D:
2024-01-31T12:08:08 < qyx> my brian is on vacation to
2024-01-31T12:08:12 < qyx> *too
2024-01-31T12:08:48 < Mangy_Dog> ive got into a bit of rimworld (a game) AND  i stayed up a little above bed time... really is totally my fault
2024-01-31T12:09:06 < Mangy_Dog> ie bed time would have been no later than 11, but ideally 10:30, i went at 11:30 :(
2024-01-31T12:09:51 < Mangy_Dog> headachy tired
2024-01-31T12:16:07 < qyx> my sleep is usually 01:00-6:30
2024-01-31T12:19:19 < jpa-> what would you use to avoid powered down MCU (which acts as I2C slave) having shared I2C bus? analog switch? N-FETs with gate tied to MCU VDD?
2024-01-31T12:19:27 < jpa-> *hanging
2024-01-31T12:19:49 < zyp> bus needs to be operative when MCU is powered down?
2024-01-31T12:20:33 < jpa-> yeah, because the MCU is just I2C slave
2024-01-31T12:20:35 < zyp> if so, I'd be tempted to use an i2c level shifter
2024-01-31T12:20:50 < zyp> or put it on a dedicated bus
2024-01-31T12:21:12 < jpa-> hmm, level shifter sounds like a good idea
2024-01-31T12:21:21 < zyp> I worked on a project recently where we've got two i2c buses because one slave got a dedicated one so everything including pullups can be powered down
2024-01-31T12:23:43 < jpa-> https://www.digikey.fi/en/products/detail/nxp-usa-inc/NX3L2T66GT-115/2530676  could work also
2024-01-31T12:30:45 < karlp> qyx: you were asking about the size of this big firmware that I as looking at the CRC load time?
2024-01-31T12:34:13 < karlp> firmware is 3.8M.  bootloader accepts via tftp and stores into nor flash.  the main _slow time_ though is reading a 64MB flash, over 1 bit spi, at 25Mhz, and then doing software crc 16 on 655k sub blocks of 14bytes each.
2024-01-31T12:34:18 < karlp> so yeah, it's real time...
2024-01-31T12:34:39 < karlp> I'll plug it back in later and time it, but it's well and truly long enough to get lost doing something else.
2024-01-31T12:37:24 < qyx> karlp: should I ask why 655k subblocks of *14* bytes?
2024-01-31T12:38:24 < qyx> I am truly amazed by this world
2024-01-31T12:40:15 < karlp> I am truly amazed as well.
2024-01-31T12:40:36 < karlp> 16 byte blocks of model records, with individual crc.
2024-01-31T12:40:51 < karlp> someone went all hi-rel on it, or at least believed they were.
2024-01-31T12:41:17 < karlp> write config changes to fram, have task that spools from fram down to nor-flash.
2024-01-31T12:41:54 < karlp> but it's "ok" as it just gets powered on and stays there...
2024-01-31T12:42:01 < karlp> (except when you're developing of course....)
2024-01-31T12:42:15 < qyx> haha
2024-01-31T12:44:31 < qyx> ok eleshop not delivered because of "incomplete address", thank you gls
2024-01-31T12:51:16 < karlp> .34
2024-01-31T13:49:10 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 264 seconds]
2024-01-31T13:49:30 -!- nerozero [~nerozero@87.253.63.54] has joined ##stm32
2024-01-31T15:34:35 -!- martinmoene_ [~martinmoe@132.229.46.129] has quit [Read error: Connection reset by peer]
2024-01-31T15:40:53 -!- martinmoene [~martinmoe@132.229.46.129] has joined ##stm32
2024-01-31T15:41:12 -!- martinmoene [~martinmoe@132.229.46.129] has left ##stm32 []
2024-01-31T15:47:39 -!- dogukan [~dogukan@user/dogukan] has joined ##stm32
2024-01-31T16:09:37 -!- dogukan [~dogukan@user/dogukan] has quit [Quit: Konversation terminated!]
2024-01-31T16:13:41 -!- jhg [~jhg@130.41.224.64] has joined ##stm32
2024-01-31T16:53:11 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-31T16:55:55 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-31T16:56:12 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-31T16:57:56 -!- rob_w [~bob@host-82-135-31-73.customer.m-online.net] has quit [Remote host closed the connection]
2024-01-31T17:01:28 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-31T17:09:28 -!- ferdna [~ferdna@user/ferdna] has quit [Quit: Leaving]
2024-01-31T17:28:22 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Read error: Connection reset by peer]
2024-01-31T17:28:50 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has joined ##stm32
2024-01-31T18:00:11 -!- martinmoene_ [~martinmoe@132.229.46.129] has joined ##stm32
2024-01-31T18:43:47 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has quit [Quit: Leaving.]
2024-01-31T19:01:14 -!- martinmoene__ [~martinmoe@132.229.46.129] has joined ##stm32
2024-01-31T19:04:09 -!- bitmask [~bitmask@c-73-112-55-67.hsd1.nj.comcast.net] has joined ##stm32
2024-01-31T19:04:11 -!- martinmoene_ [~martinmoe@132.229.46.129] has quit [Ping timeout: 252 seconds]
2024-01-31T19:11:20 -!- MGF_Fabio [~MGF_Fabio@host-217-58-46-226.business.telecomitalia.it] has quit [Ping timeout: 252 seconds]
2024-01-31T19:17:21 -!- jhg [~jhg@130.41.224.64] has quit [Quit: Client closed]
2024-01-31T20:25:10 -!- boB_K7IQ [~boB_K7IQ@184-98-171-178.phnx.qwest.net] has joined ##stm32
2024-01-31T20:33:43 -!- martinmoene_ [~Martin@2a02-a45a-96ba-1-6592-2bdf-3c4d-491c.fixed6.kpn.net] has joined ##stm32
2024-01-31T20:40:09 -!- nerozero [~nerozero@87.253.63.54] has quit [Ping timeout: 268 seconds]
2024-01-31T21:05:28 -!- emeb_mac [~emeb_mac@ip174-72-120-238.ph.ph.cox.net] has joined ##stm32
2024-01-31T21:53:16 -!- Linux_Kerio [~Linux_Ker@chello085216193138.chello.sk] has quit [Ping timeout: 276 seconds]
2024-01-31T22:33:47 -!- pragmalin [~pragmalin@user/pragmalin] has joined ##stm32
2024-01-31T22:44:44 -!- boB_K7IQ [~boB_K7IQ@184-98-171-178.phnx.qwest.net] has quit [Ping timeout: 255 seconds]
2024-01-31T22:45:28 -!- MGF_Fabio [~MGF_Fabio@2a01:e11:200d:8dd0:d4ac:f725:215e:4a05] has joined ##stm32
2024-01-31T22:45:29 -!- boB_K7IQ [~boB_K7IQ@184-98-171-178.phnx.qwest.net] has joined ##stm32
2024-01-31T22:54:08 -!- jhg [~jhg@130.41.224.65] has joined ##stm32
2024-01-31T22:55:01 -!- qyx [~qyx@84.245.121.146] has quit [Ping timeout: 264 seconds]
2024-01-31T22:56:29 -!- qyx [~qyx@84.245.121.6] has joined ##stm32
2024-01-31T23:03:50 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-31T23:13:41 -!- PaulFertser [paul@paulfertser.info] has quit [Ping timeout: 256 seconds]
2024-01-31T23:20:03 -!- nomorekaki [~nomorekak@37-219-126-217.nat.bb.dnainternet.fi] has joined ##stm32
2024-01-31T23:20:32 -!- PaulFertser [paul@paulfertser.info] has joined ##stm32
2024-01-31T23:35:16 < karlp> fucking, updated the opensda firmware on this board to latest daplink.  no swo support.
2024-01-31T23:35:28 < karlp> allegedly it supports jlink as well, but that one just bootloops.
2024-01-31T23:35:39 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has quit [Ping timeout: 256 seconds]
2024-01-31T23:38:15 < karlp> no point looking at jlink fw, they didn't even fucking connect the pin.
2024-01-31T23:38:19 < karlp> what lazy cheap shit is this.
2024-01-31T23:38:20 -!- IanW_ [~IceChat9@arcanum.force9.co.uk] has joined ##stm32
2024-01-31T23:38:22 < karlp> FRDM my arse.
2024-01-31T23:47:25 -!- pragmalin [~pragmalin@user/pragmalin] has quit [Quit: Leaving]
--- Log closed to helmi 01 00:00:19 2024