IP04 and the Asterisk Appliance

A few people have asked me to compare the IP04 and the Digium Asterisk Appliance (AA).

  1. The architecture is very similar, a Blackfin connected to Silicon Labs line interface chips. For the record, both were developed by independent teams. BTW the hardware design is not rocket science – just plugging chips together. Most of the work is done by the uClinux and Asterisk software.
  2. The IP04 hardware design is open (free as in speech). Anyone is welcome to manufacture, sell, modify, improve. It has been developed by a community, for community reasons. The AA hardware design is closed.
  3. You are welcome to use the IP04 for non-Asterisk applications, for example Freeswitch, Yate, SER, Bayonne, Callweaver. It could even be used as a substitute for a PCI line interface card, e.g. a Ethernet channel bank.
  4. The IP04 uses Oslec software echo cancellation, the AA an Octasic hardware chip. The AA echo cancellation hardware adds $50 approx to the BOM (which translates to $150-$200 more on the street price) and is, well, closed. However it arguably has higher performance (at least today), and off loads cycles from the Blackfin. However we have plenty of spare cycles (like 90%) so why not do the echo cancellation in software for zero cost?
  5. The IP04 uses the BF532 rather than BF537. The BF537 is faster, has more on board RAM, and a built-in MAC. The BF532 is cheaper and can be hand loaded (important for a hackable design). This isn’t a significant difference in low density analog systems, as the CPU load is small.
  6. The Asterisk Appliance has WAN and LAN Ethernet ports (with a 4 port VLAN), the IP04 a single Ethernet port.
  7. There are some technical differences, for example the IP04 uses single port rather than 4 port modules, 256M on-board flash compared to 8M on the AA, the AA has a CF slot, the IP04 a MMC slot. The IP04 can be expanded to 8/12/etc ports, so no big differences in density.
  8. Both designs are beta at this stage, with no production hardware in general use. The current development hardware for the AA has a minimum retail of $2195.00. A Free telephony Project kit costs around $530 (starter kit STAMP motherboard). The suggested retail (AFAIK) for the AA will be $1000, the IP04 $400 (and falling).

Stop Press

I have just discovered a new entry to the Embedded Asterisk “Appliance” space, the TechnoCo Vdex 40. This Australian product has 4 FXO ports, uses a multiple ARM/DSP processor architecture and is sampling for US$695, with street price still TBD. Nice product guys – well done.

Stop Stop Press

Another Blackfin based Asterisk Appliance/IP04 type product has appeared, the Magiclink Asterisk Appliance. This looks similar in design to the AA and IP04, however has USB and CF ports. Quantity 100 pricing for 4 FXO ports is a low $299, which is great news. Good work Magiclink.

loans 2 html million bridge dollarscheck 2000 no credit loan2003 student loans rateapplication loan 2004 mortgagefinancing loan 2005 review car car24 equity home loans hourloan payday 36 refinance loan 25loans london mortgage 2nd2 federal 3 student loanscredit 3 report score loan andfor absoultely samsung free ringtones1000 words ringtonematter dont akon ringtonev4 6 converter ringtone6620 ringtone nokiaringtones agency mp3 for verizonalltel funny ringtonestreo palm ringtone 600 Mapaffirmations sexporn granny plus 70minneaplois minnesota adult toys sexpornstar africa32 flat tv direct analog viewof canal panama advantages1950 pornoamature scenes sex Mapbad loan credit $1000 andhour loan 1 unsecured2nd 125 loan value mortgageno credit check loans 20,000rate interest loans 4.5access servicing group loanloan accredited home problemsloans alabama car Map

Building an Embedded Asterisk PBX Part 3

The IP04 is a Four Port Embedded IP PBX that runs Asterisk. The hardware design is 100% open. I just built the first IP04 prototype (really built, as in soldered), and would like to tell you about it.

This post talks about the IP04 hardware, the bring up, an explosion (!).

Hot Solder

You know surface mount soldering is fun. Really fun. It’s a nice break from the thinking-oriented work I normally do, like DSP, programming, and fighting zillion level deep makefiles that are needed for embedded systems. There is just something about making stuff with your hands. It even looks nice at the end, you can hold it and show it off to your wife and kids. Of course they don’t actually care but you can still show them!

After building a BlackfinOne, I found the IP04 quite easy to put together. I would recommend it to anyone who wants a first surface mount or embedded Linux hardware project. It’s kind of amazing, but with a days work you can build (as in solder) your very own embedded Linux system.

Flux, a stereo microscope, and a good quality PCB really help make surface mount soldering a pleasure. Tip: I check each pin of the chips after soldering by attempting to wiggle it with a sewing needle.

So I had a very enjoyable day soldering the IP04 prototype under the stereo microscope. After loading the surface mount components I gave the board a “bath” to remove the flux residue. I actually put the PCB in a bowl of hot water and used a small brush to scrub that nasty conductive flux off (conductive flux residue caused me a lot of problems when building a BlackfinOne). After washing I soaked up excess water with paper towels then put it under a hot lamp to dry quickly.

Open Hardware Hacking

Curiously, hardware hacking is getting cheaper and easier. For example the tools for surface mount work are reasonably cheap (a soldering iron and stereo microscope), there is plenty of free CAD software, low cost PCB fabrication, and web based components stores like Digikey.

With the growth of open hardware projects, they are plenty of cool designs and people on line who can help you if you get stuck.

How the IP04 Works

Here is a block diagram of the IP04 hardware architecture:

You may also like to take a look at the IP04 schematic.

When power is applied, the Blackfin boot ROM starts reading from the little 256k SPI flash chip. The program it loads is called u-boot, a powerful boot loader that has been ported to the Blackfin by the Analog Devices Blackfin team. U-boot has a command line interface that lets you load other programs from flash or via Ethernet. In normal operation it automatically loads and executes the uClinux kernel.

NAND flash is used as the main storage for the IP04. NAND flash has the advantage of high density and low cost. It’s the same stuff that is used in your MP3 player, so prices have plummeted over recent years. However the Blackfin boot ROM can’t read the NAND flash directly, which is why we need the SPI flash chip and U-boot to support the start up process. Compared to many embedded linux systems, the IP04 requires a lot of flash storage (around 16M minimum) to store the Asterisk executable and audio prompts.

When the kernel boots it runs out of SDRAM, and the NAND flash is mapped to the root filesystem. We also use a portion of the SDRAM for temporary files, e.g. /tmp.

If you would like to learn more about IP-PBX design see the Resources section of the Free Telephony Project website.

An Explosion!

So it was time for the moment of truth. After a run of successful hardware projects I was feeling pretty confident, which of course angered the Gods of open hardware. I applied 12V and started poking about with my multimeter. About 3 seconds later – BANG!. A small mushroom cloud rises a few inches off the board and gently drifts across the bench. A nasty smell fills the air, along with a string of expletives that bring the family running.

“Dad, can you do it again?”, my 8 year old son asks! He was ejected from my office shortly afterwards.

I sniffed a few areas of the board to track down the general problem area. A peek through the microscope showed a capacitor had blown it’s guts out, the white fuzzy stuff on the left of this picture:

The problem was two capacitors had their labels swapped on the PCB silkscreen. This meant I had loaded a capacitor with a 6V rating where there should have been a 25V rated capacitor. When 12V was applied – the 6V rated capacitor expressed it’s displeasure!

Apart from that the remaining assembly and bring up went pretty smoothly. One mistake I made was forgetting to supply power to the Real Time Clock (RTC). This caused U-boot to stall when it started, waiting for the RTC clock to come up. Of course, when this bug appeared I had no idea if it was a hardware or software problem. So I had to hunt through various possibilities in “bug space”, for example sprinkling printfs through the U-boot code to find out where it was stalling. Unfortunately, each new load of software took 20 minutes to flash via the Igloo JTAG cable, so it was a slow process that took 2 minutes to fix once I found it.

I modified the u-boot and uClinux configuration a little from the BlackfinOne baseline due to minor differences between the two boards; for example the smaller SPI flash, one Ethernet port, and the use of NAND flash. This was fun – I learnt a lot about U-boot and the set up of NAND flash through the MTD driver. By this time I had u-boot running so I could download new images via Ethernet and test in a few seconds.

I was re-using tested building blocks from the BlackfinOne and 4fx designs so it all went smoothly. One week from initial power up uClinux was booting and Asterisk running with 4 analog ports. Rather than stressing over the little bugs and trying to race though I took my time and enjoyed the bring up process.

Finally, I lifted the handset on a telephone connected to the IP04 and there was the dial tone! Nice.

Automated Asterisk Load Testing

The Asterisk 1.4 GUI works although it isn’t stable at present on the IP04. Sometimes the GUI freezes and I can see some core dumps on the IP04 console. This could be a Blackfin specific issue, for example uClinux is more fussy about stack space than regular MMU-enabled Linux. Some more work required to sort this one out. In the mean time, vi and Asterisk conf files are OK with me!

I was keen to see how stable the new hardware was, so I used some scripts to load the PBX over a 12 hour period. Here is a block diagram of the test set up:

A simple shell script on the x86 Asterisk box:
# lotsofcalls.sh
# David Rowe 3 April 2007

rm -f /tmp/lotsofcalls.txt
touch /tmp/lotsofcalls.txt
rm -f /var/spool/asterisk/outgoing/callastfin.call
while [ 1 ]
cp callastfin.call /var/spool/asterisk/outgoing
sleep 60
calls=`expr 1 $calls`
echo $calls >> /tmp/lotsofcalls.txt

kicks off an outgoing IAX2/GSM call to the IP04 once every minute. The call makes FXS Port 4 ring, which is connected (via a phone cable) to FXO port 2. After a few rings FXO Port 2 answers and plays an IVR script for a few seconds, then hangs up. The analog phone connected to the x86 Asterisk box rings when the IP04 call connects. As long as this phone rings every minute I know the test is still running OK. I can also lift the phone when it rings, for example to make sure the audio quality is OK.

