Small footprint USB

[westfw]

t wouldn't be that hard to fan out most of the pin of mid-size BGAs e.g. 100-200 pins on 2-layer board. Small BGAs are not a problem at all.

Really?  Got any hints?  I tried laying out a breakout board for an LPC1102  (16pin 0.5mm BGA) and couldn't come anywhere close to getting it to work within the design rules of the usual 2-layer proto houses (6mil trace/space, 0.3mm drills)  And some of the WSCP has even finer pitch.   It might be neat if some of the lower-pin count BGAs had a much larger pitch, but that doesn't seem to be the case.  Going to finer design rules multiplies the PCB cost by 6 or so...  (not really fair, since the "relaxed" PCB specs are a "special", but still...)  (going from 5mil/0.25mm to 4mil/0.2mm doubles price.)

[langwadt]

for simple and stupid, attiny and v-usb?

It is an option but without any price advantage. Cheapest attiny + 3.3V vreg IC = EFM8 I suggested. Add a crystal and it becomes more expensive. Yes it can be hacked to adjust RC oscillator cal and run crystal-less but is a dubious option and I had bad experience with it. Also needs termination resistors.

for one of it'll be hard tt beat the price of something like this

http://www.ebay.co.uk/itm/302439819311

[NorthGuy]

Do you have any examples for fanning out a medium sized BGA with a 2-layer board? What is the pin pitch? Things like eMMC doesn't count as for all those pins only 10 or so needed to be fanned out and all the remaining pins are just GND's, VDD's or NC's.

I recently made a board for PIC32MZ DA. It is 169-pin BGA with 0.8mm pitch. I used 4-layer board, but not because I needed layers, but because I needed better tolerances - OSHPark has 5mil traces on 4-layer and 6mil on 2-layer. 6mil wasn't enough. Two of the layers have gone unused - I made a power layer and a ground layer, but I didn't really needed them. I used all pins. Perhaps, if I had 2-layer board, I would have to leave some of the pins unconnected to give room for ground and power lines.

The pitch is a different story. 0.5mm BGA pitch is very hard. I looked at TI power regulator TPS62180 for an FPGA board. It is 0.5mm BGA. 6A! Many pins are combined, so may be I could've fan it out, but I decided it is too much for me and went with QFN.

[langwadt]

The pitch is a different story. 0.5mm BGA pitch is very hard. I looked at TI power regulator TPS62180 for an FPGA board. It is 0.5mm BGA. 6A! Many pins are combined, so may be I could've fan it out, but I decided it is too much for me and went with QFN.

there's a layout example in the datasheet, doesn't look like it would be much of a problem

[krho]

You do need layers to fan out bigger BGA, although it wouldn't be that hard to fan out most of the pin of mid-size BGAs e.g. 100-200 pins on 2-layer board. Small BGAs are not a problem at all.

I would also like to know how you would fan out the STM32F4's UFBGA100 package. on e.g 4 layers without blind/buried vias or even via in pad. with normal process not 3.5/3.5mil and 0.2mm holes

[NorthGuy]

I would also like to know how you would fan out the STM32F4's UFBGA100 package. on e.g 4 layers without blind/buried vias or even via in pad. with normal process not 3.5/3.5mil and 0.2mm holes

Obviously, if your minimum trace width is not small enough to put the trace between vias, you cannot do this. Similarly, if you minimum drill with annular ring isn't big enough to fit between ball pads, you must put your vias into ball pads. However, this has nothing to do with the number of layers. Given thin enough traces/drills you certainly can fan it out on 2-layer board.

Of course, with 0.4/0.5 mm pitch you need thinner traces, which will be expensive.  But if the process to fan out 0.4mm BGA is to expensive for you, it doesn't mean you're stuck with DIPs and SOICs. For 1.0mm pitch this is not a problem, and 0.8mm pitch is still fine with dog-bones and 5mil traces.

[technix]

I would also like to know how you would fan out the STM32F4's UFBGA100 package. on e.g 4 layers without blind/buried vias or even via in pad. with normal process not 3.5/3.5mil and 0.2mm holes

Obviously, if your minimum trace width is not small enough to put the trace between vias, you cannot do this. Similarly, if you minimum drill with annular ring isn't big enough to fit between ball pads, you must put your vias into ball pads. However, this has nothing to do with the number of layers. Given thin enough traces/drills you certainly can fan it out on 2-layer board.

