Memory Specs

[pickle]

Hi

I'm researching your MiniPod for a Senior Design Project. The memory specs for the MiniPod are:

# Extensive on-chip Flash w/100,000 write cycles (typical)

* 32K x 16-bits words Program Flash
* 2K x 16-bit words Boot Flash
* 4K x 16-bit words Data Flash

# On Chip RAM

* 512 x 16-bit words Program Ram
* 2K x 16-bit words Data Ram

I will need floating point numbers, so I will probably use the IsoMax software. How much memory is taken up by the IsoMax package?

If I cannot learn Forth quick enough for the project deadlines, I could use SmallC on the board right (with floating point support)?

What is the difference between the 512 bits of Program RAM and the 2K bits of Data RAM (besides quantity)?

The IsoMax package and the program code is stored on the on-chip Flash, right?

Thanks for your time,
Brandon

[RMDumse]

I will need floating point numbers, so I will probably use the IsoMax software. How much memory is taken up by the IsoMax package?

It varies by revision, as we've been updating it toward final release. But short story is half or a little more.

If I cannot learn Forth quick enough for the project deadlines, I could use SmallC on the board right (with floating point support)?

Rock and a hard spot there. SmallC does not have floating point. The Forth under IsoMax(TM) does. You could go to a full development system like Code Warrior (which has a learning curve of its own unfortunately) and get the floating point, but it is also a bit pricey.

If you can learn Forth or not quickly enough depends on your, your preconceptions picked up from other languages, and the project.

If you tell us a bit more about the project, and a bit about your background (other languages, assembly, hardware experience), we might be able to give you a better feeling of how well you'd progress.

And of course, we really try hard to provide tech help to our customers who ask.

What is the difference between the 512 bits of Program RAM and the 2K bits of Data RAM (besides quantity)?

The program RAM can hold a short program to try (RAM vs. FLASH). Dala RAM is for variables and the like.

The IsoMax package and the program code is stored on the on-chip Flash, right?

Correct.

The Forth model under IsoMax(TM) tends to compact greatly. It is not likely a beginners project would run out of program Flash. Of course, there's always the exception. However, I will say for all the projects I've done on the IsoMax(TM) systems, very few have run up against available memory.

[pickle]

Thanks for your help...

My project involves a micro that will need to control one servo motor, three h-bridges, and read three different ADC data sources. There is also about 5 different digital sources and one serial source that will be read.

All of the ADC data is put into arrays with a maximum length of 360 points.

From two of the ADC data sources, the maximum value of an array of voltage readings will have to be determined. Other than the maximum value, the other data is useless once the maximum value has been determined. So we take an array of 360 points, find the maximum and throw the array away.

The other ADC data is similar, but the minimum value of the array is needed.

By the way, is there such an existing Forth method that could find a local maximum on the fly? For example, read data until a maximum point is found. So if 1V, 2V, 3V, 2V, 2V was read from the ADC, the maximum point is 3V so no more data needs to be read from the ADC.

I can learn computer languages rather quick. The lowest level I have learned though is C. I have never learned an Assembly language. I have no hardware experience, but my team members have a lot. I think I was fishing for a "Man, no one can learn Forth in less than a year." If it's not a notoriously hard-to-learn language, I think I can learn it quick enough.

From what I've read about IsoMax, there can be different programs running parallel, is that right? Can these 'machines' communicate data with other machines? For example, can one machine who calculated the maximums mentioned above send the data to other machines who will then process that information?

I suspect your customers have used the mini pods for far more complex projects than the one I have described?

Thanks for your time and help.

[RMDumse]

By the way, is there such an existing Forth method that could find a local maximum on the fly?

Really, you probably don't want an array, just a running MIN and MAX.

Here's a quick example.


VARIABLE CURRENTMAX
VARIABLE CURRENTMIN
VARIABLE CNTREADINGS