In practice I use a script to place two calls at the same time, so the total load is two IAX/GSM calls and 4 analog calls. I let this run for about 12 hours and the IP04 worked fine – 4000 calls were placed and the loadav was about 0.2 (10% of the Blackfins CPU). Much of the code is still unoptimised so this suggests we can go to much higher call loads in the future.

Anyway given that I was testing on hardware where the solder has barely cooled I was pretty happy.

Whats Next

There is still plenty to do, for example we have quite a few Astfin tickets that need working on. If anyone would like to help out please contact me or the Astfin team.

I am working with a manufacturer to put these designs into volume commercial production. The first batch of fully assembled production units will be available in mid 2007 for around $450:

In the mean time – if your feel like a cool project – you are welcome to build an IP04 yourself! Here is some more information on obtaining bare IP04 PCBs and FXS/FXO modules.

Update – Fully Assembled and Tested IP04s now Available

July 23, 2007: You can now buy your own IP04 from the Free Telephony Project on-line store. The store also stocks parts if you would like to assemble (as in solder) your own IP04. I have blogged on the Production IP04 in Part 4 of this series.


I stand on the shoulders of giants. I have tried to add just a little bit to their work. Thanks to the Astfin & BlackfinOne teams, uClinux, Analog Devices Blackfin team, and the Asterisk community. Thanks to Mike Taht for being my editor-in-chief for this post. Sorry if I forgot anybody.


IP04 home page
Buy an IP04 from the Free Telephony Project on-line store
IP04 Schematic, PCB, CPLD code, Errata, and more
Building an Embedded Asterisk PBX Part 1
Building an Embedded Asterisk PBX Part 2
Building an Embedded Asterisk PBX Part 4
Building a BlackfinOne
How to make your Blackfin fly Part 1
Open Source Echo Canceller Part 1
IP04 and the Asterisk Appliance

bonk advantages of loansloans afco autoneeds score loan home 518 creditsettlement loan ameriquestachieva sutdent loansmebane loan of 1st savings andamerican agcredit rates loanstudent loan acpe alaska Map

A $10 ATA

In October 2006 I made my way to Dharamsala, northern India, where I visited the Tibetan Technology Center, and in particular a guy named Yahel Ben-David.

You see I am interested in developing low cost open hardware technology that can help people in the developing world. Yahel and the team at Tibtec are using commodity routers to build low cost community wireless networks. To date about 3000 computers have been connected to the Internet by the Tibtec team. As these computers are often shared it is fair to say that about 30,000 people now have Internet access thanks to the Tibtec team.

Now I have been working on some open hardware/software for building low cost embedded IP-PBXes. I had an idea that my work might be helpful to Yahel and the people at Tibtec.

As we got to talking, a few interesting economic points came up. Yahel can buy a WRT54G type router for $50 and an ATA for about the same price, due to the miracle of mass production. In small quantities, my open hardware designs couldn’t get close to this, even by removing all margins and selling them at cost. Also, for many applications, just one or two FXS ports are required, rather than a full blown PBX for 4-8 analog ports.

(Note: I have since reworked the IP-PBX design so that it can be built for less that $100 in quantity, however that is another story for another blog post).

So after leaving India, in the back of my mind was the need for a very low cost way to connect a telephone to a router.

A few months passed.

Recently, I became aware of Air-Stream – a community wireless network that extends over my home city, Adelaide, South Australia. Air-stream uses very similar technology to Tibtec – low cost commodity routers, high gain antennas, and hacking. It occurred to me that a “killer application” for Air-stream would be a way to carry phone calls for free over the Adelaide metropolitan area (in Australia we pay 25 cents for each local call).

However once again, if Airstream users can connect with a $50 commodity router, it would be nice to find a low cost way to hook up a telephone.

AVR Microcontrollers and DSP

At about the same time I came across a few articles that got me thinking. One was USBtiny – a way to implement USB in software on a low cost Atmel AVR ATtiny microcontroller. In this design the little $1.50 micro gets interrupted by each USB bit at a rate of up to 10MHz! And I thought the Zaptel 1ms interrupts were bad. For certain applications this allows very low cost USB interfaces to be built, cheaper than typical custom USB interface chips. Hmmmmmmm.

I then stumbled across a fantastic Circuit Cellar article by Marco Carnut on an AVR Phone Recorder and Telephony Platform. This project uses a $5 Atmel AVR ATMega microcontroller. As well as recording telephone signals and communicating with a host PC, the AVR also finds time for some real time DSP (DTMF decoding). What was news to me was that these little chips have some DSP capability built in – for example a relatively fast 2 cycle multiply. These AVR chips also have a bunch of other features, such as built in flash, RAM and A/D D/A converters that seem to work OK for speech signals. They are essentially little “systems on a chip” – just add crystal and stir (well, program). Hmmmmmmm (again).

So the big question is, can we use these chips to build a $10 ATA? Well, I think this might just be possible. To see why, lets first take a look at the design of a typical ATA.

ATA Design 101

The figure below shows the design of a typical ATA. Quite a lot going on. Typically the software components are implemented on some sort of fairly fast (200MHz, several MB of RAM and Flash) microcontroller that can run 1 or two channels of G729 and also support the SIP stack and perhaps a basic operating system.

The Analog FXS Interface is implemented with a chip set from companies like Silicon Labs. This chip set generates DC “battery” voltage to run the phone (e.g. 48VDC), 90Vrms ring signal, provides AC analog termination (e.g. 600 ohms impedance) and a hybrid – a gadget that separates and combines the transmit and receive voltages on the two phone wires. I have written an introduction to hybrids in an earlier post on echo cancellers.

Here is an equivalent electrical model of the Analog FXS Interface connected to a phone (click on the image for a larger version):

There are two paths – DC and AC. The DC path flows through Vbatt to Rdc and provides current to run the phone. Cblock prevents DC entering the AC path, and Ldc prevents and AC entering the DC path. This isolation allows the paths to have different impedances, for example a 200 ohm DC feed resistance Vbatt and a 600 ohm AC impedance (Zo an Zl) for audio signals.

The AC path flows from Vo through Zo and Zl (the audio signal the ATA send to the phone). In the other direction the audio from the phone is the AC path flowing from Vl through Zl and Zo. Zl and Zo are typically the “600 ohms” impedance you hear about when people talk about phone lines.

To ring the phone we switch in a low frequency (say 20Hz), high voltage ring signal Vring. When the phone answers, it closes the hook switch, which is detected by the Hook Detector.

The hybrid (not illustrated) separates Vo from Vl. It usually doesn’t get it quite right, which is where the echo canceller comes in to remove any transmit echo (residual Vo) from the received signal.

In a real world design, the actual parts Cblock, Ldc etc don’t really exist, these days electrical equivalents are all built into the chip set. For example Ldc is often implemented with transistors and a capacitor in a Gyrator circuit, as that is cheaper than using a large inductor. However this electrical model is still pretty accurate, and represents an equivalent circuit that is useful for analysis.

$10 ATA Design

So here is the proposed design of the $10 ATA:

The key points in the design are:

  1. Use a low cost ($3 in modest volume) AVR microcontroller to interface between the phone and the USB port of the router. Alternatively we can use RS232 which most routers support with slight modifications. Ethernet is also possible but costs more as we need an Ethernet chip. With RS232 it may even be possible to remove the RS232 line drivers (saving additional cost) if the line is short. Or perhaps use low cost analog circuit for the line driver alternative (given we have 12V available).
  2. Use the AVRs DSP capability to do DTMF detection.
  3. The built in RS232 UART can run at 115 kbit/s. We require approximately 64 kbit/s in either direction, so RS232 should be acceptable, even with the overhead for start and stop bits. A small amount of overhead is also required for signalling (hook status, DTMF), however this is just a few bytes per second.
  4. The AVR can also be used to implement the switch-mode power supply needed to generate a ring voltage in software (DC-DC converter). If this is not possible, we can connect a buzzer/beeper to the AVR. Instead of the phone ringing, we beep the (nearby) ATA. Usually ATAs are located close to the phone.
  5. We use the AVRs built in A/D and D/A to convert the analog signal.
  6. Use a DC “battery” voltage of 12VDC rather than 48VDC to run the phone – this is enough if the cable is only a few meters, phone only require about 6V, the 48VDC is there to overcome resistive losses on long cables.
  7. The router runs Asterisk (common on WRT54G-class routers). Asterisk talks to the ATA via USB/RS232 using a simple channel driver, for example something similar to chan_oss. The ATA is really not much more than a sound blaster – we push most of the processing to the router, which has a few more spare MIPS.
  8. Handle echo cancellation using echo training and fixed coefficients for the duration of the call. This is a low-MIPS approach that we can get away with due to the special nature of FXS lines. More on this below.
  9. Use a very simple hybrid (just an op-amp), and let the echo canceller do most of the work in separating the transmit and receive signals. We essentially move the hybrid from hardware into software, where it is free to implement.

Echo Cancellation

An FXS port is a special, rather well behaved case which fortunately is kind to echo cancellers. Cable runs are generally short (a few meters of cable) and the impedance match quite close to the ideal. This means only a short tail is required, perhaps only 8ms (64 taps).

Some other simplifications are possible. The echo path is unlikely to change during a call, so we can fix the echo canceller taps for the duration of the call. This removes about two thirds of the MIPS which are normally required to support continuous adaption.

Assuming fixed coefficients and a 64 tap FIR filter, the number of operations is 64 taps x 8000 samples/second x 5 ops/filter tap = 2.56 MIPS. This is acceptable on a 10-20 MIPS AVR. A specialised DSP chip would require just 1 operation per filter tap, however I am estimating 5 operations/filter tap for the AVR.

I have tested the fixed coefficient technique on FXS ports in the past and it works quite well when teamed with a simple echo suppressor to remove the small amount of residual echo. The filter taps can be calculated when the phone is taken off hook by sending an impulse down the line. This is the same algorithm as used by the Zaptel echo canceller when in “echotrain” mode.


