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

71–80 of 103 posts

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

#71

Post by AlotOfReading »

ants_everywhere wrote: post #32
ACCount36 wrote: post #26

Earlier quoted context omitted.

True, and Microchip is still good when compared to the likes of Broadcom and Qualcomm.

I don't do embedded work, but I see Broadcom and Qualcomm show up a lot in Linux bugs. I'd love to hear stories of what it's like to work with chips from these companies.

Unless you're buying hundreds of thousands of chips, you don't even get the "opportunity" to work with them. They won't sell you chips directly or return emails reliably.

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.

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

#72

Post by eqvinox »

howerj wrote: post #68
dmitrygr wrote: post #63

Earlier quoted context omitted.

Ran into this at Google. Qualcomm compiler for their DSP was an expensive branch of GCC. I asked my manager if we could just ask them for source instead of paying per-seat license. He said that “ our contract with Qualcomm specifically prohibits us from asking them for the source of this compiler”. They found the workaround tor GPL I guess.

I have heard that this is how it is done before. I wonder how that works with a third party? If they happened to come across the binaries some how they could demand the source. I also wonder if that clause is enforceable.

AIUI the entity distributing it has to provide the source. So if Google were to (try to) (re-)distribute that compiler, they'd be legally fucked because they'd have to provide the source… which they don't have and can't get.

(But presumably that agreement also restricts Google from redistributing the binaries anyway.)

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

#73

Post by rcxdude »

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.

There's certainly cases where the documentation basically doesn't exist, or it's essentially the same as the design documentation, and the strategy is basically that if you're a big enough customer then you'll be getting some engineer time to make things work, and if you're a smaller customer you'll be told to pound sand anyway, it's not worth them fixing up their documentation to get your business. Generally the more complex and specialised the hardware the more it'll look like this, and it basically saves them on R&D because they have only a few applications to actually focus on.

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

#74

Post by eqvinox »

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…

> not using their toolchain and BSP, it’s the end of the road.

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.

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

#75

Post by rcxdude »

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…

IME you're usually on your own anyway. I've rarely found it worth slogging through their crappy BSP for the chance of maybe receiving some useful support.

(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)

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

#76

Post by eqvinox »

mannyv wrote: post #40
lttlrck wrote: post #9

Token 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".

The ideas behind token ring underlies DOCIS. 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.

> The ideas behind token ring underlies DOCIS.

> While not technically TR, it does use a token that moves from device to device.

I assume you typo'd DOCSIS there, but no, DOCSIS does not use a token; it uses separate channels for down- & uplink, and the uplink channels are TDMA and/or CDMA depending on DOCSIS version.

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

#77

Post by eqvinox »

thyristan wrote: post #46
rbanffy wrote: post #20

Earlier quoted context omitted.

There is audio distribution real-time and nuclear reactor (or avionics, medical, etc) real-time. I assume the people doing (or certifying) the latter will want better guarantees.

The usual terminology is hard, firm and soft realtime. In hard realtime, missing a deadline is a total failure and to be avoided at all cost, i.e. your reactor melts down, you car runs over someone, stuff like that. Firm realtime means that a missed deadline will not be a total catastrophic failure but it will make the result useless. E.g. when your printer control system mistimes the "fire ink now" in the printer, a…

It should be noted these distinctions don't correlate with timing; you can have a hard realtime system that needs some network packets at 50ms±10ms intervals, and a soft realtime system that needs packets at 500µs±5µs.

Some audio setups are run quite "close to the metal", both because it needs less buffering, but also the lower human threshold for noticing latency seems to be around 10ms. And having audio not get out of phase with multiple sources/sinks gets added on top of that.

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

#78

Post by ranma42 »

azonenberg wrote: post #50
ACCount36 wrote: post #26

Earlier quoted context omitted.

True, and Microchip is still good when compared to the likes of Broadcom and Qualcomm.

This is why I used a VSC PHY. After they bought Microsemi (and Vitesse as a division of Microsemi) it looked like the only viable option to get a QSGMII PHY since all the other players were much worse. When I first started the project in 2012-13, Vitesse was just as NDA-happy and I ruled them out. The original roadmap called for a 24-port switch with 24 individual TI DP83867 SGMII PHYs on three 8-port line cards.

BTW looking at the 8051 patch bytes, they look like 8051 code to me. 0x02 is the ljmp opcode, so this is a jump table: 0x02, 0x40, 0x58, 0x02, 0x40, 0x4e, 0x02, 0x44, 0x00, 0x02, 0x42, 0x2b, 0x02, 0x41, 0x82

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 :)

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

#79

Post by junon »

HeyLaughingBoy wrote: post #64
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…

Good god. I literally just uninstalled MPLAB IDE for a project that we cancelled. It freed up something like 30Gb on my system. I built the existing project once! I also really like ST. At a previous job our go-to processors were Nordic for wearables or anything that needed BLE, and STM32 for pretty much everything else. Wasn't unusual to have an STM32 for all the peripheral I/O and an nRF52 hanging off an I2C port j…

That's good to know, thanks! And yeah, STMCube's quick pin config and clock config tools alone are what keep me coming back. I don't use any of the C generation or code editing/compiling stuff (I write all of my firmware in Rust) but having the configurator there to quickly configure peripherals is space age levels of tooling compared to any other manu I've worked with so far.

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

#80

Post by junon »

stephen_g wrote: post #43
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…

Which NXP tooling did you have trouble with? I’ve downloaded MCUXpresso earlier this week, no NDA or anything (yes you do need an account), it’s never been hard to get…

I remember their site inexplicably not letting me download anything despite being logged in. I think it wasn't able to retain my session for some reason, though it's been a while (I looked around 2023).

I do remember trying different browsers and even different machines, to no avail. Quickly gave up.

Post reply on HN