-
I buy little PCBs to break everything out to 2.54 spacing to go on a breadboard or protoboard *anyway* so tiny packages are utterly wasted on me.
Yeah, absolutely, for evaluating devices break them out to breadboard-compatible packages.
Also, Oshpark's PCB service is so cheap for very small boards, you can just layout your own breakout boards (add a few smd passives if you like) for a similar price to buying off-the-shelf breaksouts.
I am a hobbyist, 2 years ago I'd never soldered a smd, but now I'm doing 0.5mm QFN with no real problem.
Except hot air guns, don't use a hot air gun on a part you want to use (it's ok to use it to remove a dead part) because I've killed a part or two with hot air.
I also decided that no-leads packages are actually easier to handle than small-leaded packages. The tiny pins can get bent or snapped easily. This is not an issue with QFNs, DFNs. -
I buy little PCBs to break everything out to 2.54 spacing to go on a breadboard or protoboard *anyway* so tiny packages are utterly wasted on me.
I do this too. I have dozens of these. This is very handly. However, I'm gradually moving more towards "everything on the PCB" approach as PCBs are now so easy to get (and hopefully this continues).Except hot air guns, don't use a hot air gun on a part you want to use (it's ok to use it to remove a dead part) because I've killed a part or two with hot air.
The air temperature must've been too high.
-
I have a 'spoon' tip as well but a big flat 4mm tip + flux works much better. I usually solder 3 to 4 pins in one go. When using lead free solder you definitely need the right temperature though. 330 degrees Celsius works best in my experience.That depends entirely on the PCB layout. If you have problems with bridging on QFP then you are not using enough flux and the tip is too small. Use a bigger tip and more flux. For hand soldering QFN you'll need footprints which leave about 0.5mm room to put a soldering iron on but I'd take QFP over QFN every day.
I usually leave 0.25mm pad extension, which is totally fine for QFN with proper iron, but not enough for QFP. The reason drag soldering work is by wicking solder from across pins to pad extension, and it only works with long enough pad extension.
A large enough iron with large enough wicking capability (like those with a spoon inside) may also work, but I don't have a T12 station, and Metcal doesn't offer such tips for MFR series. My JBC station is small enough not to wick enough solder. If I use that C105128 spoon tip, I have to clean the tip for every 3 or 4 pins, which makes it very counter productive. -
The main reason i was wondering about the STM32F103 is that everyone else seems to be using them and they are cheap due to volume.
When you work for the hobbyist masses - you use currently most popular chip. When you work for the mass production - you use cheapest chip. When your work description is "custom solution fast", you disregard all of above. -
But 0.4mm QFN is not fun neither, especially small ones. Pins are so small that I cannot really put enough solder on the footprint before heating. Then I need to add solder to pins manually, and I need really thin tip to get to the pins, and it feels like poking in the dark to me.
yeah, i would recommend anyone new stay away from 0.4mm unless they have no other options.
I agree that QFN is easier/quicker to solder than QFP.
Usually you can just tin the pads, add flux and hot air a QFN to the board without much else needed. Get it to giggle with the hot air and you're good.
Some people (inc me) get a bit OCD about getting solder to flow up the sides of all the pads on QFN, but, if you used flux under it, it will have soldered correctly under the chip. So a side swipe isn't really needed, It does look pretty though
-
Some people (inc me) get a bit OCD about getting solder to flow up the sides of all the pads on QFN, but, if you used flux under it, it will have soldered correctly under the chip. So a side swipe isn't really needed, It does look pretty though
Putting the exact amount of solder on centerpad is key. If you put too little, it may not solder. You may need to press the chip down hard to fix this. If you put too much, it'll create a cushion and then regular pins on one of the sides will sit too high. In such case the "side swipe" is absolutely necessary. I often make mistakes, one way or the other. Thus, I don't like QFN, and prefer TQFP where you can see pins and errors are easily fixed.
With stencil and paste, the amount of solder on the centerpad is regulated by the stensil, so QFN is certainly better than TQFP.
-
Some people (inc me) get a bit OCD about getting solder to flow up the sides of all the pads on QFN, but, if you used flux under it, it will have soldered correctly under the chip. So a side swipe isn't really needed, It does look pretty though
Putting the exact amount of solder on centerpad is key. If you put too little, it may not solder. You may need to press the chip down hard to fix this. If you put too much, it'll create a cushion and then regular pins on one of the sides will sit too high. In such case the "side swipe" is absolutely necessary. I often make mistakes, one way or the other. Thus, I don't like QFN, and prefer TQFP where you can see pins and errors are easily fixed.
With stencil and paste, the amount of solder on the centerpad is regulated by the stensil, so QFN is certainly better than TQFP.
When I did not have a hot air station, I used to make small balls with the hand solder on the QFN pads and then solder the component to the PCB using enough flux. However, this cannot work on some components, that do not have the GND pads exposed and rely solely on the center square under the component itself. -
I definitely do not agree with:QuoteThe same with MCUs. The first one you use, you're going to like
When I was young microcontrollers were difficult to handle. You had to buy very expensive chips (starting around USD50) which had ceramic housings and a blob of glass and had to put them under UV light to erase them. Alternative were the Eprom based systems which needed some 40+ wires just to get a blinking led because you had to wire up data and address busses and such.
A few years later came the PIC16F84A. One of the fist with Eeprom. Everighing together in a simple DIP package, you didn't even need a crystal oscillator if the built-in RC was good enough. That was the first uC I bought. They were also cheap enough to buy a handful of them, because you know, hobbyists blow things up. I never got around to doing more than a few blinking led projects with the bloody thing. It had a completely abhorrent instruction set (Yeah only 20 or so instructions to learn). What a marketing bullshit.
Then came the AT90S1200, and quick thereafter the at90s2313 and ATMEGA8, which I all bought in various amounts. The internet was also booting up and information was increasingly easy to find. The 1200 was quite limited because of lack of RAM, and the only thing I ever did was to bitbang AN910 in it, which was programming software which interface between a serial port and the SPI bus for programming other Atmel AVR's. Bitbanging a uC in those days was by putting a few wires directly into the LPT port of your PC, and onto a breadboard with your uC. Not very reliable, but enough to bootstrap yourself on a low budget.
My sole reason for turning to Atmel was the availability of GCC for the AVR's. Programming a uC in C that is luxury!
After that I never attempted to even use any microcontroller that is not supported by GCC.
Over the years I've done some 50 odd projects with the ATmega's. and always liked them, and they were fit for my purposes, so for a long time I did not feel a need to learn a new uC family. I briefly had a look at the ATtiny's, but I disliked them very much and quick. Instead of a decent sereal port they have a USI, the I2C (which atmel called "twi" for vague reasons) worked completely differently from the ATMega's, for which I had just written and debugged a nice I2C library. Right then I vowed to never use the ATtiny's again.
Nowadays such hardware implementation differences may be hidden in software libraries, but this was all mostly before "arduino" even existed.
I could start a big rant about all the reasons I dislike "arduino" (no capital there), but I also see it's an easy way to get acquainted with uC's.
Just do not EVER use their half baked java based editor that is not worthy of the name IDE. If you want to start with "arduino" then at least use a decent IDE, such as anything supported by Platformio, or if you're on windows, the IDE that Atmel (now Microchip) distributes. I believe it's based on some Microsoft IDE and people seem to be happy with it.
Advantage of Platformio is that you can easily set up a complete tool chain and it is completely vendor independent. From whatever IDE you use with Platformio you can switch between projects with ATMEGA, ESP8266, Blue Pills, and some 20 or so other uC families. You can also work with "arduino", "mbed", and other platforms. It really is an amazing tool to try out some new uC and it's capabilities without much worrying about how to set up a complete tool chain for whatever uC you're using this week. It just pulls them from the internet somewhere.
A few years ago I decided that I wanted something "new". Nice small TFT displays became available and the ATmega's just do not have the horsepower to drive such an LCD. I do not want to wait to see individual pixels popping up on the screen. Also other projects were growing a bit, and the ATmega's were a bit sluggish or needed a lot of careful programming and interrupt scheduling to ensure proper operation.
Out of curiosity I bought a handful of "Blue Pills" and "Maple Mini's" from China. Significantly more powerful processors, these can update such a TFT with 10 or more FPS which is plenty for a responsive user interface. I fiddled a bit with "stm32duino", a website which has now closed, I believe ST has taken over it's content, and I also fiddled a bit with mbed. It feels like multiple layers of incompatibility libraries thrown together in a bowl and mixed together. When trying to understand the initialization code you find 4 function calls deep an empty funktion with the comment that you can add something there if you want. Yuch. Those 4 function calls should not have been there in the first place. I also really disliked ST's way of first declaring a structure, filling it with some bytes and then calling a library function with that structure, with the end result of just setting or clearing a single bit in a register.
The teensy's may be nice but It's unlikely I will spend USD20 on their development boards. An important factor for deciding for a uC is also the package it's in. I must be able to solder the chips relatively easy on bare PCB's I've ordered. QFP's with a pitch of 0.5mm are OK, but I'm apprehensive of using BGA's. I have never done those, and you can't visually inspect them.
I've always liked to build my own programmers, or use pre-built programmers as long as they are cheap. I thought long and hard about buying an "AVR Dragon", which was about USD80 at that time, but decided against it after reading too many stories of the thing blowing itself up. For the "Blue Pill" you buy USD3 "ST-Link V2" clones and these just work. Even if you damage them, from standing on it, ESD damage or whatever, Who cares for an USD 3 programmer? Just buy a handful of them, which also gives you more opportunities to debug the hardware if you suspect hardware problems with your programmer, you can just swap it for another. I think I've managed to damage 5 or more programmers in the last 30 years, and that is no fun if they cost USD150 each.
I do not like "bootloaders" They are far overrated. Often they are also not user friendly, they take up FLASH, you have to pamper them, often have to press a button to get into "bootloader mode" and other disadvantages. With a decent programmer you have no worries about all those things. Just connect the wires, tell your PC to program your uC and it does it. Always and reliable. Bootloaders can be handy in some niche applications in the field, but for at home on the bench a normal programmer is much easier to use.
I got my first "blue pill" working from a very nice 4 page tutorial from "pandafruits" which explains everything from initialization code & compiling and even connecting with GDB from the command line. It's a very good "getting started" guide.
Another tool I want to mention is Sigrok / Pulseview. Together with an USD 5 Cypress CY768013_something based development board, (or Saleaeae clone) you have a very capable logic analyzer that everyone should learn to use with their first blinking led project on the first uC they ever use. With the "logic analyser" in a plastic box you get 8 channels, with a generic CY7C... board you get 16 channels, but these do not have ESD protection on the inputs. This hardware can sample upto a few Msps and stream directly to Sigrok over USB, so sample depth is not an issue. It is also plenty fast for sampling UART, SPI, I2C and some 100+ other low speed serial protocols. I've even successfully sampled and decoded low-speed USB with it. (1.5Mbit/s) Such a LA is a much better debugging tool then just outputting some bytes to a serial port or printf to an lcd. You can for example continuously output trace information to any un-used peripheral your uC supports. Write "0x13" every time a specific ISR triggers, and another when another ISR triggers, and you can back track timing after your uC program crashed. With a normal debugger you can set breakpoints and halt (which completely destroys all timing) but how do you back track from there to see where it first went wrong? GDB is a powerful tool, but a logic analyzer is a good extra tool to have in your toolbox.
If you read through here you probably thought it was worth it. -
I prefer underdogs generally, which is why I like the Infineon XMC series. Good, well thought out peripherals, good documentation, etc. The only downside of this MCU family is the limited selection of development boards.
My second choice is STM32, but I find that family frustrating at times as their peripherals are all over the map with virtually no consistency between series. There's a good selection of development boards, however. -
A few years later came the PIC16F84A.
You won't believe how many people still use these old PIC16s. The question is why? -
A few years later came the PIC16F84A.
You won't believe how many people still use these old PIC16s. The question is why?
Comfort zone.
-
Lazy to switch, so stay with old deprecated crap. But if they switched, it most likely would end up doing their work more efficiently and making better and cheaper products. Spend time on learning new MCU, save time on coding or doing HW design with not abysmal platform. Not to say at some point someone's ass will start burning because supply of parts for recently designed product suddenly in no longer there.A few years later came the PIC16F84A.
You won't believe how many people still use these old PIC16s. The question is why? -
8-bit AVRs. Really easy to setup the peripherals with good community support. Up until now I didn;t had to the need for something more complex or powerful. I really "hate" ARM micros with huge datasheets and difficult peripherals configuration and stock libraries that causes more problem than you would expect from the company that designed the part.
Alexander. -
8-bit AVRs. Really easy to setup the peripherals with good community support. Up until now I didn;t had to the need for something more complex or powerful. I really "hate" ARM micros with huge datasheets and difficult peripherals configuration and stock libraries that causes more problem than you would expect from the company that designed the part.
Alexander.
10 years ago it took me weeks to learn GPIOs, I2C, SPI, CAN and UART on AVR. It took me less than 1 day to get everything running on STM32Cube. Sorry, but ARM is at different level. And when you include debug and trace capabilities, there's no discussion anymore. -
8-bit AVRs. Really easy to setup the peripherals with good community support. Up until now I didn;t had to the need for something more complex or powerful. I really "hate" ARM micros with huge datasheets and difficult peripherals configuration and stock libraries that causes more problem than you would expect from the company that designed the part.
10 years ago it took me weeks to learn GPIOs, I2C, SPI, CAN and UART on AVR. It took me less than 1 day to get everything running on STM32Cube. Sorry, but ARM is at different level. And when you include debug and trace capabilities, there's no discussion anymore.
Look at these two opinions. Is it possible that the two people observe objective reality and, based on the same facts, came to two completely different conclusions? There's only one explanation - these opinions are based on emotions and preferences.
Of course, there's nothing wrong with that. But this clearly demonstrates that it is impossible to pinpoint the single "best" group. It's just as hopeless as trying to select the "best" dish in the restaurant.
-
8-bit AVRs. Really easy to setup the peripherals with good community support. Up until now I didn;t had to the need for something more complex or powerful. I really "hate" ARM micros with huge datasheets and difficult peripherals configuration and stock libraries that causes more problem than you would expect from the company that designed the part.
10 years ago it took me weeks to learn GPIOs, I2C, SPI, CAN and UART on AVR. It took me less than 1 day to get everything running on STM32Cube. Sorry, but ARM is at different level. And when you include debug and trace capabilities, there's no discussion anymore.
Look at these two opinions. Is it possible that the two people observe objective reality and, based on the same facts, came to two completely different conclusions? There's only one explanation - these opinions are based on emotions and preferences.
Of course, there's nothing wrong with that. But this clearly demonstrates that it is impossible to pinpoint the single "best" group. It's just as hopeless as trying to select the "best" dish in the restaurant.
Exactly right, but you need to try at least a couple to find something that is better over the other... And trying doesn't mean power it up for 5 minutes, but actually try and do something working... -
Nowadays, you need to take into account the existence of code/libraries/infrastructure for the uC you're trying to choose.If you're going to rely on ASF or Cube or Arduino, you may never learn the details of the uC as much as you would have if you had to start from the datasheet and write everything (perhaps in assembler.) The flip side is that you probably don't really need or want to understand all 1000+ pages of datasheet for a modern chip - if your problem fits into the feature and performance envelope of Arduino, and is "easy" using that tool, then in some ways it's foolish to insist on more care and complexity.
The same is true for programming languages. No matter how much you love a particular languages efficiencies, I don't think it makes a lot of sense to write heavy-duty program that falls outside of the easy and efficient areas, just because some other's language features or syntax offends your sensibilities.
-
8-bit AVRs. Really easy to setup the peripherals with good community support. Up until now I didn;t had to the need for something more complex or powerful. I really "hate" ARM micros with huge datasheets and difficult peripherals configuration and stock libraries that causes more problem than you would expect from the company that designed the part.
Yes, I just did a little project with an ATTINY13A in 8-pin SOIC. The programming in C was WAY easier than any micro project ever before, the whole project was done in a couple days. Totally amazing devices! I highly recommend them for small projects.
Alexander.
For bigger projects that need net connectivity, maybe exporting a GUI, that sort of thing, then the Beagle Bone Black is quite awesome. A complete Linux node for $60 or so.
Jon -
Anyway, nothing inherently wrong in reusing the same old part over and over again if you're very familiar with it, it's still available and it still fits your requirements.
If you never use anything else/newer, you will just miss learning opportunities, which is a shame, but it's everyone's call really. If you don't want or don't need to learn, it's a pity but your problem entirely.
-
Hello,
I develop high-end circuits and/or in very small quantity so the price is not a concern.
I used Microchip family a lot ( PIC24EP and dsPIC33EP ) even when it's not necessary and a small 8bit would have been enough.
I switched to ST M3/M4 "just because" and It was hard because of the documentation is not written according to the same logic.
I miss the peripheral pin select wich is a killer feature. It is much more easy when you need almost all peripheral for the layout.
I have to test PIC32 family but with a personal project first. I heard so much hate about PIC32 ( or Microchip.....or Mplab )
I have to make my own opinion. -
I miss the peripheral pin select wich is a killer feature. It is much more easy when you need almost all peripheral for the layout.
STM32 MCUs have this as well.
-
Which ones do you have in mind ?
I have to look more deeply in their new references.
The ones I used ( STM32F405/407, STMF446 for example ) have some capabilities in pin assignment but it is not as flexible as Microchip PPS feature. -
Which ones do you have in mind ?
I have to look more deeply in their new references.
The ones I used ( STM32F405/407, STMF446 for example ) have some capabilities in pin assignment but it is not as flexible as Microchip PPS feature.
Have only worked with the 4xx line (F4/L4) so far, and yes this is what I had in mind. I don't quite remember how that was on PIC24. It may have been a bit more flexible, but as I remember, there were also some restrictions as to which function could be assigned to which pin? Maybe fewer restrictions though, can't remember the details.
-
Which ones do you have in mind ?
I have to look more deeply in their new references.
The ones I used ( STM32F405/407, STMF446 for example ) have some capabilities in pin assignment but it is not as flexible as Microchip PPS feature.
Have only worked with the 4xx line (F4/L4) so far, and yes this is what I had in mind. I don't quite remember how that was on PIC24. It may have been a bit more flexible, but as I remember, there were also some restrictions as to which function could be assigned to which pin? Maybe fewer restrictions though, can't remember the details.
one example :
On STM32F446 you only have 2 options :
you can have SPI1 on PA5 PA6 PA7.
PA5 is SCK
PA6 is MISO
PA7 is MOSI
or you can have SPI1 on PB3 PB4 PB5
PB3 is SCK
PB4 is MISO
PB5 is MOSI
dsPIC33EP512MC806 :
You have lots of remappable pins. You just have to be careful because there are RPn pins ( can be input or output ) and RPIn ( can be input only ).
If I look quickly, I see that I can assign MOSI_1 to any af RPn pins ( 16 possibilities ) and/or I can switch between MOSI and SCK if it is useful for my layout.
-
(...)
You have lots of remappable pins. You just have to be careful because there are RPn pins ( can be input or output ) and RPIn ( can be input only ).
If I look quickly, I see that I can assign MOSI_1 to any af RPn pins ( 16 possibilities ) and/or I can switch between MOSI and SCK if it is useful for my layout.
Oh, now I remember a bit more. Yes, apart from this RP/RPI thing, this was more flexible indeed. Peripherals on STM32 can only be mapped to specific sets of pins, even when there are several such possible sets, but not each function signal to any IO (IIRC, the exception was with I2C I think?). That's indeed a lot more limited for STM32 parts, and requires more planning. I've never really be bothered too much by this, but I have worked with layout guys that would go crazy if they could not re-assign almost any pin to any signal while routing.