I have mentioned in my blogs on Android and Bluetooth (see list below) that I am using the PSoC5 as the microcontroller that gathers the data and then transmits it over the Bluetooth network. This has been a monumental voyage of discovery for me, as I am learning Android, Bluetooth, PSoC5, and several ancillary fields along the way. These are my first lessons from the PSoC5.
Processors determine your code density, speed of execution, power dissipation, and code execution efficiency, but once you are programming in a high-level language, some elements are beyond your control. Unless you are working right on the edge of what is possible in these areas, many times you don’t even care.
What does play a much bigger role in your design is the peripheral set. I can tell you one thing -- the peripheral set of the PSoC3 and PSoC5 is unlike any other microcomputer on the market today. The PSoC3 has an 8051-based core while the PSoC5 has an ARM Cortex M3 core. As far as I can tell, the peripheral configuration is almost identical between the two, with the exception that the PSoC5 can have two 12-bit SAR analog to digital converters over and above the Delta Sigma ADCs already in the mix. The only differentiating selections you can get are memory and package size and the aforementioned SARs.
The PSoC’s claim to fame is its configurability, right from the days of PSoC1. I have done quite a bit of work on that foundation, so the transition to the more advanced devices has not been too difficult, at least in the short term.
The PSoC3/5 is made up of analog and digital sub-blocks that can be configured to form the sort of peripherals you would expect in a microcontroller. Within the chip's resource limits you can configure the exact peripheral set that you need. This peripheral set gets initialized in software, and so you can have one board work for many projects that depend on different setups.
But that is only the beginning. Listen to some of the peripherals you can add (in addition to your standard ADCs, UARTs, timers, PMWs): debounce inputs, CRC generator, programmable gain op-amps, comparators, logic gates, lookup tables, and much more. And you get to configure them by wiring them rather like you would with a schematic entry tool. The figure below shows a wiring combination of a multiplexer set feeding some amplifiers (obviously with programmable gain). I placed the pins and wired all the connections. Any pin can go anywhere, although some routes are preferred for analog.
If you don’t like the peripherals the chip offers, you can create your own using Verilog and the chip's programmable logic. I think it will be some time before I use this capability, but you have to admit that this is different from your usual microcontroller fare.
Let’s look a little further at the versatility. In my application, I am reading from a 12-bit ADC and passing the data to a UART for Bluetooth transmission. The simplest, fastest method is to connect a DMA controller between the ADC and the UART, leaving the micro to twiddle its thumbs. There is a slight hiccup though. I really only need 8 bits of data, so I could halve the transmission time if I got rid of the least significant four bits. I could use the micro to do that, but check out the circuit shown in the figure. The programmable logic lets me accomplish the task in hardware.
I can get a DMA controller to write each byte to a 12-bit shift register (within the blue line) and get that register to shift 12 bits out into an 8-bit shift register, leaving the most significant 8 bits, which I can then DMA using another controller into the UART. All this is configured on the internal “fabric” of the device.
But wait! Let’s stretch this idea a little further. Suppose you wanted to add a CRC to the end of the transmission. You could pass the data into the CRC register at the same time -- we just have to think a little on what hardware to add so that we are clocking only the relevant bits. All of this and the processor has done nothing yet. This is really fun!
Now I don’t want you to think that this is all wine and roses. The PSoC Creator tool that supports PSoC design -- free with a Keil C compiler -- is still somewhat immature. Cypress only just added rubber-banding of the interconnections. The DMA wizard only handles ADCs, DACs, and memory -- all the rest you have to hand code.
It appears that I am working quite near the limit of what the tool can support. I placed two test pins, for instance, to check what was happening internally. The build allocated two external pins. I didn’t want that allocation to change, so I then locked the test pins to those the tool originally selected. But on the next, identical build, the system was unable to find a solution. This surprising failure was probably the most troubling aspect of my first encounter with the PSoC.
Watch this space as I start working with the PSoC in more detail. Meanwhile, any questions?
Related posts: