The example of Ultrasonic Distance Sensor HC-SRO4 is an example on PSoC3.
If you'd like to port it to KIT-042, you need to migrate the code from PSoC3 to PSoC4.
PSoC3 is 8051 based, while PSoC4 is Cortex-M0 based. And they have different peripherals architecture.
Fortunately, the code compatibility must be better than expected. Maybe some changes should be taken care:
1. Component revision: Upgrade component.
2. API changing: Replace invalid API by searching new generated API.
3. Pins assignment changing. in Tab Pins of .cydwr, choose correct pins of PSoC4.
4. Clear other errors according to error messages.
Attached is my sample project for CY8CKIT-044.
Hopefully, it won't be too difficult to port to CY8CKIT-042 as I'm using only 2 DigitalPins.
test180709.cyprj.Archive02.zip 549.4 K
1 of 1 people found this helpful
Here is my CY8CKIT-042 Version
(1) I'm assuming temp 25.0 for the speed of sound
(2) With my kit the measure is about +4,0cm beside CY8CKIT-044 Version was about +2.0cm
Thank you so much, this worked like a charm and I am able to understand most of it. That being said I have a couple questions, just to help me learn, and better understand
1. Could you explain to me how the sprintf command works as used in this code, I understand what it does, but not how to use it.
2. What is the functionality of the
section? I understand the code inside, but I have never encountered this before.
3. I still get the warning
"Clock Warning: (Clock_10MHz's accuracy range '12 MHz +/- 2%, (11.76 MHz - 12.24 MHz)' is not within the specified tolerance range '10 MHz +/- 5%, (9.5 MHz - 10.5 MHz)'.)."
I don't completely understand the implications of this, and cannot figure how to fix it.
Thanks for the help!!
> 1. Could you explain to me how the sprintf command works
> as used in this code, I understand what it does, but not how to use it.
Being a seasoned unix hacker, I wanted to use usual printf()
but all we have with PSoC is UART_UartPutString(), etc.
So we have to compose a string before calling UART_UartPutString()
as it takes only a string as its argument.
So I used sprintf() which allows us compose a string with printf style format.
But we had another difficulty here, as it does not allow to use "%f" formatting.
For example if a double variable PI is 3.14.
Usual printf("%.2f", PI) will print out "3.14"
or sprintf(str, "%.2f", PI) will make the str as "3.14"
which we can not do with the PSoC Creator version of sprintf().
So I sprintf(str, "%d", PI) which will give "3"
and sprintf(str, "%02d", (int)(PI * 100)%100) which will give "14".
And sprintf(str, "%d.%02d", (int)PI, (int)(PI * 100)%100) will give "3.14".
Could this be an answer to your question?
> 2. What is the functionality of the
> #if 1
> section? I understand the code inside,
> but I have never encountered this before.
#if (value) sentence is a preprocessor directive
if the (value) is true, following section will be enabled
and if the (value) is false, following section will be disabled
and if there is #else section, section following #else will be
I was testing a couple of approaches to get the timer value
from rising edge of "Echo_Read()" to the falling edge of "Echo_Read()"
and I was not sure if I should stop the timer before getting the value.
As far as I tested (in a short time), I could not see much difference
so I left simpler one enabled.
You can test it changing #if 1 to #if 0, if you are interested.
> 3. I still get the warning
> "Clock Warning: (Clock_10MHz's accuracy range '12 MHz +/- 2%, (11.76 MHz - 12.24 MHz)' is not within the specified tolerance range '10 MHz +/- 5%, (9.5 MHz - 10.5 MHz)'.)."
> I don't completely understand the implications of this, and cannot figure how to fix it.
The Clock_10MHz is derived from HFClk which is 24MHz +/-2%
but creating 10MHz from 24MHz may not be an easy division
so accuracy ended up bad.
So if we ask 12MHz instead of 10MHz, we should get better accuracy.
Then we have to change the distance calcuration
distance = (double)(duration) * MACH / 200000.0 ; /* 10MHz clock */
distance = (double)(duration) * MACH / 240000.0 ; /* 12MHz clock */
As the result, we don't get the warning any more
and the measurement which has about +4cm error yesterday
is now less than 1cm error (with my kit).
Attached is the 12MHz clock version.
> One more question on this:
> I have just realized that the "while" statements in the code have a habit of slowing down or completely stopping the code which invites many problems. Is there a way I can fix this using interrupts or something?
I don't know about the " a habit of slowing down or completely stopping the code",
you might need to post another question to this community for such problems.
Having written that, IMHO, generally, "while" and "for" loop can not guarantee exact timing.
So if you want to measure data in precise interval, you should use "Timer" and trigger measurement
by it's interrupt.
There should be many "correct" way to do that.
Attached is a trial of mine.