What Microchip doesn't (officially) tell you about the VSC8512

If you're working at one of the big companies (e.g. Microsoft), they'll give you access to the documentation and source code that should be open for everyone, but even then you're going to spend time reverse engineering your own documentation because trying to get details from them is a months long process of no one being willing to say yes. It's painful. Best to stay away unless you have no other alternatives.

For larger volumes, ~100,000 you get to talk to a distributor yourself and design your own pcb. You still won't get to talk to anyone at BigSemiCo, but you will get access to datasheets and (probably) drivers. You will have to sign an NDA.

For their largest customers, they go all out. The customer gets significant input into the design roadmap years in advance. They can get cost-reduced versions of existing parts that leave off blocks they aren't using. reference board designs and example software are provided (to the extent that low-margin, enormous volume customers sometimes just change the html logo and ship). If the product needs integrating, Field Engineers will be flown out to assist.

There are some levels between these last two, where they will talk to you but not invest as much.

Take the above numbers with a pinch of salt; it's been a while since I was in that industry

I poked at a vsc73xx-based switch in the past and wrote my own test firmware, but had problems with packet loss since I didn't do all the necessary phy initializations I guess, in case this might be of interest: https://github.com/ranma/openvsc73xx/blob/master/example/pay...

Also on the device I had the EEPROM was tiny and the code is loaded from EEPROM into RAM, you were pretty much stuck with 8051 assembly that had to fit into the 8KiB of onchip RAM :)

Personally I've standardized on just three STM32 parts:

* L031 for throwaway-cheap stuff where I'm never going to do field firmware updates (so no need to burn flash on a proper bootloader) and just need to toggle some GPIOs or something

* L431 for most "small" stuff; I use these heavily on my large/complex designs as PMICs to control power rail and reset sequencing. They come in packages ranging from QFN-32 to 100-ball 0.5mm BGA which gives a nice range of IO densities.

* H735 for the main processor in a complex design (the kinds of thing most people would throw embedded Linux at). I frequently pair these with an FPGA to do the heavy datapath lifting while the H735 runs the control plane of the system.

Yes, absolutely. Notoriously, smaller customers are more needy in fact. The bigger the customer, the more competent their engineers tend to be (or, the more time they have to spend figuring out how to use your stuff). Smaller customers try to offload support onto vendors, which pushes burden onto internal vendor teams (who don't want to provide the support...).

From my perspective, it's much better to reproduce a bug with a 20-line C or assembler file that compiles with upstream gcc, completely ruling all of their custom stuff out as the root cause.

Just tell me what the silicon does when I poke this register and I'll work around it.

Mhm. I'd say, you're forced to reproduce it on their toolchain and BSP, which may or may not be the end of the road depending on how complex the problem and your use case are.

(I am aware that there's a certain kind of mindset that likes to lean on support from vendors to do basically anything, and I think if you're in a position where you actually get good support, that might work, but in most of the instances where I've seen such a mentality it tends to produce expensive results that still don't actually work, and sometimes even when AFAICT the vendor's pretty switched on, they just don't actually have all the context)

The PIC24 was actually my first large project. I learned awful lot from reading its docs, for example setting the DMA to read 32 samples from ADC and let CPU know when done. Putting it together felt like playing with LEGO blocks. There were many annoyances with the toolchain and the clumsy memory addressing but I enjoyed it overall.

The NXP was downright unpleasant compared to it. I don't think a junior could be handed a NXP dev board and all the docs to hone their craft. It requires significant patience and expertise to pick out the relevant details in the vastness of their documentation. Of course the NXP product line is huge and I can only comment on few uC models I had contact with. The sensors and other less complex ICs were vastly better and docs were quite digestable.

Audio is usually soft realtime, sometimes, e.g. when doing studio recordings, firm realtime.