There are several risks with the proposed $10 ATA design. Here is my current risk list:

  1. Speech quality through AVR A/D and D/A. What sort of anti-aliasing filters and reconstruction filter should we use (if any)? Should we over sample to reduce analog filtering requirements and possibly increase effective resolution e.g. via noise shaping in DSP? Will the A/D and D/A resolution deliver reasonable speech quality? Will we require some AGC to cope with the limited dynamic range of The A/D and D/A? Do we use companded (mulaw) over the RS232/USB link or linear?
  2. Will we run out of MIPS on the AVR or router?
  3. The AVR based DC-DC converter for ring generation. I am not familiar with DC-DC converters, however the plan is to use a similar topology to the Silicon Labs 3210, i.e. use the AVR to generate PWM that drives a switching transistor, with several safety cut outs. An alternative is to use a simple beeper, with tones generated by the AVR. This would be cheaper and faster to develop, but would only work when the ATA was close to the telephone.

An RS232 Phone

In many parts of the world analog phones are very cheap, for example in Vietnam they are about $2. This is one reason why a low cost ATA makes so much sense compared to even the cheapest SIP phone.

However there is another approach. We could use a $2 phone case, keypad and handset and put our own electronics inside. Sort of make our own “IP phone”. However it talks RS232 rather than SIP. The advantage of this approach is that we avoid most of the hassle in an ATA, i.e. dealing with the FXS interface (ring voltages, echo, 2 to four wire conversion). The microcontroller could be simpler, too.

So I thought I would mention the option of modifying a regular analog phone. It might just be cheaper and certainly less development effort. Perhaps both the $10 ATA and RS232 phone could be developed in parallel, as they share many subsystems.

Development Plan

I suggest that a staged approach to implementation be performed. We should attack the risky areas first to prove the feasibility. Here are the milestones:

  1. Milestone 1: Implement a RS232 sound blaster. Use the AVR A/D to sample speech from a phone handset, and play back speech to the handset. Connect to the router via RS232. Modify chan_oss to allow speech I/O from the RS232 port. Do not implement DTMF, echo can, or ringing power supply just yet. Control from the Asterisk CLI. The idea of this milestone is to confirm that the AVR can handle speech traffic via RS232 and that it sounds OK when teamed with Asterisk.
  2. Milestone 2: Add DTMF and echo cancellation, and implement the analog hybrid. Use a beeper for ringing, no DC-DC converter just yet. At this point we have a design that can be used in a $10 ATA of a RS232 phone.
  3. Milestone 3: Develop the ringing DC-DC converter and integrate.

Interested in Working on a $10 ATA?

I would really appreciate some help with this project, as I am kinda busy with a bunch of other stuff. People with experience or just plain interested in OpenWRT, Asterisk, channel drivers, AVR, and analog hardware development would be very welcome. In the mean time I will work on it on a part time basis.

The cool thing about this project is that the cost of entry is very low (by definition) and the hardware can be developed using plug-in bread board (no soldering required). This work also has the potential to help millions of people in the developing world get a telephone, so it is a very worthwhile project.

Please join our low cost ATA mailing list or contact David Rowe.

Ideas for Further Work

This work could be extended to multiple FXS ports with a more powerful DSP. For example if this design works, then a a $14 (Quantity 1 price) BF531 DSP chip could be used rather than a AVR. The Blackfin can run programs from internal memory requiring only a $1 SPI flash chip to boot. This DSP could handle multiple channels and possibly implement GSM or G729 compression as well. Perhaps a 8 channel FXS channel bank can be built this way for $30. This could serve a remote village, connected via the router using wireless Internet.

The $10 price point is for low volume. Imagine the possibilities given volume production. There are billions of people who need a telephone, and they have some of the cheapest labour on the planet. The circuit is simple and can be assembled by just about anyone. With a market this size, custom silicon is a possibility, which would allow us to further integrate functions into the chip.

So the possibilities for price reduction are endless. Ultimately the electronics is just sand, a little labour, and an open design.


$10 ATA Part 2

sexxx africa picsamiture cupels teensale for porn 1980 1970 moviesinformation addiction cybersexporn amature gymnast xxxvideo sex titmus abiaba teenagers withamerican daydreams porn Mapactrices pornoamateaur pornsenior sex amateur videosa transexual am itgp teen winters abby naturalmotel sex amatureteen age reason models ofbusiness process analysis airline Maploan about debt consolidationloan site add car5 5 loan autoloan credit a badmortgage home loans accessbankruptcy loans 13 studentbusiness small 26 loanloan personal hours 24 MapOrgasmus Soundclip WeiblicheGalerie Mütter Fett hässlichtranny Video Fuck TS sexFrauen Behaarte nackt FotoSharing-Swapping Frau Hahnereiteens petite YouhngSex Interrassisch Geheimnis dunkles Hahnerei GeschichtenBrustwarzen Nippel Laktierenden laktierenden Folter, Map

Improved Dragging on gEDA PCB

Over the past 12 months I have done quite a bit of design work with gEDA PCB, including some telephony designs and the BlackfinOne project.

During this work I developed an itch that needs scratching – I would like to improve the way tracks are dragged in PCB.

At present, when dragging tracks 45 degree angles are not maintained. This means that after the drag operation a lot of manual clean up is required. This consumes a lot of time, especially near the end of a board layout where moving one track may mean moving a bunch of other things out of the way. This sort of manual rework is something the computer should be able to do for me. In fact many (expensive and proprietary) PCB layout programs do just this sort of thing automatically.

Here is an example of the proposed change. Each stage is annotated with text:

So about a week ago I downloaded the PCB source and started looking into the proposed changes. Actually this was a lot of fun for me – I usually do embedded and DSP work so I found working on a x86 C application quite refreshing. The development environment is much nicer and my head doesn’t hurt as much!

Dragging Tracks

First I messed around with PCB to try and make dragging (moving) lines in rubber band mode a little easier to use, here is a video that demonstrates where I am at.

The first drag is how PCB currently works. I then switch off “All Directions Rubber Band”, which enables the new mode I am working on. Note how dragging horizontal and vertical lines maintains the 45 degree angles. This can save a lot of time when editing tracks that is currently spent in fiddly manual rework (I speak from experience).

BTW I really like the PCB source, lots of clean intuitive code. Thanks to all the various authors for their great work.

I find the process of discovery when working on new code exciting (sorry – that’s a very Geeky thing to say!). I first do a lot of ‘grep’-ing and ‘more’-ing, then sprinkle printfs here and there so I can work out what bit of code I need to work on. When I finally start to “get it” it’s a real “AH HA” experience :-) The first mod that you make that actually does something is very rewarding – you have grappled with the beast and have it under control. Well, sort of. Until the next bug at least.

Anyway the current status is that it works OK for vertical and horizontal lines (tracks), but doesn’t handle dragging components or diagonal lines yet. So it’s still early days.

Object Dragging

Of course it didn’t stop there. As the track dragging was working well I dreamed up a way I could drag an object (component) and have the tracks follow at nice 45 degrees. This required different code to dragging one track segment connected to another.

The prototype object-dragging sometimes works quite well, here is the latest video showing a mixture of components being dragged about.

Sometimes it works like magic.

It also has many cases where it makes a real mess :-) However I think its heading in the right direction, I am now going to test these dragging mods on some real PCB work for the next few weeks and see how it goes.

Trying it Out

I have developed some patches against the latest (at the time of writing) PCB snapshot: pcb-20070208p1. It’s not particularly stable and has been known to segfault at embarrassing times. Use it at your own risk!

Get a copy of pcb-20070208p1.tar.gz from Sourceforge (http://pcb.sourceforge.net), then:
$ wget http://www.rowetel.com/downloads/pcb-0.1.diff.tgz
$ tar xvzf pcb-20070208p1.tar.gz
$ tar xvzf pcb-0.1.diff.tgz
$ patch -p0 < pcb-0.1.diff
$ cd pcb-20070208p1
$ ./configure && make
$ cd src
$ /pcbtest.sh t.pcb&

The PCB files t1.pcb and t2.pcb are the demo files I have been using
for testing.

You can get a feel for where it works and the current limitations, like
dragging diagonal lines, and dragging horizontal or vertical lines too

Further Work

This work is far from finished, here some TODOs:

  • Ability drag diagonal lines and maintain 45 degrees.
  • Ability to drag points and maintain 45 degrees.
  • Sensible thing should happen when dragging past ends.
  • Handling T junctions, dragging cross should drag stem.
  • Why don’t selections rubber band drag?

First Impressions

After I wrote the post above I worked until 2:30am on my new IP04 four port IP-PBX design. I was working on routing the data bus which is quite tight as it needs to be kept short (133MHz bus on a 2 layer board):

My first impressions of the new features:

  • If I try to move a complex component with many tracks attached I get a segfault. Need to run PCB inside gdb to check this out. Autosave is my friend, but it would be nice if it saved a sequence of files (actually I think PCB did do this in past versions).
  • The track drag doesn’t do sensible things when you drag past the point where attached tracks go to zero length, this limits its usefulness. They should flip around and go in the other direction (this is hard to explain, sorry).
  • In the image above imagine trying to squeeze a new track right in the middle of the area to the left of C21. At the moment you need to delete and redraw lots of tracks. What I really need is a feature to push tracks out of the way without shorting any tracks. For example dragging one track should move all the others out of the way, intelligently rerouting as I drag.
  • The component dragging chose dumb positions (like on top of other tracks) most of the time in practice. In many cases it was easier to delete and re-draw. Sigh.
  • Overall they new routines were only useful in about 10% of the routing I did. I still find I am doing fiddly manual rip up and reroute most of the time. When they did work it was like magic – it’s far quicker to drag one track then delete three tracks and re-draw them.

So still plenty to do to make this work truly useful. It’s a humbling experience to use what you code, especially after a solid week of working on it :-) Anyway, now that I know a little about the PCB code I am getting lots of ideas on how to make these features truly useful. Thinking about coding and more itch-scratching while I lay out this PCB!

Building a BlackfinOne

Over the past week I have been assembling, debugging and testing my own BlackfinOne board:

During this time I have had a lot of help from the BlackfinOne community, in particular via ongoing chat sessions with Wojtek (pronounced Voycheck) Tryc. Yesterday, I booted uClinux on hardware that I had helped design, soldered and debugged myself. A tremendously satisfying experience.

Building hardware is a bit like software – you go quickly through stages of construction; get stuck for a day or so on a tough bug; then rapidly scream through construction again until you hit the next bug. By documenting some of my experiences I hope I can help other people with similar projects.

The BlackfinOne

The BlackfinOne is a uClinux board based on the Blackfin DSP/RISC processor. There are several features of the BlackfinOne project that make it a great project for hackers:

  1. The design is open as in GPL. Free as in freedom/libre. Anyone can use, re-use, and modify the design, just like open source software.
  2. The BlackfinOne has been designed using the gEDA open source CAD tools. This means the design can be edited without needing expensive proprietary CAD software.
  3. Quite remarkably, it is implemented (and runs well) on a two layer PCB. To run a high speed digital design (it has a 400MHz clock and 133MHz bus) on a two layer board is generally regarded as impossible. Standard engineering practice says that you must have ground plane layers to ensure signal integrity and to make routing the PCB possible. For example the Blackfin STAMP designs uses 8 layers. The trick that the original designers (Ivan Danov and Dimitar Penev) used was to place the high speed SDRAM immediately behind the Blackfin chip, on the opposite side of the PCB. This minimises the length of the nets, ensuring signal integrity despite the absence of a continuous ground plane. Using two layers makes low quantity fabrication of the PCB cheap and easy for hackers compared to a multilayer PCB.
  4. A non-BGA version of the Blackfin was used to make soldering easy for hackers.
  5. It is based around the Blackfin community (sponsored by Analog Devices, the makers of the Blackfin chip) which has very good uClinux support and a range of open hardware building blocks (such as USB and other interfaces) for the Blackfin.

The initial BlackfinOne V1.0 design (by Ivan and Dimitar) first appeared in mid 2006. This design had SDRAM, Flash, and serial support. I was interested in using it as a DSP motherboard for my telephony work so I (along with several other people) helped add dual Ethernet ports and a USB port to create the BlackfinOne V2.0. Many other people (both commercial companies and private developers) have also contributed to the hardware and software side.

Several BlackfinOne V2.0 boards have now been made and brought to life by people all over the world. For the remainder of this post, when I say BlackfinOne (or bf1 for short) I mean BlackfinOne V2.0.

The schematics for the bf1 are useful to understand the rest of this post.

Building an Igloo JTAG cable

To bring up the BlackfinOne (for example to flash the boot loader) a JTAG cable is required. I built mine using some spare parts and a spare PCB I had laying around. I built a copy of the Igloo JTAG cable. My Igloo is not a shining example of hardware construction:

By the way I obtain the 3.3V power for the cable from the board being tested/flashed, rather than using the 5V to 3.3V regulator suggested in the Igloo design. A nicer version of the same Igloo circuit was constructed by Wojtek (pronounced Voycheck) Tryc:

I tested my Igloo using a BF533 STAMP board. The idea was to test the unknown hardware (my JTAG cable) using known working hardware (the STAMP). To drive the cable I used a version of the jtagprog software that has been modified slightly for the BF532 processor and BlackfinOne platforms.

It is important to use the CVS version of the jtagprog software as this has been modified to work with the latest versions of the BF532 chip. If you use the non-CVS version you may get a “stepping error”, which means the software doesn’t recognise this version of the BF532 silicon.

OK, so I tested the cable on a BF533 STAMP board and it seemed to work OK:
jtag> cable parallel 0x378 IGLOO
Initializing Excelpoint IGLOO JTAG Cable on parallel port at 0x378
jtag> detect
IR length: 5
Chain length: 1
Device Id: 00110010011110100101000011001011
Manufacturer: Analog Devices
Part: BF533
Stepping: 3
Filename: /usr/local/share/jtag/analog/bf533/bf533
jtag> initbus bf533_stamp
jtag> detectflash 0x2000000

The last command “detectflash” gave me lots of information on the STAMPs flash chip. As a further test I also used the cable to re-flash a BF533 STAMP with a new version of u-boot. This proved that despite the rough construction my cable was OK (thanks Wojtek for this suggestion).

Other JTAG cables can be used as well, for example other developers have successfully used the JTAGblue cable which emulates very popular Xilinx Parallel – III.

For reference here is an example of a jtag session from a working BlackfinOne. However it took me a while to get that far, as described below!

Tools and Tips for Surface Mount Assembly

The BlackfinOne uses some fine pitch surface mount chips and resistors and capacitors in the 0603 size range. So you need to think a little bit about assembly.

To load my BlackfinOne I used a stereo microscope like this one in this picture (being used by my wife Rosemary whose brief geeky phase is regretfully now over):

I bought mine new for about $700 but there are very nice ones available on e-bay for about $100 up. A much cheaper alternative is an illuminated magnifier:

But trust me – a stereo microscope will change your (soldering) life once your buy one, it really is worth the investment. My eyes aren’t that great but I can work all day under the microscope with no problems or eyestrain. Mine is variable zoom 10 to 40x but I find even 10 x is just a bit too much and I never use the variable zoom. So I suggest fixed magnification in the 5 – 7x range is just right, however it’s a personal choice.

Wojtek bought this microscope for around US$100. He finds the fixed 15x magnification perfect for him:

If you can, get a microscope that has circular illumination all around the objective lens. Mine just illuminates from one direction which gives me shadows so I have to rotate the work a lot. For US$45 Wojtek found this great LED based circular light that clamps onto his microscope:

Here is a view through the microscope of one edge of the Blackfin chip. A sewing needle is in the picture for comparison.

Here is a similar image from Wojtek, through his microscope. You can just see how much fun we are having with the toys we bought for this project!

I found Darrell Harmon’s notes on surface mount soldering very useful. I bought the tweezers and flux that he recommends from Digikey and also strongly recommend them. The flux makes a very big difference in surface mount work, I have never really needed flux previously in through hole work. The flux really makes the solder “leap” onto the parts being soldered.

I also use and recommend the same procedure Darrel suggests for soldering 0603 parts; blob of solder on one pad, then slide the part in with the tweezers. Thanks Darrell.

Wojtek has also done some research on soldering irons, from a recent email:

There is 2 leaders: the Hako 936 and Metcal PS-800. The Metcal is very small, light (!) and reliable. The tips are hot in just few seconds, and are available in variety of sizes and temperatures. For most I use 650 tips, which are designated for non-RoHS components, for ground planes and headers, I use 750 – 1.5mm tip which makes it much easier (750 is RoHS temperature). The Metcal does not have a dial to change a temperature, you change it by replacing tips (2 seconds, pull and push operation). The Metcal is available from DigiKey at very competitive price.

Flux Removal is Very Important

As Darrell notes that Digikey flux is conductive, so you really need to get it all off ASAP after soldering or it will cause problems. For example I added some flux before soldering a 10M resistor (part of the bf1 clock circuit). After soldering, the resistance across the resistor measured only 340k! Some vigorous scrubbing with the flux remover and brush fixed it, and the 10M resistor once again measured as 10M. In one or two cases I have even had to remove parts as the flux was trapped underneath and not easily removed.

I use a spray can of solvent with a little brush attached to the nozzle for flux removal. Wojtek actually gave his BlackfinOne a bath (full immersion in water) with good results. Wojtek also uses this flux remover:

Both Wojtek and I have fixed many problems that were caused by flux left on the board. So Scrub-Scrub-Scrub that flux away!

From Wojtek:

It is critical to remove flux as soon as soldering is finished. Different methods could be used, solvents and a water bath both work great. But leaving flux on PCB for hours or days could potentially affect a board in a very negative way (possible even ruining it) – this stuff contains acid and is corrosive!

Initial Assembly and Smoke Test

I started with a bare PCB board, kindly supplied by Jeff Knighton:

I first loaded all the surface mount passives, then Blackfin chip, SDRAM, Flash and other chips. By loading the surface mount parts first the board was nice and flat and so easy to work with, especially under the microscope I use for surface mount parts. I loaded the large and bulky through hole passives last, as they prevent the board from sitting flat, hindering surface mount work a little.

My approach was to load various sections of the board progressively. For example I first started with the CPU and memory but left the Ethernet and USB ports unloaded for the initial tests. In hindsight I am not sure if this is a good idea, it is easy to miss something this way (like a pull up resistor you didn’t think you needed at this stage of construction).

If you are loading a V2.0.0 PCB it is important to read and fix BlackfinOne PCB Errors, this only takes about 10 minutes. These problems will be fixed on later PCBs.

After loading the CPU/memory section of the board here are the initial “smoke test” steps I when through:

  1. I checked my parts orientation against the reference photos of the BlackfinOne, for example I made sure that the writing on my chips faced the same way as the photos. Especially that damn expensive 64M SD-RAM chip.
  2. Before powering up I checked the resistance between the 3.3V rail and ground. About 300 ohms, which seemed OK. I would have been worried about a dead short.
  3. The next step was to apply power and sniff for that familiar smell of molten silicon. I used a variable power supply first with the current limit set to 100mA. Just in case I had done something stupid (a common occurrence). Mmm, no smell. Feel the top of all chips, no burnt fingers. Excellent. A better start than most projects.
  4. I measured the 3.3V rail to make sure the switching power supply came up OK. Check.
  5. Measured the 1.2V rail – this was present which proved that the Blackfin chip was doing something, as the Blackfin contains the switching power supply circuit for the 1.2V rail.
  6. With the scope I checked that the 10MHz system clock was present. Check, another sign of Blackfin life.
  7. Check reset line is H. Ooops, it’s stuck L. That means the system will be held in reset forever!

I took me a couple of hours to find the reset problem. The capacitor C53 that sets the duration of the reset pulse wasn’t fully charging due to some residual flux on the board. I gave the reset part of the board a good scrub with the solvent and reset started working OK.

Programming the CPLD was fairly straight forward – I used the Verilog file bf1_cpld.vl from the hw-0.1 CVS repository. This needed to be renamed to bf1_cpld.v for my Xilinx synthesis tools to understand it and don’t forget to include the pin locking file bf1_cpld.ucf when you synthesise the design. Free (but not open) synthesis tools are available from Xilinx for Windows or Linux. I used an ancient Windows version and a serial JTAG cable to program the CPLD.

