Arduino/AVR vs Cypress/PSOC

I've recently been working on a simple PSOC (www.cypress.com/psoc) project using the CY8C64315 USB chip and can't help but compare it to the popular Arduino platform since it is pretty similar to the AVR 328P. These are my observations:

Feature Comparison

Cypress/PSOC 9, Arduino/AVR 5

Initially I chose PSOC because it has some great features packed into a tiny 16 pin QFN part at a cheap price. In particular it provides a full-speed USB device with very few external components -- not even a crystal! It runs at 24Mhz instead of the AVR's 20mhz and contains SPI, I2C, a bunch of IOs and so forth.

One issue is that it does not contain a serial UART (but other, bigger PSOC parts do), but I'm hoping to do a soft-serial implementation.

Perhaps its kind of silly but I didn't want my USB controller to be larger, more expensive, and have more pins than an embedded CPU itself (but when you get right down to it, it is in fact on par or more powerful than the 328p)! So the tiny part size combined with good features was the clincher for me.


Documentation

Cypress/PSOC 3, Arduino/AVR 10

The Cypress Application Note search tool is totally impossible to use. And their community site www.psocdeveloper.com is better but not "alive" like the Arduino or even avrfreaks. Its too tightly coupled with Cypress I think.

And none of this stuff comes up in google searches.

Note to Cypress -- you are NOT a SEARCH company! Just post all your App Notes in HTML form on a public site and let Google do the job. It will do it much better and you'll save some money.

One wild/good thing; I posted an issue bringing the chip up and actually got an essentially unsolicited telephone call from a real human being engineer the next day to help me (but had already figured it out). So that can make up for a lot of doc issues, but of course its pretty expensive for Cypress...


Hardware Design

Cypress 2, AVR 10

2. Application Schematic? It seems that Cypress didn't bother to put one in the datasheet. In fact I had to glean portions of the full "typical application schematic" from a bunch of "Application Notes" -- USB from here, ISSP from there. And of course those schematics were not necessarily for the chip variant I chose so there was lots of uncertainty in this process.

In contrast the Arduino project and all its variants are open hardware, so there are lots of circuit examples to choose from.


PSOC Designer vs Arduino IDE

Cypress 5, Arduno 5

PSOC is supposed to be some reconfigurable hardware "magic" that requires a fancy windows-only IDE. Not in my chip. Everything is just registers AFAIK. But still you can use a GUI to configure things and then it generates the code to write these registers for you. Now, this might seem cool, but actually it just gets in the way. It gives Cypress and excuse to not supply an API like the Arduino's "pinMode" and not to supply good docs. So what if you want to CHANGE the behavior of a pin while your program runs -- you've got to delve into the registers...

The rest of the IDE is everything you'd expect from a programmer's IDE. Good job Cypress! You are just as good as the free Eclipse :-).

However I do have one or 2 beefs. It:
1. Only runs on windows *sigh*
2. Pops up an irritiating "Programming" dialog box. This should be done in a small side-docked pane so the programmer can continue to WORK while the chip gets programmed...


Build Toolchain
Cypress/PSOC 5, Arduino/AVR 5

G++, GCC???

For some reason, instead of adding a gcc backend for the PSOC CPU, Cypress decided to go with some commercial C compiler. So no C++.

The result is a bit more like "Kiel" C then gcc and in particular has irritatingly difficult tranlation between a string stored in "flash" vs one in "ram". In fact, you have to define 2 functions one to handle "__flash" strings and one to handle normal "char *". *sigh*

But of course Arduino has this strange thing called "processing" with is actually C++ with some "try to help me but actually get in the way" thrown in so really average marks on both.


How to "Blink" (Basic programs/sketches)

Cypress/PSOC 7, Arduino/AVR 10

Its pretty INSANELY hard to figure out how to do simple things like configure a digital input (you use the GUI to graphically set the pin as CPU open-drain, then in code write the bit HIGH). Also standard C functions like "printf" are there but don't work... better that they not be there if they don't work.

