Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Tools required to burn code in a quad flat microcontroller

+3
−0

I always have a doubt that how do firmware engineers dump code into a quad flat microcontroller? For a starter kit there is already connection like USB or some SPI ,I2C headers to burn the code,also starter kits are very costly. I know that for Dual inline Package there are some cheap programmers in the market.Then what about quad flat micros used in industrial application?How do you all proceed?My question is based on a hobbyist or a small firmware engineer point of view.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

General comments (1 comment)

1 answer

+5
−0

The days of socketed microcontrollers are long gone. In most cases, the socket would cost more than the micro.

Nowadays, microcontrollers, whether in quad flat pack packages or not, are surface mount soldered onto boards along with all the other parts. There are then two ways to get the program into the micro:

  1. Get the micro pre-programmed with your code.
  2. Provide connections to the programming lines and program the micro yourself during the production test and/or calibration process.

Pre-programmed

If you have a high volume product that is basically "done" where you don't expect firmware changes, then #1 can make sense. Microcontroller companies and their distributors can pre-program parts for you in volume.

At high volumes, the additional cost is usually small. The main downside is that it can be costly to change the firmware. Not only is there significant lead time, but you may end up scrapping 1000s of parts with the old firmware.

Because of the inflexibility of this approach, it is usually only done for very high-volume low-cost products which you don't expect to change. Toys, for example, can fall into this category.

Self-programmed

In most cases, you bring out the micro's programming lines to someplace on the board you can access during production test. I usually use a 5-pin Molex KK series connector for this. These are cheap and take up little room. Connecting a programmer and programming the micro are then part of the production test procedure.

For a bit higher volumes, there will probably be a custom-designed semi-automated tester anyway. In such cases, all you need to do is add some pads on the bottom of the board for pogo pins to connect to. The incremental cost to the tester is minimal, and the incremental cost to each board is very small. The largest per-unit cost in this case is probably the extra production time for programming the micro.

For hobbyist, just add the ICSP (In-Circuit Serial Programming) connector and be done with it. You'll need that for developing and debugging the firmware anyway. This is what I do most of the time for real commercial products too, when the volume is too small to justify a pogo-pin tester.

Here is a snippet of a schematic for a commercial product I'm working on right now:

Image alt text

P38 is the programming header. I generally use the same connector and pinout across products. This way I can plug the same programmer with the same interface cable into any board to program the micro. The most common connector I use for this purpose is a Molex 22-23-2051. These are cheap, widely available, and take relatively little space.

I do this so often the I have a special parts defined just for this purpose in Eagle. You can use them too. Install my Eagle Tools release from http://www.embedinc.com/pic/dload.htm and look around in the "connector" library for devices with "ICSP" in their name. As you can see above, this Eagle part includes the names of the lines each pin is supposed to be connected to. This makes it really easy to end up with the same pinout every time.

Note the resistors in series and capacitors to ground on the programming lines (PGC and PGD). These are low pass filters that slow down the edges a little when the signals are driven by the micro. Unfortunately, the standard Microchip cable puts PGC and PGD next to each other. Without the filters, there can be crosstalk, causing the communication to get out of sync and programming to fail. No, this is real. See my In-Circuit Serial Programming discussion for more information.

For this reason, my USBProg2 PIC programmer has a 6-pin connector for the programming lines. Only 5 pins are needed, but I added an additional ground pin between the programming clock and data lines to minimize crosstalk in ribbon cables. I still use the smaller 5-pin connector on boards. The two ground wires of the 6-wire ribbon cable are tied together right at the board and of the cable. I have made programming cables over 2 meters long that worked without any problems.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

1 comment thread

General comments (1 comment)

Sign up to answer this question »