Category Archives: Tutorials

Geeetech FX2LP CY7C68013A USB DevBoard

I recently purchased a Geeetech (clone/knockoff) off ebay for a small $5, and wanted to test its functionality for use with my Flight Sim devices. The CY7C68013A is the same chip used in the Salae logic analyzer (and ripoffs), so figured it should have pretty decent performance.

Despite being used in quite a number of logic analyzer type projects, I couldn’t find any decent beginner information for it, so this will try and fill the gap; especially for windows users.

This first part post will describe settings up the environment, and the second post will delve into the features of this dev board and chip.

The CY7C68013A

The chip board presents 20 GPIO ports (With 2 interrupt pins), a i2c bus, dedicated USB pins, and a couple of ancillary pins. Its work noting that the 56pin SSOP doesn’t have a serial port, which is a bit disappointing.

The board itself has 2 LEDS, D1 and D2 attached to the PA.0 and PA.1 ports respectively. This ties up both the interrupt pins, so will only be useful for initial testing.

Programming the chip is done via the EZ-USB software provided by Cypress (Or its open-source equivalent which only seems to be available on linux). The software can download a compiled .hex file directly to the RAM of the chip (Lost after reset), or the EEPROM provided and accessed via the i2c port. Data on the EEPROM will survive resets, but the chip must be disabled by adding J2 on the board before trying to reprogram it again.

Installing Software and Setting up Environment

Install Cypress Dev Kit (CY3684Setup.exe)
- Install inf file from C:\Cypress\USB\CY3684_EZ-USB_FX2LP_DVK\1.1\Drivers\Win8.1\x64 (Go into folder for your OS version, right click on inf file, click install)
Install the CY7C68013 Dev Tools from fx2lp.exe
Plug in the Device, driver will auto install
Install sdcc
Install make
Install TortoiseSVN (Optional)
Install Eclipse (Install with C/C++ Development)
Edit system path:
- Run “C:\WINDOWS\System32\control.exe system”
- Goto Advanved system settings -> Environment Variables
- Edit ‘Path’; Add:
- C:\Program Files\SDCC\bin
- C:\Program Files (x86)\GnuWin32\bin
- C:\Cypress\USB\bin

Setting Up Eclipse and Importing Code

The credit for ‘gtfx2lplib’ must all goto here: https://github.com/ubixum/fx2lib

I’ve taken the code base from there, removed whats not needed and modified it to suit the Geeetech dev board. I’ve renamed the library to ‘gtfx2lplib’

