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

Original Article ↗ Hacker News Discussion ↗

Enjoyment of the series & hardware opacity

  • Commenters praise the depth of the reverse‑engineering work and note it exemplifies how opaque hardware can be, especially PHYs.
  • People highlight that vendor capabilities and errata often only become clear late in bring‑up, forcing redesigns; some compare this to “hidden” behaviors in software libraries.
  • The VSC8512’s lineage through multiple acquisitions is seen as part of the confusion, with a sense that even “opened up” docs from Microchip still omit important details.

PHYs, legacy tech, and real-time networking

  • Token Ring support lurking in “dark silicon” sparks discussion about legacy industrial systems needing deterministic behavior.
  • Long subthread clarifies real-time categories (hard/firm/soft) and notes:
    • Consumer/pro‑audio over Ethernet is usually soft or firm real‑time.
    • Safety‑critical domains (nuclear, avionics) demand hard real‑time guarantees.
  • AVB/TSN are mentioned as making Ethernet more suitable for tight timing, but traditional Ethernet alone is seen as inadequate for the strictest cases.
  • A claim that DOCSIS is token‑based is corrected: it uses TDMA/CDMA, not token passing.

Microchip, MPLAB, and GPL concerns

  • One user objects to Microchip charging ~$1,000 to unlock compiler optimizations in what appears to be a GCC‑based toolchain, questioning GPL compliance.
  • Others respond that:
    • GPL permits charging money; the key is providing corresponding source.
    • Microchip does publish source archives, which likely satisfies the license.
    • A noted “loophole” is contracts that forbid customers from even asking for source (Qualcomm example), raising questions about enforceability.

Vendor toolchains vs custom toolchains

  • Many embedded developers dislike vendor IDEs/BSPs, finding them buggy, bloated, or hard to reproduce issues with.
  • Others insist on using vendor stacks because:
    • Vendor silicon support often requires reproducing bugs in their official environment.
    • Offloading toolchain liability is attractive for organizations.
  • There’s a split between those who prefer minimal, upstream GCC/Clang + hand‑written drivers, and those who prioritize official support and integration.

Ecosystems, documentation quality, and vendor behavior

  • Microchip receives mixed reviews: more open than some predecessors, but still poor tooling (huge MPLAB installs, broken default projects) and incomplete docs.
  • ST’s STM32 line is widely liked for CubeMX configurator and relatively good docs, but criticized for:
    • Numerous variants causing supply and selection headaches.
    • Documented and undocumented errata (especially higher‑end parts).
  • NXP is described as having “too much” documentation that’s hard to navigate; tool download friction is mentioned.
  • Nordic is praised for BLE parts and reasonable documentation, though Zephyr is seen as heavy for small MCUs.
  • RP2040 is singled out for excellent docs and a vibrant, open community; esp32 also gets positive notes for docs and framework (esp‑idf).
  • Texas Instruments’ MSP430 line is cited as a model: comprehensive family manuals, per‑device guides, and explicit errata documentation.

Big semiconductor vendors & secrecy

  • Broadcom, Qualcomm, and similar vendors are depicted as hostile to small/medium customers: NDAs, restricted docs, sales‑gatekept access, and unresponsive support unless volumes are very large.
  • Anecdotes describe:
    • Internal silos and codebases with layers of wrappers and long‑lived unfixed bugs.
    • Known bug lists kept internal and not exposed in public errata.
    • Tiered support where only high‑volume clients get real engineering help or design influence.

Why vendors stay closed

  • Several rationales are proposed:
    • Cost of producing externally consumable documentation and supporting many small customers.
    • Desire to funnel prospects through sales and management for upselling.
    • Fear that detailed public docs help competitors in feature and performance comparisons.
    • Limited margins and high NRE: sub‑million‑unit customers may not justify the support burden.

Other wishes and side notes

  • Someone wishes Microchip would publish programming algorithms and bitmaps for legacy Atmel SPLDs/CPLDs; current understanding is partly reverse‑engineered.
  • Raspberry Pi’s RP series and TI’s MSP430 are held up as examples of how good, public documentation substantially improves the embedded developer experience.