You can look at all the PSoC5 example projects in the find example catalogue. There isn't much diff between component APIs of PSoC3 and PSoC5. Most of the code is interchangeable from keil (PSoC3) to ARM (PSoC5). The data types and other diff can be found in System Reference Guide.
When you start a new project in creator 2.2 you get the choice to open some pre-defined examples. Have a look at these to see, how hardware and the associated c-program work together.
also in Creator you can open example projects featuring the usage of each component.
Does PSoC creator have example arm projects which don't utilise any of the psoc visual peripherals and just use the ARM core?
i have been wondering about how it works with the ARM core surrounded by all this cypress hardware like remap able pins. How does one code for only the ARM processor. How do I connect the pins of it to the cypress remappable pins?
bit confused on how it works coming from a PIC background where the processor and some peripherals are all you have .
All the connections inside the PSoC chip are made using "Registers" which are mapped into the address-space of the ARM processor. All this is documented and there is a TRM just for these registers. The routing is done using switches that "Look" at a register bit and get switched on or off.
The good news is that you do not need to know these internals, all is done by the code-generation which generates HDL to build the hardware.
The difference between a PSoC and a "pure" ARM-driven computer is obvios: The ARM-solution needs some additional hardware to communicate to the outer world while the PSoC already contains all external connections, you just habe to name which you need.
There is an extensive video library on using Creator, the tool for
PSOC 3/4/5LP. No so much on the ARM core itself. The philosophy
of design is C oriented coupled with GUI components, like A/D, UART,
LOGIC elements (gates, flops, buffers), LOGIC functions like counters,
timers, PWM, interface (like SDCARD, other memory types).........
Not to minimize core, you can still do micxed assembly/C, or a totally
assembly design, but that would be unusual these days. No one wants
to reinvent writing firmware from scratch if possible. One uses all the
pre-written firmware in the tool as f() calls and can design at a much
So you drop a component onto schematic, double click it to config
its basic properties, then open datasheet to see all the API calls you
can use to interact with it. Additionally there is a wiring tool to connect
component signaling to each other/pins.
Video library ( start with "psoc creator tutorials", search the library for that )-
using only plain C is not 'the PSoC way' of doing things. In the PSoC, one tries to do as much as possible in hardware. This might involve creating own components, but even without them one can do much magic :)
using only plain C is not 'the PSoC way' of doing things.
Not sure what the "PSOC way" is. Here in Boston, myself and 2 other FAEs covered several
hundred accounts. The general consensus, unless things have changed in last 5 years, was
ASM in decline, and full ASM type projects represented < 10% of the designs, and declining.
Excepting the occasional inline ASM and small targeted routines to "fix" CPU and HW limitations.
C drives time to market, and of course maintainability over product lifetime so much better than
ASM. Not the ideal language, however, as one can easily imagine alternatives to C. ASM not being
one of them in my opinion.
The PSOC "way", if there is one, is the fine granularity of HW control via use of registers and FPGA
like techniques. The more recent mix of standard cores, rudimentary logic, analog, high level compo-
nents. and routability, a great mix.
In the PSoC, one tries to do as much as possible in hardware.
We also find that 90% of a design, in time, is software development. Most of the HW that PSOC
addresses is not leading edge per se, however targets much of the market volume. I think a HW
only focus leads one into a trap, as would a SW only focus. We want the best of both worlds, and
PSOC register based architectures allows one to move freely between the two worlds.
"The PSoC way" is configure the hardware using Creator or Designer (free IDEs on Cypress.com) to do as much of the work as possible (some projects, believe it or not, use virtually zero (0) CPU cycles). Use the filter wizard, and what have you to do some of the coding. Then write code, to do the rest.
It is vital, essential, key to keep in mind that PSoC is not (just) an MCU, it really is a SOC that you can configure and re-configure (the latter can be done on-the-fly). PSoC can do things that just aren't possible with an MCU in the same price range, and it's re-configurability makes it absolutely unique.
I should offer clarification of my previous statement: A few designs can use virtually no CPU cycles once they are configured (that is, the hardware is initialized).
Although the start of this thread is nearly half a year ago the same question comes up from time to time again, mostly from users used to PICs and similar embeddeds.
Yes, you may toggle a pin in code, although you will not reach a very high frequency compared to the bus clock uf 66MHz.
But this is not the target of a PSoC: When your goal is to generate a frequency coming out of a pin, let it be a PWM signal for instance, you just pick (not PIC) a PWM component, place, wire and set it up at design-time and you have got it. After starting the PWM in your program it will run unattended as long as power is applied, no wasting of MIPs! When you want to change the duty-cycle you will have to do that in code, but after the change is done, again no further processing has to be made to keep the PWM running.
Thinking PSoC is imho not "putting everything in hardware", instead an intelligent mix of hard- and software solutions will be that one that fits best to you as the designer. Incrementing a variable is easily written in C, nobody would think of using a counter for that. Nobody? Well, if the frequency is high enough a counter solution would fit better and the PSoC would allow for that. That is "Tinking PSoC"
2) DSP Engine
3) Core (ARM)
4) Register based HW configuration
6) Rich set of fixed function HW
7) Data conversion, low and hi res
Hi to all!
I'm a VERY new PSoC user and I love it.
I'm not a C programming expert and now I'm attending a C course to go deep in it.
Having a basic C knowledge you can do great things as I did and with the help here in the forum better even. I received help from Bob Marlowe and DanaaKnight and guided me thru what I shoud read or video to see and thats the way I bulid my project, and by the way, I'thankfull with this two guys for the help at that moment.
One thing is that you got to get out the PIC concept and go to PSoC concept, you have to do a balance between hardware and software, meaning, sometimes it's not correct to use ALL components that PSoC brings and sometimes it's ok, depends on what you're doing, sometime you don't ever use the mcu and only the components! I'm truly in love (lol) with PSoc!
"read" the examples cause it teaches a lot and try to understand PSoC philosophy.
Take this opportunity to thank everyone for the help they have given me at the time.