dev
Cultivating curiosity for software developers
4 replies
5 recasts
21 reactions
1 reply
0 recast
1 reaction
Coming from a robotics / embedded side of things - ofc i started thinking about how to do this, beyond just a prototype, my mind wanders:
- well, at some point the FADEC is going to have to be on a microcontroller, should I overoptimize today, and write it all in C right now, and write the PID controller etc in C? yeah i've done that before
- should i use RTOS like Zephyr? that'd be fun
- but then I need the microcontroller to talk to each other, oh right what am i going to use?
- how about protobuf? zmq? ROS2? (absolutely out of the question) i thought about Zenoh as well, but then I'd have to sue zenoh-pico, annoying.
- what's that xkcd meme? 14 protocols, let's build a new protocol
- also protobuf the data packets that aren't sent don't have a set size upfront, so maybe zmq + nanopb, nanopb is flexible and they have fixed array sizes so you can allocate memory upfront (another reason embedded folks don't use dynamic memory allocation upfront C++ 'new' as well as C malloc. no wonder everyone hates C++ in embedde world. just allocate the memory upfront
- why not rust? you love rust July - yeah i know i know, but here's the thing, RTOS rust limited board targets today
- why not RISC-V july? yes yes I know things are improving, but a lot of my existing experience is in arm64, cortex m0~m3 environments and i'm used to it, shoot me
what packet routing will we use? how much bandwidth will it take?
- and this is just the avionics side, not even doing the mechanical yet... 1 reply
2 recasts
14 reactions
0 reply
0 recast
3 reactions
4 replies
1 recast
28 reactions
2 replies
1 recast
4 reactions
0 reply
0 recast
1 reaction
1 reply
0 recast
3 reactions
1 reply
0 recast
9 reactions
5 replies
1 recast
20 reactions
0 reply
0 recast
5 reactions
1 reply
1 recast
5 reactions
0 reply
1 recast
4 reactions
1 reply
0 recast
1 reaction
1 reply
0 recast
7 reactions