To save time, you are welcome to use my xlinx_bf1.jed file, just program the CPLD using your Xilinx JTAG cable.

Flash Problems

The next step was to connect the JTAG cable to my BF532 and try to flash the board. This is a “nervous” step – it’s the first time you actually get to see if the Blackfin chip is responding via the JTAG port. It’s also where you find out if you have soldered any memory chips on backwards.

The jtag tools detected the BF532 OK:
jtag> detect
IR length: 5
Chain length: 1
Device Id: 01010010011110100101000011001011
Manufacturer: Analog Devices
Part: BF533
Stepping: 5
Filename: /usr/local/share/jtag/analog/bf533/bf533

Note that the BF532 is detected as a BF533. This doesn’t seem to matter in practice.

However when I tried the next few steps:
jtag> initbus bf532_bf1
jtag> detectflash 0x2000000

It couldn’t find the flash chip.

My first suspicion was the CPLD, maybe I had messed up something like the pin locking and the control signals like AOE and FLASH_CS weren’t getting through to the flash chip. So I checked the control signals by watching them on the scope while I tried to read words to the flash:
jtag> peek 0x20000000
The signals were asserted when I did the read which suggested the CPLD was OK.

I then checked out the flash data sheet to work out how it should be responding. The flash chips have state machines built in, you can send commands to them and they respond in certain ways. One of the commands can tell you all about the flash chip. This is what JTAG tries to send when you run the “detectflash” command.

You can generate these commands and read response to the flash chip using the jtag peek/poke commands. For example on the BF533:
jtag> poke 0x20000055 0x98
jtag> peek 0x20000020
bus_read(0x20000020) = 0x00000051 (81)

Writing 0x98 to 0x55 on the chip (mapped to 0x20000050 on the bf1) puts the chip into “common flash interface” mode. In this mode, address 0x20 should always return 0x51 (the letter Q in ASCII). This is a good way to test if the Blackfin is talking to the Flash chip OK.

The same flash command/response on the bf1 showed just 0xff responses, which suggested either the command wasn’t getting through, or something was wrong with reading the response. I had already checked the control signals, so the next step was to check the address and data bus. Damn. This meant 32 nets to manually check.

To check the electrical connections of each net I used two methods:

  1. Under the microscope, I applied gentle pressure to each pin with a sewing needle. If the pin moved when I applied pressure, it would indicate a bad solder joint. This check didn’t find any problems.
  2. I then tested the continuity of every solder joint on the major chips using my multimeter. I placed one probe on the top of each pin, and the other on the pad it was soldered too. This is tricky to do on fine pitched pins, so I improvised some fine tipped probes (see below)!

While I was checking some pins on the SDRAM I accidentally touched two adjacent pins (pins 1 and 2) and my multimeter went “beep”, indicating a short. Hmmm, that doesn’t look right. Turns out that the D0 net was shorted to VCC, which was why the flash chip wasn’t responding. Any commands were being mangled as D0 was stuck H.

I spent an hour trying to work out why. It could be a soldering error or a PCB fault. However the track in question lives mainly under the the Blackfin and SDRAM so there was no way to check it visually without removing these chips, something I don’t have the tools for.

I used my multimeter to measure the resistance of the short. It was 0.4 ohms between VCC and D0 near the SDRAM, but 0.8 ohms between VCC and D0 on the flash chip. This suggests the short was nearer the SDRAM, right where I couldn’t get to it.

Fun with Burning Out Shorts

One fun technique I tried was to burn out the short. I have used this technique before on production PCBs that have shorts. You apply a high current (Amps), low voltage (say 0.5-1V) across the short and try to burn it out. Literally. You sometimes even hear a nice crack. It is safe for the logic chips as the low voltage means they won’t conduct any significant currents. It works best with shorts that measure a few ohms. Small enough to pass lots of current so they get hot, but larger than the parts of the track you want to keep. Too small and you risk burning out the wanted part of the track. To large and it won’t get hot enough.

Anyway, it didn’t work this time, the short passed 3A happily and I wasn’t going to risk going higher in case I vaporised the whole D0 net! So I cut out the offending parts of the D0 net and replaced them with some fine wire. Ugly, but when I fired up jtag again and there was my flash chip! Whew. Problem fixed after a day bug hunting. On to the next one.

Bug Hunts and the Geeky Mindset

If all the above sounds very cool and logical rest assured it wasn’t.

When you are in the middle of a bug hunt two things happen.

The first: the logic centres of your brain shut down. You don’t think straight. You bounce from one theory to another.

The second: you don’t want to work on anything else. You get obsessed and can’t leave it alone. Worse, doing anything else is impossible. Intense bug hunts lead to late nights, neglect of significant others, no exercise, fatigue and a further dip in intellect.

Despite all that, I really enjoy a good bug hunt. When you come through at the end, the satisfaction is supreme. And you always end up learning lots along the way that comes in useful later. Call me a geek, call me a nerd, or call my wife and commiserate with her.

Flashing problems

This was an strange one. Now that jtag could actually see my flash chip I tried to flash the chip:
jtag> cable parallel 0x378 IGLOO
jtag> detect
Jtag> initbus bf532_bf1
jtag> detectflash 0x20000000
jtag> flashmem 0x20000000 /path/to/u-boot.bin

However I kept getting verify errors. Whole sectors of the flash (each sector is 64k long) were not being written. I tried a few things like checking the JTAG signals for ringing (they were OK) and shortening the JTAG cables just in case I has signal integrity problems like ringing on the JTAG clock signal. Still verify errors.

Each attempt was very time consuming as flashing via the JTAG is slow, it takes about 20 minutes to flash the 128k u-boot program.

I was in chat contact with Wojtek at this time and he suggested I try the Igloo JTAG cable on a STAMP board. So I tried flashing u-boot onto a BF533 STAMP and it worked fine. U-boot even ran OK on the STAMP. This was a good test as it confirmed my Igloo was OK. One variable removed from the bug hunt.

So then back to the bf1 board. Suddenly it is now flashing OK! Despite nothing changing. So I tried it three more times and each time it flashed and verified OK. So I don’t know. It doesn’t always boil down to logical cause and effect. Sometimes stuff just happens. So I “declared victory” and moved on.

Now I had u-boot starting up OK when I powered up – I could interact via the serial port. This was pretty exciting, as it proved that all the major components – Blackfin, flash, SDRAM, and CPLD were working fine. The bf1 was talking to me. So I powered down and soldered on all the parts for one Ethernet port. The idea was to use Ethernet and tftp to download a uClinux image.

Torpedoed by U-Boot and Ethernet

After loading the Ethernet parts I booted into u-boot and tried to tftp. Something was happening, but there were lots of tftp time out “T” symbols and only the occasional OK packet. Ping worked OK from u-boot, but not tftp or dhcp.

I did some packet sniffing on my host and found out that packets were being received OK from the bf1, but it looked like anything the host sent back was being ignored by the bf1. So I checked the rx side wiring of the Ethernet port but couldn’t find any problems. During tftp attempts I could also see what looked like valid Ethernet signals (1Vpp nice looking data signals) on the tx and rx nets at the RJ45 connector.

I was using a binary u-boot image that I found on the bf1 site. I wanted a way to inspect packets being received and that meant I needed to compile u-boot from source. So I checked out the CVS version of u-boot for the BlackfinOne and tried to compile. However I kept getting linker errors. This is very frustrating, you are trying to fix one bug and keep getting caught by others! Such is life.

Eventually a post to the bf1 forum solved the linker problem – there was a recent bf1 u-boot fix just checked into CVS. Now I could compile u-boot and start inserting some test code. So I flashed the CVS version of u-boot and hit another problem – now Ethernet wouldn’t work at all (not even ping) and the MAC address was always a string of 0x00s. This was a step backwards from the previous binary where the MAC was set up OK and at least ping worked!

One other problem was slowing me down – that 20 minute time it took to flash u-boot every time I wanted to add a printf to test something. This made debugging very tedious and frustrating. It felt like I was getting no where fast.

One thing I did discover is that it is a good idea to erase the flash sectors before flashing using jtag, just to make sure:
jtag> eraseflash 0x20000000 2
When I didn’t perform this step I sometimes found I was booting a previous version of u-boot, not the one I had just flashed!

After a break I thought of another idea to help speed up debugging. I used a trick I read about in the Blackfin u-boot documentation – you can download a new u-boot image into SDRAM using u-boot, then execute the new u-boot image using the “go” command. As I didn’t have Ethernet working I used ymodem to download u-boot images to SDRAM. This worked really well and enabled me to test and debug in 2 minute cycles – much faster.

Note that this technique doesn’t work for all u-boot images, for example when I tried to run a u-boot image configured for 64M RAM with a 32M u-boot it failed and I needed to reflash instead. Some people have reported that ymodem doesn’t work for them, they use the kermit protocol instead.

Two iterations later I had the bug nailed. The problem was that u-boot was trying to read the MAC from the little serial EEPROM used by the Ethernet chip. However I hadn’t loaded this chip, and even if I had it would be un-programmed and the MAC would be all 0xff’s. So after some reading and grepping of the u-boot source I changed this line in include/configs/bf1.h from:
This allows the MAC to be set by the values compiled into bf1.h, or the environment variables used by u-boot. If this option is defined then the eeprom contents always overrides the MAC from the environment.

Suddenly my u-boot Ethernet was up and downloading images via tftp just fine. Cool. After 1.5 days of chasing this bug it never looked so good to see those tftp “*” symbols flashing across the screen as an image was downloaded. I also learnt a lot about u-boot and how Ethernet drivers work which was interesting.

So now we are getting real close – time to build a uClinux image!

Building uClinux for the BlackfinOne

To create a uClinux-dist for the BlackfinOne I copied all of the files in
on top of a fresh 2006R2 Rc5 uClinux-dist using “cp -R”.

