Been doing some cleaning of the ol’Tech Corner this weekend. Been reading Marie Kondo’s books(The Life-Changing Manga of Tidying Up: A Magical Story (The Life Changing Magic of Tidying Up, for instance.) on tidying up.
Anyone’s who’s gotten a good look at my tech corner can tell you it’s a bit like am old electronics shop. You know the one with the aisles and aisles of just “stuff” yeah.
So while I can’t/won’t go and drag everything of one kind out… there are literally thousands of kinds of things in there… I did set a sort of cutoff based on my prevailing interests, recent frustrations, and just YOLO/TLDR; aspects of life.
Smaller Than 1206? Out!
Any part smaller than 1206 is out. 0805? nope. Out. Those tiny ant-like SOT-23 transistors? Nope. out. If it can be mistaken for pepper or sand… it’s out.
I’m not saying they are bad.. I am just admitting I’m done with them as I lack the patience and steady hand to work with them.
One of the boards I recently worked on, employed what I thought to be some fairly easy to manage 0805 parts: resistors, capacitors… and even one SOT23 transistor, which I thought was a marvel at how small it was.
Yep. Small. It was so small that just bumping it with molten solder would have it DANCING or coming to life like a Chinese Zombie!
So… no. Anything smaller than 1206 and I’m out. No more SOT23. If it is hard to differentiate between pepper, sand, grit, or glitter… it’s probably too small for me to realistically work with. Life’s too short. -_-; So anything smaller than that is out.
Standardizing On A Smaller Set of Chips
My interests have varied over the years and during the course of that, I’ve often gone and bought a handful of any type of chip that interested me. -_-; It started with the 555 timers. Then it was the shift registers. Oh! Then there were the AND/OR/NAND/etc. logic gate IC(s). Then Arduino and the bare bone AVR chips. Then looking at the whole family of AVR chips. Then looking at GAL(s), PAL(s), CPLD(s), and finally FPGA(s). Multiple families and generations of them. So much that I feel like I’m archiving them rather than using them.
No more. Time to slim things down.
So there has been this decades long back and forth “discussion” about which was better…. AVR or PIC. Atmel or Microchip. Well, thanks to the power of the invisible hand at work in the global economy…. they are both one big happy family since Microchip bought Atmel. Yep. They are all Microchip… chips.. now.
Me, I never used Pic chips nor the BASIC stamp type chips that used Pic and pre-dated Arduino/Wiring. Why? Because the programmers were pricey and the compilers were expensive. Basically, Microchip had a relatively high barrier to entry for their platform. So I never got into it until Arduino made it available to the masses and I went and got hooked on Atmel’s AVR(s).
Now that Microchip owns it all, there really hasn’t been much difference. Why mess with the golden goose, right? It’s still two distinct markets with loyal customer bases. Just rebrand and keep pumping out the chips. Maybe do some cross-pollination of features. Boom. Win.
So I’ve got quite a few MCU(s): AVRs, ARM M-series via LPC/Teensy, and Extensa via ESP8266/ESP32.
The ARM chips are all QFP or BGA. When I use an ARM chip, it is through buying a pre-assembled module like on a Teensy, Espresso, etc. Most of these are one offs, so I’ll keep using ARM type chips, just because it’s a very very useful family of silicon.
I DO happen top have some ARM M0 chips that are PDIP! However, it’s such a limited use case, that I’m basically abandoning it. With ARM, it’s going to be a third party assembled module or not at all.
AVR ie ATtiny, ATmega, ATxmega, etc…
Seriously, I have found the AVR chips to be the most user friendly of the bunch. Maybe this is Arduino/Wiring’s layering, but I found I have gotten very comfortable with this family of chips. Of note, the ATmega328P, ATmega1284P, ATtiny85, and ATtiny2313 are the ones I tend to use in my designs. Both in the PDIP package as well as the QFP/QTFP package.
All in all, they aren’t powerful, compared to the other offerings out there, but they are straightforward to use. Not an excessive amount of bells and whistles. Easy to get ahold of. And can be operated at 3.0-5.0 volts. They are nice self-contained units and I don’t see myself switching away from them anytime soon.
Xtensa aka ESP8266 and ESP32
I have a bit of a love-hate relationship with these modules. Though to be fair, it’s not the modules I have a problem with… it’s the issue of Chinese knock-off FTDI USB-serial chips, FTDI’s resulting action which bricked quite a few peoples’ devices legit and otherwise… exposing a SERIOUS supply chain issue of the cheap knockoffs getting into the chain of normally trustworthy suppliers. I had bought a whole boatload of them thinking I would do a solid and make some coin by flashing them and selling them for a nice low price. I bought before the whole knock-off chip issue happened and got them well after. *facepalms* So now I have a crate of them that I basically use in whatever project comes to mind, because I don’t have it in me to re-sell them knowing there is a high potential for issues. That’s the hate.
The love is the flexibility of the chips. They have a nice amount of stage and ram, plenty of processing power, and they can do Wifi AP and Wifi Client. What? Yeah. Very cool. Very versatile. You can even flash them to run MicroPython. Just be aware that the ESP chips are presenting a runtime environment to you.. the low level stuff is actually running an RTOS. As a result of this and because of how the hardware is setup to do things, there are two gotchas:
- If your code has a blocking action that takes longer than 500ms or 1000ms or whatever the physical watchdog limit is set to, it will spontaneously reboot/hang. To avoid this, yield() and yield() often. Avoid delays. Avoid operations that will block for a long time.
- Because your code is running atop of…. being serviced by an RTOS, timings will have a certain degree of jitter.
Other than those two issues… and the whole knock-off usb-serial interface chips, they are great and *sighs* I will be using them for the foreseeable future.
FPGA(s)…. Going with Xilinx.
You can’t mention FPGA(s) without invoking thoughts of bitcoin mining. No, that’s not why I got into FPGA(s). I actually got into it while sort of rummaging through an old used tech shop called Weird Stuff(they have closed…). And they had a section of old circuit boards from computers and whatnot. I had been interested in GAL/PAL(s) and so wanted to see if I could find some on these boards… when I realized, many of the boards had the Xilinx XC95xx series of flash programmable CPLD(s)… an order of magnitude or two better than the GAL/PAL(s) I was interested in!
Bought some boards, did some de-soldering, and remounted onto a breakout board, and got to programming. It worked and I could program it! I was hooked. I kept going back, finding bigger and bigger chips. The biggest working one I got my hands on was an old Altera Flex with some 10’s of thousands of logic gates and I was thrilled.
But then I realized that the tech was old school and when I saw the new offerings, I realized there was so much out there… before I knew it, I had multiple families of FPGA on hand and programmers.
It basically came down to two brands: Xilinx and Altera. I never got into Lattice nor MicroSemi FPGA(s).
Both have lots going for their products. But in the end, I decided to focus on Xilinx’s FPGA offerings. The following are my personal reasons:
- Generally speaking, for a giving chip, Xilinx offered more raw capability and logic capacity.
- Xilinx maintained a website which made it fairly straightforward to access support materials.
- Altera HAD a good website but since Intel took ownership, it’s all become a maze of broken links and download reference links that no longer work…. instead, redirecting people back to their main product page… which advertises Intel more than it does FPGA(s).
- The toolchains’ UI/UX is a matter of personal taste. However, I have consistently found the Xilinx ISE and Vivaldi interfaces to be significantly faster for manipulation, processing, synthesis, route&place, etc. A persistent warning from Altera/Intel’s Quartus* software about not being licensed for more than one CPU might be the reason…. seriously, EVERY laptop and desktop I own has at least 4 cores. WTH.
Neither Lattice nor MicroSemi ever made it onto my lab bench. This isn’t a judgement of them, it’s just a factor of what I ended up encountering and following from the beginning.
However, having said that I’m standardizing on Xilinx for FPGA(s), I’ve found that in many cases, unless there is a good reason to use an FPGA… parallelism, high IO count, multiple different protocols, etc… it tended to be easier to implement with an MCU… or a more powerful MCU. This is most likely due to a lack of understanding and experience on my part. But Xilinx stays in my tech corner.
I’ve recently become interested in sound processing and digital synthesis/filtering… DSP in general. Something I remember seeing often while scrounging boards were ADSP or SHARC chips and BLACKFIN chips. I didn’t know enough about them so never bothered buying them to look at. I had seen them mainly in switches, since the store I scrounged in was primarily tech company IT infrastructure type stuff. But I’ve since learned that while I’ve been mainly mucking about in OS and embedded programming/chips/platforms, there is a more specific segment of embedded dedicated to DSP… of which Analog Devices, is a big name in.
I’ve also learned that the SHARC type chips are used in many audio processing and accelerator boards, modules, and input/output devices because they do a good job of low latency/realtime processing of incoming/outgoing/etc. signals.
Looking at their datasheets, I was wow’d. While they would not excel at general computing, they were highly optimized for the math and operations related to working with 16 and 32 bit sound samples and streams.
So while the RAW compute power of a desktop processor would crush that of one of these DSP chips… IF handling that specific task was all it was doing, it would not be able to match it, while handling the entirely of the OS functions, foreground and background tasks, processing software driven filters, etc. There would be a great deal of latency.
Contrast this to the DSP chip whose only purpose is to process those streams of data. It can apply the algorithms to the sound’s digital data very quickly and return it to the main computer.
It is very interesting. And while I currently do not own any DSP chips, I expect to look into them in the near future. 🙂 And it will most likely be an Analog Devices SHARC.
So that’s about the long and short of it. I’m still interested in SMD/SMT, but not the super tiny stuff. I’m sticking with AVR for my general goto MCU, ESP8288 modules because I have a boatload of them, Xilinx FPGA(s), and in the future, SHARC DSP(s).
I’ve cleared out a whole mess of stuff and have put together a care package for a friend of mine. >_> Er… some of the “padding” are actually ESP8266 modules still in their static bags… efficient, huh? heh heh. heh heh…..