Archive for the ‘Tricks and Tips’ Category

FTDI chip real of fake ? How to spot a fake RT232R / RT232RL and others ?

Here is a 5 minute test:

1) purchase your boards in pairs this helps detect same serial number in case of fakes. Any board you buy under $5 is probably a fake, since the bare chip costs ~$4.

2) get your chip serial number, this can be done either by downloading the FT_PROG software or even easier from Device Manager > Ports > USB Serial Port (COMx) > (Right Click) >  Properties > Details > Device Instance Path , the Serial Number is in the value after the “+” sign following the PID . For example in screenshot below it is A704DEPPA.

3) google your serial number, those faking the chip are on a tight budget so they have no time to change it, although it is quite possible that some will change it

4) if you find your serial number for example A50285BI is a popular fake, chances are you got a fake

5) Most important: do a favor to the next person and post your serial number in the comments below, in case it is a fake it will appear in Google results for next person getting a fake with same serial #.

Why it is important to spot a fake FTDI fake  and why I am posting it ? Because it can ruin your day like it did for me ! Fake FTDI chips are unreliable especially at higher baud rates and you may be pulling your hair troubleshooting your project while the problem is in fact a cheap fake chip.

Hope this helps someone,

How do you test your chips ? Comments are welcome below .




11-7-2015 12-22-37 PM

11-7-2015 12-23-11 PM

QUICK TIP: How to easily remove Hubsan X4 quadcopter battery

Hubsan X4 is a nice quadcopter that is great for learning to fly a RC model. It is also a nice way to relax on your break since it can be flown inside. Its battery life is not so great so you'll need couple of batteries if you want to prolong your enjoyment. 

Batteries are a little hard to remove after a flight since they get hot and grow in size which is normal , however please note that if you're battery is too puffy – it's time to replace it , it might not be safe ! Pulling the battery by its leads is not safe and can tear off the leads or damage the protection PCB and/or battery.

This video shows how to remove the battery first time without damaging it and then (most important) shows you a little trick how to make the future battery replacements a snap !

Enjoy ! 

Your tips and comments are welcome, also let me know if this helped you 



UNI-T UT61E Multimiter Serial Protocol Reverse Engineering

UT61E is a fantastic multimiter for the price that unfortunately comes with a terrible PC interface program:

9-17-2015 8-13-09 PM

I decided to poke arround and see if I can reverse engineer the serial protocol that might be useful for someone who would like to try to write a different software or maybe even use my SerialChart software.

So here is what I found using a serial monitor: 

9-17-2015 8-14-14 PM

The serial settings are as follows :  19200bps , 7 bit, Odd Parity, 1 Stop bit.

9-17-2015 8-13-41 PM

To start streaming data you must set the DTR flag , to stop clear the DTR flag. Simple.

9-17-2015 8-14-48 PM

Now regarding the numbers. What do they mean ?

In Voltage mode, the first digit is number of decimal points shift (+1), and then follows the value, so for example 

107393  corresponds to  07.393V  (note dot is after  1 +1 = 2nd digit in value)
201348 corresponds to  013.48V  (note dot is after 2 + 1 = 3rd digit in value)
110822 corresponds to  10.822V  (note dot is after 1 + 1 = 2nd digit in value)

As far as 000:0 it appears to always be the same in. 

The format appears to be different in Ohms range, for example:

000106300020  corresponds to 1.06Ohm
000004300020 corresponds to  0.04Ohm
504833300020 corresponds to 4.833MOhm

So again first digit appears to be a multiplier.

Hope this helps to anyone who wants to take it further .. 


My plateless Anti-vibration mounts





These 3d printed ball adapters work great! I thought that the adapter plates that come with these are too heavy so I designed and printed these white adapters, now I use them on all my models – much better than sticky foam plus they are removable!

Finally here is the test flight, note how relatively stable the tricopter is. This is without any prop or motor balancing and with stock PID setting, absolutely no tuning.



Removing stubborn 3D prints from bed (my way of doing it)


Here is my method of removing stubborn prints from your 3D printer’s bed. This method does minimum damage to the bed coating (painter’s tape / capton tape).

All you need is box cutter. Follow 3 easy steps:

1 extend the box cutter blade and while keeping it at 10-20 degrees angle slide under the part with forward and side motion

2 retract the blade so the blade does not break on next step

3 with the blade inserted under the part, twist the box cutter until the part pops up

Works for me every time and keeps the painters tape in better shape compared to trying to pry it with a screwdriver or sharp object. Hope this helps someone.




RC Crawler Truck as Robotic Platform: Part 1 – upscale from 1/8 size to ~ 1/5 conversion, now able to climb on stairs


A terrain robotic platform must be able to handle different environments and be able to go over obstacles. While looking for such a platform for an upcoming robotic project, I came across a specific class of RC models – CRAWLERS. RC Crawlers are characterized by the following:

– RC crawlers are usually slow (hence the name) but have high torque and are able to climb over obstacles
– Because they are slow their ESC has no latching brake in other words if you move in forward and then in reverse. With a traditional car ESC this will put the car in brake mode and you must move to neutral position and then again in reverse to actually go in reverse. This is not the case with crawlers, if you move the stick in reverse, there’s no brake that you have to reset by going in neutral – it goes in reverse right away. This is a good feature of ESC for a robotic transform.
– Crawler have flexible and tilting body and wheels to conform to the terrain.

To start my initial testing I picked one of these Crawlers (called MAD TORQUE by Exceed), this is a 4WD crawler with a nice modular design:


The first problem I came across is that this crawler was not able to climb over standard stairs. If this robot will be used indoors it will need to climb over stairs. The problem – forward wheels are able to climb over first stair however the back wheels are too close and are unable to push the car further.

The solution I found is rather interesting and very easy to implement. Because of the its symmetrical design I was able to get spare parts and increase the body size in a snap:


If you use the box as reference you’ll see that the body is now longer. This was achieved by adding an additional pair of body frames that are connected with a repurposed battery bracket part (I tried to use spare parts from the model to keep same nice color).

Interestingly the canopy fitted perfectly over this enlarged mod:


So I am very happy with the results. It almost looks like this car was supposed to be like this. I purchased a 1/8 crawler and after this easy mod it now looks more like a 1/5 size.  The car is able to handle the stairs without a problem (see video for full demonstration).

Can’t wait to put some sensors into this and turn it into an actual robot !

P.S. yes I was tempted to add larger wheels to this, unfortunately the gears are not designed to handle them and they broke. I am fine with the small wheels anyways, they give more torque than the larger wheels with the tradeoff of slower speed.  To compensate for the slow speed I upgraded the battery from the stock 7.4V to a LiPo 3S (11.4V), the stock ESC handles it without a problem and not even getting too hot.

Hope this helps someone, happy RC modding !


Quicktip: Program your RC transmitter with UsbThumb

