You are here

Cypress Maker Lab - Barc Go! Barc Stop! Barc Chase Your Tail! | Cypress Semiconductor

Cypress Maker Lab - Barc Go! Barc Stop! Barc Chase Your Tail!

It's time for the finishing touches on Barc's motor control circuit. It's high time I took notice of the motor driver FLT (fault) signal and I want to add the ability to walk backwards.

I started by tidying up the wiring on the breadboard. Sree was giving me some mean looks about it. Here is the neater layout with the PSoC moved closer to the driver board and the wires running underneath where the two board plug in.

I thought the FLT signal would be easy. The documentation says that it is normally high and drives low if there is an over-voltage or over-heating problem in the driver chip. So I figured I could just AND the SLP (standby) and FLT. This should automatically turn off the motors if the FLT goes low. This would be another example of how flexible PSoC is and I drew up this circuit.

I thought this looked really neat and made the fault protection really robust because it is in hardware, with no risk of an interrupt getting masked or anything naughty like that. There was just one problem. It doesn't work. The motors don't run. So I messed about with the circuit. I questioned my logic. I checked signals by wiring them to the LED. I questioned my sanity. And then I gave up and called my mate Sree. Sree is a real engineer and has a super-power I shall never possess. He can be bothered to read the documentation. I had burned most of my Sunday on this. Sree figured out over lunch that, when you enable the motors (via SLP) the FLT signal always drops low for 380 microseconds. Now, if I am honest, it actually took Sree about 3 minutes to find out the problem and the rest of lunch was taken up with me moaning about hardware and how much easier it would be to do this with software after all. But the end result didn’t change - my circuit cannot work.

I need to enable SLP, wait a while, and then start worrying about FLT. I was mulling over a plan of using a second counter to start timing when the button is pressed and sample FLT after 380us. But it seemed like overkill for the actual problem and I did not like that it meant we would be running the motor without checking FLT, even if it was for a really short period of time. Ideally I wanted to turn on SLP but keep the AIN and BIN signals low (so no load was put on the motors) until FLT was ready to be read and was high. Enter the PWM kill signal. The PWM I am using to drive the motors has an optional kill input which sets the outputs low when the kill is high. This is a really easy way to protect the motors. Press the switch and enable the motors with the PWMs killed. As soon as the FLT goes high the PWMs start. This is a really elegant solution that does not require an extra counter or make any assumptions about how long the delay on the fault signal is. I programmed it into Barc and tested that FLT does, indeed, stop the motors by wiring it up to ground before and after pressing the switch.

I feel a lot safer now. With Embedded World just a few days away I am less likely to blow up my demo! Let's add some maneuverability to this hound. I can go forward, left and right, but I cannot reverse or spin on the spot. Real dogs are pretty good at that. I need to be able to switch the PWM outputs to the AIN and BIN pins. I am going to do that by using a control register. This is an 8-bit register (I only need 2 bits) that lets me set hardware signal from firmware. Each bit shall define the direction of the motor and, in the schematic, I will simply use some more AND gates to send the signal to the desired pin. Pictures are worth a thousand words, so here is my circuit, starting with the control register, which I have called Direction.

Note how I have named the wires to make the drawing easier - it helps to see what is going on that way too. The PWM outputs get ANDed with the direction signals to either hold the pin low or pass through the PWM signal. Note that I re-enabled the HW connection on the AIN2 and BIN1 pins so I can connect them to the gates (and I no longer set them from firmware).

A little splash of firmware and we have a dog that can walk forwards and backwards and chase his tail in both directions.

#include "project.h"

int main(void)

{

    uint8 dir = 0;

    CyGlobalIntEnable;

    for(;;)

    {

        Direction_Write( dir++ );

        CyDelay( 1000 );   

    }

}

 

I am happy with Barc's agility now. He is nearly ready for the big dog show in Germany! Just one last problem to solve . How to make him "see" people and interact with them. This sounds like a big task, but PSoC's CapSense makes this quite simple… next time.

 

ALL CONTENT AND MATERIALS ON THIS SITE ARE PROVIDED "AS IS". CYPRESS SEMICONDUCTOR AND ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THESE MATERIALS FOR ANY PURPOSE AND DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THESE MATERIALS, INCLUDING BUT NOT LIMITED TO, ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL PROPERTY RIGHT. NO LICENSE, EITHER EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED BY CYPRESS SEMICONDUCTOR. USE OF THE INFORMATION ON THIS SITE MAY REQUIRE A LICENSE FROM A THIRD PARTY, OR A LICENSE FROM CYPRESS SEMICONDUCTOR.

Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms and Conditions of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms and Conditions of this site. Cypress Semiconductor and its suppliers reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.