Yet at the same time, it can be very EASY to do an entire USB HID device. So it just depends on how many Cypress libraries you can use.


Software Layers

Cypress/PSOC 9, Arduino/AVR 9

Ok, I've got to give cred to Cypress for being the 1st hardware company (AFAIK) to realise that we don't want to program at the register level. Yes, the GUI has "user modules" and you just pull them into your project to get massive functionality like a USB endpoint.

One nasty issue the use of lots of assembly??!!? All the Cypress libraries AFAIK are written in assembly. This makes reading the code hard :-). And also you can't ignore it; installing things like interrupt handlers requires you to get down in there and call out to your C. And this is NOT easy; to make the C compiler correctly save state, you have to basically trick the CPU into calling your C routine as if it was an interrupt even though you are already IN an interrupt. There's an entire App Note about how to do it :-(.

The advantage is probably smaller code sizes. But the cost is essentially that if you need to modify the library or add a feature, you have to either rewrite the whole thing yourself in C, or learn PSOC assembly which of course ties you and your work inseparably to this processor.

Summary:

Its a neat little device with lots of potential. Great hardware, great software/support philosophy but not so good implementation. But its a pretty steep learning curve...

Now, Arduino/AVR generally relies on the community to provide great programming libraries, examples, tutorials and general help. And we do.

Cypress seems to be doing all/most of the work on its own. It seems to be caught attempting to implement a modern philosophy with a traditional unidirectional information-flow structure.

So while I give cred to Cypress for the tremendous effort I'm amazed at its total disregard for the open source movement -- in compilers, in IDE, in software libraries.

And I'm surprised at its inability to truly capitalize on internet resources and community.

Lightuino Design Thoughts

From references

In designing the Lightuino I wanted to improve on my existing CCShield in several ways and provide an alternative to the Rainbowduino (which is also an Arduino compatible LED display board).

New Features!

NOT (necessarily) a shield!

The biggest change is the addition of the ATMEGA CPU, clock, etc logic, making the Lightuino a standalone board!

Of course, you can still use it as a shield, either WITH the ATMEGA populated or WITHOUT (if the ATMEGA is not populated, it MUST be used as a shield of course). And you can stack them. If it is stacked, it ought to let you do some really interesting distributed computing stuff.

By integrating the ATMEGA on-board, the total cost is a lot less, since you don't need the Arduino board. And its a lot smaller too!

Separate LED power Regulator

An LM317T was added to the board, with a 10k adjustable POT, so you can deliver consistent power to the LEDs (or to whatever) even if your wall-wart is unregulated. As long as your wall-wart provides the voltage, you can go up to 30+ volts, allowing each CCShield sink to control a string of LEDs. However the M5451 chips can only handle a 13 volt differential, so you must make sure that the voltage has dropped down to this before it enters the chip.

IDE cable headers

If you are stacking Lightuinos, the IDE cable header does not quite fit in a stack, so right angle headers are available.

The IDE cable pinout was also changed to put all of the power lines on one end, and to NOT provide a ground line unless a jumper is inserted on the board. Additionally, the pinout is the same on both sides (instead of upside down). This makes it a lot easier to wire up the LEDs AND also makes it very difficult to accidently burn out a LED by wiring it up to ground (for example) instead of to a current sink.

Finally, one of the lines is unassigned, and accessible via a pin on the board. So you can push whatever signal out that you want!

Pin Selection

Just like the CCShield, you can select whatever Arduino (digital) pins you want to control the LED portion of the board. But the CCShield's pin selection was difficult as it used extremely small SMT pads. The Lightuino simply has a section of the board with some thru-holes and you use jumper wires to make the selection.

Brightness Adjustment

It turns out that the M5451 chips can drive the LEDs at a barely discernible difference in brightness, so trim pots were added to the brightness adjustment to allow you to make the chips output the exact same light intensity (or actually, you could make one chip output bright, and one dim). Of course, this can be simply populated with resistors to save $ if exact brightness levels are not needed. It is unlikely that these will be needed for casual use.

Extras

The ATMEGA 328 QFN package has 2 additional analog inputs, so I brought those out by simply extending the Arduino standard pinout.

Also, I had extra space so I threw in the footprint of a voltage divider per analog input pin since that is a very common circuit. Just add your own resistors, and you are all set!

Comparison with Rainbowduino

Matrix?

Let me start by saying that I don't have a Rainbowduino, so this is all conjecture from reading the specs. It seems to me that it was mostly focused on driving an RGB 8x8 LED matrix display. In fact you can even plug a matrix directly into it. I was more interested in driving individually placed LEDs for art projects. While LED matrices are cool and have their uses in signage, frankly, if I wanted a big screen I'd just buy a flat screen TV! But whatever floats your boat. :-)

Of course, you can always use a LED matrix electrical connection, but not have the LEDs in a grid, but it is trickier to do that wiring... additionally you can use the Lightuino to "sink" the columns of an matrix (70 columns instead of just 24!)... but you would need to power the rows with some other circuitry. So again, its trickier :-).

Shield Compatiblitity

Additionally, the Rainbowduino does not seem to be Arduino shield compatible. This seemed to me to be a major drawback as it does not take advantage of the vast community of shields out there that can add so many cool features to a project!

CPU Power

The ATMEGA 168 is pretty limited in RAM, as I found when working with the normal Arduino, so I moved up to the 328 with double the RAM.

LED Capability

I opted for 2 chips that can drive 70 constant currents outputs at 20mA, the Rainbowduino allows you to drive fewer outputs (24) at higher capacity (120mA).

PWM Dimming

I wanted to experiment with POV art (i.e. a light strip that forms an image floating in space when your eyes flick by it, or spinning a strip to form in image in a circle) and to do that you need precise control of when the LEDs are ON vs OFF. In other words, a separate PWM chip won't work. However, this means that the Lightuino has to drive PWM in software, just like what the Arduino's PWM pins do. At very low PWM levels (say 10 on out of 256 counts) you can perceive the LED blinking (and of course more Arduino processor time is used). Therefore, you end up with another tradeoff, precise control over the blinking of each LED verses faster blink rates (note, I'm just assuming the Rainbowduino has an external PWM, but I haven't verified that).

Lightuino V2.0 -- An Arduino compatible optimized for driving LEDs

The CCShield board was pretty successful and I had a lot of fun with it, so I decided to do another run. I wanted to attempt some surface mount work but at the same time not produce a lemon if it did not work, so I created the hybrid board you see above. The board has a complete Arduino-compatible subsection on it implemented using surface mount parts and the CCShield (plus some extra goodies) implemented using thru-hole parts. The idea is that the board can be used as a shield if the surface mount parts are not populated, or used standalone if the parts are.

Another cool feature is that you can stack them -- so I can experiment with running a bunch of processors simultaneously.

I'll be adding a couple of posts about this board. This first is about building up the surface mount parts. The image above is the board with the surface mount parts baked on and the minimum thru hole parts added to bring power and the ICSP programmer on.

I used the smallest part I could find for the CPU, QFN-32 and 0603 parts for the resistors and caps. The tricky part of the QFN32 package is that the leads are underneath the part, making it hard to repair solder bridges.

To make my surface mount station, I "rescued" an old toaster oven from the dump and "splurged" on some solder paste, rosin, and wick from dealsextreme dealextreme. Then I bought some .5mm mechanical pencils from Staples, some tweezers from Walgreens. Total cost about $20.

