So from the previously linked answer,
I think the most
interesting/beneficial things for me
would be the bullet about learning the
tools (compiler and linker), and
learning different styles of software
architecture (going from interrupt
based control loops to schedulers and
RTOSes)
Porting a small operating system to a new device could help you to understand schedulers and RTOSs. FreeRTOS is popular and well documented. eCos is another.
Writing a bootloader is a good way to get to grips with a linker as you'll want to divide up memory and flash into regions.
Another tip is to pick a completely new architecture or chip and build yourself a development board. Forcing yourself to start right from the beginning and look everything up in the datasheet is a good way to learn.
Explore Protothreads. Try writing the same programs in both a threaded and state machine style. Once you're done with Protothreads, write a real thread scheduler.
Makeshift pilot holes:
If you have to drill pads and vias without pilot holes, use a thumb-tack or other sharp tool to make an indentation as close to the center as you are able. (How I deal with poorly etched pilot holes!)
Alternative software:
FreePCB (Windows-only open source program) generates gerber files with pilot holes in the copper layers corresponding to the drill holes through vias and pads. The pilot holes are optional: you can enable them with a checkbox in the CAM file generation dialog.
In the same dialog, there is an input box where you can specify the pilot hole diameter. A separate command line utility called GerberRender, distributed with FreePCB, is used for generating raster images.
DIY Pilots via Image Manipulation
If I had to use PCB software that doesn't generate pilot holes, here is what I would do: I would set the through-hole size on all my parts to have the pilot hole diameter, about 10 to 15 mils. (Since I would be making the PCB myself, I wouldn't care that the holes are wrong; however, this would have to be fixed, obviously, if the PCB is later sent out to fab.) Then I would use the image generated from the drill file as a mask to create the pilot holes in the copper layer(s), using an image-processing program such as GIMP.
Suppose you have a pair of black and white images at identical pixel dimensions, one depicting a copper layer and the other drill holes, with the holes and copper being in black, over a white background. Here is how you can use GIMP to render the holes into the copper.
- Load the copper layer image and the drill file image as two layers by using GIMP's "Open as Layers" command in the File menu, which allows multiple images to be selected and loaded as the layers of a single GIMP image.
- Ensure that the drill layer is the top one of the two, moving it up using the green arrow buttons in the Layers dialog.
- Ensure you're switched to the drill layer by clicking on it in the Layers dialog.
- Invert the layer to create a negative. This is done in the Colors menu with the Invert command. Now the holes are white, on a black background.
In the Layer dialog, change the drill layer's Mode to "Lighten only".
At this point, you see both layers, with the white regions of the
drill layer creating white holes in the copper layer.
- Do a "Merge visible layers" in the layer dialog's context menu, or, equivalently, "Merge layer down" on the drill layer.
- Do an "Export to ..." to save the resulting image as your copper-with-pilots layer.
There is probably a way to script all this from the command line via the ImageMagick utility.
A more ambitious project would be to write an image processing tool or plugin which can scan through a regular drill layer image (with holes having various diameters), identify all the holes and generate a new image in which they are all replaced by holes having a fixed, smaller diameter. Such a filter would make it unnecessary to switch to custom footprints in the part library in order to get properly sized pilot holes.
Best Answer
There are Real Time extensions to UML that were popularized by a company whose name escapes me at the moment. I remember doing a paper on it several years ago. Bruce Powell Douglass wrote a few books on the subject of modeling embedded systems using UML, but his company is not the one I'm thinking of.
That said, to echo Wouter, there is nothing special about embedded software per se. I write embedded software every day for a system that runs on Pentium-class processors; UML is quite applicable. Also, remember that many aspects of control software have been added to UML over time: there is syntax for specifying synchronous or asynchronous events along with response time in Sequence Diagrams, Petri net type behavior can be found in Activity Diagrams, Statecharts model behavior even better than State Diagrams can, etc.
OTOH, a lot of people prefer to model embedded software using Structured Design and Dataflow concepts. It's all about the type of system you're designing and what works best.