vrakaslabs[m] has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has joined #rust-embedded
<firefrommoonligh>
Hay guys! I think from the datasheet the MCU I'm using for a project has "FPU" vice "double-precision FPU" (The G4 datasheets imply single; H7 double). If I use f64 on a single-precision-FPU MCU, it will use a software float right; and if you use it on a "double-precision FPU" MCU, it will use the hardware?
<dirbaio[m]>
I don't think a double-precision cortex-m FPU exists
<dirbaio[m]>
(?)
<dirbaio[m]>
ah it indeed exists. TIL
<dirbaio[m]>
so yes, wtih single-precision fpu, f32 will use hardware and f64 will use software
<dirbaio[m]>
with double-precision fpu both will use hardware
<dirbaio[m]>
how do you tell rustc you have a double-precision fpu? I think -eabihf targets are single-precision only
<JamesMunns[m]>
I think the right answer is "make a new target json"
<JamesMunns[m]>
you need to set some LLVM attrs to make it do it, I think ryan-summers or Robert Jördens have done it, maybe adamgreig too
<ryan-summers[m]>
I think it's the targetget-cpu=cortex-m7 line
<ryan-summers[m]>
s/targetget/`target/, s//`/
<JamesMunns[m]>
I think some devices also have vfp5 (VFPv5) instead of vfp4, not sure if there is a stable way of pushing that
<JamesMunns[m]>
ah, you might need both? apparently M7 has the fpv5, so ryan's trick might get you fpv5, but you might still need the target feature to say it is 64 bit, which is optional for M7?
<firefrommoonligh>
I am loving this concept of hardware/firmware interfaces with CAN I posted about earlier. I just wrote firmware for a station-keeping/remote-repositionable sailboat/buoy. The code is mostly business logic (Plus CAN IO); the hardware is mainly an MCU + 3v3 reg + USB + CAN tranceiver/ports, because all the other stuff is delegated to hardware and firmware I already wrote. (AHRS, GNSS, power monitoring, servo control, RF control
<firefrommoonligh>
input etc)
<JamesMunns[m]>
there's no fpv4 w/ double support, so maybe +fp64 "just works" to get llvm to generate v5 instructions?
<firefrommoonligh>
It's more hardware / BOM cost /size etc than doing it all on one board/firmware, but much easier to deal with schedulign, debuging, code structure etc
<JamesMunns[m]>
firefrommoonligh: fwiw, this is how most avionics work, with the concept of "LRU", or "Line Replaceable Units", not with CAN, but using various relevant serial networks, like ARINC-429
<JamesMunns[m]>
the idea is "one system does one job, gets information/coordinates with other systems"
<firefrommoonligh>
* code structure,, * re-arranging the system to suit different purposes etc, * etc.
<firefrommoonligh>
Hah yea. I have no idea how the LRUs work, but you shut down an engine, and the maintainers replace teh faulty ones
<JamesMunns[m]>
the other challenge you didn't list is generally "tighter integration"/"compatibility concerns", but if you are writing all the firmware (and it's not some stabilized/formalized interface), it's less of a big deal
<JamesMunns[m]>
firefrommoonligh: yeah, the idea is you can even have the same system from different vendors, and it should work. So you can replace your altimeter from vendor X with vendor Y and it *should* just work,
<JamesMunns[m]>
s/*should*/_should_/, s/,/./
<JamesMunns[m]>
firefrommoonligh: yeah, basically they have racks of avionics, and use harnesses and backplanes to connect them as appropriate
<firefrommoonligh>
the flight computers, communications terminals, radios, etc I"ve seen are all that same LRU system
<JamesMunns[m]>
different vendors usually have different connectors and stuff, so you need a special backplane/harness to adapt things, but the idea is you don't have to reconfigure the rest of the system, just a different "cable adapter" basically
<firefrommoonligh>
JamesMunns[m]: True. I'm using the DroneCAN spec, so theoretically these units are replaceable with off-the-shelf ones. The devil is in the details here, as a lot of the other ones out there don't support FD, don't output the AHRS directly etc. I think the landscape here will change over the next few years; we'll see
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
yep. that's the typical rub, you're down to "lowest common denominator", and the fact that "distributed systems" can be harder to work and reason about and optimize than "tightly integrated". It's a balance tho, and modular TENDS to work better IMO in more "control systems" applications
<firefrommoonligh>
For some context, I was an F15 backseater for the past decade or so, saw a lot of that stuff, but never really looked into how it works
<JamesMunns[m]>
where you're usually just "sending/receiving pure data" vs command/control messages.
<JamesMunns[m]>
firefrommoonligh: worked in avionics for 4ish years, did a lot of the integration work/debugging. I worked primarily on TCAS/Transponder systems, which talk to a lot of other devices
<firefrommoonligh>
JamesMunns[m]: I think the point you brought up about compatibility is key here. I am running my own firmware on all these, but am hoping to lead-by-example a bit. Ideally, I'd be only writing the business-logic /main computer hardware and firmware, and using third party modules for the other things. It's been minor incompatibilities driving this
<firefrommoonligh>
JamesMunns[m]: V nice!
<JamesMunns[m]>
I talk about this at the end of the podcast I did with Ryan, about "control systems style" vs "RPC style" comms: https://jamesmunns.com/podcast/013-ryan/
<JamesMunns[m]>
(maybe about 40m in?)
<JamesMunns[m]>
but yeah, if all your devices are (basically) just shouting sensor data, or the desired state of another device, it makes a lot of things hugely less complex to work with
<JamesMunns[m]>
and ends up being a lot more like a classical control system, like pid loops or whatever.
<firefrommoonligh>
Cued up
<JamesMunns[m]>
so like instead of sending "set motor speed to X", and wait for an ACK or whatever, you just show "I want motor speed to be X" every 100ms, and look at the motor sending back "my speed is Y, my speed is Y+4, my speed is..." at whatever interval
<JamesMunns[m]>
s/show/shout/
<JamesMunns[m]>
it's still "closed loop" because you get feedback, but it's not transactional like RPC calls.
<firefrommoonligh>
The quad videos I've been posting have been from an all-in-one setup / single PCB; I'd like to move away from that. The interfaces are not well-defined
<firefrommoonligh>
JamesMunns[m]: Exactly
<firefrommoonligh>
Found the part of the clip; indeed at min 40
<firefrommoonligh>
I ended up combing the GNSS, magnetometer and AHRS computations in the same module. That involves some mixed IO and scheduling mixed with computations, but I think it makes sense because the desired interface with the rest of the systems may be just a lat+lon and attitude quaternion; this node's purpose is to fuse all the data into that output
<JamesMunns[m]>
Yeah, that's not unusual, and is just called an IMU, or GPS assisted IMU
<JamesMunns[m]>
a lot of the time you get modules that do sensor fusion with IMU+GPS data to give total position and stuff
<JamesMunns[m]>
IMU doesn't usually have GPS, but they get sensor-fusioned together so often, it's not weird to see them integrated
juliand[m] has quit [Quit: Idle timeout reached: 172800s]
<firefrommoonligh>
Yea; that makes sense. The purpose here is I'm using fusing the acceleration, baro, and GNSS posit/velocity to come up with a fused position. And using the GNSS to help separate linear from gravitational acceleration
<firefrommoonligh>
s/using//
<firefrommoonligh>
So, even though they could be treated separately, there are some nice things you can do if they work together
<JamesMunns[m]>
yup, makes sense. in fancier systems, you'll typically output all the data on separate "packets". A429 has like "packet IDs", so that fused device might send out all the separate fields (for compatibility) and then one fused output for devices that are modern enough to handle it
<JamesMunns[m]>
(a429 is a very dumb, 32-bit frame, point to point differential serial link, but basically you have an 8-bit "packet ID" where all packets with that ID have the same meaning, and then you interpret the other 24 bits of value, which will have like "altitude in feet" or "rotations per second" or something)
<firefrommoonligh>
Found the part about the LRUs in the vid
<firefrommoonligh>
Re the packets - could do it that way too
<JamesMunns[m]>
yeah, not suggesting that, CAN has much more expressiveness, just providing context of how A429 devices typically do that.
<JamesMunns[m]>
A429 is not typically bidirectional (you might have RX and TX, but they aren't strictly "coupled"), so all the devices are really just screaming into the void at nominal rate
<firefrommoonligh>
Interesting analogy re pub/sub web
<firefrommoonligh>
There's a different on-top-of-CAN protocol for small UAVs called Cyphal that goes more in that direction
corecode[m] has quit [Quit: Idle timeout reached: 172800s]
JonathanDickinso has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<datdenkikniet[m]>
What MCU do you plan on using? I think that can make a decent difference to how hard/easy it will be. If the MCU you're using already has decent support (STM32, nRFs, and some others already are) that will definitely make it a bit easier
<datdenkikniet[m]>
though I would say that, in general, it is quite doable! You get the low-levelness of C with the awesome safety of Rust :)
<datdenkikniet[m]>
s/already are//, s/bit/easier,/, s/easier/or at least a lot less work/
TimSmall[m] has quit [Quit: Idle timeout reached: 172800s]
<adamgreig[m]>
<JamesMunns[m]> "so like instead of sending "..." <- Just like this, can for the throttle servo positions and gimbal actuator positions, every 10ms or so
<adamgreig[m]>
(video is from today, finally got a little more time to play with it and got a nice on-the-ground landing)
sourcebox[m] has quit [Quit: Idle timeout reached: 172800s]
<toor[m]>
<datdenkikniet[m]> "What MCU do you plan on using? I..." <- TP4056, LM35 and arduino atm, a buzzer and display for debugging and I'll find some network chip for networking
<toor[m]>
Thing is i have close to 0 experience with embedded, except writing code for already built systems, and I'm not good at physics and things like voltage n stuff
IlPalazzo-ojiisa has joined #rust-embedded
<dirbaio[m]>
Rust support for AVR (the architecture arduinos use) is not in a great shape at the moment, i'd advise starting with something that is ARM
diondokter[m] has joined #rust-embedded
<diondokter[m]>
(Many modern arduinos use ARM chips btw, so depends on the board)
<dirbaio[m]>
the one with the weird 5v reneseas chip? might be ARM but there's no Rust HAL (yet?)
<dirbaio[m]>
ah huh there are others with more "normal" MCUs like STM32s
<diondokter[m]>
There are more boards than just the uno.
<diondokter[m]>
The nano uses uses ESP32.
<diondokter[m]>
Portenta has cortex M33 from renesas
<dirbaio[m]>
(what was noteworthy about the renesas one then? I thought the highlight was the switch to ARM)
<dirbaio[m]>
(first arduino uno with ARM?)
<diondokter[m]>
dirbaio[m]: Yeah, the uno with arm and at 5 volts
<dirbaio[m]>
got it
<diondokter[m]>
The Due has a Atmel SAM3X8E
<dirbaio[m]>
I have no idea about arduino lol
<dirbaio[m]>
so many boards
<diondokter[m]>
Yeah. Arduino is more a HAL than it is a specific hardware nowadays
<dirbaio[m]>
they just raised $22M lol
<diondokter[m]>
Ah, there is the Portenta H7 with a STM32H747
<diondokter[m]>
That's pretty normal (it being a dualcore aside)
<dirbaio[m]>
can't wait for enshittification and monetization :D
<diondokter[m]>
Ha who knows. Their IDE got a LOT better after they started building it on top of vscode
<dirbaio[m]>
vscode is the new eclipse:P
<dirbaio[m]>
* new eclipse :P
<diondokter[m]>
Except that I don't want to touch eclipse with a 10 foot pole :P
* diondokter[m]
looks at his cube IDE install and sighs
JonathanDickinso has joined #rust-embedded
<JonathanDickinso>
<dirbaio[m]> "can't wait for enshittification..." <- they have started something a lot bigger than themselves - so enshittification would be unfortunate but not a showstopper. I'm pretty eager to get the MilkV working with Rust.
<diondokter[m]>
Yeah, apparently there are multiple nanos, so the esp one probably has a longer name that I didn't catch
<firefrommoonligh>
<adamgreig[m]> "1000032373.mp4" <- Too cool!
<firefrommoonligh>
Is that an RTK tower on the left?
<JamesMunns[m]>
<adamgreig[m]> "1000032373.mp4" <- You know it's happy and wants to play because of how it is wagging it's tail
<adamgreig[m]>
firefrommoonligh: Yep, well spotted
<firefrommoonligh>
James Munns: I like your LRU analogy; am considering developing a similar standard for small CAN parts. I think a challenge is how general the form factor should be. Currently a lot of hobbyist small UASes have hodgepodge builds/mounting
<firefrommoonligh>
Interaction with the world may be an issue; antennas etc
<firefrommoonligh>
It might even make sense to do it with a bare-PCB form factor, to save size/weight. And, the rack becomes an enclosure without whatever protection from dust/water etc required