[beagleboard] Re: Beaglebone keeps shutting down when trying to drive a motor
Well, I've overcome the problem. I was using a GPIO as GND to the ESC. This was convenient since those pins are next to each other. Once I used true GND, then the problem went away. But why would using a GPIO as a GND cause a shutdown? I know it will restrict the amount of current sinked due to having to flow through an extra FET. On Saturday, May 10, 2014 9:38:55 PM UTC-7, Uncle Joe wrote: Help, I'm struggling to drive a simple ESC and brushless motor combination with the Beaglebone. I've already spent 1/2 a day figuring out the right arming sequence (caused by a +- 0.01 ms error in timing). But once I arm the ESC, the Beaglebone shuts off immediately. Most of the time, it shuts off right when it starts spinning up. Sometimes it even shuts off on one of the beeps the motor makes indicating the ESC is arming. Here's my setup: Revolver Stubby motor || || 850W PSU =12V= ESC ===3.3V=== BeagleBone The PSU is an Antec 850 high current gamer. I've disabled over-current, over-voltage, and under-voltage protection on it, so the power draw can be alot (enough to make the lights flicker when the motor starts). The BeagleBone is powered by USB and should be buffered against surges caused by the motor PSU. What could be the problem? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Beaglebone keeps shutting down when trying to drive a motor
Help, I'm struggling to drive a simple ESC and brushless motor combination with the Beaglebone. I've already spent 1/2 a day figuring out the right arming sequence (caused by a +- 0.01 ms error in timing). But once I arm the ESC, the Beaglebone shuts off immediately. Most of the time, it shuts off right when it starts spinning up. Sometimes it even shuts off on one of the beeps the motor makes indicating the ESC is arming. Here's my setup: Revolver Stubby motor || || 850W PSU =12V= ESC ===3.3V=== BeagleBone The PSU is an Antec 850 high current gamer. I've disabled over-current, over-voltage, and under-voltage protection on it, so the power draw can be alot (enough to make the lights flicker when the motor starts). The BeagleBone is powered by USB and should be buffered against surges caused by the motor PSU. What could be the problem? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: why does reading the DMTIMER clock take so long?
Wow, I completely forgot about this thread until someone just emailed me
with a question. Thanks for your interest.
The file I opened is /dev/mem
int fd = open(/dev/mem, O_RDWR | O_SYNC); //O_SYNC makes the memory
uncacheable
The file is a view of the entire 4GB physical memory space. You need to be
root to open it obviously.
I also have a conjecture about why reading the clock is slow. The DM timer
isn't part of the ARM architecture, so it has to read it externally. Today
as processors integrate more and more devices onto the same chip, packet
switched networks are used more and more instead of dedicated wires since a
packet interface is general purpose and will have higher utilization. But
packet switching will increase latency.
I'd like to know why ARM didn't include a clock as part of the
architectural state. Sure it can save some power, but it practically all
embedded devices need a clock and reading an external one will use more
power. At least one other computer architect agrees:
https://www.youtube.com/watch?v=J9kobkqAicU
At 22:30, Burton laments about the lack of a user readable clock on today's
processors.
Yale
On Friday, May 24, 2013 12:19:58 AM UTC-7, fis@gmail.com wrote:
Hi, I curentlly have some problem with reading DMTIMER. May I ask how
exactly you read the value of this counter? by which file is your
file descriptor *fd *referred (I mean when you use *mmap()*)?
On Saturday, January 28, 2012 6:18:59 AM UTC+1, Uncle Joe wrote:
I got a Beaglebone for robotics, where low latency operation is
important (especially, if I want to control 40 pins). I found the
sysfs interface to control GPIO is too slow (~2200 ns), so I resorted
to directly modifying the GPIO registers, which got the time down to
~200 ns. Then I wanted to read the clock via
clock_gettime(CLOCK_REALTIME), but that's also very slow (1500 ns).
Again I resorted to directly reading the DMTIMER2 counter and got the
time down to about 100ns. I still think this is a bit high. Can
someone enlighten me why it would take this long to read an on chip
value?
volatile uint32_t *dmtimer2_regs = (uint32_t *)mmap(NULL, 0x1000,
PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0x4804);
while (true)
{
uint32_t t0 = dmtimer2_regs[0x3c / 4];
uint32_t t1 = dmtimer2_regs[0x3c / 4];
cout t1 - t0 endl; // typically 5
clock ticks (each clock tick is ~41ns), hence each time stamp read
takes ~100ns
}
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
BeagleBoard group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
