• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 31 subscribers
  • Views 911 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Custom API for DRV8833 not quite working

Luis Afonso
Guru 20670 points

Other Parts Discussed in Thread: DRV8833, ENERGIA

Hi,

So let me try to explain the problem.
I am using the DRV8833 motor driver to control some pololu DC micromotors. I made a little API to use it with the Tiva.
I have 2 type of gearboxes, 1:100 and 1:50. Currently there is no real speed control or any feedback of the motors current or speed. Well I saw the problem first with a line follower.
When using the 1:100 there was no apparent problem, well I had to adjust the PID constants and all but so far so good.
Now with the faster motors (gearboxes), the 1:50, the problems appeared. Well the god dam motors would just be too fast and jumpy, this was mostly because I could not get them to work at lower speeds when going around corners. I assumed it was because of the lower torque. And it seemed the motors were really not even, they needed really different PWM duty values to go at about the same speed - again I assumed normal since the they are brushed and we're spinning in opposite directions (well to go forward that is necessary), it's the problems of not using speed control). 

Now later I made a similar API for other ARM and well... it works so much better! The motor starts spinning at lower and they are pretty even! I connected the Tiva to the same motor driver and motor and it needed a higher duty to start spinning (and when it started spinning it was at higher speed than with the other ARM).

Well I don't have a scope here and can't exactly get to one right now (inflamed knee prevents me from walking - I am cursed this past days) to analyze the 2 PWMs.
Basic motor knowledge probably hinders me from solving the problem easily too.
So I hope that someone here can help me. I will provide then more info on PWM.

About the DRV8833 control:
I always use the fast decay mode. Meaning that the control is made by setting a pin HIGH and the other having the PWM (reversing which one does what when the direction changes). The PWM duty of course is "reversed" - lower duty = higher speed - in the API you use higher values for higher speed and then the code takes care of reversing it.
To use the pin as GPIO I change the register GPIO_O_AFSEL. When I need to use the PWM again I change it back.

Tiva:
Running at 80Mhz
Desired frequency output: 24Mhz.
API: github.com/.../DRV8833

Other ARM:
Running at 48Mhz
Desired requency output: 24Mhz.



I currently only have extra Tivas for the project and I require the use of Energia, among other hardware specific features, hence why trying to solve this problem instead of going with the other ARM.
Maybe I should try to simply use a timer instead of the PWM module?





  • 0
    TI__Guru**** 244440 points
    Hello Luis,

    I can understand the frustration sometimes, but so much foul words (ouch). I think the first effort must be at evaluating the PWM output at low speeds on both the ARM's.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 20670 points
    Hi Amit,

    If I sounded rude I am sorry :(

    I wasn't blaming the hardware at the time, I was blaming my programming. The PWM module can be complex to get working compared to a timer (but there are advantages of course!).
    And the problem was precisely on my side. I found the solution but I could not post here at the time.

    Up and running with enconders using the QEI interface and getting data by RF. (It's so easy to use the enconders with the QEI)

    The problem was how I changed from PWM mode to GPIO mode.
    I assumed I would only need to change the AFSEL register - WRONG. And to add to that when the problem was found, the launchpad I used has 1 of the pins burned. That's what I get for sharing launchpads around (well that's why I have that many so it's expected).
    I still don't know the exact step I was missing but I solved this by setting up an internal pull-up so that when I change the AFSEL the output is set to 1 (I remember cb1 suggesting that in a post).

    Again, please don't take this as rudeness - I used the parallel because it was how I found out I was doing something wrong.
  • 0 in reply to Luis Afonso
    TI__Guru**** 244440 points
    Hello Luis,

    I trust your abilities and instincts more than anything. I did not find your writing rude in anyway but only reflecting emotions that should be curtailed when we post on a public forum (as it does show our professionalism). I do not share my LP much as I burn them faster before anyone gets them (the same disclaimer I give when borrowing a LP).

    On the topic of GPIO to Peripheral Pin usage, AFSEL and PCTL are both required.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 20670 points
    Added to the info sheet :p
  • 0 in reply to Luis Afonso
    Guru 47900 points

    May I add that as the user of FIVE ARM MCU vendors - if the PWM duty cycle is close - they ALL behave essentially the same!   My small firm has encountered NO issues of consequence - while using this vendor's MCUs - with much usage targeting motor control.   (brushed & (especially) brushless)

    To be clear - I'm not speaking to "output drive levels" - it is (most always) assumed that a proper power driver (either an integrated) or (real, 100A+ discrete FET) as my firm employs - is imposed between the MCU and the motor.

    Minus a scope - and a listing of all PWM set-ups - more detailed analysis reduces to hunch/guess-work - neither famed as best/brightest.

    As you're using (dreaded) brushed motors - keep your voltages low - flames far away - and mind not the (explosive) brush residue - surely coating your vehicle's track... BLDC Motors Rule - la resistance est futile...

    Your post's title - "blaming" this vendor's PWM module - has been proven to be unfair & unjust.   And it can be seen as "inflammatory" - that's not good!

     It can quickly/easily be corrected (open your initial post - subject line appears - then may be edited.)   I'd "fix" that - even with aching knee...  (especially w/aching, likely "inflamed" knee...)   (inflammation is to be avoided - you know that...)

  • 0 in reply to cb1
    Guru 20670 points
    I'm acostumed to not have a scope in hand...
    I used an LED to monitor the outputs, good to give an idea of distinct duty levels and LOW or HIGH outputs.
    But I agree that with a logic analyzer in hand this would have been solved much sooner.

    The motors I have here are really tiny (smaller than my little finger) and I am just feeding them max 8,4V (6V-7,4V they handle no problem) and they are pretty much free running with such a light bot.
    I don't think there is even enough space inside the motor to hold enough brush residue to cover a visible portion of the track :p
  • 0 in reply to Luis Afonso
    Guru 117855 points

    Luis Afonso said:
    I don't think there is even enough space inside the motor to hold enough brush residue...

    Just "try" to get your "brushed" motor approved for use w/in, "Hazardous" environments.

    Oh - and it is the smallest, most granular (invisible) brush particles which are (most) prone to ignite!

    Your post's new title is far more reflective of reality - good that.   (would that your knee - reduce its inflammatory aspect as well - or as quickly)

    BTW - a 14 pin M0 driving 2x08/16 Lcd can serve as a vastly superior: PWM Monitor (both frequency & duty cycle) along w/monitoring multiple GPIO levels - greatly improves upon/extends the "Led" (logarithmic detector) as test instrument...

  • 0 in reply to cb1_mobile
    Guru 20670 points
    The smaller the dust, the more inflammable it is, just look at aluminium, you can exactly light a bar of it easily, but try grinding it first... (that's what you learn when working on aluminium bars with a chemist by your side :p)

    Well, I can walk a bit now, thanks for the concern.

    Well I didn't have anything ready and really reliable to do just that. I probably could have use one of those projects open source that use MCUs as logic analizers communicating with the PC.
  • 0 in reply to Luis Afonso
    Guru 117855 points

    Luis Afonso said:
    Well I didn't have anything ready and really reliable to do just that.

    (in response to the suggestion to employ small M0 (14-20 pin) along w/text Lcd to serve as: Signal/PWM monitor, edge detector, voltage display & monitor of multiple GPIO lines...)

    You/others (especially you, Luis) who engage in multiple projects really would benefit from such a device or project.   M0 is mentioned due to its reduced size, ease of prototyping (some are available in "easy" soic (some even DIP - iirc), low cost and modern, hi performance - provided by ARM.   The small size of such MCU enables it - and all associated circuitry - to fit (completely) in the "footprint" of a standard 2x16 lcd.   (which demands 6 of the ARM MCU's GPIO)

    It should be stated that the "diversity" of the ARM MCU field (not fully employed by some) "builds & extends programming & design skills" - while encouraging (adequate) technical "investigation" - which proves invaluable on a "day to day" job & student basis...

    A carpenter without proper tools...