Of course, with 0.4/0.5 mm pitch you need thinner traces, which will be expensive.  But if the process to fan out 0.4mm BGA is to expensive for you, it doesn't mean you're stuck with DIPs and SOICs. For 1.0mm pitch this is not a problem, and 0.8mm pitch is still fine with dog-bones and 5mil traces.

Do you have an example of this?

[NorthGuy]

For 1.0mm pitch this is not a problem, and 0.8mm pitch is still fine with dog-bones and 5mil traces.

Do you have an example of this?

I've attached a picture of how this may look. This particular one is 0.8mm pitch. I'm sure if you look for some sort of BGA fan-out guides on the Internet, there must be many in great details.

[JPortici]

which is more than ordering a reel from microchip direct or digikey (unless they charge more in china for some obscure reason)

according to google 7 RMB = 0.89 EUR

SOIC 14 pin, Industrial temperature range

http://www.microchipdirect.com/ProductSearch.aspx?Keywords=ATSAMD11C14A-SSUT

100-1000 0.80 EUR
1000-5000 0.74 EUR
5000+ 0.70 EUR

and this one, extended temperature range, costs even less on digikey!!! (WTF?) https://www.digikey.it/product-detail/it/ATSAMD11C14A-SSNT/1611-ATSAMD11C14A-SSNTCT-ND/6832729?curr=it&WT.z_cid=ref_octopart_dkc_buynow&site=us

SOIC 20 pin, Industrial temperature range

http://www.microchipdirect.com/ProductSearch.aspx?keywords=ATSAMD11D14A-SSUT&utm_source=octopart&utm_medium=cpc&utm_campaign=buynow

100-1000 0.88 EUR
1000-5000 0.80 EUR
5000+ 0.77 EUR

QFN, Industrial Temperature range
http://www.microchipdirect.com/ProductSearch.aspx?Keywords=ATSAMD11D14A-MUT

100-1000 0.92 EUR
1000-5000 0.84 EUR
5000+ 0.80 EUR

[technix]

which is more than ordering a reel from microchip direct or digikey (unless they charge more in china for some obscure reason)

according to google 7 RMB = 0.89 EUR

SOIC 14 pin, Industrial temperature range

http://www.microchipdirect.com/ProductSearch.aspx?Keywords=ATSAMD11C14A-SSUT

100-1000 0.80 EUR
1000-5000 0.74 EUR
5000+ 0.70 EUR

and this one, extended temperature range, costs even less on digikey!!! (WTF?) https://www.digikey.it/product-detail/it/ATSAMD11C14A-SSNT/1611-ATSAMD11C14A-SSNTCT-ND/6832729?curr=it&WT.z_cid=ref_octopart_dkc_buynow&site=us

SOIC 20 pin, Industrial temperature range

http://www.microchipdirect.com/ProductSearch.aspx?keywords=ATSAMD11D14A-SSUT&utm_source=octopart&utm_medium=cpc&utm_campaign=buynow

100-1000 0.88 EUR
1000-5000 0.80 EUR
5000+ 0.77 EUR

QFN, Industrial Temperature range
http://www.microchipdirect.com/ProductSearch.aspx?Keywords=ATSAMD11D14A-MUT

100-1000 0.92 EUR
1000-5000 0.84 EUR
5000+ 0.80 EUR

Shipping takes forever though.

[NorthGuy]

Shipping takes forever though.

Not necessarily. MicrochipDirect ships from Thailand (PIC orders anyway). It is 4-5 days to Canada. Must be much faster to China.

[JTR]

I've just ordered a ATSAMD11-XPRO dev kit from Arrow US for < AUD$37 and that included delivery via FED-EX, Wow! This is a great deal for those of us in Oz/NZ given the price others are asking. 

Wow! I ordered Friday night Australian time and it arrived Monday morning. That is just insane especially when you consider the shipping was free! Big shout out to Arrow.

[JPortici]

Yeah, please can you explain why it would take forever?

[technix]

Yeah, please can you explain why it would take forever?

Chinese Customs.

[JTR]

Yeah, please can you explain why it would take forever?

Now that is exactly what I want to say to some suppliers. 

That is a nice segway to another possible Small footprint, crystal-less micro the PIC32MM 'GPM' series. (Come on Microchip, send the dev kit already!)

http://www.microchip.com/design-centers/32-bit/architecture/pic32mm-family


Unfortunately not available in a DIP package but 28-pin SSOP footprints are not difficult to solder if you use FLUX and SMD to DIP 600 mil adapter boards are cheap as chips on ebay and aliexpress.

