On the topic of Microchip and secrecy: I downloaded and installed their IDE, MPLAB X IDE v6.20. It is for a pic3mx chip. The compiler looks like a completely generic gcc, built to cross-compile on a Windows host. However, they want a $1000.00 “licensing fee” in order to enable any optimization level above -O0. This seems wrong. Wouldn’t this be a violation of the copyleft license covering gcc? I’m guessing there’s so…
The GPL in no way forbids that. However, if they are obeying GPL you can ask them for the source code and then remove that limit yourself. If you ask for the source and they don't give it to you, then alert GNU.
What Microchip doesn't (officially) tell you about the VSC8512
31–40 of 103 posts
Re: What Microchip doesn't (officially) tell you about the VSC8512
#32Earlier quoted context omitted.
Microchip in particular is very bad at developer experience and tooling. The only vendor I actually enjoy working with to any degree is ST, and only design boards using their uC's for that reason. I've heard good things about Nordic, though. Might try them out at some point. Microchip's own IDE and project generator spit out a hello world project that didn't even compile. NXP wouldn't even let me download their tooli…
True, and Microchip is still good when compared to the likes of Broadcom and Qualcomm.
I'd love to hear stories of what it's like to work with chips from these companies.
Re: What Microchip doesn't (officially) tell you about the VSC8512
#33The ATF15xx have BSDL files released, but that's only for testing/bypass.
Re: What Microchip doesn't (officially) tell you about the VSC8512
#34The thing I loathe the most about embedded work is dealing with silicon vendors and their boneheaded refusal to publish the fucking documentation and tooling.
Microchip in particular is very bad at developer experience and tooling. The only vendor I actually enjoy working with to any degree is ST, and only design boards using their uC's for that reason. I've heard good things about Nordic, though. Might try them out at some point. Microchip's own IDE and project generator spit out a hello world project that didn't even compile. NXP wouldn't even let me download their tooli…
A while back I tried out Espressif's esp32 and I was impressed by what they were offering. Their devices seem to be well documented and the esp-idf framework is really pleasant to use. It's much easier to work with than STM32Cube and ST's sprawling documentation.
Re: What Microchip doesn't (officially) tell you about the VSC8512
#35The thing I loathe the most about embedded work is dealing with silicon vendors and their boneheaded refusal to publish the fucking documentation and tooling.
Re: What Microchip doesn't (officially) tell you about the VSC8512
#36The thing I loathe the most about embedded work is dealing with silicon vendors and their boneheaded refusal to publish the fucking documentation and tooling.
Why though? This is clearly a problem I just don't understand what the vendors are getting out of it.
Re: What Microchip doesn't (officially) tell you about the VSC8512
#37On the topic of Microchip and secrecy: I downloaded and installed their IDE, MPLAB X IDE v6.20. It is for a pic3mx chip. The compiler looks like a completely generic gcc, built to cross-compile on a Windows host. However, they want a $1000.00 “licensing fee” in order to enable any optimization level above -O0. This seems wrong. Wouldn’t this be a violation of the copyleft license covering gcc? I’m guessing there’s so…
Yeah I’m really not a fan - we had some designs with PICs on them and ended up switching to NXP micros (MCX-A and i.MX-RT) instead, partly because of MPLAB and also because the Microchip ones had some annoying quirks. NXP’s documentation I find a lot better too. I literally try to avoid Microchip where I can from the experience…
I liked working with Microchip uC, but this was back when the whole IC (PIC24) was described in a single ~1000 page document. I found it very readable and instructive in general.
If I had to pick something today it would be with RP2040/2350. The docs look awesome and there's a huge community that is not locked down in some corporate moderated forum but spread organically, with actually useful GitHub projects. It is the only embedded product where it felt like the open source community is along for the ride and not just picking up the scraps. I hope they continue this line of products.
Re: What Microchip doesn't (officially) tell you about the VSC8512
#38Earlier quoted context omitted.
The GPL in no way forbids that. However, if they are obeying GPL you can ask them for the source code and then remove that limit yourself. If you ask for the source and they don't give it to you, then alert GNU.
Of course that depends if the optimization was compiled into the version they have. One can imagine two binaries with the optimizations just missing from the free one.
Re: What Microchip doesn't (officially) tell you about the VSC8512
#39The thing I loathe the most about embedded work is dealing with silicon vendors and their boneheaded refusal to publish the fucking documentation and tooling.
Why though? This is clearly a problem I just don't understand what the vendors are getting out of it.
How do you upsell a hardware engineer who just wants to buy a specific chip, and already has everything to evaluate and use it? You don't. So you force everyone to go through sales, and then sales wants to talk to non-engineering higher-ups, and then the upsell happens - while the people who actually knew what they wanted remain as far away as possible.
And if you don't have the pockets deep enough for the sales dept to acknowledge your existence, then you might as well not exist.
Re: What Microchip doesn't (officially) tell you about the VSC8512
#40Token ring was old in 1996 when my masters thesis focused on error handling behavior and simulation thereof. I wonder if there are certain elements in certain "industrial complexes" that need to maintain or interface with legacy TR systems and that's why it's still hanging around in "dark silicon".
While not technically TR, it does use a token that moves from device to device.
It would be interesting to know if TR is better at contention management than broadcast ethernet - which nobody does anymore because everyone uses switches.