I, by choice, prefer working with software. When I deal with networks, it’s usually only so that I can solve some problem and then get back to working on my software projects. That being the case, I often find myself in the following situation:
- Installed latest network hardware
- Configured said hardware and our networks.
- Left network in operation
- Come back two years later when something needs changed.
The story always ends the same. All the equipment I put in has been succeeded by newer, cooler hardware. The stuff we now have is outdated and only available as a support solution.
There are solutions for maintaining a network over time. Multilink Communications Products for instance offers all kinds of old and new Cisco Equipment. You’ll have to check them out yourself to see if they suite your needs and if their prices is right, but for me, I found exactly the old firewall model and license that we use in our network VPNs. They have an easy to browse menu of products. It’s easy, for instance, to browse to the Cisco Switches and see every model they have available. Once you find what you need, you can request a price quote depending on if you want new, used/refurbished, or simply whatever costs the least. There is also a Hardware and equipment lease option if you like that better.
I’ve been optimizing my firmware for throughput and I thought a good benchmark would be to test it against the CyStream example provided by Cypress. I modified their CyStream.c file to be compatible with the latest firmware file provided by fx2lib.
Here is a summary of the changes needed:
- Include the appropriate header files
- Change the functions for vendor commands to match the fx2lib functions.
- Change the interrupt handlers
- Probably the most work of the whole process, rewrite the dscr.a51 file to be in asx8051 format.
Anyhow, The attached zip files contains the sources for the modified CyStream. Here are some of my benchmark results:
|CyStream Application on Windows with Keil firmware
|Keil firmware, Linux Host with included speed.py
|SDCC firmware, unchanged, speed.py
|SDCC firmware, optimization 1, speed.py
|SDCC firmware, optimization 2, speed.py
|SDCC firmware, optimization 3, speed,py
|SDCC firmware, optimization 3, CyStream App on Windows
- Optimization: remove two if checks for interrupts in main loop and handle them directly in the interrupts
- Optimization: remove another if in main loop.
- Optimization: completely remove everything in main loop, commit packets directly in main loop, don’t write to ep buffer before committing data. Note that the fastest I could get this to go was 42.9 (or 43.8 on Windows). Further removing things didn’t make it go any faster so I think I hit my Host PC limits.
You’ll need to download fetch the latest fx2lib from github and then modify the Makefile to compile the attached firmware. You’ll need to install the fx2load package for Python from fx2lib in order to run the speed test.
CyStream for SDCC and fx2lib
Enjoy. I hope fx2lib helps someone out. Check out my other posts on fx2lib to find our mailing list and more SDCC examples for the Cypress FX2.
I sent an email to the fx2lib mailing list that I thought would make good information for a bigger audience. Eventually, I’ll probably provide a Verilog behavioral model for the GPIF on the Cy7C68013 (and variants), but for now, this may help a few of you:
- Rdy0,1, txpire etc, are registered (The data 7:0 is too). That means if Rdy0, rdy1 are true when the decision point tests them, that they were actually set during the previous clock cycle.
- When you enter a state, any control lines you set are registered out. That means if you set ctl0 high on state 2, that whatever you connect to the gpif receives the high a clock cycle later.
I started to develop a behavioral model for this. It goes something like this if you are familiar with Verilog:
reg [2:0] state;
reg rdy0_r, rdy1_r;
always @(posedge clk) begin
rdy0_r <= // rdy0 signal
rdy1_r <= // rdy1 signal
data_r <= // data signals
ctl0_r <= // state 0 ctl0 state
// example decision point logic
if (rdy0_r) begin
state <= STATE1;
ctl2_r <= // whatever you set the control lines to in state 1.
// example read state // do something with data
someoutput <= data_r; // whatever
if ( !rdy0_r) begin // decision point logic
state <= STATE2;
// etc... I don't yet have code to dynamically read the gpif output
// so until then, I just coded each state the same as I did in the
// gpif designer.
Anyway, I was able to get a functioning simulation of my device from the perspective of the 8051 by modeling the GPIF this way. When I get some time, I'd like to make this generic enough to parse the GPIF designer output and model each state dynamically so the simulation can simply call the single read, single write, and fifo waveforms and the model will execute the waveform correctly. For now, if you're going down this road of simulation, you should be able to simply mimic your GPIF waveform this way.
After playing around with the Cypress FX2 and SDCC for the past while, I’ve developed a library of utilities that make some of the common tasks for writing firmware and performing certain functions a little easier. I’m lucky to work for a company that approves of the open source initiative and believes that it is beneficial to give back as well as receive from a wider audience of developers. That being said, I’ve created a git repository with my library:
Here is fx2lib on github: http://github.com/mulicheng/fx2lib/
You can clone it with git like this:
> git clone git://github.com/mulicheng/fx2lib.git fx2lib
Here is a short list of some of the things you can do with this library:
- Read/Write data on the i2c bus
- Handle USB and GPIF interrupts
- Read/Write data on to a serial console
- Handle the common USB vendor commands
- Implement your own vendor commands
- Program the GPIF
Hope you enjoy!
Update 12/15/08: Added project home page at Sourceforge: fx2lib home.
I’ve had the enjoyable experience of playing around with the Cy7c68013a chip on the Ez-Usb development board for the past few weeks. I thought I’d post a few tips for developing in this type of environment with open source software.
Convert to Linux
The tools that Cypress provides with the development kit are Windows based. You can download a number of their items directly from their website, but i didn’t find a way to unpack their source code examples without running their installer in a Windows session. The installer creates a new directory: C:\Cypress\ You can ignore the bin directory. Copy the docs directory (You’ll need the TRM) and the examples directory to your Linux machine. The examples won’t compile on Linux (The c51 compiler provided by Keil is Windows based) but they provide good insight into how to do a few things when it isn’t immediately clear by reading the TRM. You may also be interested in their util sources but I’ve found only minor uses for these since there are open source alternatives to a lot of what they do.
Convert to SDCC
On Linux, you’ll compile programs for the 8051 chip with SDCC. You can install it from their sources or from a package provided by your Linux distribution. SDCC works very similar to gcc but provides output that can be loaded onto embedded devices.
A couple important switches for compiling:
- -mmcs51 Tells the compiler to produce output for the 8051 chip
- -xram-loc Tells the compiler where to start putting xdata variables
(If a program suddenly doesn’t work after you add an xdata variable, try playing with this 1st.)
Convert the fx2regs.h file
The fx2regs.h file provided with cypress won’t compile with SDCC (It’s Keil specific). There are a few things you can do.
- Just use the 8051.h (or 8052.h) file provided by sdcc. (Works if you don’t need lots of the extended registers. Also works for getting started with basic examples.
- Rewrite it in non compiler specific macros. SDCC comes with a compiler.h file that has macros for SFR, SBIT, etc. You can use these and generate a header file that can be compiled on more than one platform.
- Use a convert utility. There is a perl script on SDCCs contrib folder that can convert Keil to SDCC headers.
(For clarification, this script is included in the source tarball.)
- Rewrite it yourself by hand. Well, if you don’t trust the conversion script anyway.
Learn how to run programs
The Cy7c68013a chip handles some basic USB commands for you. 1st of all, it will enumerate itself. 2nd, it will allow you to upload and download firmware to the 8051. This 2nd tidbit is vital. You can 1st upload a byte to the reset bit location in firmware (putting the chip in reset), then upload a new firmware, and then upload a byte that puts it back out of reset, thus running your program.
This fairly straight forward process is documented in the TRM. Even cooler though, someone already implemented it for you so you don’t have to. I use the cycfx2prog utility. It’s GPLed and the source is available to download.
After compiling a simple program (which produces an ihx-intel hex file), you can upload it like this:
> cycfx2prog prg:program.ihx run
Port a couple example programs to SDCC.
I started by rewriting a few of the examples and libraries for testing. I recommend 1st getting serial io working so you can debug easier. After that, play around with the i2c board and lights. Finally, test writing to eeprom. (For eeprom images, the hex2bix program that comes with the development kit can easily be ported to run on Linux by using linux time libraries instead of the windows files.)
Perhaps this section deserves it’s own blog post later on.
Anyway, I haven’t yet found anything that can’t be done on Linux with the Ez-USB kit.
UPDATE 12/5/08: Added Open Source FX2 Library.
Friends and family often ask me what laptop they ought to purchase. My answer is always the same: “It depends”. Then I proceed to break down the pluses and minuses of different types of laptops and try to determine where to start looking. After that, I find out more about exactly what they want, how much they want to spend, and we begin to find a number of machines that may suit their needs.
Part of the process of picking a laptop, for me anyway, always centers around reading reviews of different models. There are certainly a lot of reviews out there, but it helps to find lots of details about the laptops you are interested in along with the reviews. One source for reviews that I’ve come across is Computer Shopper. Particularly, they have a number of reviews for Dell Laptops that are very insightful into the benefits, cost comparisons, performance, and overall value of Dells laptop lineup.
Computer Shopper has a great lineup of products and they provided an individual review for each of the products I looked at. Not only do they give you the key specs for each machine, they also provide insight into who the machines are good for. They have a quick overview listing pros and cons of the machine, and then you can dig deeper into the review to find out how an individual machine stacks up against your other possibilities.
If you are looking for a machine over the long term, and not interested in buying something immediately, you can also check out their blog format reviews. When a new machine is announced, Computer Shopper gives you a quick overview of the machine, lets you know where it will be sold and for how much, and how this machine is different from what is currently on the market. It is really a handy feature and I’ve added Computer Shopper to my list of resources for the next time the question comes: “Which laptop should I buy?”!