All x86 processors since the Pentium have a 48 bit hardware register that
counts the number of machine clocks since the processor was turned on. The
counter runs at the clock rate of the processor (2.4 gigahertz processor
means 2.4 giga counts per second on the counter).
This counter can be read with an unprotected assembly instruction "rdtsc".
This does not require a system call to do it.
You can use this little ditty to read it.
static __inline u_int64_t
__asm __volatile(".byte 0x0f, 0x31" : "=A" (rv));
Thought this might be useful.
My handy dandy calculator says 3.7 years. Keep in mind the counter starts at
zero after each reboot. So if you plan on your application having an uptime
of more than 3.7 years you will have to handle the counter wrapping. If your
application is Windows based, you have nothing to worry about. ;-)
On Sun, Apr 10, 2005 at 05:27:16PM -0400, mlw wrote:
There are two aspects to consider. The one you mentioned is a
response time issue of the robot. One obvious example is for safety.
The problem with non-real time control here is that response is
unpredictable. Is the response to bumper switch activation .000005
seconds or 2.5 seconds? Shutting down the motors in 5 microseconds
might mean you stop in half a second, but more importantly, not
shutting down the motors instantly means you collide with the obstacle
under full power. That does a lot more damage than colliding under no
power. Think of bumping into a chair and it moves a half-inch or so.
Now think of running into the chair and pushing it across the floor
and right through the china cabinet.
The other is control signal generation. These have varying demands
depending. Lots of small robots use R/C servos. The timing of the
pulse needs to be within the range of 1ms to 2ms with around
microsecond resolution, and repeated with a period of around 20 ms.
The repeat period is not so critical, but the pulse duration is. If
the timing constraints are not met, you get jitter.
Direct h-bridge control requires the ability to generate the PWM
waveform - typical square wave of fixed period and varying duty cycle.
The duty cycle determines the power across the motor. The frequency
is pretty important - there's not one size fits all for frequency, but
in general, higher is better, both from a control point of view and
also that lower frequencies tend to make the motors whine and can be
quite noisy and irritating. Failure to meet these timing requirements
also is bad - your motors don't do what their told.
Typical microcontrollers handle this latter with specialized hardware
support to generate the PWM signals. Typically it involves
configuring a hardware timer, configuring pins to do the control, and
then plugging the duty cycle into an "output compare" register. After
that, the signal is totally hardware generated and the MCU spends 0
processor cycles generating the wave form. PC's typically don't have
this hardware - you won't find it on your parallel port or general
purpose I/O card. Your choice is to add hardware to do it, or
generate the signals using software. Generating them with software is
going to be difficult to meet the timing requirements to control
Both are real-time requirements, just at different levels of control.
I think you've been thinking of mostly the former, but I think a lot
of the folks responding to you about microcontrollers have been
thinking of the latter. At least I have, but I can't speak for
BDMICRO - ATmega128 Based MAVRIC Controllers
2.5 seconds is unacceptable. Assume no greater than two quanta, say 0.02
seconds, which means on average you can expect 0.1 seconds response time.
In real life on a system without competing high priority processes, it is
usually MUCH less.
Again, how much precision are you using? Microseconds? How think is your
bumper? What's it made of? Actual physical switch response time? Nature of
the surface on which you are runing. Tread ware of the wheels. There are so
many factors, 0.01, hell, even 0.05 seconds isn't going to help you.
This isn't a small robot, 25~40 lbs.
What makes you think I'm timing the PWM?
I am using an analog signal from a D/A converter and sending that to a PWM
Don't need it.
Or use a ramp generator and some comparitors for $3.00
A lot of people responding have strong feelings about the subject, but not a
lot of strong information. They make assumptions and work from their
Take for instance, ".000005 seconds or 2.5 seconds?" clearly you know that
2.5 seconds is out of the question, but you don't think that I would have
thought about that. It would have been better for you to ask "How will you
manage response time? What is your maximum response time?"
To which I would reply, "well, I've been doing some tests on the PC, and
under load, a single high priority task has never seen more than 0.02
latency variation." Which is about to be expected.
The real problem is device driver interrupt routines, these need to be
inspected for quality and how long they diable interupts.
Could you provide a part number? There 1000+ D/A converters at
DigiKey. I've done a variety of searchs and can't find any that
are that inexpensive. It probably means that I haven't found the
right set of parameters to search for.
Are you sure that is the right device? The quantity 1 price at
Digikey is $3.04 and the quantity 1 price at Future is $3.00.
Also, it only has one D/A channel, so you would need one of these
chips for each motor. Am I missing something here?
You see this chip on the Linux boards from time to time because someone
wrote a library for it. Philips has others if you're not looking for the
A/D channels. Also note Digikey is 0 stock, and Future has a minimum of
25 (for the rail).
A quick look shows Digikey has a 16-bit I2C DAC (DAC8571), in MSOP
package, in available quantities. But it's $6.
I've used a MAX548 on some of my many other projects (non-robotic).
It is a dual 8-bit 3-wire serial D/A, but it still costs $4.64
quantity 1 from Digikey. What I liked about it is that it comes
in a 8-pin DIP. I've also used a TLC5620, which is a 3-wire serial
quad D/A. It actually costs a little less at $3.60 quantity 1 from
DigiKey. Neither of these 2 parts work with I2C though.
On Mon, Apr 11, 2005 at 07:24:32AM -0400, mlw wrote:
You can't assume any such thing. Your process might be swapped out to
disk. It could be many hundreds of milliseconds or even seconds
before your process gets control. Or ... you reference an unmapped
page of virtual memory which causes a page fault or multiples of page
faults. There are lots of code paths in non-real-time systems that
can result in unpredictable timing.
Just because you ran it for a while and the greatest you saw was 20 ms
doesn't mean that is the largest it can be. You aren't seriously
calling that a proof, are you? Surely you know better.
I'm taking about your response time being non-deterministic. See
above. If you are unable to respond to a bumper switch because your
process is not in memory and takes a long time to swap in, you collide
with the obstacle while your motors are fully powered, rather than
braking. There's a big difference. Just to illustrate what I'm
referring to, golfers know this as follow-through on their swing -
means the difference of the ball going a 400 yards vs 50 yards.
Golf swing: follow-through = good; out of control robots:
follow-through = bad.
I never said you were. I was answering your question about why motor
control is a real-time process - which you did ask, did you not? You
mentioned only one aspect of motor control - the macro level of
stopping the base or platform. There's also the actual control aspect
of driving the motor.
Yes, I remember.
In case your other method doesn't work out for some reason, you'll
need a "Plan B."
You are too.
That's not clear at all. See, there you go making assumptions that
you are accusing everyone else of making.
You've only shown that your system is operating reasonably as expected
under conditions that you have anticipated. I would certainly expect
it to be reasonably well behaved under these conditions. But what
about conditions that you haven't anticipated? Do you really think
you've exercised even a fraction of the available code paths? Have
you really loaded up several memory hungry processes to see what
happens when your systems starts swapping? Or what happens if you
cause a packet storm - i.e., a flood ping or similar? You did mention
your system will be networked. Does your kernel rate limit responses
so that it doesn't suffer from DOS? All these things can a do affect
your response time. And not just a few milliseconds. We are
literally talking seconds in some cases.
BDMICRO - ATmega128 Based MAVRIC Controllers
On Mon, Apr 11, 2005 at 08:51:26PM -0400, mlw wrote:
Pages of "processes" that have been sleeping for over a certain amount
of time are most certainly high on the list to swap out when memory is
in short supply. The paging system doesn't select random pages for
swapping out to disk. Whether your process is entirely or partially
swapped out is kind've irrelevant if the pages it needs to run are on
disk. The point is, when it needs to run, it can't do so in a timely
manner - some other processes's pages may need to be swapped out in
order to make room for your process's pages to be swapped back in so
it can execute.
So you don't make programming errors? Cool.
With no bugs, of course. Again, my hat is off to you.
Oh, I don't know, maybe you call 'malloc()' or something? Maybe you
call printf() or any host of other library routines which can call
'malloc()'? And then, after calling it, maybe you actually reference
the memory address which generates a page fault which in turn causes a
physical page of memory to be mapped in at said address? So your
supposed 3 clock cycle memory access that you so carefully planned for
in your timing requirements suddenly becomes many thousands of clock
cycles. That's how virtual memory works.
As a side note, I was at first surprised at the breadth of your
knowledge, but it quickly became clear that the depth of your
knowledge in any given area appears to be very shallow. It's actually
becoming quite tiresome. You seem to have accumulated a collection of
"facts" with little understanding about how things work. And the
really irritating thing is that you don't seem to realize that you
don't know how things work. I'm not saying that to be mean - it's
just an observation. And that I'm a little irritated at your
combative attitude and responses, so don't take offense - I'm just
airing a bit. As a bit more constructive criticism, perhaps you would
do well to not post a question, if you are going to simply mince words
and go on the offensive with anyone who takes the time to respond.
It's fine to have disagreements, but my impression is that you take it
to a combative level with anyone who has a differing opinion than you
- like when you demand that folks must prove their assertions. I say
"No!". They have answered your question - if you want more background
information do your own homework and don't ask everyone here to
spoon-feed you answers. And if you think you already know more than
everyone on this list, why are you asking us? Instead you should
simply point us to your accomplishments so we can look upon them in
Also, its irritating when people say "you should listen to me because
I have ..." and then start spouting off credentials about where they
used to work, etc, etc. We don't really care. Nobody here does that.
If you want to impress us, show us your robots.
BTW, I'm still waiting to see your mouse encoder adapted to motor /
wheel encoder. So far I have not seen any of your work.
That's not what I meant. The discussion wasn't really about the size
of your robot, but rather that motor control is a real-time process.
Size of the motors are irrelevant.
I have no doubt.
Limited testing. Which is fine, for you.
So you can predict the future now, too?
More like programming errors. Oversights - no one is perfect. Also,
a little thing affectionately referred to as "Creature Feep."
Maybe you can make that RAM materialize while your robot is careening
down the stairs. Again, that's the beauty of the unexpected - you
never know when you will need it.
Personally, I would make it happen as part of my testing and ensure
that my system could handle that. I know I'm not a perfect programmer
and if I write a program to open a socket to my 'bot to display a live
video feed or whatever, I also know that I can make a programming
error and perhaps cause a similar event, unexpectedly. So I would
test for it.
I wasn't really considering an intentional DOS attack - I was thinking
DOS due to programming error, looping process becoming a major CPU
hog, etc. It's an accidental, self-inflected DOS.
I don't know what your Linux experience has been, but even on my Dual
2 GHz PowerMac G5 with 512 Meg of memory, processes get swapped out
while doing certain highly memory intensive operations - the game Halo
comes to mind :-). You can really feel the response suffer when you
exit the game and press a key in the window of a swapped out process.
Several seconds for response is not unusual at all. Adding a Gig of
memory for a total of 1.5 Gig fixed that, but that doesn't mean it
can't still happen with an even more memory intensive application.
No, I don't anticipate you will be playing Halo on your robot, but you
did say real time vision processing - lots of memory and CPU
utilization there. Speech recognition and generation - lots of CPU,
modest memory. Navigation - are you constructing maps of your
environment? - more memory and computation. Path planning? More
memory and computation.
BDMICRO - ATmega128 Based MAVRIC Controllers
"When memory is in short supply." Not going to happen.
Nope, pages that are not regularly used.
Why would pages of a regularly executed process be swapped out to disk?
(Assuming the pages are not marked as non-pagable)
Assuming (a) a memory starved condition, (b) the process and pages that need
to be executed are somehow at the top of the LRU list, and (c) the pages
are not marked non-pageable.
Three assumptions that can easily be managed.
If we are talking about programming errors, a RTOS won't help you either.
Again, if we must account for bugs, what is a RTOS going to do with a NULL
If the system is running a well defined loop to handle the motors, it isn't
going to call malloc, it isn't going to execute code that isn't regularly
hit. It's going to stay in a few VM pages (stack, data, and code), never
get swapped, and live in a high priority task.
It is tiring to have done the very things all you people say can't be done,
and be accusued of ignorance or stupidity because I don't listen.
In your critique of VM paging, you say I don't know what I'm talking about.
You are so busy trying to come up with strawman scenarios to "prove" that
it can't be done, you refuse to see that these scenarios can easily be
My motor control loop isn't going to be paged out and you know it. It is an
active small process running at high priority, sleeping most of the time,
and hitting no external functions except for read(), write(), and select().
I have 512M ram on the robot, swap has 0K used. How will that be paged? It
is a stupid argument made for the sake arguing. I can even mark the pages
so that they are non-pagable if I ever see a problem. It is a non-issue,
but we have to argue about it, and I'm the one who is [fill in the blank:
argumentative, ignorant, etc.]
You talk about bugs, well, if you get a null pointer or bad code on a RTOS,
that will be just as much a problem as any other.
When I did post a clear concise question, like all usenet postings, the
thread gets all wild and out of hand.
That's called an engineering discussion, it is not being "combative." Maybe
I'm too used to dealing with engineers.
I don't ask anyone to spoon feed answers, but lines like "You'll need a
microcontroller because a PC can't do it," are nonsense. It is not based in
fact, it is their preference on implementation. I have a different
preference. So I ask for a logical rational explanation for the statement,
and they get bent out of shape.
Well, I've spent a lot of years working on engineering projects heavily
weighted down by NDA, I have nothing to point to at this time. It is
frustrating to have built the motor controls, the power supplies, written
the software, and built the systems over my career, but have nothing that I
I am used to working with head strong engineers and scientists. I guess I'm
having difficulty communicating here.
I usualy respond like that when people say things like "You should listen
I posted some code, here is a picture of the motors:
A small little mouse robot will have a shorter stopping distance and time
than a larger one. The larger the stopping time, the less of a factor
atency will be.
Seriously, I was running it today, but a careless test lead in the motor
amplifier burnt up a couple transistors. FedEX comes tomorrow.
Which is fine because it is a limited application.
I can, and you should be able as well, to predict what will run on your
These will affect *any* system.
You can NEVER test all the code paths, not only I, but every software
engineering and QA management book proves it.
It isn't going to grow anything out of the lab.
These are very data centric games. The process space for these is probably
bigger than available RAM.
When you said "swapped out" I knew you were a mac guy. Processes don't swap
out in OS/X like they did in the old mac. The VM paging is pretty clean.
Still if you are using more memory than RAM...
OK, if I don't play Halo on the robot, will you admit that virtual memory is
not going to be an issue?
Less memory than you would think. Video capture devices typically use NTSC
resolution which is tiny. LOTS of CPU, but a CPU bound process that is not
I/O intensive can be put in a lower priority an not affect responsiveness
of the system. Essentially suckup unused CPU cycles.
Yup, see above.
Not much memory. I could asign a byte for every squre inch of the house and
still be under 64M.
On Mon, Apr 11, 2005 at 11:38:30PM -0400, mlw wrote:
You could be right in that I'm assuming too much. Many robot
implementations brake up their function by organization into seperate
individual "behaviours." Typically these behaviours lie latent until
the right set of conditions exist at which time they are activated.
While your "motor control" process is always active, the "avoid"
behaviour is typically only awoken when some set of obstacle sensors
So, no, I wasn't assuming that the behaviour that takes control of
your robot in response to obstacles was running all the time. And
when awoken, I was assuming that it would write its motor control
commands out and the motor control process would do as it is told.
Thus, it could be asleep for a long time before it is actually needed.
Depends on the RTOS and the architecture it is running on.
Again, I'm thinking of a model where you have broken your robot
control down into a collection of processes. Am I wrong to assume
this? I would have thought that would be one of the strong points of
Linux - process management and the ability to use the rich Unix
development environment. If you are making one giant process then I'm
not sure you are really making a case for using Linux in the first
But there are many bugs that might cause a process to loop. Assuming
an independent process model, this will largely not affect the other
processes such that they can still keep running. Maybe you've got a
bug in a high level process that does something relatively
inconsequential such as, oh, I don't know - being beligerant to your
neighbors using the speech synthesis or something. Lets just say,
hopothetically speaking of course, that it starts looping, repeating
the same old stuff monotonously.
A preemptive RTOS will still ensure that your critical real-time
processes that you have designated as such will get the cycles they
need to keep your 'bot under control, even though you have an errant
process trying to consume too much CPU.
Of course, nothing can protect you from every possible mistake.
But I'm not really advocating RTOS's, per se. We started this simply
talking about motor control, which is a real time process.
Not too many people have said certain things cannot be done. I can
only speak for myself and my position is simply that a PC motherboard
is not a particularly good platform for the low-level control of a
robot. You do seem to agree with that somewhat based on some of your
responses to others. I get the impression that maybe you've
challenged yourself to do this and if that's the case, then no amount
of information or "proofs" or anything else is going to change your
But a lot of your problems pretty much vanish if you use a good old
reliable microcontroller. Pick a flavor - we've got Basic, Forth, C,
Pascal. AVR, PIC, 68xx, Motorola DSP, 8051, ARM. Unix tools, Windows
tools, expensive tools, free tools. Interpretted, compiled. Flash
memory, eeprom, serial eeprom. Breadboards, polished boards, surf
boards (OK, how'd that get in there?). So much variety to choose
from, inifinite diversity in infinite combinations. More flavors than
Baskin Robins. There's bound to be one you can find acceptable to you
and within your budget.
Come on ... you know you want to.
Why not make your $400 or $500 robot a $500 or $600 robot?
Nothing in all that time - not home made robots or anything?
OK, that's pretty cool. Were you able to retain quadrature? I'm
assuming so if the mouse interface is still working.
I can predict cause and effect. It's harder to predict actual events,
though. You know, Murphy and all that.
But you can calculate worst case response time by examining code paths.
Actually I'm a "new" Mac guy - I know very little about MacOS 9. I'm
really a FreeBSD guy who switched to a MacOS X desktop about a year
ago, and still have a handful of FreeBSD systems for various purposes
in my home office / lab. I don't claim to be an expert on the *BSD VM
system (there's only a couple of people who can claim that) but I do
have a working knowledge of it, as well as most of the FreeBSD
internals. Linux less so.
Why don't you want to play Halo on your robot?
Sounds like you have a plan. Keep us updated on your progress.
BDMICRO - ATmega128 Based MAVRIC Controllers
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.