tokomak has quit [Read error: Connection reset by peer]
tokomak has joined #rust-embedded
<re_irc>
<@korken89:matrix.org> Does anyone here know if it's "OK" to forward PoE? I'm thinking of making a small Ethernet based device that has one Ethernet in, one out and RMII to the MCU (so I'll have a 3 port swich IC on the board), but I'd like it to work from PoE and forward the PoE to the next unit. Just connecting the power center taps and forward the power seems to work fine - but I'm not sure if this can cause problems with like...
<re_irc>
... PoE+ equipment. Does anyone know here? I have only tried with passive PoE.
<re_irc>
<@jordens:matrix.org> I can see that causing problems when the downstream devices wants to use LLDP to negotiate PoE+. You'd have to forward that as well.
<re_irc>
<@korken89:matrix.org> Hmm right
<re_irc>
<@korken89:matrix.org> Can one be sneaky and only go with passive PoE? Or is that a bad thing today?
<re_irc>
<@korken89:matrix.org> I mean, I really don't care about other equipment - I just want to forward the PoE for it to work with more of my units in series
<re_irc>
<@ryan-summers:matrix.org> It's difficult for people to know what type of PoE their switch is providing
<re_irc>
<@korken89:matrix.org> But I want to use Ethernet and normal cabling
<re_irc>
<@ryan-summers:matrix.org> So it would manifest as "some devices work fine" and others just don't at all, and it wouldn't be clear why
<re_irc>
<@korken89:matrix.org> Maybe just mark the outport as "not ethernet"
<re_irc>
<@korken89:matrix.org> Though that seems doomed to fail xD
<re_irc>
<@jordens:matrix.org> Passive PoE with 100BaseT over the unused pairs is likely to work just fine IME.
<re_irc>
<@korken89:matrix.org> jordens:matrix.org: Yeah, I have tested exactly this just as a PoC
<re_irc>
<@jordens:matrix.org> ... also with "high end" PSE.
<re_irc>
<@korken89:matrix.org> I connected about 600m of cable in the end with 12 units to evaluate
<re_irc>
<@korken89:matrix.org> No problemo
<re_irc>
<@korken89:matrix.org> But the PoE stuff scares me :P
<re_irc>
<@ryan-summers:matrix.org> So if you just forward and don't deal with LLDP, you would support basic PoE, but not PoE+ or PoE++
<re_irc>
<@ryan-summers:matrix.org> Most COTS stuff is likely to be PoE+ or PoE++ from what I've seen
<re_irc>
<@ryan-summers:matrix.org> Since most switches are gigabit nowadays since they're all pretty cheep
<re_irc>
<@korken89:matrix.org> Right
<re_irc>
<@korken89:matrix.org> What happens if you connect a "stupid" passive PoE device into a PoE+ PSE?
<re_irc>
<@korken89:matrix.org> Without negotiation chip
<re_irc>
<@korken89:matrix.org> Do they fallback to passive PoE or just nothing?
<re_irc>
<@ryan-summers:matrix.org> It depends on the PSE - if it supports basic PoE, it might work? Would have to dig into the standards
<re_irc>
<@korken89:matrix.org> Makes sense
<re_irc>
<@korken89:matrix.org> Maybe I should upgrade my house switch to support PoE+ :D
<re_irc>
<@ryan-summers:matrix.org> I haven't looked into how negotiation via LLDP works
<re_irc>
<@korken89:matrix.org> I checked ICs such as MAX5969, but it would only make sense for the unit actually connecting to the PSE
<re_irc>
<@korken89:matrix.org> But then I can request 25W Class 4 PoE
<re_irc>
<@korken89:matrix.org> Quite a fun design challenge
<re_irc>
<@ryan-summers:matrix.org> Ah, so handle negotiation, but just reserve it for your downstream?
<re_irc>
<@korken89:matrix.org> I just want to connect my sensors together and not be dependent on a star network
<re_irc>
<@ryan-summers:matrix.org> That's an interesting idea
<re_irc>
<@korken89:matrix.org> But still stay in Ethernet land
<re_irc>
<@korken89:matrix.org> As I don't want to hack my own communication protocols and all that :P
<re_irc>
<@korken89:matrix.org> And <3 ethernet
<re_irc>
<@korken89:matrix.org> But thanks for discussing! I need to experiment some more :)
<re_irc>
<@korken89:matrix.org> And actually maybe read the standard xD
<re_irc>
<@korken89:matrix.org> Oh, that negotiation chip can be used to enable power downstream
<re_irc>
<@korken89:matrix.org> And if it sees actual PoE voltage it just turns on and assumes passive PoE
<re_irc>
<@korken89:matrix.org> So the top unit would negotiate, and all the rest would just turn on
<re_irc>
<@ryan-summers:matrix.org> And then you just forward the PoE signals to the other ethernet port?
<re_irc>
<@korken89:matrix.org> Yeah
<re_irc>
<@korken89:matrix.org> One would need a switch to enable downstream power though probably...
<re_irc>
<@korken89:matrix.org> But that can be solved
<re_irc>
<@ryan-summers:matrix.org> I think the various PoE implementations put the DC voltage on different pairs depending on the link speed. You may need to handle moving DC bias from gigabit pairs over to unused ethernet pairs
<re_irc>
<@korken89:matrix.org> Hmm yeah
<re_irc>
<@ryan-summers:matrix.org> Might be simplified if you only assume 100Mbit PHYs?
<re_irc>
<@korken89:matrix.org> Yeah, I force the managed switch IC to 100MBit currently
<re_irc>
<@korken89:matrix.org> It supportes 10 and 100 MBit
<re_irc>
<@korken89:matrix.org> (testing with the LAN9303)
<re_irc>
<@korken89:matrix.org> It's not like my IoT sensors need 100 MBit either xD
<re_irc>
<@korken89:matrix.org> But having 100Mbit "backbone" makes sure there are no perf issues ever
<re_irc>
<@ryan-summers:matrix.org> Nowadays it's probably more work to go 10MB only than to just go for 10/100 ;)
<re_irc>
<@korken89:matrix.org> Yeah
<re_irc>
<@korken89:matrix.org> They also auto negoitate 100 Mbit, so it was quite nice
<re_irc>
<@korken89:matrix.org> Plug and play
<re_irc>
<@pinealservo:matrix.org> You don't even need special crossover cables to go NIC-to-NIC anymore. Magic!
fabic has quit [Ping timeout: 265 seconds]
<re_irc>
<@therealprof:matrix.org> Though Auto-MDIX is cursed, too. High-end equipment still has problems with Auto-MDIX and even autonegotiation today so people still disable those features...
cr1901 has quit [Ping timeout: 260 seconds]
Amadiro has quit [Remote host closed the connection]
<re_irc>
<@adamgreig:matrix.org> korken89:matrix.org: in general 802.3af (PoE) PSEs will not supply any "passive" PoE, only negotiated, and 802.3at/bt PoE+/++ PSEs will all (that I've ever seen...) also negotiate 802.3af/PoE just fine
<re_irc>
<@adamgreig:matrix.org> I think your plan of having a PoE(+) PD chip on the upstream-facing switch port and then applying the DC power to a spare pair on the downstream port should work OK
<re_irc>
<@korken89:matrix.org> Cool, so as long as one has the "negotiation chip" all should be fine I guess
<re_irc>
<@adamgreig:matrix.org> unless your first device in the chain is always special, maybe just give them all the negotiation chip?
<re_irc>
<@adamgreig:matrix.org> then any of them can be powered by passive or active PoE(+)
<re_irc>
<@korken89:matrix.org> Yeah, I was sort of thinking the same
<re_irc>
<@korken89:matrix.org> I wonder if it
<re_irc>
<@korken89:matrix.org> If one only forwards the pairs
<re_irc>
<@korken89:matrix.org> Else each unit would need to disable downstream power while negotiating
<re_irc>
<@adamgreig:matrix.org> the PD chip in the most upstream device would not enable output power until it's negotiated
<re_irc>
<@adamgreig:matrix.org> the PD chips typically gate the power out
<re_irc>
<@adamgreig:matrix.org> you can buy PSE chips too, so could do active downstream PoE, but I don't think there's that much point
<re_irc>
<@adamgreig:matrix.org> except _maybe_ safety concerns if you worry about 48V being live on a disconnected cable?
<re_irc>
<@korken89:matrix.org> Yeah, but it's "in parallel" with just forwarding the PoE
<re_irc>
<@korken89:matrix.org> Oh right
<re_irc>
<@adamgreig:matrix.org> it wouldn't be in parallel, each PD would only turn on when it either negotiates PoE or detects enough voltage from a passive PoE
<re_irc>
<@korken89:matrix.org> Ah, I mean if one just connects the center taps between the 2 connectors
<re_irc>
<@adamgreig:matrix.org> they have to anyway, to control the current drawn from the PSE which is used for signalling
<re_irc>
<@adamgreig:matrix.org> oh, yea, don't do that I guess
<re_irc>
<@korken89:matrix.org> That's my sneaky current method
<re_irc>
<@korken89:matrix.org> Yeah, adding a switch is no problem
<re_irc>
<@adamgreig:matrix.org> if you have a bunch of uncontrolled loads I don't think PoE negotiation would succeed at all
<re_irc>
<@adamgreig:matrix.org> usually the PD chips contain the switch
<re_irc>
<@korken89:matrix.org> Yeah, but the PD chip is after a rectifier so you'd pay for the voltage drop per node
<re_irc>
<@korken89:matrix.org> Hmm, but that can be cirumvented
<re_irc>
<@adamgreig:matrix.org> asking for trouble without the rectifier
<re_irc>
<@adamgreig:matrix.org> if someone uses a crossover cable by mistake...
<re_irc>
<@adamgreig:matrix.org> how long are you imagining the chain being, given you only have like 12 or maybe 25W to play with?
<re_irc>
<@korken89:matrix.org> So far with the "stupid" forward 600m was fine
<re_irc>
<@adamgreig:matrix.org> sorry, I mean, how many devices?
<re_irc>
<@korken89:matrix.org> Ah not sure, but I guess max 20
<re_irc>
<@korken89:matrix.org> They draw just under 1W it seems
<re_irc>
<@korken89:matrix.org> So with class 4 PoE I get 25W
<re_irc>
<@korken89:matrix.org> - losses
<re_irc>
<@adamgreig:matrix.org> hmm, yea, I guess 20 diode voltage drops would be pretty annoying
<re_irc>
<@adamgreig:matrix.org> I guess each node can have a rectifier and just not daisychain the power through it
<re_irc>
<@korken89:matrix.org> I have no idea to be honest I just like the idea of many units in a daisychain :)
<re_irc>
<@adamgreig:matrix.org> use the PD power-good output to enable a bypass switch for supplying downstream
<re_irc>
<@korken89:matrix.org> Yeah, something like that
<re_irc>
<@korken89:matrix.org> I think just 2 back to back P fets would do it
<re_irc>
<@adamgreig:matrix.org> so the device's own power comes through the PoE chip, and once the device is turned on, it can also turn on a switch to supply downstream directly from upstream pairs
<re_irc>
<@korken89:matrix.org> Exactly
<re_irc>
<@korken89:matrix.org> I think that would work and with low Rds on
<re_irc>
<@adamgreig:matrix.org> don't forget about isolation, unless your whole device is not otherwise connected to anything else
<re_irc>
<@adamgreig:matrix.org> but yea seems pretty reasonable. worth experimenting at least
<re_irc>
<@korken89:matrix.org> It's all in a box, does one need isolated then?
<re_irc>
<@korken89:matrix.org> Currently I just have a DCDC that supports up to 60V
<re_irc>
<@adamgreig:matrix.org> not if the only external connection is ethernet
<re_irc>
<@adamgreig:matrix.org> I like the TPS2378 PoE+ PD chip btw, though they're basically all the same
<re_irc>
<@korken89:matrix.org> Yeah that's the only external connected the rest is radio and temp sensors :)
<re_irc>
<@korken89:matrix.org> Oh
<re_irc>
<@korken89:matrix.org> I have to take a look at that one
<re_irc>
<@korken89:matrix.org> I currently have the MAX5969
<re_irc>
<@korken89:matrix.org> That I can experiment with
<re_irc>
<@adamgreig:matrix.org> I'm sure it's basically the same
<re_irc>
<@korken89:matrix.org> I'll check :)
<re_irc>
<@korken89:matrix.org> Ah yes it also connects the GND when negotiation is OK
<re_irc>
<@korken89:matrix.org> Sweet always good to have more options in today chip shortage xD
<re_irc>
<@korken89:matrix.org> To test the ethernet I'm harvesting STM32s from devboards xD
<re_irc>
<@adamgreig:matrix.org> desperate times
<re_irc>
<@korken89:matrix.org> Yeah
<re_irc>
<@korken89:matrix.org> Luckily the devboards are almost the price of the ICs
<re_irc>
<@korken89:matrix.org> Like i wanted the KSZ8863RLL 3port switch I
<re_irc>
<@korken89:matrix.org> As it has finished Rust driver
<re_irc>
<@korken89:matrix.org> Buuuut like 100 weeks leadtime xD
<re_irc>
<@adamgreig:matrix.org> D:
<re_irc>
<@korken89:matrix.org> And devboards with it is 100 euros
<re_irc>
<@korken89:matrix.org> So no go there haha
<re_irc>
<@adamgreig:matrix.org> I ended up with some irritating realtek rgmii phy recently because all the micrel/microchip rgmii were completely out of stock, frustrating
<re_irc>
<@korken89:matrix.org> Luckily they had more that was equivalent
<re_irc>
<@adamgreig:matrix.org> and of course all you can get for those is leaked datasheets with half the numbers redacted
<re_irc>
<@korken89:matrix.org> OIof
<re_irc>
<@adamgreig:matrix.org> guess what value of RSET current-setting resistor to use based on an ST app note for their MP1 dev board that used a similar realtek rgmii phy
<re_irc>
<@adamgreig:matrix.org> seems to have worked, lol
<re_irc>
<@korken89:matrix.org> xD
<re_irc>
<@korken89:matrix.org> Haha awesome
<re_irc>
<@korken89:matrix.org> As you said, deperate times
dreamcat4 has quit [Quit: Connection closed for inactivity]
<re_irc>
<@korken89:matrix.org> But thanks for letting me pick your brain! :D
<re_irc>
<@korken89:matrix.org> Now I need to get lunch
cr1901 has joined #rust-embedded
<re_irc>
<@korken89:matrix.org> Hey adamgreig I remember sometime long ago you pointed me to an Ethernet based bootloader you liked, but I cannot for the life of me find it. Could you help me find it again?
<re_irc>
<@korken89:matrix.org> ryan-summers: One thing I saw, I saw that you got the MAC from an EEPROM
<re_irc>
<@korken89:matrix.org> A newbie question there
<re_irc>
<@ryan-summers:matrix.org> The EEPROM is actually a MAC chip with like 128 bytes of EEPROM as well
<re_irc>
<@ryan-summers:matrix.org> It comes from microchip with a hardware unique MAC to use
<re_irc>
<@korken89:matrix.org> Ahh cool
<re_irc>
<@korken89:matrix.org> I saw that MAC is assigned based on company and such
<re_irc>
<@korken89:matrix.org> So I was sort of wondering if it's like with USB where one needs to buy a AMC
<re_irc>
<@ryan-summers:matrix.org> Yeah, we just buy the chips from microchip, so the MAC is using Microchips company code
<re_irc>
<@ryan-summers:matrix.org> AFAIK the chips are still really cheap
<re_irc>
<@korken89:matrix.org> Nice
<re_irc>
<@korken89:matrix.org> Awesome, another worry laid to rest :
<re_irc>
<@korken89:matrix.org> Thanks!
<re_irc>
<@ryan-summers:matrix.org> No worries!
<re_irc>
<@adamgreig:matrix.org> you can also buy a small MAC prefix (4096 addresses) for not much money, but then you have to organise assigning them to hardware
<re_irc>
<@adamgreig:matrix.org> the MAC EEPROMs are really nice, I've used them on a bunch of things
<re_irc>
<@adamgreig:matrix.org> advantage of buying an actual prefix is that wireshark will eventually update to show your company name in the decodes which is pretty fun
<re_irc>
<@adamgreig:matrix.org> (still $780, so only "not much money" compared to a USB VID)
<re_irc>
<@dirbaio:matrix.org> you can also use a random locally administered mac address 🙈
<re_irc>
<@adamgreig:matrix.org> you can also just make them up and use locally administered ones, if you just want to watch the world burn :P
<re_irc>
<@korken89:matrix.org> Hehe
<re_irc>
<@dirbaio:matrix.org> and hope no network admin gets angry at you
<re_irc>
<@dirbaio:matrix.org> lol
<re_irc>
<@adamgreig:matrix.org> I saw you typing and knew what you were about to say :P
<re_irc>
<@dirbaio:matrix.org> ahhahah 🤣
<re_irc>
<@korken89:matrix.org> Huh but this reminds me of a thing
<re_irc>
<@korken89:matrix.org> Aren't phones and such always using random MAC?
<re_irc>
<@korken89:matrix.org> I guess that's maybe only for WiFi though
<re_irc>
<@korken89:matrix.org> Cable connected stuff might now be as happy with the idea
<re_irc>
<@dirbaio:matrix.org> well you can assign a random mac at factory, so it's random per device, not per boot
<re_irc>
<@korken89:matrix.org> Yeah
<re_irc>
<@korken89:matrix.org> Would that pass certification tests?
<re_irc>
<@dirbaio:matrix.org> I don't think there's any such test for ethernet (?)
<re_irc>
<@korken89:matrix.org> Ah well then, no problem :D
<re_irc>
<@dirbaio:matrix.org> the only downsides are
<re_irc>
<@dirbaio:matrix.org> very remote chance of collision, in practice none because literally nobody uses the locally administered range
<re_irc>
<@dirbaio:matrix.org> and it's rude to network admins because they can't see what company made the device
<re_irc>
<@korken89:matrix.org> Right, thanks for the clarification!
<re_irc>
<@dirbaio:matrix.org> some SBCs do that too, orange pis for example
<re_irc>
<@jordens:matrix.org> If you share a network with android and ios phones then all of them will default to locally administered random macs.
<re_irc>
<@adamgreig:matrix.org> yea, for wifi there are privacy implications of using a fixed mac on a personal portable device
<re_irc>
<@adamgreig:matrix.org> eg on android, on wifi network details, you can set random/device MAC per-network
<re_irc>
<@dirbaio:matrix.org> they still have 46 bits of entropy, collisions should be ultra rare
<re_irc>
<@jordens:matrix.org> just pointing out that locally administered addresses are in fact very common and the chance of collision isn't zero. you expect to have one collision in a set of couple million.
<re_irc>
<@dirbaio:matrix.org> 🤔 how do android/ios deal with these collisions then?
<re_irc>
<@jordens:matrix.org> No idea. Guessing that they either pray or do probing similar to stateless autoconf for ip6
ni has quit [Quit: WeeChat 2.8]
ni has joined #rust-embedded
fabic has joined #rust-embedded
<re_irc>
<@willeml:matrix.org> How would I go about making the linker put a whole module (say, everything in crate::external, into another section of flash) and also, how would I do the same with a whole library?
<re_irc>
<@willeml:matrix.org> (trying to bring back a project I put on hold a couple months ago because I could not figure this out
<re_irc>
<@willeml:matrix.org> )
<re_irc>
<@ruabmbua:matrix.org> I ended up with two binaries, and copying one of them with include_bytes into the other.
<re_irc>
<@ruabmbua:matrix.org> Good question. I was also not able to solve that particular problem.
<re_irc>
<@ruabmbua:matrix.org> + Some linker script magic and awful code
<re_irc>
<@willeml:matrix.org> ah, do you have a link to code that I could look at? (linker script magic)
<re_irc>
<@ruabmbua:matrix.org> Unfortunately no, but I can summarize:
<re_irc>
<@ruabmbua:matrix.org> include_bytes into a static array with #[link_section].
<re_irc>
<@ruabmbua:matrix.org> And then use that section in the linker script, to put it where you want.
<re_irc>
<@ruabmbua:matrix.org> I don't know a good guide for linker scripts, I learned by example
<re_irc>
<@ruabmbua:matrix.org> I was able to call into that code then, by declaring a struct of function pointers, and assigning the correct address, with the help of the linker script.
<re_irc>
<@ruabmbua:matrix.org> The blob in the static array contained a trampoline at t beginning, which forwarded to the correct address inside.
<re_irc>
<@ruabmbua:matrix.org> Of course everything extern C. Maybe that was unnecessary.
<re_irc>
<@adamgreig:matrix.org> that's a pretty neat way of ensuring the code doesn't call into functions that end up in flash or anything
<re_irc>
<@adamgreig:matrix.org> i mean, a bit horrid, maybe you could use build.rs or something to really tidy it up, but as a concept it's pretty neat..
<re_irc>
<@ruabmbua:matrix.org> Yep
<re_irc>
<@ruabmbua:matrix.org> In my case it was a bootloader, which had functions that were callable (size optimization)
<re_irc>
<@ruabmbua:matrix.org> I used a Makefile, had to call strip objcopy etc...
<re_irc>
<@ruabmbua:matrix.org> To be honest, the array was probably unnecessary in the end. Could have concated the binaries together.
<re_irc>
<@adamgreig:matrix.org> how did you deal with position-independent code/relocations? did the blob just get compiled for a fixed known start address and that's the section you put the static array into?
<re_irc>
<@almindor:matrix.org> I started on something similar by stripping riscv-rt into "module-rt" that does nothing but basic entrypoint stuff. Idea is pretty much same to what ruabmbua is doing AFAICS. Load the binary to a predefined location and jump to it. TockOS does things exactly this way in an established way tho, sadly they don't use embedded-hal for drivers
<re_irc>
<@ruabmbua:matrix.org> I tried with relocatable code in my os kernel, but that failed in the end with rust bugs (core::fmt) generated completely wrong code for some reason
<re_irc>
<@adamgreig:matrix.org> yea, llvm support for PIC on armv7 is incomplete and a bunch of things just don't work
<re_irc>
<@dirbaio:matrix.org> ARM has both the "normal" PIC and the "freestanding" ROPI/RWPI PIC
<re_irc>
<@dirbaio:matrix.org> "normal" pic should work, but only with a dynamic loader to do the relocation fixups and stuff
<re_irc>
<@dirbaio:matrix.org> while ROPI/RWPI shouldn't need it but is incomplete
<re_irc>
<@dirbaio:matrix.org> does riscv have an equivalent of that?
<re_irc>
<@dirbaio:matrix.org> I think it just has "normal" pic (?)
<re_irc>
<@adamgreig:matrix.org> the r-v link ^ is about designing a spec like ropi/rwpi for risc-v
<re_irc>
<@adamgreig:matrix.org> ropi/rwpi being an llvm/keil invention for arm specifically
<re_irc>
<@adamgreig:matrix.org> (and in current llvm doesn't support c++ because it doesn't support vtables, but in armclang it does due to extra patches not merged upstream)
<re_irc>
<@ruabmbua:matrix.org> I did eventually do manual relocation ^^
<re_irc>
<@adamgreig:matrix.org> it's not been updated since early 2020 though
<re_irc>
<@ruabmbua:matrix.org> adamgreig: No custom format, just elf
<re_irc>
<@adamgreig:matrix.org> an elf loader in your firmware?
<re_irc>
<@adamgreig:matrix.org> or a desktop tool to relocate to a new .bin?
<re_irc>
<@almindor:matrix.org> I was thinking about doing the same with elf, but it seemed cheaper to do elf -> bin + some metadata (e.g. data start, bss size) and load from that
<re_irc>
<@ruabmbua:matrix.org> Yes, that would maybe be a better idea.
<re_irc>
<@ruabmbua:matrix.org> I want to reduce the amount of assembly used to 0
<re_irc>
<@ruabmbua:matrix.org> If anyone has a good idea tell me 😅
<re_irc>
<@almindor:matrix.org> i was aiming for just something that hopefully objcopy + awk or such could do :D
<re_irc>
<@almindor:matrix.org> objcopy -> bin and objdump -> awk the metadata and store that as some bin header
<re_irc>
<@almindor:matrix.org> thing is tho, the e310 core has such small RAM I didn't try to go any further
<re_irc>
<@dirbaio:matrix.org> what are your use cases? dynamically flashable modules, a/b partition firmware updates?
<re_irc>
<@almindor:matrix.org> gameboy mini :D
<re_irc>
<@almindor:matrix.org> i wanted to build something like play.date with pluggable usb module setups
<re_irc>
<@ruabmbua:matrix.org> But you still need to patch a the address references in the binary, so a table of all of them is still required, unless you use something like ROPI/RWPI
<re_irc>
<@almindor:matrix.org> yeah I never got anywhere near usable, then found out about TockOS and then decided its notwhere near feasible with 16k total RAM
<re_irc>
<@ruabmbua:matrix.org> adamgreig: Just a small part of a kernel, that is completely PIC, and relocates the rest to match the physical address.
<re_irc>
<@ruabmbua:matrix.org> Is partially obsolete, because I finally started with MMU based memory management, but that is far from done
<re_irc>
<@adamgreig:matrix.org> cool!
<re_irc>
<@dirbaio:matrix.org> fancy
<re_irc>
<@dirbaio:matrix.org> I just want it for a/b partition firmware updates... so if I send a device a bad update it doesn't get bricked
<re_irc>
<@dirbaio:matrix.org> the addresses of the two partitions are known though, so I could do the ultra-low-tech solution of just building the firmware twice lol
<re_irc>
<@almindor:matrix.org> you can re-flash the flash from runtime no?
<re_irc>
<@adamgreig:matrix.org> can you remap two flash banks?
<re_irc>
<@dirbaio:matrix.org> nope, no flash mapping in nrf52 :(
<re_irc>
<@adamgreig:matrix.org> ah shame
<re_irc>
<@adamgreig:matrix.org> on the dual-bank stm32 you can just rotate the banks
<re_irc>
<@dirbaio:matrix.org> almindor: yeah, but the issue is devices are completely unattended
<re_irc>
<@dirbaio:matrix.org> so a solution like "when bricked, power up holding the BOOT button and then flash a new firmware with your phone via BLE" is not good
<re_irc>
<@ryan-summers:matrix.org> Are you still at hardware design phase? One approach I often take is "staging" the new firmware in an external EEPROM
<re_irc>
<@ryan-summers:matrix.org> Then validating it before doing the copy to flash
<re_irc>
<@ryan-summers:matrix.org> (Jumping in totally in the middle here, so I'm very lacking in context if this makes no sense)
<re_irc>
<@dirbaio:matrix.org> I have enough internal flash for two copies and I do crc stuff before applying the update
<re_irc>
<@dirbaio:matrix.org> so it's safe from corruption
<re_irc>
<@ryan-summers:matrix.org> Ah gotcha, that works equally well
<re_irc>
<@dirbaio:matrix.org> the thing I'm scared of is a firmware update having a bug where the device can no longer connect to the server
<re_irc>
<@dirbaio:matrix.org> or crashes on startup or whatever
<re_irc>
<@dirbaio:matrix.org> like a smoltcp DHCP bug, lol
<re_irc>
<@ryan-summers:matrix.org> So your bootloader doesn't have the capability of communicating with the server? The app itself gets the new app and stages it, then has the bootloader do the copy?
<re_irc>
<@ryan-summers:matrix.org> Or do you not even have a formal bootloader?
<re_irc>
<@dirbaio:matrix.org> the app gets the new firmware, yes. The bootloader is dumb, it just crc's and copies
<re_irc>
<@dirbaio:matrix.org> pasting a whole copy of the entire protocol inside the bootloader was too big...
<re_irc>
<@ryan-summers:matrix.org> Gotcha. So the bootloader doesn't actually handle image acquisition
<re_irc>
<@dirbaio:matrix.org> it can run over a custom BLE mesh or over ethernet or over mobile (AT/PPP), has crypto and stuff...
<re_irc>
<@dirbaio:matrix.org> so it's too big :C
<re_irc>
<@dirbaio:matrix.org> so ideally
<re_irc>
<@ryan-summers:matrix.org> Yeah, trust me I understand
<re_irc>
<@adamgreig:matrix.org> how does it work out if the A firmware is bad and it should retry the B firmware?
<re_irc>
<@adamgreig:matrix.org> as in, passes the CRC but has a latent bug
<re_irc>
<@ryan-summers:matrix.org> Ultimately, firmware can only do self detection of its own bugs imo, e.g. via watchdogs, self tests, etc.
<re_irc>
<@ryan-summers:matrix.org> And it could theoretically tell the bootloader" I'm having issues, give the other guy a shot"
<re_irc>
<@ryan-summers:matrix.org> ?
<re_irc>
<@adamgreig:matrix.org> yea
<re_irc>
<@ryan-summers:matrix.org> If the firmware is a dud, I don't think you can do much
<re_irc>
<@ryan-summers:matrix.org> Maybe on first execution, have it explicitly say "Yes, I'm working"
<re_irc>
<@adamgreig:matrix.org> I guess bootloader can at least start a watchdog that the main firmware only clears if it's happy or something
<re_irc>
<@ryan-summers:matrix.org> And if the BL comes back around and that wasn't indicated, fall back
<re_irc>
<@adamgreig:matrix.org> yea, or even just bootloader sets a flag in ram
<re_irc>
<@adamgreig:matrix.org> but eh, that won't help if the firmware gets stuck
<re_irc>
<@ryan-summers:matrix.org> Ideally a flag via some NVM
<re_irc>
<@dirbaio:matrix.org> it'd work something like this
<re_irc>
<@dirbaio:matrix.org> - bootloader sets up some watchdog "if not connected to the server in 10min, reboot"
<re_irc>
<@dirbaio:matrix.org> - app on slot 1 downloads new firmware on slot 2
<re_irc>
<@dirbaio:matrix.org> - app tells bootloader to boot slot 2 in "trial mode"
<re_irc>
<@almindor:matrix.org> right now it's very messy for the drivers wrt. working with CS pin in manual vs auto mode and "HW" vs "SW" control of it + framing
<re_irc>
<@dirbaio:matrix.org> that was the motivation for the `ManagedCS` marker trait thing
<re_irc>
<@almindor:matrix.org> so the issue imo is a bit bigger than that
<re_irc>
<@almindor:matrix.org> there are I think 4 configurations that the drivers need to cope with somehow:
<re_irc>
<@almindor:matrix.org> 1. managedCS with Transactional support (proper CS framing)
<re_irc>
<@almindor:matrix.org> 2. unmanagedCS with Transactional support
<re_irc>
<@almindor:matrix.org> 3. managedCS without Transactional support
<re_irc>
<@almindor:matrix.org> 4. unmanagedCS without Transactional support
<re_irc>
<@almindor:matrix.org> it's a big mess, because if a driver needs transactional (framing) it needs to handle possibly all 4 cases someho
<re_irc>
<@dirbaio:matrix.org> I think the idea was that
<re_irc>
<@dirbaio:matrix.org> if you're writing a driver for a device that requires a CS pin, you require `T: Transactional+ManagedCS`
<re_irc>
<@almindor:matrix.org> yeah but that leaves out a lot of HALs right now :(
<re_irc>
<@dirbaio:matrix.org> you don't accept Unmanaged CS at all
<re_irc>
<@almindor:matrix.org> and only because of the abstraction, you can still make it work with non-transactional non-managed CS too
<re_irc>
<@dirbaio:matrix.org> instead, the user must wrap their unmanaged SPI with something like `SpiWithCs` from that PR
<re_irc>
<@dirbaio:matrix.org> it takes a `Transactional` and an `OutputPin` and gives you a `Transactional+ManagedCS`
<re_irc>
<@almindor:matrix.org> is there any actual MCU that has a reason to not have `Transactional` ?
<re_irc>
<@dirbaio:matrix.org> or the HAL can provide a Transactionsl+ManagedCS if there's a more efficient way of implementing it via hardware-managed CS or whatever
<re_irc>
<@dirbaio:matrix.org> but the point is as a driver writer you don't care
<re_irc>
<@dirbaio:matrix.org> you just require `T: Transactional+ManagedCS`
<re_irc>
<@dirbaio:matrix.org> so you have the guarantee *something* is driving CS for you
<re_irc>
<@dirbaio:matrix.org> almindor: you can always impl `Transactional` out of `Write + Transfer`, so it should be available everywher
<re_irc>
<@dirbaio:matrix.org> ee
<re_irc>
<@almindor:matrix.org> yeah the reality is I had to construct this wrapper myself (even if this trait existed) because a lot of xxx-hals don't have Transactional at all
<re_irc>
<@almindor:matrix.org> e.g. gv32xx
<re_irc>
<@dirbaio:matrix.org> you can always impl it with software
<re_irc>
<@dirbaio:matrix.org> but some mcus can "chain DMAs" or whatever so you can do all the operations back-to-back without pauses which is neat
<re_irc>
<@almindor:matrix.org> yes, what I'm saying is we shouldn't have spi::Write and spi::Transfer as mains anymore and IMO should in post 1.0 world force a single Transactional as minimum
<re_irc>
<@dirbaio:matrix.org> hm
<re_irc>
<@dirbaio:matrix.org> not sure
<re_irc>
<@dirbaio:matrix.org> maybe a driver wants just `Transfer + ManagedCS` because all the transfers it does are just a single buffer
<re_irc>
<@dirbaio:matrix.org> `Transactional` is quite overcomplicated
<re_irc>
<@dirbaio:matrix.org> but the optimization opportunities from it are nice, and it fits nicely with ManagedCs
<re_irc>
<@dirbaio:matrix.org> dunno
<re_irc>
<@almindor:matrix.org> ok then Transactional wrapper that does all 3 in one trait
<re_irc>
<@almindor:matrix.org> the driver can use singletons but the hals should be forced to have exec
<re_irc>
<@dirbaio:matrix.org> IMO hals should just implement it
<re_irc>
<@almindor:matrix.org> yeah but they don't :)
<re_irc>
<@dirbaio:matrix.org> 💩
<re_irc>
<@dirbaio:matrix.org> currently stuff is a bit stuck
<re_irc>
<@dirbaio:matrix.org> because no HALs implement it, then driver authors work around the lack of it, which means no driver requires it, which means there's no demand for it in HALs
<re_irc>
<@dirbaio:matrix.org> chicken-and-egg 🤣
<re_irc>
<@almindor:matrix.org> example case: https://github.com/riscv-rust/gd32vf103xx-hal/blob/master/src/spi.rs and the fix is easy and I'll probably do it but the issue is turnaround time for these can be pretty bug, easier to write a driver hack (also I burned my longan nano 😥)
<re_irc>
<@almindor:matrix.org> in general I think we should consider adopting a "hal traits should be singletons" strategy as much as possible so that we don't fracture out own backends
<re_irc>
<@dirbaio:matrix.org> by "singleton" you mean "a single trait with all the methods"?
<re_irc>
<@dirbaio:matrix.org> to force HALs to implement all?
<re_irc>
<@almindor:matrix.org> yes
<re_irc>
<@dirbaio:matrix.org> yeah...
<re_irc>
<@almindor:matrix.org> they can be compound of course but we should present a forced view for hal implementors
<re_irc>
<@dirbaio:matrix.org> the reason they're split is HALs may want a "read-only SPI" or a "write-only SPI"
<re_irc>
<@dirbaio:matrix.org> like, if you create an SPI with a MOSI pin but not MISO pin, the HAL could impl Write but not Read
<re_irc>
<@almindor:matrix.org> that's ok but then make it a special case not the default. In this case it's "we have write and transfer but then there's also this new transactional kid on the block" and so any hals from older times won't have it
<re_irc>
<@dirbaio:matrix.org> yeah..
<re_irc>
<@dirbaio:matrix.org> damn.. :D
<re_irc>
<@almindor:matrix.org> also IMO the SPIs should be implemented as Bus + Drivers instead of a single block SPI bus so they can be properly shared (and traited)
<re_irc>
<@dirbaio:matrix.org> what if it was like this
<re_irc>
<@almindor:matrix.org> that's an implementation detail tho
<re_irc>
<@dirbaio:matrix.org> wrt DMA it should be as good as the current traits
<re_irc>
<@dirbaio:matrix.org> lol there's WriteIter too, what about that
<re_irc>
<@almindor:matrix.org> WriteIter is imo a "nice to have" :D
<re_irc>
<@almindor:matrix.org> but maybe one day someone would come and claim my own point against me hehe
<re_irc>
<@dirbaio:matrix.org> it's impossible to impl with DMA though
<re_irc>
<@dirbaio:matrix.org> not sure if it should be part of the monolithic ReadWrite triat
<re_irc>
<@dirbaio:matrix.org> but again, if it's not then HALs don't implement it, then it's not useful for drivers
<re_irc>
<@almindor:matrix.org> well.. couldn't the default implementation just for loop it?
<re_irc>
<@dirbaio:matrix.org> hmm maybe yeah
<re_irc>
<@dirbaio:matrix.org> it's sloooooooow though on DMA impls because you esentially have to do N times 1-byte DMA transfers which are slow to start/stop
<re_irc>
<@dirbaio:matrix.org> in nrf's you *must* use DMA, there's no "DR" like in stm32s where you can write bytes
<re_irc>
<@almindor:matrix.org> yeah it's a pickle, that's why I think making that one optional would work
<re_irc>
<@almindor:matrix.org> it's such a PITA that Rust doesn't have !Trait support
<re_irc>
<@dirbaio:matrix.org> to auto-impl it only when the HAL doesn't already impl it?
<re_irc>
<@almindor:matrix.org> if there was a ! I could do both sides of the thing with no need for manual wrapper typing by the users
<re_irc>
<@dirbaio:matrix.org> yea... that'd be the same as a default trait method though, right?
<re_irc>
<@almindor:matrix.org> yes in this case, you mean for the "non transactional" side
<re_irc>
<@dirbaio:matrix.org> yeah
<re_irc>
<@dirbaio:matrix.org> the bare minimum HALs would have to impl is: read, write, transfer, transfer_implace
<re_irc>
<@dirbaio:matrix.org> but if they have more efficient ways of impling batching (such as chaining DMAs) then they can override the default impl of the batch methods
<re_irc>
<@almindor:matrix.org> and writeiter as an optional extra?
<re_irc>
<@dirbaio:matrix.org> having it extra makes it useless in practice because HALs wont impl it
<re_irc>
<@dirbaio:matrix.org> so I guess make it another default trait method
<re_irc>
<@dirbaio:matrix.org> or remove it, idk
<re_irc>
<@almindor:matrix.org> hmm how about making it default with a "optimized" marker
<re_irc>
<@almindor:matrix.org> so that you can check if using iter would be considered a happy path
<re_irc>
<@dirbaio:matrix.org> hmm but drivers won't bound on the "optimized" marker, as they want their driver to work everyhere even if slow
<re_irc>
<@almindor:matrix.org> true
<re_irc>
<@almindor:matrix.org> runtime check? :D
<re_irc>
<@dirbaio:matrix.org> and panic if it's slow? same issue :D
<re_irc>
<@almindor:matrix.org> that was a joke, to make things completely clear
<re_irc>
<@dirbaio:matrix.org> ah okay 🤣
<re_irc>
<@almindor:matrix.org> usefulness of iter is mainly for memory reasons I guess
<re_irc>
<@swedishhat:matrix.org> Hey folks, I'm an electronics engineer with a bit of embedded C experience to support a firmware engineer. I'm really interested in embedded Rust, and I'm making my way through https://docs.rust-embedded.org/book/ as well as the main language book. In y'all's opinion, is the embedded Rust job market still pretty sparse for relatively inexperienced people like me to make a career change?
<re_irc>
<@swedishhat:matrix.org> Any pointers on how I can level up enough to give myself a better shot at making that jump?
<re_irc>
<@korken89:matrix.org> swedishhat:matrix.org: When we hire Rust engineers they have 9 Rust experience (generally C embedded devs) and we help them for 1-2 months to learn Rust :)
<re_irc>
<@korken89:matrix.org> I think many more have the same approach as finding Rust embedded devs is asking a lot
<re_irc>
<@korken89:matrix.org> Plus I see you're maybe Swedish
<re_irc>
<@korken89:matrix.org> Come to Luleå ett have 3 companies in the same building hunting Rust embedded devs :)
<re_irc>
<@swedishhat:matrix.org> I'm not in any way swedish, unfortunately 😛
<re_irc>
<@korken89:matrix.org> Aww, well it's never too late to become one ;)
<re_irc>
<@korken89:matrix.org> But anyways, don't be afraid to hunt Rust jobs
<re_irc>
<@swedishhat:matrix.org> korken89:matrix.org: Well, if it gives me a better shot at becoming and embedded Rust dev...
<re_irc>
<@korken89:matrix.org> We have successfully converted 3 C devs :)
<re_irc>
<@korken89:matrix.org> As long as there is a person that can mentor we have seen the people get into Rust fast
<re_irc>
<@korken89:matrix.org> But if you have questions feel free to ping
<re_irc>
<@adamgreig:matrix.org> honestly faster than new embedded engineers with C I think
<re_irc>
<@adamgreig:matrix.org> or maybe slower but better?
<re_irc>
<@adamgreig:matrix.org> faster and better :P
<re_irc>
<@korken89:matrix.org> Yeah
<re_irc>
<@korken89:matrix.org> The speed at which we have been able to build our system is awesome
<re_irc>
<@korken89:matrix.org> Hack without fear
<re_irc>
<@korken89:matrix.org> That is the amazing thing
<re_irc>
<@korken89:matrix.org> And when crap really breaks I get to step in :D
<re_irc>
<@josfemova:matrix.org> korken89:matrix.org: Suddenly wanting to become swedish rn
<re_irc>
<@korken89:matrix.org> Now I'm mostly a backend person ;P
<re_irc>
<@dirbaio:matrix.org> Rust is awesome
<re_irc>
<@korken89:matrix.org> josfemova:matrix.org: Do it! In our company we are 15% foreign
<re_irc>
<@dirbaio:matrix.org> before rust, with C, almost all my bugs were memory management/corruption bugs
<re_irc>
<@korken89:matrix.org> korken89:matrix.org: The consultancy next to us are like 20 rust embedded people now
<re_irc>
<@dirbaio:matrix.org> with Rust these are poof, gone. Bugs are now usually logic bugs, and rust helps a lot with even these with the decent type system
<re_irc>
<@korken89:matrix.org> They are beginning the university :P
<re_irc>
<@korken89:matrix.org> I'm mostly amazed Scott the boundaries that don't exist anymore
<re_irc>
<@korken89:matrix.org> We move data over 4 different CPU architectures with s single library in the end
<re_irc>
<@korken89:matrix.org> From embedded to backend
<re_irc>
<@korken89:matrix.org> And it's not even hard :D
fabic has quit [Ping timeout: 252 seconds]
<re_irc>
<@korken89:matrix.org> (thank you serde)
<re_irc>
<@lachlansneff:matrix.org> Yeah, I’m trying to teach some other students embedded software for rocketry stuff and I think it’d be a lost cause without rust
<re_irc>
<@lachlansneff:matrix.org> (Lost cause in the time we have, there’s so much context one needs to know to even use C in this kind is system)
tokomak has quit [Ping timeout: 265 seconds]
<re_irc>
<@therealprof:matrix.org> Re: MAC adresses. I'm sure there are regulations which require that a vendor guarantees that the burned-in MAC address of any shipped networking interface is worldwide unique. Newer Apple and Android devices are using randomly generated locally administered MAC addresses only for network scanning to not disclose their real identity and allow worldwide tracing of devices. For communication they're using...
<re_irc>
... their built-in MAC addresses. Whenever you're using locally administered addresses you're supposed to do duplicate address detection (DAD) and if you detect a conflict you have to either chose a different address or stop communicating.
<re_irc>
<@adamgreig:matrix.org> in both cases enabled by default
<re_irc>
<@adamgreig:matrix.org> though I couldn't find the part of AOSP that actually generates the random MAC, so I'm not sure if it's deterministic given the real MAC and the SSID (for example) or totally random but persisted in memory
<re_irc>
<@adamgreig:matrix.org> either way, it's unpredictable and has the LA bit set
<re_irc>
<@adamgreig:matrix.org> I think they also use the google OUI in android?
<re_irc>
<@therealprof:matrix.org> Hm, I just checked and Apple devices are definitely not the Apple OUI.
<re_irc>
<@therealprof:matrix.org> adamgreig: I'm convinced IEEE doesn't hand out OUIs where the LA bit is set.
<re_irc>
<@adamgreig:matrix.org> oh, sorry, I didn't mean to imply that at all
<re_irc>
<@adamgreig:matrix.org> they surely do not
<re_irc>
<@adamgreig:matrix.org> but one could still set the LA bit and otherwise use their own OUI while generating a random LA address, right?
<re_irc>
<@therealprof:matrix.org> adamgreig: But how could they use the Google OUI then? 😉
<re_irc>
<@monacoprinsen:matrix.org> Is there a way to get a 3V output from one pin to toggle on the stm32f4?
<re_irc>
<@monacoprinsen:matrix.org> Now i only measure 0.6 when i set a pin high
<re_irc>
<@therealprof:matrix.org> Apple doesn't seem to do that.
<re_irc>
<@adamgreig:matrix.org> monacoprinsen:matrix.org: do you see any toggling, or do you just measure constant 0.6?
<re_irc>
<@monacoprinsen:matrix.org> Toggling, but I set it to high to measure
<re_irc>
<@adamgreig:matrix.org> could the pin have been configured in "open drain" mode in your firmware, instead of "push pull"?
<re_irc>
<@monacoprinsen:matrix.org> It's enough for a LED but not for what I need
<re_irc>
<@adamgreig:matrix.org> and, is the pin connected to anything else when you measure it?
<re_irc>
<@theunkn0wn1:matrix.org> firefrommoonlight:matrix.org: If you're still open to feedback, I would prefer to see the HAL-utilizing section appear before the raw register manipulations / PAC level code.
<re_irc>
<@theunkn0wn1:matrix.org> As a user who doesn't know rust and its ecosystem, and potentially not a whole lot more than Arduino, seeing the register manipulations may scare them off without reading further. IMHO its more important to present how to use Rust in embedded before explaining how it works
<re_irc>
<@monacoprinsen:matrix.org> It is connected to something else, I measure directly on the pins, it is set to pusher pull
<re_irc>
<@monacoprinsen:matrix.org> Into push pull output
<re_irc>
<@adamgreig:matrix.org> what is it connected to? the stm32 itself can only drive to its supply voltage (3.3V probably), there's no setting to drive to 0.6, so either it's not actually driving it to 3.3 at all (which would be the case in 'open drain') or something else in the circuit is pulling the voltage down
<re_irc>
<@adamgreig:matrix.org> you could try toggling a different pin that's not connected to anything, and see if that reads 3.3V
<re_irc>
<@monacoprinsen:matrix.org> It's connected to a vibration motor
<re_irc>
<@monacoprinsen:matrix.org> I also use ADC on a another pin
<re_irc>
<@monacoprinsen:matrix.org> When I disconnect everything I get 3.3V
<re_irc>
<@adamgreig:matrix.org> do you have a part number or anything for the motor?
<re_irc>
<@monacoprinsen:matrix.org> Just salvaged it from a phone
<re_irc>
<@adamgreig:matrix.org> maybe it needs more current than the stm32 can deliver, so it pulls the voltage down
<re_irc>
<@monacoprinsen:matrix.org> Oh ok
<re_irc>
<@adamgreig:matrix.org> usually for driving a motor you would need some kind of external switch, like a MOSFET or similar, and the stm32 turns that on, and the switch connects power to the motor
<re_irc>
<@monacoprinsen:matrix.org> Thanks, will try that!
<re_irc>
<@monacoprinsen:matrix.org> Directly from the 3.3V pin it works but then I can't toggle
<re_irc>
<@monacoprinsen:matrix.org> Will get a mosfet then
<re_irc>
<@monacoprinsen:matrix.org> Thanks a lot!
<re_irc>
<@adamgreig:matrix.org> (using an arduino, but you'd only need to look at the circuit)
<re_irc>
<@monacoprinsen:matrix.org> I have transistors, will try
<re_irc>
<@monacoprinsen:matrix.org> Thank you!
<re_irc>
<@adamgreig:matrix.org> np!
<cr1901>
This is hypothetical: Is it possible in Rust currently to make a library crate such that if you import it into an application, you MUST use a specific function, or your application will fail to compile or link?
<cr1901>
Hypothetical use case: library crate that comes w/ an interrupt handler function that you must put into an interrupt handler
<re_irc>
<@sympatron:matrix.org> Should be doable with macros
<re_irc>
<@monacoprinsen:matrix.org> adamgreig: Got it to work!
<re_irc>
<@sympatron:matrix.org> Embassy does something similar
<re_irc>
<@sympatron:matrix.org> You would have to declare and use some global symbol in the library that the application has to define, which can be done with a macro.
<cr1901>
embassy was a potential use case too, happy to look at what they do for inspiration
<re_irc>
<@mehmet:grusbv.com> Hi, I see that HALs have pins individually typed, like `GPIO::P0::P0_13`
<re_irc>
<@mehmet:grusbv.com> How can I write pin independent functions:
<re_irc>
<@dirbaio:matrix.org> Mehmet Ali: nrf-hal has .degrade() that gives you instances of `Pin`
<re_irc>
<@almindor:matrix.org> mehmet:grusbv.com: You use the embedded-hal trait `OutputPin` for example (or Input)
<re_irc>
<@almindor:matrix.org> mehmet:grusbv.com: So e.g. `impl<PIN> ... where PIN: OutputPin` and then you can do `pin.set_high()` etc.
<re_irc>
<@dirbaio:matrix.org> quick overview of how embassy does it:
<re_irc>
<@dirbaio:matrix.org> 1. registers the interrupt handler to some embassy-internal handler function
<re_irc>
<@dirbaio:matrix.org> 2. checks whether it has been run before with a static bool, panics if it has (similar to `pac::peripherals::take()`)
<re_irc>
<@dirbaio:matrix.org> it has a macro `interrupt::take!(USART1)` which:
<re_irc>
<@mehmet:grusbv.com> dirbaio:matrix.org: Does that degrade the pin from, being singleton?
<re_irc>
<@firefrommoonlight:matrix.org> theunkn0wn1:matrix.org: That's a great point I didn't consider. I'm going to think about this, then make the change if it seems like it's worth the swap. Will add some clarification either way, or a note to skip that section as required. I don't think the direct memory manipulation is a good API for application code, but I wanted to open with that before pulling in dependencies
<re_irc>
<@firefrommoonlight:matrix.org> (I think PAC use can be suitable for application-level code in some cases, but not others. For example, I'd be happy writing an entire nRF-52 program using just PAC, but would never do that for STM32)
<re_irc>
<@dirbaio:matrix.org> mehmet:grusbv.com: `Pin` instances are still singletons, you can't clone them either. You can't get two `Pin` instances for the same pin. It just makes them into the same type, so you can put them in arrays, or write functions that take any pin, etc
<re_irc>
<@firefrommoonlight:matrix.org> I guess my thought process was: "Here's where the magic happens - these `read_volatile` and `write_volatile` commands. This is where you go from abstract computer logic to making things happen! This took me a surprisingly long amount of time to GROK, and I acccepted it as magic. The PAC and HALs are still doing these commands, but with a nicer API
<re_irc>
<@adamgreig:matrix.org> yea, I quite like your current sequence of the most basic thing first and then the abstractions
<re_irc>
<@adamgreig:matrix.org> but a well-highlighted note to skip to the abstractions might be good... i'm probably not the target audience
<re_irc>
<@adamgreig:matrix.org> (also I love just writing the whole application using only the pac on stm32, so I'm definitely an outlier :P)
<re_irc>
<@theunkn0wn1:matrix.org> firefrommoonlight:matrix.org: My comment is from the perspective of a relative newbie; and the fustrations I had with how the embeded-rust book was written at the time (may still be? haven't checked in on that recently).
<re_irc>
<@theunkn0wn1:matrix.org> As a beginner, i don't want to know what the magic is, i want to know what the "best" / "easiest" way is. Once i have a solid launching point (Writing against a HAL), I have somewhere to rest at so i don't drown deep down the rabbit hole
<re_irc>
<@theunkn0wn1:matrix.org> Its very easy to get lost in PAC and below if you don't already know how it all works.
<re_irc>
<@firefrommoonlight:matrix.org> I added a scary bold warning note to skip ahead before going into the direct register edit code
<re_irc>
<@josfemova:matrix.org> The "embedded rust learning experience" would perhaps be better served by some noob-friendly stuff in a place like instructables too
<cr1901>
dirbaio: using a singleton at runtime wasn't exactly what I had in mind, but even for the smallest targets RAM isn't the limiting factor, so that'll do
<re_irc>
<@theunkn0wn1:matrix.org> That is likely enough (waiting on deployment), giving the reader the indication things get better later on is good enough :)
<re_irc>
<@josfemova:matrix.org> Would also help if hal's had like a showcase" section or something for guidance
<re_irc>
<@theunkn0wn1:matrix.org> What i found the most useful when i started out was existing codebases honestly
<re_irc>
<@firefrommoonlight:matrix.org> I appreciate the feedback
<re_irc>
<@theunkn0wn1:matrix.org> i found so little value in the books
<re_irc>
<@theunkn0wn1:matrix.org> (sorry if this is coming off bluntly)
<re_irc>
<@dirbaio:matrix.org> irc_libera_cr1901:psion.agg.io: yeah unfortunately it's not fully zero-cost. I'm not 100% happy with it either, will probably try alternatives in the future
<cr1901>
dirbaio: Are the interrupt owned singletons !Send as well as !Sync?
<re_irc>
<@dirbaio:matrix.org> They're Send+Sync, but not Copy/Clone
<cr1901>
Oh, that works too lol
<re_irc>
<@josfemova:matrix.org> I found the book good for initial reference, but examples + embedded hal docs were like the ones that carried me the most
<re_irc>
<@firefrommoonlight:matrix.org> I think part of the reason for the confusion is this article doesn't have great scope control; ie it tries to provide info to people with varying levels of experience in embedded and Rust. Ie, I think the current order makes more sense for someone used to embedded, but not Rust, since they can map the code to the most general way of looking at it
<re_irc>
<@theunkn0wn1:matrix.org> firefrommoonlight:matrix.org: yeah, your current article reads as if its target audience is seasoned embedded-C programmers
<re_irc>
<@firefrommoonlight:matrix.org> It also demystifies what PAC and HAL are doing. (Going to make another edit clarifying this, that PAC/HAL are really just wrapping these writes
<re_irc>
<@theunkn0wn1:matrix.org> But its ALMOST scoped right for newbies too
<re_irc>
<@firefrommoonlight:matrix.org> And HAL may just wrap the PAC
<cr1901>
dirbaio: I was recently mulling over how to create a "very smol fixed hashmap", and "make it use a 'static buffer, but don't make it Copy/Clone" was one method I considered
<re_irc>
<@theunkn0wn1:matrix.org> firefrommoonlight:matrix.org: its wrapping the PAC and implementing device-specific sequences
<cr1901>
It seems like an effective strategy for "free Send/Sync" lmao
<cr1901>
(I wanted to create multiple impls and have them "duke it out" in benchmarks to see memory usage and speed on a slow micro or simulation. But of course that takes work)
<re_irc>
<@josfemova:matrix.org> josfemova:matrix.org: Would help if it provided sections for different boards other than the f3 tho. F4's and F1's are the easier to get boards. F4's specially because even if you lack the st link, you can still load binaries via dfu
<re_irc>
<@theunkn0wn1:matrix.org> I believe there was a lot of discussion in the embedded book's gh about the availability of various MCUs.
hifi has quit [Ping timeout: 252 seconds]
hifi has joined #rust-embedded
<re_irc>
<@almindor:matrix.org> how do you guys "provide" a println! to drivers when needing to debug internal stuff?
<re_irc>
<@dirbaio:matrix.org> so from inside the crate you can do `info!("test {}", 42);`, and the user can choose whether that goes to `log`, `defmt`, or nowhere