This was set up for the jffs2 file system, however I wanted to try a ramfs config as I was more familiar with that from my STAMP work. This was probably a mistake, as I spent several hours working out how to get this working. uClinux was starting OK but kernel panicking when it couldn’t mount root. I was using the u-boot command:
bf1> tftp 0x1000000 uImage
bf1> bootm 0x1000000

To download and boot the uImage. The uImage file combines the kernel and the root files system in one compressed image.

At Wojtek’s suggestion (again via chat) I compared the boot sequence of the bf1 to my STAMPs. I noticed something odd about the Memory Map section of the boot sequence. When I booted the STAMP I was getting something like this.
Memory map:
text = 0x00001000-0x00107f94
init = 0x00108000-0x00115508
data = 0x00115b4c-0x00145e60
stack = 0x00116000-0x00118000
bss = 0x00145e60-0x00153394
available = 0x00153394-0x03800000
rootfs = 0x07700000-0x07f00000
DMA Zone = 0x07f00000-0x08000000

Note the “rootfs” line. This says that 8M is allocated to the rootfs. This was the BF533 STAMP, which has 128M available, which means the top address is 0x8000 0000. Note that the “available” memory is about 57M. Now when I compared the rootfs line for the bf1, I saw:
rootfs = 0x00600000-0x001f00000
Which is 25M allocated for rootfs. Now at this stage I only had my bf1 configured for 32M, so that rootfs was consuming most of the available memory. In fact when I checked the available line, only 416k was free for the entire operating system! I traced the problem to the vendors/IvanDanov/BLACKFINONEV2/Makefile. The BLOCKS line that controls the size of the rootfs was set to 25600 rather than 8000. As I mentioned earlier, this is only really a problem if you are using ramfs.

I changed the line back to BLOCKS=8000, rebuilt the uImage and managed to (finally) boot uClinux. So I ran around the house telling everyone but nobody cared much (except my baby son, as discussed below). Oh well, it still made my day!

A little more work to u-boot and kernel configuration and I had a 64M BlackfinOne booting OK. Wojtek showed me how to configure u-boot for 64M:

  1. In board/bf1/config.mk make TEXT_BASE = 0x03fe0000.
  2. In include/configs/bf1.h set the #define CONFIG_MEM_SIZE to 64.
  3. make mclean;make mrproper; make bf1_config;make.

To configure uClinux for 64M “make linux_menuconfig and set “Blackfin Processor Options – Use SDRAM chip” to your memory chip, then rebuild uClinux-dist with the usual “make”.

If you have built a 64M BlackfinOne you are welcome to try my u-boot and uClinux uImages. They might be useful for initial testing and save you the steps of compiling your own. Once you have flashed u-boot-bf1v2-64M.bin, place uImagebf1v2-64M on your tftp server and on the bf1 console:
bf1> tftp 0x1000000 uImagebf1v2-64M
bf1> tftp 0x1000000

Note that this uImage uses ramfs not jffs2, and I used the -75 memory chip. This should work OK with the slightly faster -7E chips.

While experimenting I noticed that you need a u-boot configured for 64M to boot a 64M uClinux, otherwise uClinux bombed for me shortly after the uImage was uncompressed. However you can boot a 32M linux using a 64M u-boot.

I set the Ethernet MAC and IP for uClinux using environment variables in u-boot that are passed to uClinux, using the addnet script:
bootargs=root=/dev/mtdblock0 rw
addnet=setenv bootargs $(bootargs) ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask):$(hostname):eth0:off
flashboot=run addnet;bootm 0x20040000

Flashboot is called when the bf1 starts, which calls the addnet script, and boots uClinux. I would rather have u-boot set just the MAC and let uClinux set the IP through /etc/rc, however I haven’t worked out how to do this just yet.

Open Hardware

The BlackfinOne project is a great example of open hardware development. There is a growing community of developers that have contributed to hardware, software, and even tracking down problem parts for each other. There are parts being air-mailed all over the world as one person helps another get parts that are tough to find in their country. An interesting example of open/community development being applied to hardware – obtaining parts is not a problem for open software development!

Web-based parts supply companies like Digikey have helped make this sort of project possible. You can now easily buy many obscure parts and get them delivered anywhere in the world in a week or so. The web has helped hardware hacking get easier, and made it possible to build complex, sophisticated designs like the bf1.

Chat and mailing lists proved invaluable. Wojtek and I were in constant chat contact, and we used the bf1 forums to help us when we got stuck. Even though at this time of year we are about 12 hours apart in time (and about 40 degrees C in temperature). Just being able to explain each our problems was very useful – it made the problem clear in your own head when you have to express it to another person. I have been developing hardware for about 20 years and this as truly a new way of working for me. Nothing new for software development I guess, but very different for hardware (at least for me). In my experience (mainly in smaller companies), the hardware guy has often worked more or less alone.


This has been a really great experience. I assembled my very own uClinux hardware, then brought it up through various stages until it booted. I still can’t believe that I actually soldered together my very own Linux machine! If you are interested in trying out a hardware project, I thoroughly recommend this project. Great design, great community. Open hardware in action.

When I told my baby son about my working BlackfinOne, this was his reaction:

I know exactly how he feels!


Wojtek for your review of this post and photos.

amount interest negative loan of capitalizationloans 10 dollar paydaypayday law 10 new 15 loan100 payday loan faxemergency 1000 loan1000 loan business opploan no check credit 10000il equity 125 value home loan Mappanasonic ringtone 55 gdmobile ringtone t 6010ringtone ppc sprint 6700ringtone nextel 7100ito how ringtone 8125911 ringtone 69999a 670 ringtonesyour a900 make ringtones Mapringtones chocolate to lg convertcool metallica ringtonescountry ringtoneringtones crazy freecreate ringtones free share andcreate ringtone my owncreate cellular us for ringtonesmidi ringtone creating Map

EMI Testing 101


Electromagnetic Interference (EMI) testing measures the amount of energy your electronic product radiates. If it radiates too much EMI, it might interfere with other products, for example a PC with bad EMI might make it hard to use your radio or cell phone.

EMI is a growing problem, as most devices contains some sort of computer, and the frequencies of clock signals are rising all the time. All those fast signals can potentially create lots of EMI.

EMI tests can be a stressful time in the product development cycle. These tests are usually occur right at the end, when the budget is blown, you are overdue and you need to get that product out the door “or else”. They are expensive (especially for small companies) and are “make or break” – a failure could send you back to the drawing board to redesign the printed circuit board costing months of development time.

My EMI Testing Experience

There are certain standards that you need to meet for EMI. In October 2006 I attempted to obtain US/Australian/European EMI compliance for the following system (the 4fx telephony boards combined with a BF537 STAMP):

The tests were performed by Austest, in their Adelaide Labs. The US standard for EMI is known as FCC-15. The Australian/European standards overlap in most areas so can be performed at the same time.

The idea was to use the STAMP (an off the shelf development board from Analog Devices) plus my 4fx daughter board to get a first pass product “to market” quickly, without the engineering effort required to develop our own Blackfin motherboard. This would be a a good way to get the technology into real world use quickly. We could then follow up with a lower cost/volume manufactured custom motherboard.

Unfortunately, I flunked part of the tests. Below I describe why I flunked and how I traced the problem. I have got to admit that this hurts – these tests cost me around US$3,000 out of my own pocket! However maybe by blogging on it I can share some of the experience I gained and help share some of the value from the tests.

This means that we can’t use the STAMP/4fx combination for a real-world, volume manufactured product, although it’s OK for “test and evaluation” (the EMI standards generally have exemptions for development work).

The good news is the telephony daughter board looks good from an EMI point of view – it was the STAMP board that was radiating too strongly to meet the requirements of FCC-15. So with a Blackfin DSP motherboard designed to minimise EMI we should be able to eventually pass the EMI tests OK.

The EMI Test Procedure

The EMI tests are designed to accurately measure radiation from your product, called the Equipment Under Test or EUT. Radiation can come from a variety of sources:

  1. Any cable connected to your device can act as an effective antenna under the right circumstances. For example power cables, Ethernet, and phone cables.
  2. The Printed Circuit Board (PCB) can also radiate directly. High frequency currents can flow around the board, for example from a clock oscillator through the power supply rails. If the loop area of the current is large (say due to the PCB layout), it may radiate EMI.

The FCC-15 tests are divided into two sorts of tests, designed to pick up EMI in different parts of the spectrum:

  1. Conducted tests, where voltages conducted down the cables are sampled.
  2. Radiated tests, where the actual radiation of the EUT is measured using an antenna.

Conducted tests

Conducted tests are used for lower frequencies (150kHz to 30MHz). Low frequency signals have long wavelengths. At these frequencies it’s easier to determine if the EUT is likely to radiate by sampling the voltages on the cables connected to the EUT, rather than say using an antenna. Otherwise you might need very large antennas (like several km long) to be sensitive to radiations at low frequencies. Common problem at these frequencies are switching power supply noise. For example those big lumps in your power supply cables are ferrites that are designed to block power supply noise travelling down the power supply cable.

The conducted tests were performed inside a shielded room. Note the careful arrangement of the EUT, wires were connected to all ports to simulate real world operation. Any little change in this configuration could change the EMI signature.

To sample the signals special boxes are used that are carefully calibrated to sample any EMI signals on the Ethernet/telephone/power cables without affecting normal operation:

The signals detected by these boxes are fed to a spectrum analyser – a device that can measure the EMI energy in various parts of the spectrum and determine if it is above or beneath the required levels.

The levels for the conducted tests were sampled from the power, Ethernet, RS232 serial, FXS and FXO ports and found to meet the requirements. All well and good, so on to the radiated tests.

Radiated Tests

For higher frequencies (30MHz to 1.5GHz in this case), an antenna is used to directly sense EMI from the EUT. The test lab I used have an outdoor test site:

Outdoor test sites tend to be in relatively remote locations, away from any ambient sources of radio waves that might interfere with the tests. You can see that this site is in a valley, with only a few houses in sight. The sites are carefully calibrated each time they are used to make sure there are no new sources of “ambients”.

The EUT is placed on a rotating table, so its EMI radiation can be measured at different angles:

A very special (and very expensive) antenna is used to sense the EMI radiation. This is carefully calibrated and has a known response across the frequencies of interest:

Below is an example of the typical test results. This graph measures the level of EMI energy between 30MHz and 1500MHz. Click on the image to get a larger, more legible version.

The green line shows the background (or ambient) radio signals at the site, the black line shows the combination of ambient plus the EUT. The red and blue lines show the permissible limits.

During the tests the antenna is moved up and down, and the EUT table rotated to maximise the signals from the EUT at various frequencies. The EMI signature tends to vary a lot with orientation and antenna height.

It was here that we hit some problems – the EUT was radiating a very strong signal at 300MHz – far exceeding the level allowable by the standard. The 300MHz signal was about as strong as a small radio transmitter (for example like one used to open your car doors)!

By a process of elimination we tracked the problem down to STAMP board itself. When all the cables (except power) and the telephony daughter boards were removed the STAMP sat there radiating approximately the same signal at 300MHz.

After a few hours of attempting to reduce the EMI level at 300MHz (for example shielded boxes, and metal plates under the STAMP board) we called it a day – the signal was just too strong to be easily fixed.

I guess the good news was that my telephony boards were fairly clean – telephony boards often have problems with radiation from phone cables (they make good antennas for EMI). However adding and removing the daughter boards and phone cables didn’t have much effect on the EMI levels.

Somewhat (OK very) disappointed, I retired to home base to think about the problem and do some tests.

Now I should emphasise that the BF537 STAMP board was not designed for EMI compliance, rather it was optimised for development purposes. These two requirements are at odds, for example on the STAMP all of the high speed address/data bus nets are routed to headers, which means lots of extra high speed nets on the board, all potential EMI radiators. In a commercial, FCC-15 compliant design, the number and length of high speed nets would be minimised. I was just hoping that the STAMP would be FCC-15 compliant and therefore suitable for early deployment of my telephony systems. So I took a chance and messed up. My mistake.

However I learnt a lot and had fun tracing the source of the EMI, as described below.

The Elusive EMI Bug Hunt

To track the problem I built a little sniffer probe: two turns of wire connected to 50 ohm coax. I viewed the signal from the sniffer using a 500MHz scope with the input set for 50 ohm termination. One handy feature of my scope was a FFT function – this let me see the 300 MHz signal on a frequency scale. I could also see the signal on the regular time domain display when the sniffer probe was close to the STAMP.

When placed near the STAMP PCB a very clear 300MHz signal can be seen. The level of the signal varies as the probe is moved over different parts of the board.

Here is a picture of the sniffer probe in action. It is like a poor antenna, that picks up EMI from just a few cm away – useful for localising the source of the EMI on the PCB.

Here are the initial results:

  1. I found that the 300MHz noise was all over the ground plane, but is not present in the power cable. This suggests that the noise is not being radiated by the power cable.
  2. I found peaks in the signal level over the SDRAM chips. This is expected, as there is a 100MHz bus connecting the SDRAM chips to the CPU, which means lots of digital noise.
  3. Curiously, I found another big peak over the “Blackfin” graphic (see photo above). This peak was not expected, as there were no parts loaded on this part of the PCB (on the upper or lower side).

Now 300MHz is the 3rd harmonic of the 100MHz bus frequency. Digital signals are square waves which are made up of odd-harmonics of the square wave frequency, so from a 100MHz bus we would expect to see energy at 100MHz, 300MHz, 500MHz, etc.

I guessed that the 300MHz signal was a harmonic of the 100MHz bus that for some reason was radiating effectively from the PCB. To test this theory I changed the bus frequency to 125MHz, and saw the strong signal at 300MHz shift up to 375MHz. So it looks like the source of the EMI is the bus.

Now to radiate EMI you need a signal source (the bus in this case) and an effective antenna (for example a cable around one quarter of the wavelength or a current loop of similar size).

I suspect the PCB has a resonance at around 300MHz. This would explain why the signal is so strong at 300MHz but the fundamental (100MHz) and 5th harmonic (500MHz) are not visible on the scope.

At 300MHz, a good 1/4 wave antenna would be 25cm long – close to the length of the board. There could be AC currents travelling over tracks of that length of the PCB board.

Splits in PCB Power Plane

Fortunately the STAMP designs are all open. I therefore inspected the BF537 STAMP Gerber files, which are available from the Blackfin site. Gerber files are the graphics files that define the Printed Circuit Board (PCB) layout. They are the files you send to the PCB house to get your boards made. The BF537 STAMP board is an 8 layer design.

There is a very nice Linux Gerber viewer program called gerbv that comes with the gEDA tools that I have used to design the 4fx hardware. To view the Gerber files I unzipped the STAMP Gerbers then ran gerbv:
$gerbv *.pho&

I took a look at the PCB in the area of the Blackfin logo:

The image above has the layer 0 (a signal layer) and layer 1 (VCC power plane) displayed. Layer 0 has some wiring for high speed signals. Layer 1 is the VCC plane and is split into areas for each VCC rail (5V, 3V3, 1V2 etc).

Now remember that my sniffer found a peak over the Blackfin logo – this area is the rectangular box in the image above. Curiously, this area corresponds to a split in layer 1, the VCC plane.

High speed digital signals like to take the path of least impedance, i.e. the most direct path (Note: see comment below by Icarus75 on this). They tend to flow out of a pin, along a net, then back through the ground or power plane to the ground pin of the chip generating the signal.

A split in power or ground plane causes the signal to take a longer path (it must flow around the split), causing the total loop area to increase. Signals flowing through large loop areas make good antennas for EMI.

If layer 1 is placed directly under Layer 0 it will not be doing a good job as an signal return path – the splits will cause signals to take big detours, with large loop areas, and generate lots of EMI (plus possibly other high speed digital issues).

To minimise loop area (and hence EMI) you really want a continuous plane (VCC or GND) under any high speed nets.

So my theory is that the EMI is being caused by having a split power plane directly beneath a high speed signal layer, i.e. the problem may be the PCB layout, or more correctly the ordering of the layers in the PCB. This theory is supported by the high level of the problem 300MHz signal found over a split in the VCC plane.

Next Steps

The next step is to design a new DSP motherboard that is FCC-15 compliant. As a first step I have been working with a team of open developers on the BlackfinOne project. This is Blackfin DSP motherboard, designed using the gEDA open CAD tools by a community of developers. This design has been customised a little for telephony work and some steps have been taken at the design stage to minimise EMI. Several people in the BlackfinOne community now have this design up and running.

When I have loaded my BlackfinOne, I will do some preliminary in-house testing of the design before determining if the board will be submitted for FCC-15 testing. It is possible to construct some test jigs to do preliminary EMI testing outside of the EMI labs. Although uncalibrated, it should be possible to determine if there are any serious problems. More on this in another post!


Thanks to Paul Kay at Austest for patiently explaining to me the issues involved with EMI. Despite the poor results, he made the two days we spent testing enjoyable and a fascinating learning experience!
movies gay boyinteracial samples moviesexy movie scenesteen movies nudevintage movies sexxxx movie clip sampleselectra movies sex carmensapphic exclusive movies Mapabet universities crediteds crisis farm credit 1980rental laptop addwords apr creditcredits 50 music dates first200 child credit ontario50 first dates music credits2b whiskey credit lullaby videoloans balloon 2 28 Map

Open Source Hardware

An important part of the Free Telephony Project is the idea of “open hardware”. The hardware designs that are being developed are being placed in the public domain under the GPL.

As a business model, it’s a bit of an experiment.

The technology being developed has very strong business possibilities – for example the ability to build a powerful IP-PBX for a couple of hundred dollars, much less than current IP-PBXes and even less than a low end analog PBX.

I have had to fend off several corporate dudes who wanted me to join them in ventures to make lots of money. It’s hard to turn them down but as I was not interested in “closing” the hardware they ran away fast. This makes sense if you want to build a large business, you need “secret sauce”. In other words: Intellectual Property (IP).

What I would really like is some sponsors for my work who can work with the open hardware concept, but so far they all want to lock up the IP. Which of course is the right thing to do if you want to make lots of money.

This has made me think through the concept of open hardware:

  1. I think open software has been a good thing for the world, so I think open hardware is also good.
  2. If closed IP makes a small amount of people a lot of money – does opening the IP make a moderate amount of money for a large amount of people? The latter seems a better outcome to me. It also suggests that open hardware benefits small companies more than large ones.
  3. I think the specific benefit of open hardware is lower R&D costs. This is what is happening with my project – there is a small team of people designing DSP boards, BRI-ISDN hardware, doing Asterisk ports etc. So far I would estimate about 5 man-years of hardware R&D I now have available for free. If I like I can now re-use this open hardware in my local market, potentially without hurting the business of my co-developers. There is a spirit of cooperation rather than competition.
  4. A common perception is that “if the hardware design is open, people will just copy it and put you out of business”. Well after some thought I disagree. A business is much more than just the product design – for example you need support, capital, manufacture, service, and relationships with customers. So even if the whole design is open, you can still build a nice little business (but perhaps not a $100M business). You can also add proprietary components and build on the open technology, or focus on your local market.
  5. My pet favourite – open hardware allows us to invent new business models, for example developing countries could build advanced telephone systems for cost price. This is so much better than buying technology from a first-world profit-oriented business that must charge a 70% mark up to cover their overheads. This is the business model behind the one laptop per child project. A $100 laptop is possible if u remove the overheads, use community input and sponsership for R&D and build volume. Well a $100 IP-PBX is also possible. Another benefit is that the hardware can be built locally (remember the hardware design is free) overcoming import tariff problems and building local industry. Combining these elements means lots of people getting connected cheaply. And that is a very good thing for the world.


