Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
A recent PSoC3 Problem Determination episode elicited a Cypress Forum suggestion to migrate from Creator 2 to Creator 3 in an effort to find the cause. This step was undertaken but with a large amount of trepidation as to what to do if Creator 3 resolved the problem.
A significant amount of development, which included extensive testing, was expended using Creator 2. My project is one of an embedded design for Data Acquisition and Control of some fairly expensive machinery; one where expensive damage to the machinery could occur if an error went undetected as a result of a migration. The damage could well exceed the profit that would accrue as a result of a customer purchasing my embedded system.
Being a small shop, I did not develop extensive regression testing procedures. I employed as much data independency as the Keil C compiler would support so that incremental changes to my C code would be isolated from other code. Granted this is not a fool-proof process.
During the testing of Creator 3, I took a few minutes to compare selected Creator 2 generated source files with Creator 3 versions. I particularly noted that the PS0C3 files of CyLib.c and ADC.c Delta Sig appear to be significantly re-written. I rely heavily on the ADC Delta Sig. Thus I am faced with having to re-do a significant testing effort if I migrate.
So far, Creator 3 testing has not solved the problem. But if it were to do so, would Cypress provide a corrective “patch” for Creator 2?
Creator strongly advises that Component upgrades be made when migrating to a new release. Do older component versions get regression-tested with a new release so that migration can be a slow process by a user without introducing transition problems as a result?