Hacker News Reader

Comment by jeff_ciesielski | Hacker News Reader

This is a nice breakdown, however it is leaving out one interesting piece: Active slew rate controllers.

In some cases where you need to exceed the typically allowed bus capacitance either due to a high number of attached devices, or over a long cable run (it happens...it sucks, but it happens), you can use a part like the LTC4311 which, rather than using resistors to passively pull the bus lines to a resting high state, detects the direction changes and actively assists in pulling the lines to their intended states.

https://www.analog.com/media/en/technical-documentation/data...

View on HN

I wish software packages had data sheets! It would be great to have a concise/standardized format with bullet points and a "typical applications" section on github landing pages.

Be the change [pull request] you want to see in the World!

(I hate it when people say that!!)

Well, someone has to do the work. Asking someone else to do it seems kinda crappy if it's you who wants something for nothing.

I think GP means they hate the phrase 'be the change you want to see in the world' (as do I) but was begrudgingly applying it to pull requests.

The problem I have is the sense "you're only allowed to ask for progress or give direction if you code it".

Maybe you're eg a UI/UX expert, you can help plan the direction for a project, feedback the changes needed and why, help make the project a success but just aren't competent enough to code those changes. Sure, no-one owes you their FOSS work, but it seems like we lose something if the only input allowed is from people able to do the coding.

Of course you might also just be a user. If you pay it forward, do you get to make a feature request?? If I don't code it myself ... maybe I should stop being a user if I can't contribute code?

Demanding work for free, and offering suggestions for improvements can be seen as synonymous, but they can actually be vastly different.

Projects I use heavily, like Ubuntu, I try to make myself useful offering advice on forums. That's not putting "money" in the bank of any coders but seems like it's in the spirit of FOSS - contributing what we can to create a better system.

There's always someone ready to exploit others.

Analog Devices and Linear Technology (now owned by Analog Devices) have the cleanest looking datasheets. Texas Instruments is ok but not great. Standard Microcircuit Drawings, the kind of government datasheets used for milspec parts, are absolutely horrendous and should be avoided if the manufacturer has a normal looking datasheet to look at.

Linears are great, I find the AD sheets hard to read sometimes. Microchip historically has some decent ones but it’s been a while since I’ve used their parts.

Datasheets for Japanese connectors are like a circle of hell for me. Confusing and possibly incomplete dimensions, and the drawing usually looks like it was printed, scanned, and converted to jpg several times.

Ugh, I've been using a datasheet from Panasonic [0] recently, and it's been a trip. The original Japanese is all there, with a lackluster English translation below each paragraph. Plugging the Japanese in to Google Translate for the particularly bad sections usually helps. At least this version is clean, I ran across a few PDFs floating around for this part that looked like they had been run though the print-scan-jpeg cycle a few times.

0: https://mediap.industry.panasonic.eu/assets/custom-upload/Co...

Eait until you see Chinese market only parts without datasheets in English, and thenselves mostly done by not so bright engineers of sales offices of Western big semis.

TI's technical reference manuals for their MCUs are some of the best I've used, though. That's not saying much. But compared to Marvell or NXP/Freescale they're really good.

In "Object-Oriented programming an evolutionary approach", Brad J. Cox (the inventor of Objective-C) hoped for the birth of "software-ICs", software components that should have been widely reusable, and documented with the equivalent of the datasheets used for traditional ICs. This was his vision for OOP.

IC datasheets are dominated by the mundane but critical things like timing diagrams and electrical tolerances. Software components can't even agree on which "ICs" fit into which breadboards.

Cypress PSOC chips have a bunch of software modules you can load into them to implement various functionality, and each piece of such software includes a datasheet, just as if it was a standalone chip. It's glorious.

Read your comment after a whole day of desperately troubleshooting an i2c bus on (way too) long wires. I already held an mcp2515 board in my hands thinking about how to retrofit every device with CAN, knowing this would take weeks until robustly running. Maybe adding LTC4311's will keep the system running until I truly have time for the conversion.

Thanks a lot for your comment! (Just created an account to write this!)

That's right. A current source (active) instead of a 'poor man's current source' (a resistor) can help fix problems. I had to run 400 kHz i2c over a few meters, and it really helps to drive the cables properly.

Excellent recommendation, I'm going to test this out!

Reply on news.ycombinator.com