You are here

Batch build project with changing preprocessor defines | Cypress Semiconductor

Batch build project with changing preprocessor defines

Summary: 1 Reply, Latest post by danaaknight on 04 Jul 2015 02:43 PM PDT
Verified Answers: 0
Last post
Log in to post new comments.
swohler's picture
4 posts

 I've read a few forum posts that come close to describing how this may be done, but none of them have so far answered the question.

Basically this is what I need to do:

I have a PSoC Creator 3.2 project for a PSoC3 device. I am using the Keil C51 toolchain. For each output device I need a unique number (let's call it an address) that I hard-code into the source via a #define.

I need to generate 100s of HEX files with different values compiled into the source. What I'd like to be able to do is automate the process so that I can let it run on its own without worrying about it. It is going to be a huge waste of time and effort to manually change the value, re-build the project, and re-name the resulting HEX file for each value.

Ideally for each value change, the output file should contain the value in the filename.

For instance, if the pre-processor is:

#define VALUE  23

the generated output file should be:


Where XXX is the version number pulled from (or pushed into) another source file. Or something like that. If I had control over the generated filename that would be even better.

I recognize that I can pass DF flags to c51, but that is only part of the process.

In any other (non-Cypress) project, I'd have a Makefile where I could script the generation process. However, because of the layers of code-generation for these devices, it doesn't seem feasible.

Is there any way to do this with cyprjmgr? It doesn't appear to have flags for making this level of change.

My other alternative is to script the process with python, modifying the source file from the script, making subprocess calls to the cyprjmgr utility, then renaming the resulting output file. This process is a little clunky and requires iterative testing to get right.

Does anyone have a reasonable alternative to accomplished what I've just described?

user_14586677's picture
7646 posts

I am sure you have seen the thread(s) on unique silicon ID, or a lack thereoff.

Several wafers in a lot will have die in the same x - y position on individual

wafers carry the same ID.


Your last comments on Python is not too clunky, fairly simple I would think. Except

for the time of builds seems a reasonable approach. Or the device ID chips, pretty

cheap these days, one wire, small packages. IDs big enough to handle the Galaxy.


Regards, Dana.

Log in to post new comments.