PSoC™ Creator & Designer Forum Discussions

I would like to generate a pointer array in flash (ROM) initialized with the addresses of tool generated variables (G4 CapSense data from the structure) for tuning and general debugging.  This way I'm able to use a loop to index the data without using the macro "CapSense_BUTTON0_SNS0_RAW0_VALUE".  I've tried named areas and assigned the area to flash in the build settings for the linker. 

I understand

const uint8 Variable = 0x12;  // Put in flash.

needs an initializer to put it into flash.  Otherwise the compiler create a RAM variable.

const uint8 Variable;              // Put in RAM.

Here is a snippet of the declaration.  The comments added are what I've determine by using the debugger to confirm the compiler's placement in memory.  I have successfully used a struct in a named area in flash with initializers before, so I'm puzzled why the declaration and initialization does not work.

uint16 * const VariableCapSense_sensorRaw4[] = // INCORRECT array in FLASH of random? addresses.

{

&CapSense_BUTTON0_SNS0_RAW0_VALUE,

&CapSense_BUTTON1_SNS0_RAW0_VALUE,

&CapSense_BUTTON2_SNS0_RAW0_VALUE,

&CapSense_BUTTON3_SNS0_RAW0_VALUE

};

 This should be the correct construction - VariableCapSense_sensorRaw4[] is an array in const memory of pointers to uint16's in RAM.

But my results placed this array at address 0 according to the debugger.

I just installed version 4.1 of Creator. Now I see a squiggly blue line under my #include statement for one of the includes and a yellow warning triangle in left margin. There is nothing in the "Warnings" window. I have been using this project for ages in creator 4.0 without this being highlighted.

Project compiles ok but annoying having a warning showing without understanding what it means

Made a mistake of updating to PSoc Creator 4.0.  Now the debug does not show the variable value, just the address.  Tried to go back to Creator 3.3 but it's not compatible.  Are you guys aware of this problem?  When will it be fixed?  How can I go back to 3.3?

I have been looking at adding a 9-clock-cycles to an I2C application and since the component does not provide a function to reset a hung SDA, I was wondering if I could insert it in the I2C_Init function of the component.     It seems to me that the use of a callback would be perfect, but looking into how they work I ran into the following thoughts/questions:

- If I understand it correctly, the component generated code has to have defined hooking points.    If that is the case, the callback functionality has limited value because components barely have any hooking points.   

- If I develop a new component containing hooking points in the generated source, would just the existence of the hooking point(s) and the proper user request entry in cyapicallbacks.h,  result in executing the callback ?   Or does the developer need to do some additional work

- Again, if I was to develop a new component X that uses an existing component Y that accepts a given callback, and I needed to use the callback, then it seems there is no way to perform the callback hook definition within the confine of the component X context.   The component X user will need to know the need to set in cyapicallbacks.h, which does not seem that desirable to me.   It would be nice if there was some kind of a definition mechanism to hook the callback in Y (other than typing in cyapicallbacks.h) 

- Is it fair to assume the use of Merge Region has some similar peculiarities?

May be I am a bit (or a lot) confused in my understanding...

Tony

Is it normal to have PSoC 4 generated code tree for a PSoC 5 device?    I would expect to generate only the PSoC 5 tree.      

Tony

OK, here's my conundrum....

Been working on a design for a year, been through lots of iterations.  I wanna start with a clean slate, preserving the pinout and most of the instantiated components.  Does anyone have a suggestion short of manually re-entering the pinout and copy-paste between the projects?

Any help is much appreciated!

Thanks!

Scott