Wixel with HC-SR04

I got a HC-SR04 and would like to use with Wixel. But I dont know a practical way to measuring the echo time. Measure milliseconds do not work, ultrasound pulse need to be measured in units much smaller than a millisecond.

Someone already used the HC-SR04 with Wixel? Could please give me a hint?


About that, I found this topic were Ben suggest a code to drive a hc-sr04 with 3pi robot and I try to adapt that code to work with wixel, but it dont work.

In main loop there is a call to get_ticks() function, but I found no function equivalent to get_ticks() in Wixel’s library. Any suggestions?

Im using P0_0 pin to trigger and P0_1 pin to get echo.

No hints?


Using the Wixel with that sensor might be difficult. As you noticed, the Wixel does not have a command equivalent to get_ticks(). Measuring pulses would require use of interrupts on the CC2511F32 microcontroller. Do you have any experience using interrupts?

Alternatively, you might be able to measure with the HC-SR04 using a different microcontroller and then relay the information to the Wixel. However, without knowing what you are trying to accomplish, I can not give you any particular suggestions.

- Jeremy

Hello Jeremy, thanks for the reply,

I did a small robot controlled by the computer using a pair of wixels to communicate. Wixel in robot also controls the pulses to stepper motors. A few months ago I opened a topic here to show the result:

After that I made some improvements in robot and now would like to add a distance sensor in it, so I bought the HC-SR04.

From what I saw in other topics, I was wondering what would be tricky to measure intervals of less than millisecond, so I thought I’d create my own ticks using something like the code below. Certainly would not be very accurate, but perhaps solve, then I can put the result here.

My ticks are loops in a while statement. At startup I make an estimate of how many “ticks” per second can be produced.

uint32 ticks4sec = 0;
#define BIGnumber 1000000

