To all,

I've enhanced some of my previously submitted code shares (Terminal Component - Simplifies UART or USBUART communication and GetString() function that supports input character filtering.  Includes menu-driven commands. ).

I've now expanded these previous submits and placed them in a Component Library that can be easily shared with all your projects and with other users.

Here is a list of the components in the library:

• Term - Terminal (UART) replacement that can be configured as UART or USBUART types.
• String_Funcs - This is an enhancement of the GetString() function.  It is easier to use.
• MenuCmds - This feature was included in the GetString demo code I shared earlier.  It is now a component with some improvements.

With each of the Components, I have include at least one demo project for each component to illustrate how these components can be used.

I've also included datasheets for the Components, the demo projects and a instructional on how to install a library/component to be shared across all your projects.

All the components have the source code included for educational purposes.  If you know how to write component code, you can modify it.

The components String_Funcs and MenuCmds are designed to work with ANY PSoC. (They are mostly library functions.)

The Term component currently only works with the PSoC5.

I hope everyone who download's this component will find it useful.

Len

Message was edited by: Len Update: Added PSoC6 and PSoC4 demo code examples.

Message was edited by: Len  Update: Added two more PSoC4 demo code examples. Both using the SCB_UART component and one of them with a Bootladable (-049 kit).

Message was edited by: Leonard Poma This library includes the latest version (2.3) of Term. Attached is also two demo examples of using Term.

UPDATED: 12.30.2021

Hi,

I'm attaching a project which includes a pre-component version of a 14-bit VDAC using the dithering method to generate the extra bits of resolution beyond the inherent 8-bits provided by the Cypress VDAC8 component.

In principle it is identical to the Cypress DVDAC (12-bits max resolution) in theory of operation.  It even has the same API calls.

Besides having 2 additional bits of resolution (max 14-bits), it doesn't use the DMA to operate the dithering.  Instead it uses a 100% HW state machine created with UDBs.  Therefore, the dithering is always in-sync to the VDAC clock and is not prone to DMA latencies.  In fact, it uses 0% CPU cycles to keep it running!

Project SW Requirements:

• PSoC Creator 4.2.

PSoC5LP Requirements:

• Use project DVDAC14_Demo_PSoC5
• The project supplied is designed to run on a stock CY8CKIT-059 with NO EXTERNAL components!
• The project can be modified to run on other PSoC5LP-based designs. (eg CY8CKIT-050, SparkFun boards, etc.)

PSoC3 Requirements:

• Use project DVDAC14_Demo_PSoC3
• The project supplied is designed to run on a stock CY8CKIT-030 with the addition on one small capacitor.
• The project can be modified to run on other PSoC3-based designs. 

he project attached is a Demo code example that allows for user modify the DVDAC14 'component' parameters through the API calls to the included pre-component.

The Demo project uses my Term, MenuCmds and String_Funcs components to simplify the user access to the run-time features. 

I have include the needed component libraries as imported into the project for your convenience.

Here is a link to my component library: Terminal-Support-Component-Library  if you'd prefer to use these components as a shared resource for your other projects.

Why do this?

Because you (more specifically ... I) can.   Cypress demonstrated that this is possible with their DVDAC12.  I extended their idea to a HW-only solution as a learning experience and possibly a teaching tool to help show the value of the PSoCs that have UDBs.  It has been my experience as an engineer that if you can move highly repetitive operations into a HW state-machine, you can achieve significant performance gains.

There might be some of you that ask:  Can the DVDAC be made to support 16-bits?  The short answer is yes.  However, in this style of implementation you would need 32 UDB blocks.  This would deplete your UDB resources.  Additionally, the extra VDAC sensitivity virtually gained would be outweighed by the noise in practically any system.

Next Steps

I have released the DVDAC14 as a pre-component.  It has about 80% of the component structures including the API calls.

I'm looking for user feedback.  This includes implementation bugs if you find some.  If you have some suggestions, I'd welcome the input.

Once I feel the pre-component version is stable I would consider making it into a full-fledged component.

Happy Holidays and Enjoy!