How embedded friendly is this? And I'm not talking raspberry pi but actual MCUs. I saw a mbedTLS depends somewhere.
Discussion
I'm not judging BTW, this is awesome! I'm just curious.
Don't be afraid to post your critiques! Not just me but every dev, I know what I open myself too when I share this stuff!
I do hardware hacking like yourself. My automotive experience was briefly on the obd side.
However, I ran into some chiptuners along the way. I always got the sense they were bitter their cars were going digital 😀
XD. Yeah I did old stuff, 8065 things (yeah motorola version with a psudo x86 before it was released)
I wanted to get into datalogging development and newer model obd stuff but it's even harder to find that kind of black magic info. Diesel stuff is really undocumented and DMRs are just guess and check. And most people writing the DMR addresses don't even look at disassembly to see actually memory layout so it's just a guess (usually wrong) then uneducated tuners go melting engines down.
SAE makes you pay for everything and take stupid classes to get access to those documents. I of course, wanted to get into rom flashing via DLC, so bootmode and such.
I could spend all day talking about it even though I'm out of the game (EPA)
Yeah right on. We'll, I saw you other not about being in a cave :) I'd say we need more HW/FW types. If you like RF there are projects like meshtastic that are super popular right now.
Also reticulum.
I'm working on some FM demodulation analog style with a PLL circuit to fm demod some voice data on a cassette. But I'm waiting for the parts.
I was playing with LoRa a few years ago, most of the guys in the club I was in at school were into RF stuff, most of the guys were EE I was the only CPE, so they were mostly messing with SDRs and making packet trackers. One of their projects was to be able to coordinate within 1 meter an 802.11 radio up to 1 mile with a single antenna and an SDR. They did it before I left.
I really like Microchip/Atmel products and their tools/libraries. I was writing firmware, and a linux driver for rpis for LoRa because it was really underdeveloped and even the SPI library was maked as partially working and no longer maintained. Probably still in use today. So i went to rewrite it all but life got in the way. Finding work has been tough, so I've had to try where there's more money and personal freedom and that seems to be software if I can land it. I don't want to give up on HW/FW but that's how I see it for now. I miss electronics/tinkering for sure!
That said. here is what's left of my lab. My other benches and large parts bins are still full but in my storage shed for now. I still want a nice logic and spectrum analyzer one of thes days.
We have a lot of the same gear :)
Yeah I hear you on the FW side. You can also apply to Microchip :) but yeah, don't know your personal situation. They are in AZ.
Yeah that's a good shout! I'm a workaholic so the WFH bug got me too, I can work, and while work is slow I can work on projects XD. But we'll see.
In short: its on the road map!
The high level api is designed to be agnostic to it, although there will probably be some hold ups. It's written in C89/90 and compiler enforced but I currently use CMake as the build system but it shoudln't be hard to transition to a native compiler. mbedTLS is currently an optional back-end for this reason
One of the largest is that it depends on libsecp256k1, which requires over 1mb of data segment for lookup tables, which is just way too much for most MCUs.
Have you looked into what trezor crypto does? They are using a secp256k library on a stm32f2. So there are embedded libraries that do this especially from the hardware wallet side.
I have looked into some I thing uBitcoin but I wasn't happy with the arch. I suppose I could make it pluggable during build time, but libsecp256k1 has my heart in design. If someone else has a worthy dependency I will consider it so thanks for the referalls!
My intentions were to fork libsecp256k1, because we want to add some CPU intrinsic helpers or assembly routines where necessary, and it's one of the most forkable libs I've worked with so thats the motivation.
Oh libwally too. It was developed by blockstream.