PSoC™ 5, 3 & 1 Forum Discussions

If you are running out of FLASH space these might help -

1 - If any float math minimize the number of lines you do divides, if possible convert
to multiplies. Convert float to integer math where possible. Pay attention to factoring
of expressions, possible operation reduction, hence code reduction may result.

2 - Lines with function calls, minimize f(g()) compound typed expressions.

3 - Make sure you only use a variable type no larger than needed.

4 - Use unsigned variables wherever possible.

5 - Watchout for structures with mixed const and ram pointers within them,
some compilers choke on this.

6 - If you are heavy on Flash, light on RAM use, convert routines to RAM based
wherever possible.

7 - Try test cases of looping structures, to see what affects code size generation.

8 - Examine .lst file for code that looks wacky in bytes used, understand what
compiler did, and consider rewrite.

9 - Use inline ASM where .lst file C generation looks excessive.

10 - Look at module reuse, sharing, dual purpose, to eliminate # modules 
needed, like counters/timers....Also look at data sheets of modules that could
serve function needed, and compare ROM/RAM requirements needed. Optimize
global HW, like clocks VC1/2/3/Sleep, to eliminate need for other timer/counters.
Use register routing control to "share" module from one task to another, one pin
to another.

11 - Extended library, functions within them are written to be perfectly general,
hence larger code size, you may be able to write one with less code needed for
your specific requirements that result in smaller code size.

12 – Look for approximations to compute transcendental functions if used.

13 - Although no longer supported by HiTech or Cypress, the HiTech Pro compiler
yielded on first try ~ 40% code reduction in my design when I first converted
to it. Then the prior comments yielded another 4 K later in design as I was up
against 32 K Flash limitation.

14 - Some compilers have a setting to optimize code size or speed, the latter
prone to larger code size. Also look at compiler vendors web site for ap notes
and suggestions on optimization, compilers from different vendors behave and
optimize  differently.

15 - const data, strings, etc.., look for ability to reuse common string mnemonics,
text.

16 - Pointer usage can lessen code size, see url's below. Look for function calls
passing longs as value vs pointer, convert to latter. Compiler has to copy all these,
if not referenced. Do not pass longs or floats as values, keep always in mind native
machine size.

17 - Most compilers will optimize when indexes, pointers, a power of 2, or divides,
divide becomes a shift.

18 - Look at how linker distributed code and data segments, sometimes you can discover
a poor decision by linker and force code/data into certain psects using pragma constructs,
thereby minimizing wasted ROM space.

19 – When you debug generally you want to turn off optimization, as compiler/linker will
remove code and make jumps that do not make “sense” but are the result of optimization.
When you are up to Flash boundary you may not be able to turn it off, otherwise
application will not load. Keep this in mind, that  your debug strategy may have to change.
I also found if using ICE Cube that debugger may no longer report “watch” variables, this
occurred at ~ 31.5K bytes. In either case you may want to comment out large code sections
to effectively debug.

20 – f() calls take overhead, if you only call a f() once you might eliminate it as a f()
call and place code inline.

21 – Look for f() opportunities, wherever you are coding and repeating similar  operations.
This is obvious, but sometimes missed.

22 – Check compiler on macros, to see if they are being optimized or just being used inline
using more code space vs a f() call solution.

23 – Examine compiler/linker parameter control. For example in HiTech there is the AUTOBANK
setting that controls where local variables are stored, in my case setting to 1 lowered code
size by ~ 250 bytes. READ the MANUAL !

