electronics

Posted on 07-04-2008 under avr

As promised, here come the schematics.

Porgrammer Schematics v2 [pdf]

If you want to run this cable with PonyProg, in the Setup->Interface Setup dialog choose Serial. In the drop-down box choose SI Prog API. In the check-boxes below you’ll have to check all except RESET.

Pony Prog Settings

If you’re using avrdude, you’ll have to add the following to your avrdude.conf file.

# SIPROG Inverted programmer
# reset=!txd sck=rts mosi=dtr miso=cts

programmer
  id    = "siprogn"; 
  desc  = "Inverted Lancos SI-Prog “;
  type  = serbb;
  reset = ~3;
  sck   = ~7;
  mosi  = ~4;
  miso  = ~8;
;

More information on the programmer is in the README.

A shot of the cable is below. Its short, but thats because we had already converted the serial port signals to TTL. Of course this is really too short. You can make it a bit longer. Ideally of course, you the longer length should be before the level conversion stage. If you can get your hands on a serial cable, that would allow and instead of plugging the programmer into the computer, you plug it into one end of the cable, you can really extend its operating distance.

Programming Cable

REFERENCES:
LancOS’ site has a few nice serial schematics but all of them use discrete components to do level conversion, and frankly, I dont trust discrete components. At least, not the ones available in our maket. This schematic shows the pin connections on the serial port for the SI Prog programmer. Using this allows us to program using PonyProg.
This page uses a similar Max232 connection. We got the idea to use 10nf capacitors from here, thus reducing the size of the ciruit.

NEXT STEP:

USB. woo!! This is gonna be really easy actually because some circuits are already available online. One of these I really like is ladyada’s circuit. Although I think I can do away with the buffer. And I might have to replace the ATTiny with an ATMega8 because I might not be able to find it in the market.

EDIT [ 14th July, 2008 ] : Corrected a problem with the RESET circuit.

Posted on 07-03-2008 under avr

Our brand new office PCs didn’t have serial or parallel port in them. USB is great for normal people, but we NEED serial and parallel ports to do our work. We then have to buy extra hardware to add serial ports via USB.  Which is getting more and more expensive and less and less reliable.

For example, we bought a PCI parallel and serial port adapter which looked promising enough. Unfortunately it refused to budge. After much scratching of chins, and a lot of poking around, ranging from loading userspace drivers on Windows, to installing Debian and trying to access the port from there; we found that the chip on the board was faulty. Similar problems lie with almost all converters that are available in the market, or so I’ve heard.

We had to actually “make” a serial port by pulling lines directly from a header on the motherboard.

So we banged up a simple RS-232 programmer that uses the serial port to program an AVR. Simple and minimal, it uses only a MAX232, a transistor and diode, and a couple of resistors thrown in for good measure. Estimated price, under Rs. 100. See the pic below. (All the soldering is credited to Qaiser Hussain who is amazing with an iron).

Avr Serial Programmer Front

More details, including schematics and programming instructions coming soon :)

Posted on 04-16-2008 under electronics, howto, linux

After two days of banging my head against the wall, interspersed with issuing ineffectual commands, I’ve finally done it. (See shot below).

Xilinx Cable Connected and Running!

The cable drivers available with the Xilinx 9.1i software suite just won’t compile on my system. Apparently they use some proprietary functionality that does not support any kernel other than 2.4. And since I have 2.6 installed…

I had help from here, here and here.

Here’s a rundown of how I made it run on my system, which is a Debian 4.0 testing, with the following output for uname -a

Linux galileo 2.6.24-1-686 #1 SMP Thu Mar 27 17:45:04 UTC 2008 i686 GNU/Linux

I used bash throughout. If you use another shell, some commands may change.

1.

In order to avoid problems later, install libusb-dev and fxload.

 aptitude install libusb-dev fxload

2.

Make a directory somewhere to store the driver’s sources.

mkdir ~/tmp/xildriver
cd ~/tmp/xildriver

3.

Download the source tarball.

 wget "http://git.zerfleddert.de/cgi-bin/gitweb.cgi/
usb-driver?a=snapshot;h=HEAD;sf=tgz" -O usb-driver.tar.gz

(without the line breaks)

 tar zxvf usb-driver.tar.gz
 cd usb-driver

4.

Compile the driver.

 make

5.

copy the library to a lib directory.

 su
 cp *.so /usr/local/lib/
 exit

This step is totally optional. Just make sure you substitute the right path in the next step.

6.

make the linker aware of the new library

 export LD_PRELOAD=/usr/local/lib/libusb-driver.so

This step will need to be repeated every time you login. Or you can add it to your shell’s rc file. For bash this is /home/user/.bashrc.

All the previous steps are common to all tutorials and sources I’ve mentioned earlier. Its also given in the README file that comes with the source. After this though, its all from Verhaegen’s email.

7.

Make a new udev rule file
I absolutely do not understand this step, but I believe it has something to do with how the USB cable is detected.

 su
 vim /etc/udev/50-xilinx-usb-osdriver.rules    # a new file with arbitrary
#name ("50" is recommended)

Now paste this into the file and save it.

ACTION=="add", BUS=="usb", SYSFS{idVendor}=="03fd", MODE="666"

If you don’t know how to use vim, use nano instead ( or learn it). If you would rather use a graphical editor, then exit from root user and type