If starting from scratch I would still prefer the SAMD over this family but if you are already using microchip stuff and know it then it this is a good option.

[funkathustra]

The EFM8UB1 is available in a QSSOP or QFN package (EFM8UB11 for the QSOP, EFM8UB10 for the QFN).

It's extremely low-cost, and readily available in China (my China board houses have no problem getting them for <10 yuan in small volume).

It's a fantastic part and can be flashed and debugged using a $35 SiLabs USB Debug Adapter, or its $10 clones (search on Taobao for either).

Simplicity Studio, the IDE, is Eclipse-based and completely free. It runs well on Windows, macOS, and Linux. Includes a full, free license to Keil C51 (the 8051 C compiler).

The GUI code generator tool built-in (called Simplicity Configurator) has support for all the peripherals, as well as the USB stack, so it's completely seamless. Really nice property-pane configuration of all the endpoints and descriptors that makes the whole thing a breeze. Silicon Labs also has a USBXpress library that basically gives you a "black box" solution for exchanging byte arrays with a computer --- they provide the library on the part, the USB driver, and a DLL you can call into. It's super easy to use, but obviously has some limitations inherent to its design.

I honestly have no idea why people fuck around with trying to make ancient ATtiny microcontrollers and other AVR parts emulate USB with weird external zener clamp diodes and a bit-banged stack for low-speed, 1.1 operation. It would be one thing if those parts were, like ten times cheaper than the USB-equipped MCUs, but they're actually often more expensive. Ridiculous.

The Atmel SAM D11 has USB, but the only small packages it comes in is QFN, which the OP rejected (I disagree with that, as I have no issues hand-soldering them with a hot plate, hot air gun, or reflow oven, but whatever). Be sure to verify this, but if I remember correctly, it's got the same business as the other Atmel USB chips have: external crystal required, external pull-up resistors, external series resistors, blah blah blah.

Atmel START is pretty clunky compared to Simplicity Configurator, and it doesn't seem to have any GUI for configuring USB descriptors or endpoints.

The PIC16F1454 comes in a TSSOP package, and Microchip Code Configurator has some basic support for the MLA USB stack, but I think they only supported a single endpoint last I checked. No control over polling vs async callbacks, etc. The MCU itself isn't bad, though (crystal-less, attached directly to the USB pins with no external pull-ups or anything, built-in 3.3V regulator). And Microchip has lots of demos in their MLA library. The PIC32MM has some USB support, too, and it's going to be the same deal.

I don't have time to mess around with crappy dev tools anymore — especially on small-run projects and prototypes. Stick the Silicon Labs stuff — you'll save yourself a world of hurt.

[technix]

The EFM8UB1 is available in a QSSOP or QFN package (EFM8UB11 for the QSOP, EFM8UB10 for the QFN).

It's extremely low-cost, and readily available in China (my China board houses have no problem getting them for <10 yuan in small volume).

It's a fantastic part and can be flashed and debugged using a $35 SiLabs USB Debug Adapter, or its $10 clones (search on Taobao for either).

Simplicity Studio, the IDE, is Eclipse-based and completely free. It runs well on Windows, macOS, and Linux. Includes a full, free license to Keil C51 (the 8051 C compiler).

The GUI code generator tool built-in (called Simplicity Configurator) has support for all the peripherals, as well as the USB stack, so it's completely seamless. Really nice property-pane configuration of all the endpoints and descriptors that makes the whole thing a breeze. Silicon Labs also has a USBXpress library that basically gives you a "black box" solution for exchanging byte arrays with a computer --- they provide the library on the part, the USB driver, and a DLL you can call into. It's super easy to use, but obviously has some limitations inherent to its design.

I honestly have no idea why people fuck around with trying to make ancient ATtiny microcontrollers and other AVR parts emulate USB with weird external zener clamp diodes and a bit-banged stack for low-speed, 1.1 operation. It would be one thing if those parts were, like ten times cheaper than the USB-equipped MCUs, but they're actually often more expensive. Ridiculous.

The Atmel SAM D11 has USB, but the only small packages it comes in is QFN, which the OP rejected (I disagree with that, as I have no issues hand-soldering them with a hot plate, hot air gun, or reflow oven, but whatever). Be sure to verify this, but if I remember correctly, it's got the same business as the other Atmel USB chips have: external crystal required, external pull-up resistors, external series resistors, blah blah blah.

Atmel START is pretty clunky compared to Simplicity Configurator, and it doesn't seem to have any GUI for configuring USB descriptors or endpoints.