24 – Use inline variable declarations, vs pre declaration (compiler dependent) -

 This  void dosomething ( void  ) {

    for (  unsigned char I = 0;…..
   }

 Not This void dosomething ( void  ) {

   Unsigned char I = 0;

    for (  I = 0;…..
   }

Some help -

http://www.codeproject.com/Articles/6154/Writing-Efficient-C-and-C-Code-Optimization

http://www.eventhelix.com/realtimemantra/basics/optimizingcandcppcode.htm

http://www.azillionmonkeys.com/qed/optimize.html

By using these techniques I was able to regain ~ 4K Bytes of code space in a 32K design, which
I promptly used up again 😞

Regards, Dana.

Below is an amazing blog post by Mark Hastings! Just can't resist reposting it here on the forum so that the members can make best out of it.

PSoC Creator 2.1 has just been released and has even more good stuff to help the user design and debug his or her application.  I know that many of you at times wanted more information on just how your signal was routed from a GPIO pin to the DelSig ADC or how an internal signal was connected between a VDAC and Comparator.  Well, wait no more!  Now you can look at any analog route, lock it down and even change it if you have a preference.  Even better, you can do all this graphically.  Here are a couple slides that I created a few months back for an internal training class.  This should be just enough to peak your interest about PSoC Creator 2.1. 

The following is an actual screen shot of the Analog Device Viewer/Editor.  If you look close, note that all the resources used, including routes are highlighted.  You can click on the nets on the right or the graphical routes on the left to examine the nets and routes.

Example Circuit

Below is an example circuit and the analog viewer s representation.  Note how AMux_1 consist of the light blue traces.  It is easy to understand just how the signals are routed and exactly the resources used to create the circuit, no more guess work!

Lock down signals and component placements graphically

Many of you at times wish you could easily lock down blocks that are used for a specific component implementation.  You may have learned to use the constraints editor but found it a real pain trying to remember the syntax.  I know I did.  Now you can graphically lock down or move blocks right in the analog editor.  I can almost hear the cheers in the background from you seasoned users.

Analog Mux and Simulation

Ever asked yourself I wonder exactly how my analog mux is implemented?   I know I have.  Now you can go into the tool and connect the analog mux one channel at a time and see the actual signal path.  No more laying awake at night wondering if your signal took AGL[6] or AGL[7] on its way home to the ADC.

View analog switch names, registers, and masks.

This feature is for the real hard core guys that want to know the actual register and mask to control each analog switch.  Now just by hovering over a switch you can get all that information.  No more digging into that big 1000+ page document to try and figure out how to control that one switch.

Measure typical route resistance with an Ohm Meter

This is another cool tool.  The Ohm Meter tool lets you measure the route resistance between any two endpoints of a signal.  Of course the measurement is not exact, but it gives you a ballpark number of what to expect. ( Please ignore the significant digits of the ohm meter reading in the figure below, it has been rounded off in the current version.)

Toggle analog switches interactively in the debugger

This feature is really powerful.  While in the debugger, you can view the state of almost any switch.  The only ones you can t monitor is the state of any switch that is controlled by hardware, such as the hardware mux.  All other analog switches that are part of a route, or controlled by software can be examined interactively.  So each time you halt the operation in the debugger, you can actually view the current state of the switches.  But wait, there s more!  You can actually toggle the state of each switch as well.  This means you can debug any route you want and interactively see what happens when you open or close a switch.  I often use a spare route and pin to internally probe signals.  Yes you heard me, this allows you to probe internal nodes while the chip is running.  If you don t like this feature, you shouldn t call yourself an engineer!

Set breakpoints when a switch opens or closes

OK one more amazing feature.  Just think of being able to click on an analog switch and set a breakpoint when that switch opens, closes, or just changes states.  Yes not kidding!  I dare you to find another vender s tool and MCU that will let you do that!

I hope this was just enough information to give you a taste of some of the new features in PSoC Creator 2.1.  So don t delay, go download PSoC Creator 2.1 and play with some of the new analog debug and design features.   If this isn t enough there are even more features to help you get your design to market faster.  You can download the new feature packed PSoC Creator 2.1 here.  So don t delay, go checkout all the good stuff!

I designed a board for a client of mine, and the board uses a PSoC 5 chip.

I got a whole load of boards made at a contract manufacturer and the client began testing them.

They all worked really well, except one small issue with one board, which I thought would be something simple.

The issue with the one board was that it could only be programmed with the 5-Pin header. When hooked up via USB windows did not detect the device at all, so it could not be programmed with BootloaderHost - and the customer needs to be able to flash via USB.

I got the board sent up to me for further investigation.

The board powered up OK, and ran though all the self tests perfectly, with the one exception that it did not appear as a USB device during boot. I thought it'd just be a connector or soldering issue.

When I looked a bit closer at the board I discovered that 7 capacitors were missing around the PSoC - in fact, all the 100nF caps were missing on the power rails going to the PSoC. For some reason yet to be determined, the manufacturer had missed off the decoupling caps at the PSOC.

Then I noticed somethint else, something far more interesting - there is a small, but deep hole in the top of the PSoC. Yip a small hole in the chip! It has a bit of charing around it. I assume something has gone POP inside the chip. It is strange that the only function not working is USB! I have attached a photo and you can just about make out the hole in the PSoC chip - and this board still works - all apart frm the USB functions!

This device only connects to GND, D+ and D- of the USB connector. The +V pin on the USB Type B connector is not used since we do not source any power from the USB host.

 I already followed all the instructions posted on this website:

http://www.cypress.com/?id=4&rID=54068

Or the instructions on the CapSense_CSD[v3.10]  datasheet, section CapSense Tuning Process, page 30; and I still have problems when I click Start on the CapSense_CSD Tuner. I get the message:

Read operation failed! Check I2C bus connection.

Is there any further instructions, like some code I have to add or some pin assignment for the EZI2C that haven't been included in the datasheets?

This is my code in main.c:

void main()

{

CYGlobalIntEnable;

CapSense_CSD_TunerStart();

EZI2C_Start(); // Extra line attempting to fix the connection problem.

EZI2C_Enable(); // Extra line attempting to fix the connection problem.

while(1)

{

CapSense_CSD_TunerComm();

}

}

Thank you!!

最近看收到的书，发现两个问题。

1.PSOC3内的PLL,通过设置__因子和__因子，产生需要的系统时钟频率。

是输入因子和反馈因子吗？

2.PSOC3内的ILO主要用于__和__模块。

是时钟模块和电源模块吗？

请高手指教，谢谢！

 Hello,

         Can i implement Speech Recognition using PSoC3(Cy8C001 kit)??

Here is an issue I came across on the dev kit for PSOC5 (I think it is ES1). I have mostly resolved it by changing routing internally, but am throwing it out here in case its useful or anyone has any insights.

I have an input square wave signal that is variable in frequency and I need to sample this to determine the result of the instrument (a gravity meter). This particular frequency is on the order of 7 kHz and needs to be resolved to 0.005 Hz. I can take a couple of minutes to arrive at this resolution.

I decided to "clean" the signal by running it through a comparator, so I chose one of the SIO pins with a voltage comparison. The nice thing here is the signal becomes a great looking square wave that is synchronized to the internal bus clock. I used an external OCXO (26Mhz) as a frequency input to a pin just to get that extra bit of precision (used this as masterclock). To arrive at the frequency with minimal noise, I tried many different peripheral arrangements, but I can get to those later, as depending on timer/counter/capture/trigger routing etc, there was additional "noise" added.

The interesting thing about using the SIO as the input was it introduced frequency "noise", I guess it could be called jitter. It did not matter what reference voltage I chose. The syncronized squarewave that came out of this arrangement had lots of error (i really can't recall how much). I don't know if this is related to the voltage reference being slightly unstable, or the internal comparator being slow or something else

This I was able to mitigate by changing the routing. Turned out that from trial and error I got the best results by using an analog input pin, followed by an opamp buffer. This signal was fed into a comparator with 0.256V reference, and following this the output was fed into a sync component.

This arrangement gave me much better jitter probably 10 times better (lets say 90% of the time)

Now of course I am wondering can I get into one of the components and use an non-synchronized (dangerous!) clock signal...