pronvis has quit [Remote host closed the connection]
pronvis has joined #rust-embedded
AtleoS has quit [Ping timeout: 268 seconds]
pronvis has quit [Remote host closed the connection]
pronvis has joined #rust-embedded
Mathias[m] has joined #rust-embedded
<Mathias[m]>
Hello. I am in Berlin for the Oxidize Conference. I was wondering if others in this channel attending or local interested in meeting this week.
pronvis has quit [Ping timeout: 240 seconds]
<JamesMunns[m]1>
I'm also here (always, but also for this week!), interested to join if folks are in town, also up if anyone wants to chat for a [Chats with James](https://jamesmunns.com/podcast/) episode, DM me to arrange :D
M9names[m] has joined #rust-embedded
<M9names[m]>
i'd forgotten all about Oxidize (RustNL was yesterday right?). have fun in berlin!
<Mathias[m]>
The conference has a social event for attendees on Wednesday that ends at 7pm. Maybe locals we can suggest a venue not to for drinks / dinner after?
<JamesMunns[m]1>
<Mathias[m]> "The conference has a social..." <- hmm, the area around the venue is kinda commercial/a lot of offices but not a ton of nightlife. There's probably some stuff around there, but I'm not too sure. There are some fun areas south (Bergmannkiez) and east (Oranienstr, near Kottbusser Tör), but they are a decent walk (20-30m) or a couple transit stops away. Going north on Friedrichstr is probably closer, but it's a
<JamesMunns[m]1>
little more touristy (this is probably fine tho just to find somewhere to go to eat/drink).
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 255 seconds]
IlPalazzo-ojiisa has joined #rust-embedded
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 256 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 268 seconds]
pronvis has joined #rust-embedded
<sourcebox[m]>
So, the transfer of the usbd-midi crate to r-e-c is finished and I've also some cleanup on it. A release could be done soon, but there's one thing that bothers me: the readme contains an example for the STM32 BluePill. It will likely not compile anymore after 3 years and there's no mention which HAL is used for it. Any advice how to deal with such a situation?
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
andreas[m] has quit [Quit: Idle timeout reached: 172800s]
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
<sourcebox[m]> "For whatever reason, Element..." <- Interesting! I find it doesn't crash for me, but it has some unpleasant habits, including an unreliable message-read count, frequent notifications to verify, but a broken verification process, and poor performance.
<firefrommoonligh>
* poor performance. (Windows)
<firefrommoonligh>
* Interesting! I find it doesn't crash for me, but it has some unpleasant habits, including an unreliable unread message indication frequent notifications to verify, but a broken verification process, and poor performance. (Windows)
<firefrommoonligh>
Granted, the unread message indication seems to have fixed itself a month or so agao
<sourcebox[m]>
I'm on Linux, it often just quits.
<firefrommoonligh>
sounds like Pulseview for me...
<sourcebox[m]>
And yes, I should have a look at the logs, I know...
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
if you are on element nightly, they added a nice feature, a global thread view. So you now get working notifications on a per thread basis across all channels and can click on it and get directly into it. It works better as the normal thread overview, though still only working to 95% 😂 It showed me a couple of threads where the normal view said that i had unread messages but never actually showed me the unread messages...
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]>
<Mathias[m]> "The conference has a social..." <- I'll be in town for the conference as well, feel free to message me (or find me at the conference!)
<sourcebox[m]>
Maybe I should just remove all hardware-dependent parts like in the readme of usbd-serial.
badyjoke[m] has joined #rust-embedded
<badyjoke[m]>
Hello ! Do you know some good examples using embedded-hal-mock I could look at ?
<M9names[m]>
I don't know about good examples, but I did write a bunch of mock tests for wii-ext:
<M9names[m]>
The nunchuk tests are the easiest to read (no macros)
TomB[m] has quit [Quit: Idle timeout reached: 172800s]
<badyjoke[m]>
Thanks ! I was also asking myself, if it's a good pratice to write test for HAL, looking throught some of them I didn't see any test.
<badyjoke[m]>
s/HAL/HALs /
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
testing HALs themselves is trickier.
<dirbaio[m]>
for a driver for some chip that uses i2c, you can mock the i2c
<dirbaio[m]>
but the HAL is what makes i2c itself work. you could mock i2c peripheral register writes and assert the i2c driver is doing the correct ones, but that's very annoying and won't catch many bugs
<dirbaio[m]>
because many hal bugs are due to incorrect/incomplete model of what you think the hardware does. like from reading docs you THINK you have to do these reg writes to do an i2c transfer, you make your test assert that, it passes, all nice. but then the hardware has some weird quirk where under some condition it'll hang or corrupt data
<dirbaio[m]>
in my experience testing with actual hardware is the best effort/benefit ratio
<dirbaio[m]>
much less annoying than mocking registers, and can catch more bugs
<dirbaio[m]>
the biggest downside is means your CI needs access to real hardware
<badyjoke[m]>
Thanks for the infos ! I agree with you, hardware as its own consciousness sometimes 😅
<firefrommoonligh>
As DB is aware, programming I2C on Stm32 is a pain. The timings alone are a mess the RM doesn't prepare you for.
<ryan-summers[m]>
I personally haven't had much issue with it, but indeed the only real way to verify peripheral functionality is to run it on hardware IME
<firefrommoonligh>
That's why I don't do tests for embedded, outside specific logic-heavy functions
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
<Lumpio->
I think the RM I looked at didn't even entirely specify how to calculate the timing parameters...
<Lumpio->
Just like "use CubeMX or this Excel sheet with VB macros"
<Lumpio->
Usually the RMs are pretty good but I2C too complicated apparently
<sourcebox[m]>
Is it advisable to specify the dependency on usb-devie just as usb-device = "0.3" or with the full version number?
<sourcebox[m]>
s/devie/device/
<sourcebox[m]>
Ommiting the patch field would give the resolver more options as I understand it.
<ryan-summers[m]>
I don't think it actually matters at all unless you use a preceding specifier (i.e. =0.3.1, ^0.3.1)
<ryan-summers[m]>
If you just say usb-device = "0.3", it should work the same as usb-device = "0.3.2". The actual patch version is maintained in the lockfile
<ryan-summers[m]>
(As long as say 0.3.2 exists)
<sourcebox[m]>
So, I can just leave "0.3.2" as version if it doesn't matter.
<ryan-summers[m]>
Yeah should be fine I believe
AlexandrosLiarok has joined #rust-embedded
<AlexandrosLiarok>
I find the st LL-drivers very useful. They are not as reusable as higher-level HALs but they are a good way to get a readable overview of a peripheral's capabilities, often one can get away without knowing exactly which register sets which option.
<AlexandrosLiarok>
s/st/ST's/, s/ as/_as_/
<sourcebox[m]>
Would you like to include the crate in the readme of usb-device?
<AlexandrosLiarok>
* I find the ST's LL-drivers very useful. They are not as reusable as higher-level HALs but they are a good way to get a readable overview of a peripheral's capabilities, often one can get away without knowing exactly which register sets which option. They are often easier to get right as well. I am thinking of using stm32-data to retrieve the LL headers, parse them and generate a rust port.
<ryan-summers[m]>
Although I'm not seeing a firm answer anywhere in the docs, just mentioning my experience so far
<AlexandrosLiarok>
* I find the ST's LL-drivers very useful. They are not as reusable as higher-level HALs but they are a good way to get a readable overview of a peripheral's capabilities, often one can get away without knowing exactly which register sets which option. They are often easier to get right as well. I am thinking of using stm32-data to retrieve the LL headers, parse them and generate a rust port. Anyone thinks this would be
<AlexandrosLiarok>
useful ?
<AlexandrosLiarok>
* I find ST's LL-drivers very useful. They are not as reusable as higher-level HALs but they are a good way to get a readable overview of a peripheral's capabilities, often one can get away without knowing exactly which register sets which option. They are often easier to get right as well. I am thinking of using stm32-data to retrieve the LL headers, parse them and generate a rust port. Anyone thinks this would be
<AlexandrosLiarok>
useful ?
<sourcebox[m]>
Maybe I should specify 0.3.0 just for the case that some HAL is not yet on 0.3.2
<ryan-summers[m]>
Just write 0.3
<sourcebox[m]>
ok
<ryan-summers[m]>
Unless there's a specific reason to use something higher than 0.3.0, in which case you'd want to do something like ^0.3.1
AlexandervanSaas has quit [Quit: Idle timeout reached: 172800s]
<sourcebox[m]>
So, release is done. Some internals are still discussible, but later. E.g. there is a manual calculation of the descriptor size, not sure if that was required in earlier versions of usb-device or if it was just done due to lack of knowledge.
pronvis has quit [Remote host closed the connection]