kdesu kwrite /etc/udev/50-xilinx-usb-osdriver.rules

Now restart udev.

 /etc/init.d/udev restart

8.

Get the bus and number of the USB cable.
Plug the board in and type

lsusb | grep Xilinx

Note the bus number and the device number. Here’s my output

 Bus 005 Device 016: ID 03fd:0008 Xilinx, Inc.

9.

Update firmware
If the ID in the above line is not 03fd:0008 in your case, do the following.

 su
 /sbin/fxload -v -t fx2 -I /home/zohair/installed/Xilinx91i/bin/
lin/xusbdfwu.hex -D /proc/bus/usb/005/016

Again without the linebreaks.
Replace your bus and device numbers from the above step into this command.

10.

Start impact (as normal user of course)

 ~/installed/Xilinx91i/bin/lin/impact


Impact should detect your cable automatically. If it does not go to Output->Cable Setup: and choose Xilinx USB cable.


If it still does not work, there are some more instructions in Verhaegen’s email (steps 13 onwards).


Credits


Credits go to Michael Gernoth who took the time out to make these drivers. And also to Paul Verhaegen’s excellent email and  Luzerne GANHIR . Thanks guys.

										

			



			


			
			
Posted on 04-09-2008 under electronics,  firmware

			
											
I subscribe to a newsletter called the “Embedded Muse”, run by Jack Ganssle. It  carries quite useful information about engineering practices, and writing good code. Ganssle is particularly focused on making better coders out of all of us engineers. The Embedded Muse is highly recommended for anyone who has to write firmware, or work on embedded systems in general.


The current post however, is about this week’s joke column. <warning> The following text is liable to go over your head if you do not know what “assembly” means. So if you aren’t an electronics engineer, don’t come back to me saying you didn’t get it </warning>. Some of these are so gold, I just had to share them.


Tom Paden wrote:


 The early 6800 had an undocumented test op-code called HCF; Halt and Catch Fire. It would fetch from consecutive memory locations to test out the address bus. I forget

how I found out about it, but it’s documented on Wikipedia: http://en.wikipedia.org/wiki/Halt_and_Catch_Fire


Chris Nelson wrote (especially good):


 An early mainframe OS at RPI had a joke language

called Screwbol (if I recall correctly) which actually implemented HEO

(Halt and Eat Operator). When executed, this instruction caused the

big line printer to open the access door then slam the write head back

and forth to cause the printer to walk across the floor toward the

operator console.


Man, I would have loved to see that.


Stephen Irons wrote:


 The ones I always tried to

avoid were from Motorola’s 6803 microcontrollers:


BHT: Branch if High Tide


BLT: Branch if Low Tide


These were real instructions for at least the 6803, and I think for

the whole 6800-series. The real meaning if I remember correctly were

Branch if Higher Than and Branch if Lower Than, using an unsigned

comparison, as opposed to BGT and BLT (greater than and less than)

which did a signed comparison.


And last, but not least, Gary Gaebel writes:


 The 9046 x N, random access, write-only memory chip. I actually have

a spec sheet for this one.

…

the Quad Two Input Maybe Gate. Apply any combination of

0’s and 1’s to the two input pins, and maybe you’ll get a 0 on the

output, or maybe you’ll get a 1. Think random number generator…


That last one was hilarious.

										

			



			


			
			
Posted on 03-11-2008 under electronics,  karachi,  web crawling

			
											
Solar power is seeing increasing amounts of development these days. According to EETimes, the solar industry has seen revenues rise from $10 billion in 2006 to $13 billion in 2007. Cell efficiencies for the experimental varieties are getting to the point that they may be able to compete with fossil fuel generation. It may not be far off in the future when we are free of fossil fuel producers and their control over the international market.


The current market leaders in solar cell production are Japan and Germany. But China is rapidly increasing its output capacity, and it will very quickly overtake Japan, the current lead.


Increasingly, semi-conductor manufacturers are spending R&D budgets on this new, rapidly expanding market. According to John Boyd at EETimes:


We can be sure that almost every large semiconductor manufacturer has a PV program of some sort and is assessing strategies to leverage its manufacturing experience and depreciating assets.


While this is very good news for the environment, it is also good news for power generation. Sufficiently mass-produced and well-researched, this option may be cheap enough for low-income economies like our own.


So what does the future of solar power hold for Pakistan, with our gift of eternal sun. Recently some encouraging actions have been taken by our government.


According to the Business Recorder dated 10th February, 2008:


The government has decided to use solar energy-based lights on all important buildings … “With appropriate energy conservation policy, a minimum saving up to 25 percent in various segments of the energy sector can bring saving of $2 billion per annum.”


And on uniquepakistan.com, dated 24th February, 2008:


City District Government Karachi has decided to use solar energy system as alternate source for electricity at public places in Karach … City Government has invited Expression of Interest (EOI) from Foreign/Local Firms … for providing solar energy system for parks, street lights, on bridges, lamp poles, spotlights, wall mounted lights, landscape lights etc. in Karachi.


In light of the current power situation in Pakistan, and especially Karachi, this is welcome news. It remains to be seen how this plan is actually carried out, since the change in government might just put this on the backburner. I do believe however, that Pakistan is very ripe for solar power, perhaps even to a surplus production capacity.  Lets all wait and see.

										

			



						

				« Previous entries