void initTicks(){
	uint16 ms;
        uint32 tk;

    tk= BIGnumber;
    ms= getMs();
    ms= getMs()-ms;
        ticks4sec = (BIGnumber*1000) / ms;
    // else need a bigger number

The idea is count “ticks” during pulse and then calculate time based on estimate made before:

#define pnTrigg P0_0
#define pnEcho  P0_1

uint32 ultraSonicTicks()
{   uint32 tcks=0;

    pnTrigg = 0;
    pnTrigg = 1;
    pnTrigg = 0;

    while (!pnEcho);    // <---- Problem here


    return tcks;

But is not working, first while never stop and now im trying find out why. Bellow my startup code:

void main()

    // pin 00 to digital output - trigger
    setDigitalOutput(00, LOW);
    // pin 01 to digital input - echo
    setDigitalInput(01, true);

    . . . 

Since Wixel pins are not 5V tolerant, pin P0_1 is being fed through a voltage divider as showed in user guide at pololu.com/docs/0J46/5.b

About interrupts, I have no experience, but I would really like to learn to use. I have searched on the matter but it would be very instructive to see a specific code example for Wixel.


About measurement intervals, where the function delayMicroseconds() is implemented ? I could only find the prototype of it, this function is precompiled? Perhaps a look at the code help.
This function is accurate?

Come on guys, I need some help here.

The delayMicroseconds() function is written in assembly and is defined in delay.s. It is accurate, as long as an interrupt does not occur while this function is called.

If you have access to an oscilloscope, could you measure the pins during the problematic while loop to see if they are changing?

- Jeremy

Ok Jeremy,

No, I dont have an oscilloscope, anyway I’m not electronic engineer and I am not professional in this area. I have a lot of experience with programming, but with microcontrollers is my first time. I dont know what you guys want for Wixel, but the way I see it targets hobbyists and enthusiasts, not professionals.

Every time you guys answer a question by sending datasheet link Pololu lose dozens of potential customers. Datasheet is not tutorial, not meant to teach, was made to inform those who already know, which is not the case for most of forum’s users. You guys can not expect that hobbyists who work in other areas can read and fully understand a datasheet that has almost 250 pages. You are professionals, we dont.

Wixel is an excellent product, despite its limitations and it is clear that user guide it has a lot of work to be done. What was done in user guide was very well done, but could have some code examples, especially on issues that generate more doubts on users, such as timers and interrupts, for example. I dont think you have to explain every concept involved, but it would not cost too much give some code examples with a brief explanation in user guide. Whenever any concept is explained, it should be code examples too. Or at least, you could do a better documentation of apps. App’s documentation in guide does not help too much. I did not buy Wixel to use the applications that come with it. Is not much help to say what an application does, we need to know how the application does. We need a app code documentation, not app documentation.

You guys did a great job with Wixel, is a pity that you stopped. I guess you are busy with other products. Must be why now the answers are short and slow in wixel forum.

Anyway, thank’s for your time

Thank you for your feedback. I understand that this can be frustrating for people who are new to electronics. Unfortunately, developing new apps for the Wixel is not intended for beginners (there are more beginner friendly devices out there). If you are writing your own app, it will require looking at the datasheet and the SDK documentation. Ultimately, we do want to make the Wixel a more beginner friendly product, but it takes a lot of work and is not our priority right now. Please keep in mind that the employees who respond on these forums are actual engineers that are working on other stuff. Also, your issue is nontrivial, there can be multiple sources to your problem, and it requires some time to figure out a solution before getting back to you.

If you would like to continue troubleshoot your issue, we can try to figure if the problem is with your code. Could you disconnect the sensor and put a pull-up resistor to VCC in its place? Could you then try pulling the pin to ground to see if the program escapes the problematic loop?

- Jeremy

Hi Jeremy,
My previous post was not about the pin that never gets in high level, dont worry about that, it’s probably a bad contact in some solder point. Once I get my multimeter back’ll test. I just posted the code because I thought I might be doing something wrong in algorithm to activate sensor. But if algorithm is correct, problem should be on board. Also I was not sure if the ticks system that I did would work.

The issue is that I can not understand why you guys refuse to give examples of source code. I see several threads of users asking questions that could be answered with a few lines of code, but instead you send the datasheet’s link.

After all, what’s the problem in put some code example in user guide? To make wixel most friendly you guys dont need to change anything in it. Just make a more friendly documentation. I’m not saying you guys have to explain the concepts involved. Microcontrollers are all kinda similar, use the same concepts, it is easy to find information about the concepts. But details of wixel programming is not easy to find and you guys do not make it easier for users.

For example, no one needs to explain me the concept of timer and interrupt, I know what it means and I also know the working principle. And I read a lot about it in datasheet (SDK documentation dont say a single word about timers and interrupts). All I needed now was to see some code example, few lines, that’s all. And I asked this a few times, including in the post where I put my code. But this seems to be a taboo subject here. Other users have asked same thing in other threads and all they got was a link to datasheet.

But i got your message:

And hell, maybe you’re right. Perhaps wixel is the wrong choice for this project. I’m not just trying to make a little robot. I am a professor in a college which has some computer courses but none related to electronics or mechatronics. My project is introduce robotics in college creating a little robot that has a very simple electronics, so that it could be easily replicated by students, but that can run relatively sophisticated programs and encourage students to program robot. As I enjoyed working with Wixel and had success with basic programming, I thought I could use wixel in this project. But if this is the posture of you guys, it will not work.

I was trying to avoid Arduino because it’s too easy download and install programs on it without knowing what is happening. Also I would have to provide wireless communication with another device, which would endearing and complicating the project. But now I have to rethink this issue, because students will not have where to seek information to make programs, and even crosses my mind to suggest that they study the datasheet.

When you have some time, take a look, is not done yet, but is in progress. Wixel is mentioned in introduction:

fperrotti.wikispaces.com/Projet … m%C3%B3vel


Hi, Perrotti.

Thanks for your feedback. I noticed this question:

We do give example pieces of code sometimes, and you said yourself that you tried adapting some code provided here on the forum. But something else you wrote gets at the more general reason:

My goal with this forum is to help others learn how to determine the answers for themselves, not just to give them answers. With code examples in particular, I want to avoid giving out bad or incorrect examples, and it’s often not practical for our engineers to write and test sample programs for each question that comes in. From my experience of helping beginners, it’s rare that questions can really “be answered with a few lines of code”, especially with small microcontrollers, where there are many complex interactions that require a good understanding of how the microcontroller works.

We are continuing to put resources into the Wixel, and I do want to make it easier for people to use. Can you give me some specific examples of where you think a few lines of code in the user’s guide would be very helpful?

One other concern I have regarding creating tutorials for beginners is that I do not want to suggest that it is easy for beginners (to microcontrollers) to create the Wixel programs themselves. I think we specifically say that programming the Wixel from scratch (as opposed to using the pre-made apps) is for advanced users. Is there something in our presentation of the Wixel that made you think it would be easy for beginners to program?

- Jan

As a professor of physics who is also interested in introducing robotics to students, I can sympathize with Prof. Perotti’s frustration with the Wixel and the lack of well documented general routines for exercising its various peripherals and accomplishing certain tasks. I also understand his reluctance to adopt the Arduino environment. Not only do Arduino enthusiasts encourage people to assume that “things will just work”, there is an incredible amount of flaky Arduino code in the public domain that makes for a great deal of frustration for beginners and experts alike.

However, for a variety of reasons I respectfully suggest that Prof. Perotti’s initial decision to base a robotics learning project on the Wixel was premature and/or possibly ill advised. The microcontroller used is rather new (except for the core); the radio is fun but unnecessary and adds an enormous amount of complication for beginners; there is not a large community of people using the microcontroller (hence little available source code, few discussion forums, etc); the program development environment is complex and ill suited to beginners and the compiler is quirkier and possibly less reliable than gcc.

In order to suggest an alternative I looked through Prof. Perotti’s web pages (I speak German and Spanish and read several romance languages) and although it is clearly far from complete, I couldn’t find a clear set of goals for the overall learning experience that he has in mind. For example, will learning about robot hardware be more important than learning about firmware/software? Will the students build a robot chassis, or will they program a standard chassis? Will they write low-level motor control functions or solve mazes?

Nevertheless, I’m still willing to make a recommendation and that is to stick with AVR-based processors as I plan to do for a course I’m developing. They are by far the most popular in amateur robotics and there are several extremely reliable program development environments, free for download, and suitable for any level of program sophistication. Plus, there is a huge base of freely available software.

For an intermediate hardware solution between Arduino and Wixel, Pololu has done an outstanding job of developing the Orangutan series of robot control modules and the provided software library covers just about all the bases in a very well documented environment. As for motorized platforms, the 3PI would be just about perfect if it had wheel encoders.

Finally, I believe that everyone interested in hands-on robotics will have to learn to read a microcontroller data sheet. It is impossible to make full use of port functions, timers, interrupts and peripherals, or to repurpose someone else’s code without that skill. Also for AVR, there are web sites describing many of the microcontroller functions (timers in particular) that are easier to read than the data sheet.

I hope that helps!
Cheers, Jim