This supplemented my current thru-hole solder station that consists of a plastic clamp (Home Depot) to hold a circuit board, a radio-shack 40 watt soldering iron, and an old a magnifying glass/light on arm combo from the basement (really its the bright light that's important).

I then used the mechanical pencil to "paint" the solder paste on the leads. For the QFN part, I just laid the paste across the leads and then used an Exacto-knife to "cut" the spaces between them. It seems like the biggest pitfall is simply using TOO MUCH PASTE. You want just the thinnest layer, and do not even cover the entire pad!

Then I just placed the components in their positions using the tweezers, and did fine adjustment of the QFN32 part with the edge of the tweezers.

Baking was easy. I followed the temperature profile here. But not really... I used the thermostat on the oven, not a real temperature gauge. Basically, just set your oven for 170 C put the boards in and wait 3 minutes. Then raise the temperature to 220 C and shine a bright light in so you can see the boards clearly. After a minute or two the solder will go from grey to silvery. Wait another 30 sec to a minute to be sure that ALL the solder has gone silvery. Then turn off the oven (but leave the boards in there) and crack open the door. You want to cool the boards evenly. After a few minutes, open the door fully, and when they are cool to the touch, pop them out!

I did 4 boards and had 2 solder bridges on the QFN parts. Every other part worked without any issues.

If you have a bridge (you can see it), paint the entire side of the part with a gob of rosin. Then place your solder wick over all of the leads and heat it all up with a clean iron on top of the wick. The rosin will help the solder flow and it will either flow onto the pins, or onto your wick. Easy!

So if you are a DIYer who has been leery of using SMT parts, I'd say "go for it"!

[edit oct 15, 2009: I just did 12 successful boards without any solder bridges. Mix 50/50 paste and flux so the result is viscous like maple syrup]

Arduino + wireless + reconfigurable hardware: A proposal

I am thinking about doing a quadruple whammy Arduino board: Atmel Mega 640 + CPLD + wireless + MicroSD card.

For those of you who are unfamiliar with the term "CPLD", it is a reconfigurable hardware chip. Essentially, today's CPUs all follow what is called the "von Neumann architecture" in which a CPU executes a set of instructions in a sequential fashion. A CPLD is very different. It is a "sea of logic gates", so it essentially executes every instruction simultaneously. So if you visualize a plot with the horizontal axis being what can be done per unit time, and the vertical being how much time to do a task, the CPU plot looks long and thin. It can't DO much per unit time, but you can string together many instructions to do complex tasks. The CPLD plot looks short and fat. It can DO a lot per unit time, but cannot do complex tasks since tasks must be completed in essentially 1 time unit. CPUs are much more well known both because they are programmed in a manner more intuitive to people and because ultimately you can get a lot more done with a CPU. However, their linear nature means that there are things that CPUs do not do well, like simultaneously and monitoring rapidly fluctuating inputs.

The reasoning behind integrating a wireless network and MicroSD is much simpler. First of all, the MicroSD card has a very simple interface (8 wires) so its easy to plop down and very useful for data recording, etc. Its so simple there is no reason to NOT integrate it. Purchased separately, a wireless network is expensive. You must buy a shield ($20-30) and a wireless module (another $20-$30). So this ends up being an additional $40-$60, not that expensive until you consider that the most interesting uses are to have not just one or 2 devices but to have a "cloud" of them. So for 10 devices, that would cost $500 -- outside of the casual hobbyiest budget. However the basic wireless chips cost about $4 for single quantities, and maybe $5 when the few additional parts are added. So an integrated wireless would cost an extra $50.


It seems to me that once you leave thru-hole chipsets, the casual user can't just plop the AVR down on his own handwired circuit board... but if people are OK with that (and it seems like they are given how many other surface mount Arduino clones exist), then it really opens the door for a base platform that hits key features that the Arduino is missing today. If the chips are integrated into the base platform, this platform becomes MUCH cheaper and smaller then buying all the shields separately. The final result is a tiny computer with the all the essential components of a "standard" PC (CPU, network, disk) AND the components required for a high performance/high IO embedded device (CPLD running at 100mhz with 50+ digital IOs). This combination can be used for sensor networks, cooperative mini-robotics, illumination, art/design projects etc and would probably cost around $50 or less.