The PIC16F1454 comes in a TSSOP package, and Microchip Code Configurator has some basic support for the MLA USB stack, but I think they only supported a single endpoint last I checked. No control over polling vs async callbacks, etc. The MCU itself isn't bad, though (crystal-less, attached directly to the USB pins with no external pull-ups or anything, built-in 3.3V regulator). And Microchip has lots of demos in their MLA library. The PIC32MM has some USB support, too, and it's going to be the same deal.

I don't have time to mess around with crappy dev tools anymore — especially on small-run projects and prototypes. Stick the Silicon Labs stuff — you'll save yourself a world of hurt.

Does this stack work under macOS or Linux?

[funkathustra]

[...] Simplicity Studio, the IDE, is Eclipse-based and completely free. It runs well on Windows, macOS, and Linux. Includes a full, free license to Keil C51 (the 8051 C compiler).

The GUI code generator tool built-in (called Simplicity Configurator) has support for all the peripherals, as well as the USB stack, so it's completely seamless. Really nice property-pane configuration of all the endpoints and descriptors that makes the whole thing a breeze. Silicon Labs also has a USBXpress library that basically gives you a "black box" solution for exchanging byte arrays with a computer --- they provide the library on the part, the USB driver, and a DLL you can call into. It's super easy to use, but obviously has some limitations inherent to its design.

Does this stack work under macOS or Linux?

If you're asking about the USB firmware stack, yes you can develop EFM8 firmware inside of Linux (using Simplicity Studio, which is cross-platform)

If you're asking if the "USBXpress" package — which is a do-everything-for-you-black-box — works in Linux, the answer is "yes, if you know what you're doing." The main thing that USBXpress does is provide a frictionless Windows development experience; developers get a DLL file they can easily call into from C++ or .NET, and all the drivers are handled for them (that's the big issue on Windows, until Microsoft came up with WinUSB). In Linux, a properly-permissioned user can open any arbitrary device with libusb, and start exchanging data with it. Since USBXpress is just a single bulk I/O endpoint set, with no data encoding, you should be able to easily use it. But it's not much harder to just use full USB stack, too, and that gives you flexibility to develop for an HID device, or have multiple endpoints, etc.

It sounds like you might be new to USB. You should learn about device classes and types of endpoints before you dig into the weeds too much. Keep in mind that you're going to have to do some host-side software development (Windows, Linux, macOS... whatever your computers are connected to your KVM) — a lot of embedded devs don't necessarily realize that when they get started.

For your PWM LED gadget, you'll probably do either an HID device, or a vendor device (class code 0xFF) with a bulk-I/O endpoint. HIDAPI is one such library that provides a cross-platform API you can use to talk to an HID device; if you do a vendor-class device, you'll probably be using WinUSB on Windows, and direct LibUSB calls on Linux.

There are important technical differences between HID (which is limited to a single, 64-byte interrupt endpoint that's polled once every millisecond) and bulk devices (which can spit out a lot more data), but for your application, either will work.

Shameless plug: I'm currently getting ready to launch an open-source project, called Treehopper (https://treehopper.io), that would basically be a plug-and-play solution to your problem. It's essentially a "black box" development board with analog, digital I/O, PWM, UART, SPI, and I2C interfaces, and you can talk to it from Windows, Linux, and macOS using .NET (C#), Java, or C++. The firmware running on the boards essentially listens to commands from the computer to toggle pins, collect ADC readings, send/receive bytes through the comms interfaces, or change PWM duty cycles. In this way, you can build software on your computer that can interact with physical hardware, and you won't need to do any embedded programming at all.

If you used Treehopper for your project, you'd essentially write a computer program that did this:

Code: [Select]

var board = await ConnectionService.Instance.GetFirstDeviceAsync(); // get the first board out there
await board.ConnectAsync();
board.Pwm1.Enabled = true; // start PWM1 output
board.Pwm1.DutyCycle = 0.7; // turn the LED to 70%

While they're still a month or two away from being available on Amazon, I have a few prototypes kicking around that I'd be more than willing to ship to you if you're interested in beta-testing them. Just send me a PM with your address and I'll get something in the mail to you!

Treehopper is great for software-oriented people new to hardware development, or for engineers or hobbyists who want to get stuff working quickly. However, it completely hides all the USB implementation details, so if you're interested in learning this stuff, I'd stick to bare-metal development on the Silicon Labs EFM8UB1 line of MCUs.

[JTR]

The Atmel SAM D11 has USB, but the only small packages it comes in is QFN, which the OP rejected (I disagree with that, as I have no issues hand-soldering them with a hot plate, hot air gun, or reflow oven, but whatever). Be sure to verify this, but if I remember correctly, it's got the same business as the other Atmel USB chips have: external crystal required, external pull-up resistors, external series resistors, blah blah blah.

You might want to check the data sheet. On the first point you are incorrect but I suspect you made a typo with the rest.  It comes in 14 & 20-pin SOIC and does NOT require an external crystal for FULL-SPEED USB device mode nor does it require external pull-ups etc.

[funkathustra]

You might want to check the data sheet. On the first point you are incorrect [...] It comes in 14 & 20-pin SOIC.

I would not consider a 14 or 20-pin SOIC a "small package" as the OP asked — but I suppose that's up for debate. I guess to me, 4x4mm is about the cut-off for what I would consider "small"

You're totally right about the other points, though. Unlike all the other Atmel parts, the new SAM D11 has clock recovery and internal resistors, so you won't need external components. Thanks for the correction.

I still think you're going to run into more development friction than with the Silicon Labs parts when it comes to the USB stack, simply because how simple it is to use Simplicity Studio to configure everything.

[technix]

You might want to check the data sheet. On the first point you are incorrect [...] It comes in 14 & 20-pin SOIC.

I would not consider a 14 or 20-pin SOIC a "small package" as the OP asked — but I suppose that's up for debate. I guess to me, 4x4mm is about the cut-off for what I would consider "small"

You're totally right about the other points, though. Unlike all the other Atmel parts, the new SAM D11 has clock recovery and internal resistors, so you won't need external components. Thanks for the correction.

I still think you're going to run into more development friction than with the Silicon Labs parts when it comes to the USB stack, simply because how simple it is to use Simplicity Studio to configure everything.

For me "small" have a threefold meaning: small physical size, small board size and cheap. BGA and CSP are immediately out because of the "cheap" metric for fanning them out immediately requires a 4-layer board which is 2x-5x more expensive. QFN is shaky as it can give me routing difficulties on dual layer small boards since I cannot put traces on the bottom of the chip (and when untented vias are involved even the back side is occupied by the QFN.) All three packages can give me difficulties in inspecting too.

How would SiLabs parts fare without Simplicity Studio? Or can Simplicity Studio work under macOS or Linux? What kind of debug probe is required here?

And I am very uncomfortable with Keil C51 (and ARMCC v5, ARMCC v6 does not count for it is based on LLVM/clang) since it is not even C99 feature complete (while all my code is have almost completely converted to C11/C++14, which my usual compilers, GCC and LLVM/clang accepts.)

[funkathustra]

How would SiLabs parts fare without Simplicity Studio?

SiLabs header files use compiler-agnostic #defines for everything, purposely to allow developing with different compilers. If you're looking for a FOSS route, try SDCC. Never used it myself, though.

Or can Simplicity Studio work under macOS or Linux? What kind of debug probe is required here?

Yes, as I've mentioned (now twice...  ) Simplicity Studio is fully cross-compatible with macOS and Linux. The official Silicon Labs debug probe is called the USB Debug Adapter; it's $35. There are several clones.

However, Simplicity Studio also has full support for regular old Segger J-Link probes (which is awesome! you can use your ARM tools for EFM8 development). I routinely go back and forth between both of them. Note that with J-Link, you have to manually specify the attached target to Simplicity Studio; with USB Debug Adapters, this is automatic. Flash speed on J-Link is faster, but not noticeably so.

You can program them in Keil uVision, too, but obviously that's Windows-only. Because Simplicity Studio is Eclipse-based, obviously the GUI is "native" in all three platforms. Under the hood, SiLabs spent a *lot* of time building nice installers that prepackages an internal WINE system to call the command-line C51 tools (yes, you get a full version of Keil C51 for free when you download Simplicity Studio).

And I am very uncomfortable with Keil C51 (and ARMCC v5, ARMCC v6 does not count for it is based on LLVM/clang) since it is not even C99 feature complete (while all my code is have almost completely converted to C11/C++14, which my usual compilers, GCC and LLVM/clang accepts.)

Yup, that's the thing that sucks about Keil C51. Not because of its lack of C11 support, but because it's a bizarre compiler. But honestly, it doesn't seem to affect my productivity much. The biggest trap for newbies is all the reserved words; I spent a good 20 minutes trying to figure out why "uint8_t data = 5;" wouldn't compile (it threw weird error messages), until I realized that "data" is a reserved word. Now my "data" variables are named "datuh" or "dater" or "dayta" etc 

As for C99 / C11, for small embedded projects, the biggest language feature I see from C90 to C99 is declaring variables inside loop constructs, honestly. And maybe variadic macros. Everything else is either widely supported already (stdint, one-line comments), or probably not relevant (or good) for embedded programming (VLAs, restrict pointers, flexible array members). Again, this stuff is awesome when I'm building big embedded projects (networking stacks are great to implement in C99/C11), but not on little 8051 projects, in my opinion.

[technix]

How would SiLabs parts fare without Simplicity Studio?

SiLabs header files use compiler-agnostic #defines for everything, purposely to allow developing with different compilers. If you're looking for a FOSS route, try SDCC. Never used it myself, though.

Or can Simplicity Studio work under macOS or Linux? What kind of debug probe is required here?

Yes, as I've mentioned (now twice...  ) Simplicity Studio is fully cross-compatible with macOS and Linux. The official Silicon Labs debug probe is called the USB Debug Adapter; it's $35. There are several clones.

However, Simplicity Studio also has full support for regular old Segger J-Link probes (which is awesome! you can use your ARM tools for EFM8 development). I routinely go back and forth between both of them. Note that with J-Link, you have to manually specify the attached target to Simplicity Studio; with USB Debug Adapters, this is automatic. Flash speed on J-Link is faster, but not noticeably so.

You can program them in Keil uVision, too, but obviously that's Windows-only. Because Simplicity Studio is Eclipse-based, obviously the GUI is "native" in all three platforms. Under the hood, SiLabs spent a *lot* of time building nice installers that prepackages an internal WINE system to call the command-line C51 tools (yes, you get a full version of Keil C51 for free when you download Simplicity Studio).

It is good to know that my existing tools can work with EFM8. I might get some parts or a dev kit to try it out.

QSOP24 is still a bit larger than the TSSOP20 STM32F042F6 though...

I wonder if I can steal the copy of full Keil C51 for another vendor’s chip, for which they don’t even have headers for any other compiler?

And I am very uncomfortable with Keil C51 (and ARMCC v5, ARMCC v6 does not count for it is based on LLVM/clang) since it is not even C99 feature complete (while all my code is have almost completely converted to C11/C++14, which my usual compilers, GCC and LLVM/clang accepts.)

Yup, that's the thing that sucks about Keil C51. Not because of its lack of C11 support, but because it's a bizarre compiler. But honestly, it doesn't seem to affect my productivity much. The biggest trap for newbies is all the reserved words; I spent a good 20 minutes trying to figure out why "uint8_t data = 5;" wouldn't compile (it threw weird error messages), until I realized that "data" is a reserved word. Now my "data" variables are named "datuh" or "dater" or "dayta" etc 

There is a reason why GCC folks (and LLVM/clang, and to some extent MSVC) introduced the __attribute__ keyword, so those features wont hog up the entire identifier namespace. I definitely prefer “__attribute__((section(“.data”)))” with “-fmemory-large” over Keil’s approach.

The GCC __attribute__ is seeping into standards, like the [[attribute]] syntax in C++14.

As for C99 / C11, for small embedded projects, the biggest language feature I see from C90 to C99 is declaring variables inside loop constructs, honestly. And maybe variadic macros. Everything else is either widely supported already (stdint, one-line comments), or probably not relevant (or good) for embedded programming (VLAs, restrict pointers, flexible array members). Again, this stuff is awesome when I'm building big embedded projects (networking stacks are great to implement in C99/C11), but not on little 8051 projects, in my opinion.

[mikeselectricstuff]

QFNs are superior to TQFPs or SSOPs because they take less space for the same die size all other things being equal.

And you don't get bent pins, or solder wicking between pins. If you can avoid soldering the die pad (i.e. device doesn't require it for heat) that makes rework a lot easier. As long as you extend the pads outside the outline, it's no harder to hand-work with than QFP

[technix]

QFNs are superior to TQFPs or SSOPs because they take less space for the same die size all other things being equal.

And you don't get bent pins, or solder wicking between pins. If you can avoid soldering the die pad (i.e. device doesn't require it for heat) that makes rework a lot easier. As long as you extend the pads outside the outline, it's no harder to hand-work with than QFP

A recent (company) project used a lot of QFN's. The failure rate is scratching my boundry. And that is a power package that requires the die pad to be soldered and via stitched.