HC-SR04 Ultrasonic Sensor with CY8KIT-042

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

I've been trying to recreate my adruino project on the Pioneer kit, and have been struggeling with using my ultrasonic sensor. I tried to follow this:Ultrasonic Distance Sensor HC-SRO4  but ended up with nothing in my .cysch and a lot of errors(because of this, I assume). I would appriciate help with getting this sensor working, I have lots of adruino experience but very little with the whole Cyprus kit.

Thanks!

0 Likes
1 Solution
lock attach
Attachments are accessible only for community members.
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

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

moto

View solution in original post

6 Replies
RyanZhao
Moderator
Moderator
Moderator
250 sign-ins First question asked 750 replies posted

Hi Luke,

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.

Thanks,

Ryan

0 Likes
lock attach
Attachments are accessible only for community members.
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

Hi,

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.

moto

lock attach
Attachments are accessible only for community members.
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

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

moto

Anonymous
Not applicable

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

#if 1

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!!

0 Likes
lock attach
Attachments are accessible only for community members.
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

Dear lukebartol-san,

> 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

enabled.

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

from

  distance = (double)(duration) * MACH / 200000.0 ; /* 10MHz clock */

to

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.

moto

0 Likes
lock attach
Attachments are accessible only for community members.
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

> 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.

moto

0 Likes