: GETMAX0 ( here's the routine
ADC0 ANALOGIN (read ADC 0
CURRENTMAX @ MAX CURRENTMAX !
CNTREADINGS 1+!
;

: GETMIN1 ( here's the routine
ADC1 ANALOGIN (read ADC 1
CURRENTMIN @ MIN CURRENTMIN !
;

0 CURRENTMAX !
-1 CURRENTMIN !
ISOMAX-START
INSTALL GETMAX0
INSTALL GETMIN1


So now, anytime you look in the variables, the latest A/D readings MIN or MAX is present, dating back to the last time they were cleared.

Not too tough.

Of course there are details about how often you might need this to run (periodicity) and what you want to do with the results, etc., but you can get the flavor there.

I can learn computer languages rather quick. I think I was fishing for a "Man, no one can learn Forth in less than a year." If it's not a notoriously hard-to-learn language, I think I can learn it quick enough.

Well, Forth is notorious. That's for sure. Well, here's an example. I taught a 17 week university course, now called Digital Electronics and Introduction to Robotics. I taught digital fundamentals, microprocessor fundamentals, motors, PWM, sensors, _and_ the language. The students had a passing ability to modify their programs to pass the course. They all did.

From what I've read about IsoMax, there can be different programs running parallel, is that right? Can these 'machines' communicate data with other machines? For example, can one machine who calculated the maximums mentioned above send the data to other machines who will then process that information?

Yes. This was shown in the example where two threads were installed into the background process.

I suspect your customers have used the mini pods for far more complex projects than the one I have described?

Sure. For instance intricate multiple motor camera control inside movie cameras.

[pickle]

I have a servo that turns one degree at a time and needs to read the voltages from a sensor over a 360 degree turn. My objective is to find the degree MAXANGLE1 where the max was found and record the variable. The FINDMAX1 routine would be called by a main routine that decides when it needs the MAXANGLE1 variable, so the GETMAX1 routine isn't called periodically.

Is this the correct approach as far as thinking in IsoMax...


VARIABLE CURRENTMAX
VARIABLE CURRENTMIN
VARIABLE N

: FINDMAX1 ( this routine will find and assign angle for max ADC1
N TURNSERVO ( TURNSERVO turns the servo clock-wise n degrees, n is determined by the calling function so it is set before it is called
ADC1 ANALOGIN ( read ADC 1 and it's put on top of stack
CURRENTMAX @ < ( compare ADC1 and CURRENTMAX value
IF . ( if CURRENTMAX is the greater, then we have found a local max
N @ MAXANGLE1 ! ( assign MAXANGLE1 the current servo position
ELSE CURRENTMAX @ MAX CURRENTMAX ! ( else assign new CURRENTMAX value
;


So, can an installed machine call the FINDMAX1 routine when it needed an updated MAXANGLE1 variable?

Is it correct that the FINDMAX1 routine isn't an installed machine, but a routine available to other routines and installed machines?

[RMDumse]

I have a servo that turns one degree at a time

Is this an RC Servo? Or is this something we're controlling with an H-bridge? If the later, how is the position loop closed? Quadrature? Position pot? Other?

needs to read the voltages from a sensor over a 360 degree turn.

Okay. Not tough so far.

My objective is to find the degree MAXANGLE1 where the max was found and record the variable. The FINDMAX1 routine would be called by a main routine that decides when it needs the MAXANGLE1 variable, so the GETMAX1 routine isn't called periodically.

Okay, but I notice in the code you move the servo and then take the reading. Better to move the servo at the end of the routine before leaving, so it settled and ready for the next reading.

Otherwise you should wait after moving the servo until it reaches its position.

So, can an installed machine call the FINDMAX1 routine when it needed an updated MAXANGLE1 variable?

Yes, but the code might need some touching up. TURNSERVO needs to be defined. Main as well.

Is it correct that the FINDMAX1 routine isn't an installed machine, but a routine available to other routines and installed machines?

Yes, I believe you have the right idea there.

If the servo is an RC Servo: it is unlikely you can move 1/360th turn, or one degree at a time because of their internal deadbands, which are only about 1/100 range sensitive. Also they tend not to have a 360 degree range, and 185 or so is the usual absolute maximum.

It's not a great idea to put prints in your realtime programs (unless you are prepared to take the time to have them actually print, because it's not instantaneous).

Plus, there's nothing on the stack to print. It was consumed in the comparison CURRENTMAX @ < .

Same with CURRENTMAX @ MAX CURRENTMAX !. The A/D reading is already gone.

And you're missing the closing THEN.

[pickle]

Is this an RC Servo? Or is this something we're controlling with an H-bridge? If the later, how is the position loop closed? Quadrature? Position pot? Other?

We may be using the servo described at http://www.servocity.com/html/hs-785hb_3_5_rotations.html . We are allowing for a +/- 1 degree error. The product's description boasts "precise heavy duty Karbonite gears for accurate positioning and minimal backlash as well as an integrated circuit that provides strong standing torque and stability." We haven't tested for accuracy yet, so at this point we're assuming a +/- 1 degree accuracy. This would require a PWM output right? I'm not sure about closing the loop, sounds like I need read PWM computing? So does the servo require a constantly running machine to hold it's positon? Maybe a background process that runs every so often and checks the variable ANGLE?

Okay, but I notice in the code you move the servo and then take the reading. Better to move the servo at the end of the routine before leaving, so it settled and ready for the next reading.

Otherwise you should wait after moving the servo until it reaches its position.
Thanks for the advice. Since we will be turning the servo and will need to read the ADC as fast as possible, I see we need to test the servo and determine how long that it is necessary to wait before reading the ADC.

It's not a great idea to put prints in your realtime programs (unless you are prepared to take the time to have them actually print, because it's not instantaneous).

Thanks for the tip. I was assuming that 'IF' reads a true/false value from the stack.

Is there a built in timer in the IsoMax package? For instance, can a one second timer be started and checked later. If not, it seems like I could write a machine to increase a variable every one second. Whenever I need to know how long it is been since the routine has started, just check the variable?

[RMDumse]

We may be using the servo ... This would require a PWM output right?

Yes, you can generate this signal with either a timer or a PWM output.

Let's see, they say, 400uS gives 630 degrees of turn. Suppose that might be a typo and they mean 360? Hum... Oh well, can't guess.

Anyway, the languge has PWM-OUT words to handle this.

I'm not sure about closing the loop, sounds like I need read PWM computing?

No, if you were using a non-RC-servo, you might need to close the loop. Inside the RC Servo, there's a pot and an IC that reads it and closes the loop.

You just have to send it position commands.

So does the server require a constantly running machine to hold it's positon?

No. The PWM and timers set up the PWM rate, and once set, you can forget it, and the same PWM pulse will be sent over and over.

Maybe a background process that runs every so often and checks the variable ANGLE?

Well, that's what i'd recommend. Put in a process that runs 0 to 360, then starts over, or reverses 360 to 0.

It can all be made to run in the background.

RC Servos only update about 50 Hz, so if you update more often than that, and just read every 50 Hz, you'll get your answer about as fast as the Servo will allow. So if you can do 1 degree 50 times a second, it means it will take you a bit over 7 seconds to get all 360 readings. Is that fast enough?

Since we will be turning the servo and will need to read the ADC as fast as possible, I see we need to test the servo and determine how long that it is necessary to wait before reading the ADC.

Well, my above estimate would be pretty close, but always good to actually test.

Thanks for the tip. I was assuming that 'IF' reads a true/false value from the stack.

It does. But the < consumes two numberic values and leaves one true/false value, which the IF tests and consumes. Result is nothing left to print or operate on.

Is there a built in timer in the IsoMax package? For instance, can a one second timer be started and checked later. If not, it seems like I could write a machine to increase a variable every one second. Whenever I need to know how long it is been since the routine has started, just check the variable?

Lots of possibilities here. There's a system timer running in the background you can just count. There are 14 other timers available for other purposes (less on the MinPod(TM) cause all the pins aren't brought out).

[pickle]

RC Servos only update about 50 Hz, so if you update more often than that, and just read every 50 Hz, you'll get your answer about as fast as the Servo will allow. So if you can do 1 degree 50 times a second, it means it will take you a bit over 7 seconds to get all 360 readings. Is that fast enough?

That's a little too slow. I think I can cut down the required readings by only finding the local maximum. The servo we're looking at does a complete 360 degree turn in 1.4 seconds, and we were hoping to get the verdict in within about 2 seconds. Also, I think having a background process that's constantly seeking the maximum value would require less readings. If I can get the required readings to about 100 different degrees, I can find the angle in about 2 seconds.

[RMDumse]

Well, you could just command the 0 position, then command the 360 position, take 260 readings per second. Or vice versa, and have your answer as fast as the servo would go, but your accuracy would be questionable.

This is what they say is "not good engineering practice" because you really don't know exactly how fast the servo is going (notice different timing depending on supply voltage) or where it is in it's swing (i.e. when it exactly gets its new command in the 50 Hz update scheme, or when it starts moving, and if it might not move faster at one end of the scale or the other.)

Here, if you closed the loop with an optical encoder, you could know exactly where the position was at each moment, and take the readings accordingly. (This is the closed loop idea resurfacing.) In other words, you just tell the Servo to go as fast as it can, and you take readings of where it is and decide if you want to read there or not.

None of this has anything to do with programming or microcontroller issues. This is purely about the construction and capabilities of the servo.

You can only send the servo new position commands every 20mS. Actually, there is some fudge room in that number, and you can push that boundary a bit and update more often, but probably not more than 30% or so. Pressed, the servo might update at 75 Hz. I think we've even tried some at 90 Hz. But somewhere up there, you're may hit a point where you are over currenting your motor. Again, you'll be out of spec, and "not within good engineering practice".

You could just update multiple degrees per update, and hope it ran linearly, and be done in 1.2 S, but that's faster than it can physically run.

But there's your bottle neck.

[pickle]

Hi

I thought y'all might be interested in knowing that the robot described above won first place in an IEEE Region Hardware competition that included schools such as Georgia Tech, University of Florida, Alabama, Tenessee and many more. We used the Minipod for the brains of the robot.

I have no regrets using the Minipod and IsoMax to program the robot. If you are willing to learn some simple Forth (it's not hard) and can draw state diagrams you can use a Pod.

I didn't realize how good I had it until I saw teams at the competition having to compile a program in C or some other language to do something simple as reading an ADC value. It was so nice being able to just type ADC7 ANALOGIN to check a value and not have to compile a program.

I really appreciate how well the mini pods are documented and also the prompt, detailed responses I received via this forum (especially from RMDumse)

If anyone's interested in seeing pictures of the robot and minipod I will gladly post them. Also, I would be glad to share any code or details if interested.

[RMDumse]

Hi Pickle! Congratulations!

It is one of our most profound joys to hear our customer's success stories. We have lots of them, but seldom do they make it back to our boards like this for the public to read, so thank you very much.

Yes, your experience of having interactive access to the internal workings gives you a considerable advantage over those who have to compile a program to have any hope of knowing what is going on in their system.

It is almost becoming unknown. So be proud of your win, and your choice to use our products, and we will be very proud to have helped you as well.

Best wishes, and thanks for letting us know!