Download gtfx2lplib.zip
- Extract it somewhere
- Most up to date source available from NewioIT WebSVN
Import gtfx2lplib into Eclipse:
- New -> Makefile project with existing code
- Once import, create build targets ‘all’ and ‘clean’ (If they dont exist)
- (Right click gtfx2lib, goto ‘Build Targets’ – Create; name one ‘all’, and one ‘clean’

Building Code and Deploying

Now we just have to build the code, and upload an example to the dev board. The below will write the code to the RAM, which will be lost after reset.

Right click on the ‘all’ build target and build it
Check the console to make sure everything compiled correctly
Run CyConzole EZ-USB (Start menu or “C:\Cypress\USB\bin\CyConsole.exe EZ”
Click on ‘Download’
Goto examples\led\, select the led.hex file
The file will be uploaded to the board, and the leds will start alternatively flash.

Led Code

Here is the code use for the ‘leds’ example. It deliberately doesn’t use the gtfx2lplib files as to allow a base example of whats happening. There is also the ‘lights’ code, which uses the library itself to run its functions.

// Geeetech LEDs on PA.0 and PA.1
// OEx sets I/O Direction of the 8 port pins (0=Input, 1=Output)
// IOx Output: Sets value. Input & Output: read value
// i.e.
//   OEA |= 0x01  - Set PA.0 to Output
//   IOA |= 0x01  - Set PA.0 output value to 1
 
// Location of IOA and OEA
__sfr __at(0x80) IOA;
__sfr __at(0xb2) OEA;
 
// Macros to return bit value
#define _BV(bit) (1 << (bit))
// Macro to flip bits
#define xbi(sfr, bit)   ((sfr) ^= _BV(bit))
 
void leddelay();
 
void main(void)
{
    OEA |= 0x03;        // PA.0 & PA.1 to Outputs
    IOA = 0x02;         // Led 1 Off, Led 2 On
    for (;;) {          // Loop forever
        xbi(IOA, 0);    // Flip PA.0
        xbi(IOA, 1);    // Flip PA.1
        leddelay();     // Do a delay
    }
}
 
// Some code to provide a delay
void leddelay()
{
    int i = 0,k = 0;
    for(i = 0;i < 1000;i++) {
        for(k = 0;k < 100; )k++;
    }
}

Deploying to EEPROM

To keep your code int eh device beyond a power down or reset, the code needs to be deployed to the EEPROM. To do so:

Ensure jumper J2 is in place
Reset the device (power cycle or press reset button)
Remove jumper J2, this will enable the EEPROM, but as the chips is powered, it won’t read its code from it)
Open EZUSB (Start menu or “CyConsole.exe EZ”
Click on the ‘Lg EEPROM’.
Navigate to examples\leds, select leds.iic, click ok
EZUSB will now copy the code to the EEPROM instead of RAM
Once complete, press the reset button. Code will be loaded from EEPROM

The above procedure must be repeated each time you wish to program the EEPROM (i.e. replace the jumper, reset, remove jumper, program. I find it easier to do inital development work using just RAM, and then program the EEPROM with code when im ready to more production style testing.

Tutorials – 4MHz Colpitts Crystal Oscillator

Introduction

Colpitts Oscillator, with AY38910 PSG in background

Clock sources are used in pretty much all digital electronics these days. There are many ways to create clock sources, from a simple 555 timers, to using a micro-controller (PIC, AVR) to output a clock source. I had a specific need for a 2MHz clock source to drive an AY38910 programmable sound generator chip I had ordered off ebay.

After looking through my surplus crystal, the lowest speed I could find was a 4Mhz crystal. Using that as a starting point, I went searching for how to quickly put it to use to get a stable and accurate signal. For this, i came across the Colpitts Oscillator.

Wikipedia describes the Colpitt Oscillator as:

A Colpitts oscillator, invented in 1918 by American engineer Edwin H. Colpitts, is one of a number of designs for LC oscillators, electronic oscillators that use a combination of inductors (L) and capacitors (C) to produce an oscillation at a certain frequency. The distinguishing feature of the Colpitts oscillator is that the feedback for the active device is taken from a voltage divider made of two capacitors in series across the inductor.

The Colpitts Oscillator Circuit

So after reviewing some circuit diagrams, and resistor/capacitor values, i came up with this circuit for generating a stable 4Mhz square wave.

4MHz Colpitts Oscillator

Download: The CADSoft Eagle schematic here

This all seemed to work pretty well. I pestered around with bumping up to 8Mhz, which worked with a bit of degradation on the amplitude of this signal. 12MHz had the output so low it wouldn’t drive TTL inputs. Given i was after a fairly low frequency, i didn’t investigate why i couldn’t get to higher speeds. The Colpitts Oscillator should be able to get up to about 20Mhz.

Its time to measure up the frequency of the output. I was a little annoyed at the latest update of the Bitscope DSO software. usually, the cursor frequency shows in the bar down the bottom, but now its in the left hand side bar… which isn’t included in the ‘save as image’ function.

So here is the signal output on the oscilloscope. You’ll have to take my word for it that the cursor (Vertical lines) indicates a 4MHz something resembling a sine wave.

Colpitts Oscillator outputting a 4MHz signal

Creating a 2MHz Signal, with a CMOS 4017 Decade Counter

At the start of this post, you may remember saying that the AY38910 PSG required 2MHz (Or more correctly, between 1 and 2 MHz). You might also remember be saying that the lowest frequency crystal I had was 4MHz. All true. So the question now is how do I get the 4MHz output from the Colpitts Oscillator down to the 2MHz required by the PSG.

I searched around the net for a solution, and most seemed to revolve around using a J-K type Flip-Flop. Havnt not any of these in stock, I remembered an old trick used a while back: Using a CMOS 4017 decade counter with 2nd clock counter pin connected to the reset pin. Thus when the reset pin is triggered, that becomes your ‘divided by two’ output.

This can be used to divide to get all sorts of lower frequencies, i.e.

4 / 2 = 2.00 MHz
4 / 3 = 1.33 MHz
4 / 4 = 1.00 MHz
4 / 5 = 0.80 MHz
and so on…

So with the above in mind, I modified the 4 MHz Colpitts Oscillator to look like this:

Download The CADSoft Eagle schematic here

Using the CMOS chip had the added benefit of restoring the rather weak signal from the T1 transistor to the full 5V level (Im guessing this is due to the BC549 transistor’s base not being loaded to near saturation, if anyone can improve this, let me know!). The below oscilloscope screenie shows the yellow trace as the Colpitts output, and the green trace the output from the 4017. Once again you’ll have to take my word that the yellow is 4 MHz, and the green is 2 MHz.

And here is one more showing 1.33 MHz. I ended up using 1.33 MHz to clock the PSG, as the sound produced was a bit more crisp. It’s also the frequency that GIC use for their example circuits in the PSG Data Manual (The best source of info for the AY38910!)

Conclusion

The Colpitts driver is a nice way to generate a stable and accurate clock signal. Truth be told though, its probably much easier just to use a can resonator. It was a nice break from digital electronics though, i dont often get to use the oscilloscope part of my BitScope.

I’ll leave here with a sneak peak video of the Colpitts Oscillator clocking the AY38910 to play… the Overworld Mario Bros. theme song!!. This project will be published here in the next couple of weeks. Its using an arduino to program the PSG, which i’ll be replacing with a straight AtMega168 (I dont use arduino for finished projects).

And another picture of the Colpitts Oscillator driving the AY38910 PSG

Tutorials – Quadrature Generator

Introduction

I’ve been doing quite a lot of work with rotary encoders lately. Testing the code of written for the AVR chips becomes quite a hassle when you need to turn a rotary encoder and just the right speed and duration to produce a good signal to debug against. I found this schematic somewhere on the web that automatically produces a quadrature signal. I’ve bumped it against a 555 timer with trimpot to make an adjustable timing for it.

For those that don’t know what a Quadrature Encoder is, its simply a device that outputs two signals that are 90 degrees out of phase with each other. WikiPedia has some decent information about quadrature, along with how they are used with rotary encoders. Briefly however, the below image shows how quadrature works. As a bonus, this is the actual output from the Quadrature Generator.

Output from the Quadrature Generator, captured on Bitscope Logic

The red trace it the clock input from the 555 timer, and the other two traces are is the quadrature. Notice they are 90 degress out of phase of each other, taking four clock cycles for a full rotation.

Schematic

So i must apologise for this schematic. I had it beautifully drawn on my Galaxy Note 10.1, but the Eagle component libraries have different pin locations then what I had used. So the net connections are all over the place. Hope the idea is there though…

Schematic, Flip-Flop is a 74LS74, click for larger version

Download the Cadsoft Eagle schematic here

The 555 timer simply provides a variable clock source (By adjusting TrimPot R2) to the 74LS74 Dual D-type Flip-Flop. The 4 way jumper provides an connection for the clock, output 1, output 2 and a ground connection (Making it easy to debug). The 2 way jumper is the +/- supply. The 74 series chips limits the Vcc to +5V, but replacing it with a CMOS 4013 flip flop will allow voltages up to around 15V (With a max speed of about 2Mhz).

Bill of Parts

74LS74 Dual type Flip-Flop
NE555 Timer
100k trimpot (I’ve used a horizontal mount type)
10k 1/4W resistor
390nF ceramic cap
0.1uF electro cap
0.01uF ceramic cap
2 way jumper header
4 way jumper header

Testing the output with the bitscope

PIC Tutorial – Part 01 – I2C

Introduction

This is the first part of a article on intercommunication between PIC chips with the I2C protocol. We will start with a basic example on using I2C send send and receive data on a 2-wire I2C bus, and then expand on this in later examples.

Included In This Tutorial

Source code for Master PIC16F84
Source code for Slave PIC16F88
Schematic to build the circuit

A PIC16F84 will be used for the master, and a PIC16F88 for the slave. Some simple bit-banging I2C code will be used to create the master, so it doesn’t really call for anything special on the chip end. In fact, i did initial develop for the code on a baseline range 16F509 chip!

The slave is a different beast however. The detecting of start/stop bit is a little more complex, at requires the use of some firmware built into the PIC16F88. The ‘SSP’ module can be used with interrupts to detect start and stop bits and process code based on these events.

Other chips, namely the PIC16F887 also comes with an ‘MSSP’ module that allows it to run as a master, completely automated. I might look at one of these in the future.

What is I2C

I2C is a serial communications bus created by Philips. Philips released there patent control over I2C around 2006, where is has found pretty decent usage in the micro controller world due to its simplicity. Competing transmission protocols are SPI and RS232.

I2C uses two lines: SDC and SCL. These are joined between one or more micro controllers, generally with one operating as the master and the other as slaves. Both lines required a pull-up resistor attached to the 5+ bus. The PIC controllers then can control the lines simply by turning them into an INPUT (Which pulls the line low), and having them as an OUTPUT which forces the line high. This system allows either device to control the state of the line. I.e: If the slave requires more time to complete an operation, it can hold the clock line low. As the master won’t be able to bring the line high, it’ll keep polling until it can do so before trying to send anymore data.

For a deeper understanding of how the I2C protocol works, Wikipedia has a great article: I2C

The Plan

The goal for Part 1 of this article is simple enough. There will be a I2C ‘Master’ (PIC16F84), and the I2C ‘Slave’ (PIC16F88). The Master will use some custom bit-banging code to send some data packets to the Slave which will then do some kind output to prove that it received the packet.

I was thinking an incrementing counter will be a nice bit of data to send. It’ll be easy to see on my logic analyzer to debug, is easily repeatable (it will roll over to 0x00 after 0xFF and continue on), and will be able to display some output easily by light a LED when the 8th bit is set. This will mean that any number after 0x80 will enable to LED, and when the counter rolls back over to 0x00, the LED will turn off.

The above image shows what we are trying to achieve after Part 1 of this tutorial. The left hand breadboard show’s the ‘Master’ PIC16F84, while the left has the ‘Slave’ PIC16F88. The LED on the master is active during a packet transmission, as this allow it to be used as a trigger by the logic analyzer. The ‘Slave’ LED will place when a transmitted byte is greater then 0x80 (i.e. its set to display the 8th bit of the byte).

The ‘Master’

The master is really just a bunch of bit-banging (modifying individual bits without too much overall complexity) that create the illusion of well timed operations. The code base listed below will pretty much serve the basis through all of these articles.

A ‘packet’ of I2C data consists of:

A start bit
A 7-bit address
An Ack (Or Nack) from the slave
An 8-bit data packet
An Ack (Or Nack) from the slave
Another data, followed by Ack OR
A stop bit

For the sake on simplicity, i’ll be leaving out step 6 for the meantime. Also, during the initial development, before a functioning ‘slave’ is up and running; it can be easier to leave out receiving a response from the slave. Just clock the SCL line while SDA is low and move on. This will also help us not having to detect the state of SCL.

This image shows a single packet sent by the I2C master. The ‘Red’ line is the LED connected to the master which provides the trigger for the packets. The first drop is SDA, followed by SCL going low is the ‘Start’ bit. Each SCL ‘strobe’ then signifies a bit transmission, and finally when SCL, then SDA go high indicate the ‘Stop’ bit.

The bit traffic reads as 010011100010111000

Breaking this down we find:

Address 7-bits: 0100111 (0x27)
Mode 1-bit: 0 or Write Mode (1 is Read mode)
Ack 1-bit: 0 (Ack, 1 is Nack)
Data 8-bits: 01011100 (0x5c)
Ack 1-bit: 0 (Ack)

So we have a successful transmission of the byte 0x5c to the slave with address 0x27.

To put this to test, we are going to have the master run two main process:

Each iteration of the main_loop, increment a variable. This variable will roll over to 0x00 once it reaches 0xFF
Each iteration of the main_loop, send the variable across the wire to the slave

We will also have the main_loop test is the byte was successfully sent, and if not, to have it resent rather then out slave miss out on a number.

The Slave

Bit-banging methods may work fine for the master, but its not going to cut it on our slave device. It is very hard to detect start and stop bits measuring individual inputs and discrete timings. Luckily for us, Microchip provides built in ‘SSP’ modules for some of its chips. This was my main defining reason for using the PIC16F88; as it has one of these modules built right into the chip. The SSP module can only function as a slave, and even then there is quite a bit of code that requires this to work.

Other chips such as the PIC16F877 have an in-built ‘MSSP’ module, will are much more advanced. It allows for full master and slave functionality all built into the firmware. However, for our purposes the function of the PIC16F88 will suffice.

So far we have a master chip sending out packets as quick as it can to the slave. The slaves job is therefore easy. First, we set the address of the slave. The slave will listen for address packets that arrive along the I2C line. If the address doesn’t match its own, then it ignores the rest of the data all the way up until the stop bit. If it’s own address does match the one sent however, or it matches the ‘General Call’ (which has an address of 0x00), then the slave will jump to action.

For the purposes of Part 1 of this tutorial, we will just be accessing the 8th bit of any incoming data, and using the to either have the LED switched on or off. With the 8th bit being set on from 0x80 – 0xFF, and off from 0x00 – 0x79, we’ll end up with approx a 25% duty cycle. On a 4Mhz crystal, this will have the LED flashing at a decent pace.

The Circuit

Time it get into the grunt of it! As you can see from the first picture, I’ve built my circuit across two breadboards. If you want to follow my tutorials, do the same as we’ll be adding a latch to the slave board along with 8 LEDS, and at some point another large breadboard with a second slave.

The test circuit here uses just a handful of components. The 16F88 could probably just use its own Internal 4MHz oscillator, but i havn’t got around to testing that yet. Also waiting on my 10 & 20MHz crystals to arrive so i can test out higher speeds! The stabilising capacitors are really needed, but i’ve got a whole draw full of 29pF ceramics just sitting there so added them anyway. I also need to research if one crystal can be shared between two micro’s.

As every I2C forum will tell you, ensure the pull-up resistors are installed on the SDA and SCL lines. I’m using 2.2K 1/4W resistors in the picture, but 4.7K – 10K will probably work just as well. The diodes are there for when programming the chips using the PICKit 3. You can save a significant amount of time by programming the chips in circuit. Infact; while i was building the circuit, the PICKit3 was able to supply power reducing the need for another external power supply. The picture below shows the PICkit3 attached to the slave chip. To program the master, only the Vpp, PGA and PGC lines need to be relocated, making it a quick and easy solution.

Unlike the master, in which we can choose what pins to run SDA and SCL on, the PIC16F88 and dedicated pins to running the SSP module. Its also unfortunate that they sit right int he middle of the PORTB set of 8 outputs, but there are workarounds for this. I’ve also avoided using the PGD and PGC datalines to make ICSProgramming easier (We don’t have to put load resistors in place to protect the application circuit this way.

I’ve created the schematic for this circuit in EagleCAD. Its by far the easiest software i’ve used, over multisim and altium designer. It does have some drawback when created PCB’s, but for this task its worked well.

Click the image for a larger version

Errata: I’ve missed a GND connection from PIN5 of the PIC16F88. Ensure you connect this to the GND line on the breadboard or not much of this circuit will work at all!

The Code

The code for this project will mature over time, so i’ll link into the subversion revision of the code used at the time of writing. This way as the code is developed over time, it’ll just be a simple matter of copying out the new version of code and programming the chip.

There are plenty of source out there on how to program a PIC chip, so i won’t go into that here (Or will perhaps write a separate article in future on how to do so.

The master code borrows heavily from the work of Phanderson. The code has mostly been written to clean it up a little, but the basis of how it works is all the same. Phanseron’s tutorial includes an example of using a port expander, something i will be covering in a later tutorial.

Click here to view the ‘Master’ code in WebSVN.

The slave code is based on the Microchip AN734 specification. This is referenced here and includes a lot of detail about implementing SSP on the PIC16F88, its pretty much a required read. The code needed a few tweaks, such as clearing the ANSEL analogue lines, setting with SDA and SCL lines as inuts and a couple of other changes.

Click here to view the ‘Slave’ code in WebSVN.

Testing

Any testing using logic levels over multiple wires is bet performed with a Logic Analyzer. I’m lucky enough to have a BitScope at hand, easily one of the most versatile instruments an amateur electrical engineer can have on hand! Using a bit scope to analyse data is as easy as connecting the data lines to the scope, selecting what type of protocol you want to analyse and clicking on ‘Run’. I also added an extra line to turn on a LED when a packet is being send, and turning off when its done. This allows this line to be set as a rising edge trigger on the scope, making capturing data a lot easier.

I’ve already shown a small snippet of the output (In the form of a single packet), but here is a screenshot from the BitScope Logic software:

Click the image for a larger version

What Next

To ensure that every bit was actually being transmitted, i filled out the other 7 LED’s so that the whole Byte could be viewed. To actually see the LED’s moving i needed to change the Delay_Short in the master main_loop to a Delay_Long. It takes just over a minute to count up to 255.

If you want to build it yourself, here are the ports i attached the LED’s to. Each LED required its own 220-470Ω resistor:

LED#	Port	Pin
0	RA0	17
1	RA1	18
2	RA2	1
3	RA3	2
4	RA4	3
5	RB2	8
6	RB0	6
7	RB5	11

If you decide not to build these additions, i’ve uploaded a video of the circuit in action to YouTube: