Jamey Sharp @jamey@toot.cat

@er1n I feel like every UAV project invents a wire protocol DSL eventually... 😅 I do think it's a better idea to have some higher-level interface than raw bytes, because one of the major kinds of bugs in these kinds of systems (I claim, without actually having any evidence) comes from screwing up the raw byte handling.

@er1n I had not seen uavcan before! it apparently tries to tackle almost every challenge I've ever had with CAN. I hate it, and also, it looks fine

@er1n yeah, absolutely. I mean I feel like "this is awful but I don't know of any better options" goes for pretty much every technology though, so,

@er1n all that said, I don't actually know of a better option for avionics kinds of things; I will grudgingly grant that from a hardware perspective it's a pretty solid spec.

@er1n yeah, the 8-byte limit is the biggest thing I didn't like about it. you might want to look at the newer CAN-FD spec though? I think I heard hardware is starting to become available even at hobbyist levels for that, and it gives you up to 64 bytes per message, IIRC. there are also games you can play with how you use message ID bits, but that gets obnoxious quickly. also the whole broadcast nature of CAN seems to feel unnatural to anyone used to things like internet protocols.

@er1n sure! what are you doing with CAN? before those two projects (one of which I got paid to work on), we used it in the http://psas.pdx.edu rocket in 2005, and I've pretty much hated it ever since. so I can probably answer questions if you want to run anything by me 😕

@er1n I mentored somebody through writing this little STM32 Rust demo: https://github.com/oresat/syscon-rs/blob/master/src/main.rs

I had the advantage of having previously written a driver for the same bxCAN peripheral in a Haskell-embedded DSL that generated C: https://github.com/GaloisInc/ivory-tower-stm32/tree/master/ivory-bsp-stm32/src/Ivory/BSP/STM32/Peripheral/CAN

I'm still proud that my driver computed the bus timing settings at compile time, so at runtime it just had to poke constants into a few registers.

most embarrassing, though: I got a register address wrong and spent literally days debugging

@ehashman "normal people" are the ones who are perpendicular to a tangent, right? 🤔

I want a program that expands #include directives in C pre-processor source, but keeps track of all possibilities for macro definitions and only eliminates #if directives that are provably false. The latter is necessary to prevent infinite recursion for source code that relies on include guards, but also means it can report which macros you can define that actually have an effect on how the program is compiled. This is kind of like unifdef; maybe "uninclude"?

@nancywisser please stop spying on my therapy sessions

@grainloom Yes, I certainly think it can be worth-while, and more so as the data you're transferring gets bigger! Also, yes, more people should play with seL4... 😁

@grainloom I'm pretty sure the operations you can do on a memory capability in seL4 let you transfer ownership of pages to another process, and I'm also fairly certain that that's necessary for security in a lot of cases. (if the sender can modify things while the recipient is reading them, it might be able to pass a valid value, wait for that value to be checked for validity, and then change it to something invalid before use.) changing MMU page tables has performance costs, though.