3 ms·
Sure. But that difficulty all comes down to whose shoulders you stand on. If the peripherals' functionalities and their registers are fully described in a dat
by flyingcircus3 3y ago
Sure. But that difficulty all comes down to whose shoulders you stand on. If the peripherals' functionalities and their registers are fully described in a datasheet, and you have a working toolchain, and a viable method for loading binaries, then you are set. Additional libraries on top would make it even easier, but you at least have the device's specifications.
Companies like Qualcomm, Broadcom, and Marvell are notorious for locking down their documentation. If you're not shipping millions of units, they're not going to give you the time of day. And even if they are willing to work with you, they're not going to provide you with full register maps, or really anything that would allow you to be independent of them. Instead, they'll give you binary blobs that handle low level details. Every datasheet is watermarked, and NDAs are required to get them.
Most of the other big players, STMicro, Texas Instruments, Nordic, Microchip, etc, are far more open. Just about all of their parts are well documented, and those documents are freely available.
- the__alchemist 3y agoST's RMs are a bit of a pain, but the info is there, and reasonably consistent. The SVDs have many errors, and inconsistent between variants, but there are some open source patch systems available. (Like SVD2Rust). It's nice ST is getting into this space, even though I don't have a use case for this type of device now. As you mention, Nordic's docs are great too. I noticed for a certain ST part (rangefinder), instead of a documented register API, there was a C library for it. I posted on their forum because I was confused (and not using C). An engineer explained that they did it that way because at the hardware level, the device was very complicated, and they weren't sure the best ways to configure it; they wanted to leave open the option to change it later. So, not obfuscation like you're describing with the *COMs, but a technical decision to use a library.