I have had some great discussions on this topic with Rich Bodo. He has coined the phrase Intellectual Antiproperty on his blog.
sex wmv free moviesprev movie xxxnaked movie stars youngmovies 1 cumshotsmovies porn 19703d adult moviesfree adult thumb moviehomemade adult moviesfull sites adult download movieadult galleries moviecredit 3000 loan check noscore loan 400 creditneed 5000 credit loan bad9 6 loan payday directlstudent consolidate steps loan 7 simple80 texas hard money loanus aa personal loanspay college accept loan iloan personal acceptance guaranteed onlineaccess bar group loanssex movies bondagemovies boylovemovie bunch bradybanks briana movies freeskye threesome britany movieschasethehottie movieschicago theatre moviechinese movies sexmovie chocolatchristian teen for retreats moviesst accredited funeral servicesholder account adult credit card merchantcrunch 1990 creditenglish grade credit assignments 9th extraprogram aacsb accreditedstatus university of coast california accreditationsociety saskatchewan of credit agriculturalunion community credit 1st garland Mapporn review 1280×720girl porn 13lesbian porn 14porn 14v year oldmin fere 15 pornmin 15 porn previews15 minute clips pornporn minutes 15 Map

Icarus Verilog Mini How To

For my Free Telephony Hardware project I need to program a small Xilinx CPLD to handle some SPI bus decoding.

I have been using the gEDA tools for schematic entry and PCB design. gEDA also includes Icarus Verilog so I decided to check it out.

Verilog is a hardware description language. Instead of drawing schematic circuit diagrams you use source code to describe digital logic. Like this:
module d_ff( d, clk, q, q_bar);
input d, clk;
output q, q_bar;
reg q;
reg q_bar;

always @ (posedge clk)
q <= d;
q_bar <= !d;

This is the Verilog source for d_ff.vl, a D flip-flop. Here is a “test bench” (d_ff_tb.vl) to drive the D flip-flop:
module d_ff_tb;

reg clock, reset, d;
wire q, q_bar;

initial begin
$dumpfile ("d_ff_tb.vcd");
$dumpvars (1, d_ff_tb);
$monitor ("clock=%b, d=%b, q=%b, q_bar=%b", clock, d, q, q_bar);
clock = 0;
d = 1;
#10 d = 0;
#20 $finish;

always begin
#5 clock = !clock;

d_ff d0(
.d (d),
.clk (clock),
.q (q),
.q_bar (q_bar)


You can see the instance of the d_ff at the bottom, and the notation used to tie its “terminals” to nets in the test bench. You compile and run like this:
$ iverilog -o d_ff_tb d_ff_tb.vl d_ff.vl
$ vvp d_ff_tb
VCD info: dumpfile d_ff_tb.vcd opened for output.
clock=0, d=1, q=x, q_bar=x
clock=1, d=1, q=1, q_bar=0
clock=0, d=0, q=1, q_bar=0
clock=1, d=0, q=0, q_bar=1
clock=0, d=0, q=0, q_bar=1
clock=1, d=0, q=0, q_bar=1

You can see the flip-flop being put through its paces. First we set d=1, then on the next rising edge of the clock you can see q and q_bar change. Then we try d=0 for a few clock cycles. There is also a companion program called GTKWave that allows you to plot waveforms:

BTW I gotta say I just love the splash screen from GTKwave! I always knew engineering was as cool as surfing:

I have done a little VHDL coding (VHDL is a cousin of Verilog) using Windows GUI based tools (using a Xilinx IDE and ModelSim) and actually found it quite painful to get started and run simple simulations. So I was pleasantly surprised with how easy it was to use Icarus to develop and test simple logic designs.

Even though I had never used Verilog before it only took me about 3 hours of research on the web to get the simple simulation above written and running. This is very cool, I actually found this much easier than my first VHDL experience on a Windows GUI. Thank you very much and kudos to Stephen Williams who wrote Icarus Verilog (and thanks also to the developers of GTKWave).

I think one of the great features of Icarus is that it uses the command line and text files for everything, rather than the typical bloated Windows GUI approach. I am a big fan of the command line & text files, for example in the other gEDA tools like gschem (schematic entry) and PCB (PCB layout) text files are used to store the designs. This makes powerful processing and automation possible like manipulating PCB designs using Perl.

As an aside the Pragmatic Programmer guys have a good article on the benefits of text files here.

I am a raw beginner at Verilog and found the tutorial information on the Asic World site to be very useful. Thanks Deepak Kumar Tala for putting that site together.

Renumbering components using Perl

I am designing a telephony version of the BlackfinOne DSP/uClinux board. To develop the design I am using the gEDA CAD tools. This board runs uClinux on a Blackfin BF532 processor, and has been designed using the open source gEDA tools which makes it really easy for anyone to re-use the design. Thank you very much to Dimitar Penev and Ivan Danov who designed and published this board. They have done an excellent job.

The first stage in any electronic design is usually to enter the schematic. The schematic shows the components and their wiring in a form that is easy to follow:

I wanted to add two Ethernet ports to the BlackfinOne design, so I found a reference design and entered the schematic using the gschem program.

After I entered some sheets for the Ethernet chips, I had a little problem. In the schematic above you can see that every component has a letter & number next to it, for example, C1, C2 for capacitors, or U1, U2 etc for chips. This is a unique ID for each part. The letter generally indicates what sort of part is is (capacitor, resistor, chip etc). These IDs are know as reference designators or as a “refdes”.

Now I wanted the refdes on my new Ethernet sheets to merge nicely with those on the existing BlackfinOne design. For example if the last capacitors refdes on the BlackfinOne design stopped at C51, then my C’s should start at C52.

There is a program to do this (refdes_renum described here in the gEDA tutorial) but unfortunately it renumbers all of the refdes in the design, and I only wanted to renumber the new parts that I had added. I didn’t want to mess up anything in the existing design. Please also see the Links section below for a new alternative – grenum.

Now of course it is possible to number the components manually in gschem via the GUI, but if you know a little Perl then its much more fun to hack out a solution! Now fortunately gschem uses text files to store the schematic. The refdes are stored in the schematic file like this:
C 7000 87800 1 0 0 bf-93LC46.sym
T 8200 89100 5 10 1 1 0 0 1

I think this means that the component (leading C) that is drawn using the bf-93LC46.sym symbol file has a refdes called U19. The line starting with T tells gschem where to place the refdes text on the sheet. Anyway all I am really interested in is reading and changing the refdes lines.

So the Perl script num_refdes.pl first scans all of the existing schematic files for lines that have the text /refdes=/. The number of the refdes is then extracted, and stored in a hash if it is the largest refdes so far. On the new schematics, I initially enter each refdes as C?, U? etc. The script scans these, and wherever it finds a ? it replaces it with the next refdes in that series.

Improvements and Reflections

There is one obvious improvement. The current script isn’t smart enough to use a refdes that hasn’t been used yet, for example if C1,C2,C4 are currently used it isn’t smart enough to use C3, it will use C5 instead.

This script took me about 70 minutes to write and it worked perfectly the first time. To be honest it didn’t really save me any time (I could have manually entered the refdes in less time) but it was lots more fun to do it this way. And I guess it will be useful the next time I have this problem. Perhaps now that I have posted on it some one else might also find it useful. Come to think of it writing this blog post took longer than writing the script! DOH!

BTW every time I work with Perl (which is maybe once every two months) I spend the first 20 minutes looking up web sites to work out which regexp to use, how to iterate through a hash, etc. If I don’t work on Perl and regexps constantly it all looks like line noise to me after a few weeks:
if ($line =~ /refdes=(\w)(\?)/) {

But hey, its no big deal to refresh my memory every few months.

Solving little problems like this with Perl is fun. You almost hope there isn’t a solution out there already, just so you have an excuse to write one!


I have also written a few Perl scripts for PCB (the PCB design application in the gEDA suite) here.

After I posted the above, Levente Kovacs kindly pointed out his grenum utility which is now included with gEDA! This has been recently added to gEDA and performs the same job as the Perl script above, but can also spot gaps in refdes sequences. As grenum is now part of the official gEDA distribution I would recommend using it rather than num_refdes.pl. I share a trait common among engineers – a strong desire to “do it myself” rather than checking carefully for existing solutions! Thanks Levente!
14 payday 20 loan directory2500 cash quick loansquick 26 loan 37 paydaycredit bad loan 2b personal45 loan payday 31 advance uksites 37 payday loan 53loan cash payday advance 5 5006 loan online kentucky payday 8loan 6 cost 20,8 payday lowlink 60 payday loanmovies hentaimovie lesbiansex moviesmovies adultfree hentai moviesporn moviesmovie clips porn freemovies gay free Mapmp3 achha ji1990 mp3 temptationsnation acumen mp3drame mp3 adamatecktonik mp3 tepr acdgmp3 ackermann sucheachhe mp3 lagtemp3 blog 1990s Mapfree naked moviesdildo movies hugehardcore clips moviemovies dans pornblow free movies job bestwomen movies nakedgirls free teen moviesdouble penetration free movies Mapporn cliphunterporn clipmasterclips free pornporn anal of clipsof girl porn clipsporn clipsporno clips gratuitclipsporn Map

Using Make to build hardware

I have been working on some telephony hardware using the gEDA open source CAD software. Now designing Printed Circuit Boards (PCBs) is fun, but very GUI-centric. Click-Click-Click with the mouse all day. After a few frustrating experiences (OK I messed up the design a few times) I thought “there must be a better way” and “why can’t I use the command line and Make for this?”

Lucky for me the gEDA software uses text files to store the PCB layout so as an experiment I wrote some Perl scripts to handle some boring repetitive tasks. The bottom line is I am using Make to assemble a Printed Circuit Board design from smaller “modules” of PCB – just like software. I have written about it (with lots of fancy screen shots) here.movie enemafacesit moviessex women movies fatmovie favorite quotesfemale movies strippershitting females moviesfighting movie website the temptationfinal xi fantasy moviemovies free wmv adultfree sex anal movie downloadsringtone sanyo 5400 sprint freesamsung ringtone a680 midiamc 30 barrington moviesnokia easy 3585i text ringtone freeaudiovox ringtone 8910 cricketclowns 1000 ringtone nextelfree a950 ringtone samsung scha660 samsung sprint free ringtone Mapto credit allowing friends use2bcredit accept 2bcardsunion credit affinity federal 07481accreditation masters divinity aabc inmaine federal union credit acadia madawaskaaccreditation ahrpcard processingcom gambling merchant credit accountbureas 3 credit Map