Close

Intro to PSOC

A project log for RoboBarista: A Coffee Brewing Robot

A flexible, open source robot arm that grinds, pours, and serves only the best robotic brewed Coffee.

Jim ShealyJim Shealy 05/01/2014 at 21:230 Comments

So what is PSOC? Why the heck would I use this over an arduino? 

The simple answer is this: FPGA (esque), large libraries, tons of documentation, useful IDE, Debugging

Doesn't make sense yet? It took me a while to get it also! I saw a cool kickstarter project for this development board (FREESOC) and after watching the video, it got me thinking that this chip had leaps and bounds more capability than the arduino!

Here's John Morello's video of the FREESOC, even if you don't know half of what he's saying (I didn't), it's really useful to start imagining all the possibilities of what you could do:

https://www.kickstarter.com/projects/18182218/freesoc-and-freesoc-mini/widget/video.html

If you didn't watch, PSOC stands for "Programmable System On a Chip". What makes it so special is that there are digital, analog, and communications components that work in PARALLEL with the CPU! If you look at the picture below the different boxes each represent a "parallel" component that operate independently of the CPU. 

Pretty neat isn't it? It's like your CPU is a person driving a car, you design the hardware on the digital and analog systems to be capable of navigating the track, and then teach your CPU how to sit at the helm and drive the vehicle you designed. The CPU doesn't have to do both at the same time!

Having used arduinos a decent amount, I've found that I get to a certain point of complexity and I suddenly have to start digging into interrupts. This is where the simple arduino code begins to break down and starts to get really ugly and confusing.

I've constantly run into this working with counters on Arduino. I need something to count to some varying value, but I can't afford to use "Delay" or "Millis"  because it makes my code really laggy, or isn't consistent enough. So, I turn to interrupts. They're neat because my code can jump from one thing to another, but all of a sudden I'm bit shifting control registers in the ATMEL and everyone's code that I'm trying to follow doesn't look anything like what I normally use in the IDE. Then, suddenly things start to break in ways I don't understand, and I won't even start on using multiple interrupts...

This is where the PSOC starts to become really neat. I can place a "counter" component, hook up a time source (clock), set the clock to a specific frequency, tell the counter "go" and it does what I tell it to do. Not only that, but your code can "set and forget" the counter because the counter will keep on counting, even if the CPU is asleep, or using "Delay", or whatever! Neat! And all I have to do is drag and drop a component, click it to set what I want, and we're done. 

So that's the long story of why I chose the PSOC to run this project. The CPU does the calculations to drive the arm, and the hardware and counters take care of the mechanics of actually incrementing/decrementing the stepper motor drivers to the correct positions. The CPU says how far and how fast, and the hardware takes care of doing it.

Now, that's not to say PSOC isn't without pitfalls, ESPECIALLY for a complete novice like myself at C and programmable logic. Check out the lessons learned with PSOC to get a better idea of what you need to do to actually get started and save (literally) hundreds of hours of frustration.

(I'll add the link once I get that page up, patience ;) )

Discussions