If you own a low-end RC transmitter with the Trainer port, you can program it using USBThumb (using the default USBThumbSerial firmware

The pin-out for the Trainer port is as follows, note the green wire (ground) is connected to the outer metal ring of the connector.




Please note that this is not guaranteed to work with all transmitters, but if you own an UsbThumb you can use it this way. I also use UsbThumb to program Propeller chips (see

Build a really fast pulse generator (50ps rise time) using an ultra fast SiGe comparator.


If you purchase a new or used scope you will probably need a way to test its advertised bandwidth. One way to test the bandwidth of the scope is to feed a really fast pulse into the oscilloscope and measure its rise time.  The reason why this makes sense is because a square wave contains many higher frequency harmonics. The frequency of its highest harmonic will determine the steepness of its falling or rising edge. If you look at a sinusoid wave of 1Ghz and one of 1Khz – the 1Ghz wave will have a steeper slope than the 1Khz sinusoid. A square wave or a pulse consists of the sum of many sinusoids, your scope bandwidth limitation will discard or attenuate the higher frequencies components and thus will alter the steepness of the wave that you see on your screen.

The bandwidth of the scope will be then given by the formula:

Bw = 0.35 / Tr      (Note: 0.4 / Tr  is sometimes used for modern digital scopes)

where Tr is the measured rise time of the pulse on the oscilloscope. This formula only stands when Tr >> Tra (Tr is much larger, usually at least 10 times than Tra)  , where Tra is the actual rise time of the pulse. I will describe a quick circuit for building a fast pulse generator with a Tra of 50ps. 50ps corresponds to a  bandwidth of  0.35/50ps  = 7Ghz, so you should be safe to evaluate bandwidth of scopes up to 700Mhz. For scopes with larger bandwidths you can still use same method but you need to take into account Tra, the formula becomes then:

Bw = 0.35/SQRT(Tr^2 – Tra^2)


The Circuit

The circuit uses a single chip, ultra fast comparator ADCMP580 available from Analog Devices.




For this circuit you will need a dual rail power supply (+5/-5V) , if you don’t have one you can use an ATX power supply from a computer case – it has both +5V and –5V rails. You will also need a way to generate a (slow rising) input pulse that the circuit above will convert to a fast rising (50ps) pulse.

The input pulse must not exceed +3V/-2V according to ADCMP580 datasheet. Keep this in mind If you’re using your Arduino  or a 555 timer circuit to feed in the input pulse , you will probably want to feed the pulse through a voltage divider if it exceeds these levels. Take into consideration that the ADCMP580 already has an internal 50Ohm resistor that you might use for your voltage divider.  Also please note that if you signal goes only from 0V to 5V , Vn will need to be somewhere in-between, again you can form a voltage divider to set it at about 2.5V. The outputs Q/Qb will toggle when your signal crosses the threshold set by Vn. In my case since I have a pulse generator that feeds a pulse from –1.25V to 1.25V (2.5Vpp) I am setting my Vn  threshold to ground. I am also using the internal 50Ohm termination just to place some “weight” on the circuit and filter out any noise pickup.

Rh is the hysteresis resistors this can be  anywhere between 0 to 10Kohm. I found that a value of 100Ohm worked great for me . Let’s say your signal is going up but then because of the noise it decides to go a little down, hysteresis feature of ADCMP580 protects against the output reacting to that noise, the output signal will only go back down when the voltage will fall Vhys below the point that made it go up. Below is a chart that describes the relationship between Vhys and Rh. You can see that in my case since I am using a 100Ohm resistor I have about 55mV of a buffer zone, so my output will not fluctuate if the noise level is less than roughly 55mV, in other words it will always take more than 55mV change in signal to toggle the comparator back in opposite state.



The Build and Results

Luckily Analog Devices offers an inexpensive ADCMP580 demo board, I picked mine from Mouser for around 50 dollars. The board is basically a breakout of the ADCMP580 chip with some decoupling capacitors and 2.9mm connectors for signals and standard 4mm banana sockets for the power supplies. Fear not the 2.9mm connectors , they are generally compatible with SMA connectors so I used some SMA-M to BNC-M cables to connect the signals to my scope and signal generator. (Some people will warn you that if you have some very expensive equipment do not use SMA connectors with 2.9mm connectors – the tolerances might be different and you might break the connectors on your expensive equipment). I also used some 50Ohm SMA terminators, on the QB, LE and VN connectors. The schematic above calls for LE and VN to be connected to ground via wire, however I found that a 50Ohm cap did the job. In case of QB connector it must be terminated with 50Ohm to ground, even if you’re not using its output so the 50Ohm terminator is required. LEB is connected to VEE (-5V) via a 1Kohm resistor and you might notice in the picture I have a 100 ohm resistor in the HYS slot (see between the black Q and red VEE cable).  You can see that the VTF_F, VTP_F, VTT, VCC0, CGND are left unconnected (the necessary connections are made by the blue jumpers on the board). Please note that although VCC1 may appear unconnected on the picture there’s an alligator clip under the board that connects it to the +5V rail of the power supply.




Once I completed the setup above I fed in a 2.5Vpp(@50Ohm load)  1Khz square wave into  VP,  my Q output was connected to my 500Mhz bandwidth oscilloscope, below is the result of this experiment:




The rise time of my input signal (Ch4) is 16.57ns while the rise time of the output (Ch1)  is 536ps (average) with a dispersion of 36ps, the momentary reading when the screenshot was taken was 590ps. So let’s calculate the bandwidth of the scope, I am taking a conservative approach using the worst number of 590ps:

Bw = 0.35 / 590ps =  0.35 / (590* 10^-12) = 0.000593 * 10^12 Hz = 593 * 10^6 Hz = 593 Mhz

So my scope has a bandwidth of no less than 593Mhz on Channel 1.  This is above it’s rated bandwidth of 500Mhz.


Conclusion and some notes

For around $50 I created a very fast pulse generator setup that allowed me to evaluate the bandwidth of my scope. 

Please note that if you read the ADCMP580 datasheet you will find a Rise/Fall Time of 37ps, however this is the rise time from 20% to 80%, the scope measures the rise time from 10% to 90%. I simply prorated this number  37ps * (90-10) / (80-20)  = 49.3ps ~ 50ps to get the rise time from 10% to 90%.

You will also see in datasheet the advertised equivalent rise time bandwidth of 8Ghz , I believe this comes from the formula 0.4/50ps = 8Ghz that applies to many modern digital scope. In my calculations I used the “old” conservative formula of  0.35/Tr instead of 0.4/Tr.

Finally please note that the output of ADCMP580 uses CML levels of  0V(High) and –0.4V(Low) according to datasheet. I found these levels to be actually lower in my setup (-0.472V High and -0.868V low), but with same difference of about 400mV as you can see in the scope screenshot below. If you have an explanation for this please leave a note in the comments section.





ADCMP580/ADCMP581/ADCMP582 Datasheet:

EVAL-ADCMP580BCPZ Evaluation Board

Evaluating Oscilloscope Bandwidths for Your Application

Digital Oscilloscope Bandwidth Measurement – direct and using risetime

Basics of Analog Oscilloscope Bandwidth

Analog Oscilloscope bandwidth considerations

EEVblog #306 – Jim Williams Pulse Generator

EEVblog #311 – Jim Williams Pulser Followup

EEVblog #316 – More PFANG, More 13GHz Scope, & More Pulser


Parts List


SMA-M Bnc Cable

SMA Terminator 50Ohm

Triple Power Supply

Function Generator




USB firmware debugging with USBTrace, PicKit & MPLAB IDE

Ah, the joy of firmware debugging! I’ve been working on a USB firmware for my new upcoming product that involves a dual traditional TTL (Serial) and a USB-TO-SERIAL converter (CDC Communication Port) implemented in the same firmware. The firmware was written in C18 , using the USB stack from Microchip Applications Libraries.

Everything worked well until I suddenly discovered that while sending data over the CDC port from the computer to the device, the device would *sometimes* receive garbage data instead of what I sent. This wouldn’t be so discouraging if the data received would be the same, or at least this would happen always not *sometimes*.  The bug was caught in the act on the screenshot below, the arrows show the data I actually sent ‘stop’ followed by LF (0xA) char and the character codes (in decimal) actually received. This is garbage because 92,162,62,180 are note the ASCII chars for ‘stop’.  Please note that this will only occur *sometimes*, however I could almost consistently repeat it after several retries of sending a command to the device.


The tracking of this bug turned out to be so adventurous and involved that I decided to write a tutorial about it. It involved some tools that I didn’t use often before, but now they proved indispensable in locating this furry and fuzzy code pest . As you’ll see at the end of the article the bug was pretty obvious at least for me (I already made this mistake many times , but forgot about it), however it might be really useful for someone just starting working with microcontrollers,  C and/or  interrupts. It also provides an opportunity to review some tools I used in the process.

So where do we go from here ? Same data is send over a USB CDC Serial Emulator Port  but sometimes the microcontroller receives garbage instead of the original data. A general rule of thumb is – start at the source and go up. Let’s identify the possible problems:

#1  – the computer terminal, or USB driver has gone crazy, it is sending something else instead of what was typed
#2  – there’s a hardware noise problem on the USB lines
#3  – there’s a bug in the Microchip USB Stack
#4  – there’s a bug in my code

Ok so we start with #1 , how do we see that the terminal is actually sending the correct data ? We need a way to see the actual packets send via USB. For someone who had a hardware USB protocol analyzer it would be a good time to power it up. Unfortunately these devices are really costly (let me know in the comments if I am wrong and you know any affordable solutions), and luckily for us there are decent software USB protocol analyzers that we can use instead. The tool that I used and that I highly recommend is USBTrace. It is not free , but still affordable and a great value that will pay off if you value your debug time. The reason I like USBTrace is that is so easy to use. You know a good product because after you start it you don’t have to read a manual to perform a basic function. Once I started USBTrace on the left side I was able to find a list of all USB devices, it was easy to track down my virtual CDC Serial port because in the bottom panel I could see the device descriptors. Please note that I also had connected a FTDI serial converter that I could have confused with my device. However my device had some strings in the descriptor that I recognized from my firmware such as “CDC RS-23 Emulation Demo”. Once I checked my device I was ready to click the green Run buttons. And the packets started pouring in …


Wow , that was an overwhelming number of packets! My device was in streaming mode and sending a lot of data to the EndPoint #82. I only needed data that I send to device so how do I do that ? Again USBTrace was great and very intuitive , clicked on the funnel icon (Filter) and I got following dialog:


Here I was able to set the Direction of the packet – OUT. Please note that for USB packets , by convention , the direction is as looking from host – so OUT from computer to device. I also set the CDC OUT endpoint as specified in my firmware #2, finally I set the request type to BULK_OR_INTRRUPT_TRANSFER.

Now all I had to do is to send the ‘stop’ command couple of times until the bug happened again, that was easy to spot since the streaming would not stop once garbage was received. And once it happened, I checked the contents of the last packet in USBTrace, and what do I see:


The data is completely correct, so my first guess is ruled out. Let the bug hunt continue. Moving on to #2.

#2 – there’s a hardware noise problem on the USB lines

I had a look at the cables, I had a look at the device, I knew the hardware setup worked perfectly before. If I had a hardware USB analyzer I would hook it up. But I didn’t so I took a leap of faith and I skipped #2. This wasn’t by the books. However it was all I could do in reasonable time. So moving on to #3.

#3 – there’s a bug in the Microchip USB stack

Once you download the USB stack, and integrate into your project , it becomes part of your project. So tracking Microchip’s bug was no different than tracking my own code bug. So I moved to #4 and handled #3 in the same step.

#4 – there’s a bug in my code

Ok so here we are in the MPLAB IDE 8.83. My PIC device is capable of up to 4 Hardware breakpoints. This means that the MCU can halt on specific memory locations, it also can halt when a specific memory location is written or read.  By scanning through the USB Stack code, I found that it stores the incoming  USB CDC data in the cdc_data_rx[] buffer . From the .map file I was able to determine that this buffer address is starting at 0xE08. The MAP file is basically a file the compiler creates and where you can find all your variables and code and at what address they are stored, look for it in the same folder where you output .hex file is.

Setting a memory breakpoint is accomplished by clicking on the “ADV.B”  blue button in the debugger toolbar, this brings up a dialog like this:


I just punched in the address of my buffer, selected access type as Write. Now when the first byte in the incoming CDC buffer is written with good / or garbage data the code should break and point me to where the data writing happened. Again I stared sending data, and I had to click on the green debug run icon couple of times, to skip through good cases until the bad garbage write happened. The MPLAB debugger didn’t stop every time the bad case happened , I am not sure if this is a limitation of the debugger or something caused by my code bug, but finally it stopped at a place where I defined some code that was executed inside an interrupt.


This is the code for receiving the data over the other port the TTL USART, not the one having problems CDC Serial !  It basically fills out a buffer called usart_rx_buf, but this not the cdc_data_rx buffer so how could they interfere?  Eureka ! Buffer overflow – the index used to access the buffer byte  uasart_rx_pos was going crazy out of bounds. Indeed I looked at how usart_rx_pos was declared:


The only other place where this variable was used was in this non-interrupt code:


Now this is a big problem, let’s look at the last statement

usart_rx_pos = 0

If we look at the disable of this instruction, on a PIC 8 bit controller we can see that it takes actually 2 instruction to complete it:


This is because this is a 2 bytes variable . Now think what would happen if the interrupt happens between these two instructions. The interrupt mentioned above modifies the variable. So while the main code thinks it has “0” in usart_rx_pos, in fact it only sets to 0 the second part of the variable the first one could have been modified by an interrupt! Thus the unpredictable behavior … usart_rx_pos becomes a random variable which causes the buffer overflow. Data is written at random locations in program memory . Scarrrrrry !

So how did this happened , even if  “I’ve been there done that” many times ? Well the timer interrupt code was not inside an interrupt initially , I later migrated it to an interrupt and forgot to do a sanity check of variable types. In fact I don’t need an int for usart_rx_pos (the buffer is smaller than 255). So I changed it’s declaration  to:


Now that writing of one byte is done in single instruction there’s no risk of corruption by an interrupt updating same variable. However as we’ll see below this is only part of the solution. Below is the disassembly code of writing 0 to a one byte variable:


Please note that I also added an important ‘volatile’ specification in front of all variables modified by the interrupt code.  Actually the lack of ‘volatile’ was my second guess why the bug happened. Without ‘volatile’ compiler might think that there’s no other place where the variable can change besides the spot it compiles. So it might optimize the code in weird ways. Here is an example, if a variable is not volatile the compiler could theoretically update this code

x =  1;
y = 0;
x = 1;

to simply

x = 1;
y = 0;

It removes the second assignment of x since it considers it redundant, while in fact if you have an interrupt executing let’s say before y=0 , and modifying x=0 thus in this case the  x=1 at the end is necessary ! So ‘volatile’ basically tells the compiler that a variable can change suddenly ‘out of the blue’ and it should take care while optimizing the code and not to remove any assignments even if they look redundant.

I’ll now present my final solution to ensure the interrupt code does not modify usart_rx_pos and usart_rx_buf  while we’re processing it in non-interrupt code.  The solution is to prevent the interrupt from happening during that time. No worries, if interrupt has to happen while it was disabled by us -  there ‘s usually  a flag set and the interrupt will happen eventually once we’re re-enabling it. Because the processing in session_new_char() might take a while (and you don’t want to disable USART receiving interrupts for a long time) my strategy was to declare two SAFE non-volatile variables and copy data over quickly then re-enable the interrupt. Please note that this code would work fine even if usart_rx_pos was an int (dual instruction assignment) :





Please note that I didn’t have to disable all interrupts, it was enough to disable only the interrupts that would cause our variable to be modified (the USART Receive interrupt). It’s enabled  or disabled by the RC1IE flag in PIE1 register.

After testing this new code, the problem was gone. So now I am thinking “everything is for the best” , I spent some time tracing a bug, but I learned along the way and sure thing  I wrote this tutorial so I never again forget that interrupts can modify variables when you don’t expect to !

Bottom line:

A.  Declare variables modified in interrupts as  ‘volatile’ to stop compiler doing nasty things to them
B.  Disable the interrupts that can modify those variables, while working with these variables in a non-interrupt code (both reading and writing), this will create a so called ‘atomic’ code, called so because it cannot be split by an interrupt.
C.  Keep ‘the atomic’ code short – the interrupts can wait , but not for too long in some cases.  For example the hardware USART buffer on my device only has 2 bytes – so it would get filled and lost soon if the processing done in the interrupt   would be halted for too long.
D. Have fun. Life is beautiful even when debugging Smile


Add a simple mechanical fine tune control to any bench instrument without voiding warranty


I was looking for a way to make the adjustment for my power supply more precise and easier to dial let’s say to a voltage like 3.3 , but without a built-in fine tune potentiometer this was difficult so I found one of those foam rings that are always on top of a CD box, and it fit perfectly over the dial making it bigger and now easier to dial any voltage. This works based on the “gears” principle  – with the larger “gear” attached , finger has to travel a longer distance to make same change, thus easier to dial anything in between that was before harder.

Plain and simple, but just thought to share the non-warranty voiding trick – acceptable choice if you can’t really open up the power supply and add a new potentiometer in series with the main one.  I am also glad I finally found a use for those CD foam rings Smile If you’re curious what power supply it is on the picture, it is a Tenma budget 10A linear power supply works well except the above mentioned lack of fine-tune dial.

Use extra-long headers to hold a board on a pogo pins testing jig

Adafruit has a nice tutorial on how to build a neat testing jig that allows you to test a breakout board without having to actually solder the header.

So I decided to build one for  the the acc_gyro boards. But how do you hold the board in place ? Using screws is secure but takes long time to put a board in and out. I needed a faster way to test a larger amount of boards.

Well after several experimentations with velcro tape, rubber bands , and even custom fitted clamps made out of polymorth , I arrived at this simple solution, just use some headers with extra long leads , the pictures tell it all:

The board is basically held by the plastic parts of 2 long headers. You simply spread them apart, insert the board and then , when they come back together they hold the board in place by the spring action of the pogo pins that pushes the board up.

To remove the board simply spread the headers again and the board pops up …

Hope the method could be useful to someone , so decided to share.


Open pde files with Arduino under Windows

This has been bugging me for while – I could not associate .pde files with arduino executable , I would select Open With… choose the executable but it won't work , so I decided to write a .reg script to correct the problem. After some research turns out other people had the same problem it happens with Windows 7 and might have something to do  with having Processing installed, in any case if you have this problem here is the fix.

Create a file called  arduino.reg with the following contents:

Windows Registry Editor Version 5.00


@="\"C:\\arduino\\arduino.exe\" \"%1\""

Please note this assumes your arduino installation was unzipped to C:\arduino\ . If different , update accordingly the reg file but make sure to use double quotes \\ for path delimiter as highlighted above.

Next simply double click on the arduino.reg file you have created and the keys will be imported to your registry. Now when you right click on the .pde file you should see arduino as one of the options (and you can make it default program to open pde files). 

Use macro definitions to simplify work with I/O ports in C (MICROCHIP PIC/ATMEL AVR)

Wouldn't it be nice that instead of the following PIC  C  ( or similar AVR C ) code:

TRISAbits.TRISA2 = 1;  //make switch pin an input
WPUAbits.WPUA2 = 1;    //turn on the pull-up on switch pin
TRISBbits.TRISB5 = 0;  //make led pin an output


You could just right something like this, that allows you to change later on the PIN assigned for a specific function:


#define pinSwitch(f)       f(A,2)        //Declare Switch pin RA2
#define pinLed(f)          f(B,5)        //Declar Led pin RB5
_TRIS(pinSwitch) = 1; //make pin an input
_WPU(pinSwitch) = 1;  // turn on internal pull-up on switch pin
_TRIS(pinLed) = 0;    // make led pin an output


If you're interested how you can simplify your PIC/AVR C code then read on ….


I started working with MCUs using Basic Stamps 2. My first programs where written in PBASIC. I enjoyed the simplicity of this language but soon moved on to C. One particular thing that I was missing in the C enviroment was the ability to define a pin at the begining of the program and then perform various operations on it. (Make it an input or output, toggle the pin, read its level, output a high or low signal). PIC Microcontrollers make use of several registers to perform these operations, and if you change your pin you need to update all your lines of code that perform these operation.

To illustrate let's take a simple example. Let's say you have a button and a led, you'd like to create a simple application that will turn on the led when a momentary switch is pressed. The hardware setup will be very simple: the led is connected to an output pin of MCU (with a resitor in series to avoid burning the led); the switch is connected to another pin with an optional external pull-up resistor (some PIC and AVR can use an internal pull-up). Please note when the switch is pressed it will output 0 (LOW) and when it is not pressed it will output 1 (HIGH) due to the pull-up resistor.

Read More »

A Simple Method to Connect a Nokia LCD Screen to Your Project (No Soldering Required)

Some LCD screens from old cell phones have gained popularity among electronic enthusiats. They are easy to interface with a microcontroller and consume very little power. Best of all they come free or at very little cost. One common problem with these screens is how to connect them to your project. They usually have very tiny contact connectors that are hard or sometimes even impossible to solder to. Here is a nice trick I learned by trial an error how to connect a Nokia LCD to your breadboard without soldering.

For this purpose you will need to search your junk box for a flex cable with the same pitch as your LCD connector. For my Nokia LCD this happens to be a 1mm pitch cable that I found in an old CD-ROM drive. Similar cables can be found in other computer equipment like printers, scanners, fax machines.


Read More »