Questions about abdrive lib

Rsadeika

What is it about the abdrive library, that when added it pushes the program size by ~10K? I have been trying to create a program that would drive the ActivityBot using the least amount of code size, but it seems like the abdrive lib is responsible for a lot of the code size increase.

After looking at the abdrive lib itself, I cannot determine if it is this:

#include"simpletext.h"
#include "fdserial.h"
#include <string.h>

that pushes up the code size. Another large library, code size, is the use of the SD lib, when you combine the SD lib with the abdrive lib you really do not have very much room left to develop an exciting ActivityBot. It almost seems that the availability of XMMC should be mandatory, or we revert to programming in PASM.

In a very basic abdrive program, it shows "Code Size 13,000 bytes (16,820 total)", so has there been another 3,820 bytes added making even less room for program expansion? I am still trying to figure out how much RAM is really being used. Other than that ...

Ray

jazzed

Hi Ray,

If you use Project Manager you can right-click on a file-name and use Show Map File to see what's eating memory.

libabdrive is using 0x12b0 or 4784 bytes.

Rsadeika

Since showing some code always makes a difference, below is a snippet, and after doing "Build Project", I get - Code Size 12,760 bytes (16,564 total). I guess the first question is, (16,564 total) does this mean approximately half the memory available is used? And, 4784 bytes for the abdrive lib, 15564 - 4784 = 11780, what is using 11780 bytes? Why is this skeleton of a program so bloated?

Ray

/*
  Blank Simple Project.c
  http://learn.parallax.com/propeller-c-tutorials 
*/
#include "simpletools.h"                      // Include simple tools
#include "abdrive.h"

static volatile int speedLeft = 0;
static volatile int speedRight = 0;

void ab_nav(void);

int main()                                    // Main function
{
  // Add startup code here.

 
  while(1)
  {
    // Add main loop code here.
    
  }  
}


/* The servo drive control function. */
void ab_nav(void)
{
//  if(speedLeftOld != speedLeft || speedRightOld != speedRight)
//  {
    drive_speed(speedLeft, speedRight);
//    speedLeftOld = speedLeft;
//    speedRightOld = speedRight;
//  } 
  pause(20);
}

jazzed

Can you fish for the difference using Show Map File? It shows usage for each function and library as well as many sections such as data .... Maybe we need a map file primer.

Steph Lindsay

As soon as Andy finalizes the encoder redesign, he plans to sigificantly reduce the size of abdrive, while adding some planned features. So stay tuned, or feel free to experiment with it yourself!

Rsadeika

... or feel free to experiment with it yourself!

Usually when I look at the code that Andy has provided, I can sort of figure out what is going on, but abdrive.c is an exception. That code listing, without any meaningful comments, is very difficult to decipher, if not impossible, for me. I was trying to find the function that basically drives the servos, no luck, I am not sure how that is being done. I thought that there would be that basic function, manipulate the servos, and then build off of that. Maybe, in Learn section, you should have a basic lesson, how the servos are driven using C/C++ code.

XMMC does not support launching LMM/CMM code into other cogs, which is what the abdrive library does. A COGC or PASM version of abdrive will have to be developed to support code in XMMC mode. The same is true for any other library that launches LMM/CMM code into a cog.

I am not really sure what this comment means, I thought the problem was that using cogs in XMMC resulted in some very sluggish run times? If you create a COGC or PASM version and then run it in XMMC mode you would get the same sluggish response, correct. So I am not sure why you would not just have the availability of writing all your cog(s) necessary code in XMMC to begin with?

It looks like there is a very heavy reliance on CMM mode, but with the hefty libraries that have to be used, that is starting to fall short of being a good remedy. Just my thoughts, I am sure that I am probably the only one that sees this as a problem.

Ray

David Betz

Rsadeika wrote: »

Usually when I look at the code that Andy has provided, I can sort of figure out what is going on, but abdrive.c is an exception. That code listing, without any meaningful comments, is very difficult to decipher, if not impossible, for me. I was trying to find the function that basically drives the servos, no luck, I am not sure how that is being done. I thought that there would be that basic function, manipulate the servos, and then build off of that. Maybe, in Learn section, you should have a basic lesson, how the servos are driven using C/C++ code.


I am not really sure what this comment means, I thought the problem was that using cogs in XMMC resulted in some very sluggish run times? If you create a COGC or PASM version and then run it in XMMC mode you would get the same sluggish response, correct. So I am not sure why you would not just have the availability of writing all your cog(s) necessary code in XMMC to begin with?

It looks like there is a very heavy reliance on CMM mode, but with the hefty libraries that have to be used, that is starting to fall short of being a good remedy. Just my thoughts, I am sure that I am probably the only one that sees this as a problem.

Ray

PropGCC does not allow you to run code using different memory models together with the exception that you can make a "driver" using COG mode and load that at runtime. LMM and CMM can't be mixed with XMM. There is a project underway to allow for multiple XMM COGs but it isn't ready yet.

jazzed

Rsadeika wrote: »

I am not really sure what this comment means, I thought the problem was that using cogs in XMMC resulted in some very sluggish run times? If you create a COGC or PASM version and then run it in XMMC mode you would get the same sluggish response, correct. So I am not sure why you would not just have the availability of writing all your cog(s) necessary code in XMMC to begin with?

