Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

serd.es

Post reply on HN
Print view View original

51–60 of 103 posts

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

#51

Post by Aurornis »

traverseda wrote: post #35
ACCount36 wrote: post #24

The 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.

When you get into high volume production, the vendors have their own engineers who will work with you directly. Depending on the arrangement and your volume they might bill you for the time, require you to buy blocks of support hours, or they might bend over backward to help you out in any way possible if you’re buying enough parts from them.

Dealing with small clients is not a priority for most part vendors. Many of them won’t even sell you chips at all until you can qualify yourself as a big customer or, in some cases, buy a license to start designing with their parts for six figures or more.

Unfortunately for the small players, it’s not a priority for most companies to support small customers who might only buy a couple thousand parts or less.

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

#52

Post by Aurornis »

junon wrote: post #25
ACCount36 wrote: post #24

The 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…

> The only vendor I actually enjoy working with to any degree is ST, and only design boards using their uC's for that reason.

ST has good documentation most of the time, but for a while some of their higher end MCUs had a lot of weird bugs and errata that were simply not documented. I haven’t used any of their modern parts recently but I’ve heard the situation has started improving. I have some friends who were ready to abandon ST altogether after losing so much time on a design to undocumented bugs and parts not behaving as documented.

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

#53

Post by Aurornis »

znpy wrote: post #23
fragmede wrote: post #13

Earlier quoted context omitted.

The GPL doesn't say you can't charge money for things. Do they provide patches for their changes to the source?

I think that the issue here is the following: - you can charge money for things - anything that's not built with the "official compiler" is not "supported" I've interviewed for a junior embedded software engineer when i was in university and when i started mentioning i had experience building cross-compilers i was immediately stopped by the guy interviewing me (he literally didn't even let me finish the sentence) and…

> Absolutely no. We don't want to maintain our own toolchain and we want everything to be coming from the BSP [Board support package] and integrated nicely with the vendor's IDE

This is critical if you want any support from the vendor.

If you come to them with a bug in their hardware but you’re not using their toolchain and BSP, it’s the end of the road. You have to recreate a minimal reproduction of the bug in their ecosystem before they’ll look at it.

When you’re working at company scale, paying $1000 for a compiler is a trivial expense.

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

#54

Post by azonenberg »

Aurornis wrote: post #52
junon wrote: post #25

Earlier 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…

> The only vendor I actually enjoy working with to any degree is ST, and only design boards using their uC's for that reason. ST has good documentation most of the time, but for a while some of their higher end MCUs had a lot of weird bugs and errata that were simply not documented. I haven’t used any of their modern parts recently but I’ve heard the situation has started improving. I have some friends who were ready…

I don't think I've ever used a ST part without reporting a bunch of datasheet errors.

I haven't been bit by an undocumented silicon bug, but I step on documented STM32H7 bugs on a pretty regular basis and there are some poor design decisions around the OCTOSPI (in addition to bugs) that make me avoid it in almost every situation.

But at least they document (mostly correctly) the registers to talk to their crypto accelerator unlike the Renesas and NXP parts I looked at as potential replacements, both of which needed an NDA to get any info about the registers (although they did supply obfuscated or blob driver layers IIRC).

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

#55

Post by azonenberg »

Sanzig wrote: post #47
Gracana wrote: post #34

Earlier quoted context omitted.

I was on the Microchip bandwagon until the PIC32. Little MIPS MCUs with onboard RAM and graphics, awesome! ...except they came with an errata that listed huge problems with every interesting peripheral, and it didn't improve for ages. They may still suck, I don't know. 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 fr…

I really like the STM32 ecosystem, but you have hit the nail on the head - there's too many variants. You really don't need 200 variations of a basic M0+ part, and having all those SKUs hurts availability because you're playing roulette when it comes to what will actually be in stock when your CM goes to order parts.

I did not like that part of it.

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.

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

#56

Post by FpUser »

ACCount36 wrote: post #24

The thing I loathe the most about embedded work is dealing with silicon vendors and their boneheaded refusal to publish the fucking documentation and tooling.

My last experience with embedded MCUs was few years ago with ATMEL and all was fine

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

#57

Post by azonenberg »

Aurornis wrote: post #53
znpy wrote: post #23

Earlier quoted context omitted.

I think that the issue here is the following: - you can charge money for things - anything that's not built with the "official compiler" is not "supported" I've interviewed for a junior embedded software engineer when i was in university and when i started mentioning i had experience building cross-compilers i was immediately stopped by the guy interviewing me (he literally didn't even let me finish the sentence) and…

> Absolutely no. We don't want to maintain our own toolchain and we want everything to be coming from the BSP [Board support package] and integrated nicely with the vendor's IDE This is critical if you want any support from the vendor. If you come to them with a bug in their hardware but you’re not using their toolchain and BSP, it’s the end of the road. You have to recreate a minimal reproduction of the bug in their…

I avoid vendor toolchains and BSPs just because of how buggy they are.

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.

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

#59

Post by InitialLastName »

FpUser wrote: post #56
ACCount36 wrote: post #24

The thing I loathe the most about embedded work is dealing with silicon vendors and their boneheaded refusal to publish the fucking documentation and tooling.

My last experience with embedded MCUs was few years ago with ATMEL and all was fine

Atmel hasn't existed for almost 10 years (Microchip bought them in 2016). The situation has not improved in the intervening time.

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

#60

Post by jmiskovic »

mardifoufs wrote: post #41
jmiskovic wrote: post #37

Earlier quoted context omitted.

Personally I hated the NXP's docs for the ARM M4 core. Bunch of dry tables listing each register in details, lacking the juicy diagrams and descriptions on how the bits integrate to work as a subsystem. I constantly needed to cross-reference 3+ documents (most of which describe the whole family and not the specific IC). Their HALs and code samples were obviously written by students/interns. I liked working with Micro…

Yeah, NXP in my experience had an issue with having too much documentation. In the sense that you get drowned in a 3000 pages PDF that lists every detail but becomes hard to parse unless you want to base everything around that specific platform for years. Though that sounds like an awesome "issue" to have in some circumstances.

It felt very different and not pleasant.

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.

Post reply on HN