The comment is "XMMC does not support launching LMM/CMM code into other cogs, which is what the abdrive library does...."

Propeller GCC supports running a function in a separate COG just like Spin does. This is only available at the moment in CMM/LMM modes in the release. In a future release, we will also be able to run a function in a separate COG in XMM modes.

Hope that helps.
--Steve

Andy Lindsay (Parallax)

Hi Ray,

I am sorry for leaving abdrive in such a state. I am just about done with my other tasks and will post a smaller memory footprint version immediately after that.

The encoder counting, feedback control system, servo control, and trim compensation are all stuffed into one function named encoders that runs in a separate CMM cog. You will see the values of PHSA and PHSB set near the end of abdrive.c. Those get started as servo pulses that the A and B counter modules complete while the cog's code moves on to rechecking the encoders, recalculating distance, correcting for distance errors, etc.

Andy

Andy Lindsay (Parallax)

P.S. Memory will be reduced by: (1) Changing from 32 to 16 bit variables in arrays that hold calibration values, (2) moving non interdependent functions into separate files and then recompiling, and (3) reducing the size of the stack, and (4) collapsing code that repeats for each side into loops. That should make your CMM code space considerably more roomy.

Rsadeika

Another key feature of the ActivityBot, along with the servo drives, is the uSD adaptor. By adding this:

  int DO = 22, CLK = 23, DI = 24, CS = 25;  // SD I/O pins
  sd_mount(DO, CLK, DI, CS);

also increases the program size by approximately ~10K, I wonder if anything can be done to reduce the size of that? Once people get a feel for the new and improved abdrive lib, they just might want to data log the encoder related values on the uSD card.

Ray

Andy Lindsay (Parallax)

No need to wait for abdrive cleanup, you can do that now with 5 k remaining for your application code. Although the libraries take sizable chunks, you application fit a lot into 5 k. I'm hoping to recover an additional 5 k with the abdrive corrections.

Andy Lindsay (Parallax)

...and about a LITE version of sd, I tried Spin2Cpp on FSRW with only a slight size reduction. Using the PASM components and hand translating some of the Spin methods might yield better results.

Andy Lindsay (Parallax)

Hi Ray,

My first pass at reducing abdrive's footprint in Main RAM program memory reduced typical navigation programs by 6.5 k.

I still have lots of updates to do, but figured you might be interested in testing it since it makes lots of extra room for the applications you seem to be interested in writing. So a slightly modified example of your app from MyActivityBot Post #51 is attached.

19.8 kB - With current abdrive
13.3 kB - With abdrive in attached zip

---

6.5 kB - Net savings from first edit

Keep the Footprint Small

To take advantage of the whole 6.5 kB, avoid print, dprint, sprint and scan unless you actually have to print floating point values. So far, all I see are decimal values in the app, so use printStr and printDec instead. You are already using writeStr and readStr in place of dprint, which also saves space. For more info on these functions, click Help in SimpleIDE, select Simple Library Reference, then follow the simpletext.h link.

Andy

Andy Lindsay (Parallax)

Rsadeika wrote: »

Another key feature of the ActivityBot, along with the servo drives, is the uSD adaptor. By adding this:

  int DO = 22, CLK = 23, DI = 24, CS = 25;  // SD I/O pins
  sd_mount(DO, CLK, DI, CS);

also increases the program size by approximately ~10K, I wonder if anything can be done to reduce the size of that? Once people get a feel for the new and improved abdrive lib, they just might want to data log the encoder related values on the uSD card.
Ray

Alright, let's start with the downsized abdrive library and your app from MyActivityBot Post #51. Then, we can add SD card datalogging of IR remote key presses to this mix. That should make a decent example because your app is already using lots of library features:

• abdrive uses another cog to monitor encoders, feedback system calculations, and servo control
• abdrive also uses I2C and EEPROM libraries to load linear interpolation tables to improve responses to drive_speed and other calls
• fdserial for communication in another cog + simpletext for communication with PC terminal through XBee radio
• ping for simplifying Ping))) Ultrasonic Sensor measurements
• sonyremote for monitoring and processing IR remote button presses

...and the application is also already doing a number of tasks, including:

• Processing TV remote commands and making the ActivityBot respond accordingly
• Processing commands from PC sent wirelessly to an XBee on the ActivityBot, which also makes the ActivityBot respond accordingly
• Reporting status wirelessly to PC via XB
• Reporting status wired to SimpleIDE Terminal (when connected)
• On command, switch into autonomous mode and roam with Ping))) Ultrasonic Distance Sensor

The example is attached, and again, it uses the downsized abdrive, and following the rules from my previous post, it takes 24.4 kB. This leaves 8 kB for further expanding your application. Given everything it's already doing, I think you'll be able to use that space to significantly expand the program's feature set.

We'll also continue to make the Simple Libraries more compact. The second and third passes through abdrive should free up more space, and we'll look into a lighter SD option as well.

Rsadeika

Thank you Andy, I will be taking a look at what you have done, shortly. I am also thinking about that Sensirion library, I have not seen that in an official release yet. I am thinking that the ActivityBot could do something useful, like data log some temp/humidity data in some designated areas, once the ActivityBot learns how to map some rooms. All I need now is an expansion shelf for the ActivityBot to place some more sensors, and a Raspberry Pi to help do some of the heavy lifting, with so much data that will be available for processing.

Ray