Shop OBEX P1 Docs P2 Docs Learn Events
Proposal: A book for PropGCC? - Page 2 — Parallax Forums

Proposal: A book for PropGCC?

2»

Comments

  • jazzedjazzed Posts: 11,803
    edited 2014-01-20 09:46
    I'm not writing the book, but I certainly am interested in the usefulness of it. I wanted to answer the question below.

    Rick you are welcome to use anything I write - well, things that are on topic that is :)

    Jack3 wrote: »
    ... I am relearning ANSI C, and working on Spin, C#, C++. I mess around with the Arduino version of C. ...

    So differences in the language related specifically to Prop (for example why print instead of printf ?). ....

    Functions like printf and friends are specified by ANSI C to behave a certain way. We have printf and friends in the propeller-gcc library that are ANSI C compliant that you can use.

    Function print is not ANSI C compliant. It provides a subset of what printf offers. It also is small enough to use in the limited memory space of the propeller chip and doesn't have surprises like growing to fill all available memory when using floating point.
  • twm47099twm47099 Posts: 867
    edited 2014-01-20 09:54
    I am very inexperienced with robots and microcontrollers. I'm a retired metallurgical/mechanical engineer. I had an early computer in the 1970's/80's that I programmed in basic (built in), MS fortran - a miserable experience, tiny C, and fig forth. I did a lot of programming at work for operating mechanical test machines using techtronics basic (using built in library functions) and a little MS C for translating different instrumentation data into formats that techtronics could use. But all that was a long time ago.

    I bought the activity bot for myself while I was buying a BoeBot for my nephew for Christmas. I started going through the activity bot C tuorials, then got interested in Spin and forth. So right now I have skimmed the tutorials, but haven't completed them in any language, but get interested in trying to do something and figure out how to make things work.

    For example, I programmed the abot (in propC) to move in response to SIRC commands (fwd, back, stop, pivot, travel in a curve, speed up and slow down.) After running into things, I added the whisker routine from the tutorials. I didn't like that because there was a delay between the whisker hitting something and the bot stopping/reversing/turning, so I learned how to run the whisker in another cog.

    I also learned how to have the abot scan an area with ping+bracket, move a meter in the "x" direction, turn 90 deg rescan with ping+bracket, save both scans to the SD card, then download them into excel and plot them superimposed. However, I'm not happy with how I did that programming. I wanted to place the abo0t pointing in the 'x' direction. Have it turn 90deg (right or left depending on a sirc command), have ping do a 180deg scan and save the angle (5deg increments) and distance to a file. Then abot turn back to "x", go fwd 1 meter, turn and repeat the scan from the different location. I wanted to put the ping scans/file saves into a function, but using the tutorial examples, I was not able to record both sets of data (in the same or different files) and couldn't figure out how and where to declare and open files. So I included the scan and file routines 2x in the program.

    Long story - but, the point is the C-tutorials are great in getting across basic knowledge and applying it to the activitybot so the user can see results quickly. But in some of the tutorials the "why it works that way" is a little lean, and it is hard to make the leap from what is there to how can I do something else. Also there is great reliance on the libraries which makes visible progress quick but the "what's going on?" isn't answered. For example, I have no idea how the commands to the servos and signals from the encoders are used, I just use abdrive_xxx(). That's where I think a book would be useful; how do you do the low level things? One reason for my interest in that is that with the limits on propeller memory, loading in the C-libraries eats a lot of that up. Being able to program some of the lower level function, might allow freeing up some of that memory.

    For example some questions I have based on things I've done and would like to do:
    - How can I send a SIRC command (IR LED, but what and how to send) to my Sony camera mounted on the bot to photograph? (I believe there are Spin objects for this and a recent thread where someone is trying it in C)
    - How to put segments of programs SD, have a running program load a segment from SD to EEPROM and do a propeller reset so the prop will load and run that segment? (Is there a C command that resets the prop? or does it take a PASM segment to do that?)
    - How to use the other memory models, particularly can XMM be used with my program that has the whisker routines in a separate cog? (I read the words in SIMPLEIDE & watch them fly over my head).

    I would also like to see (eventually) the C tutorials in hard copy format. I realize that they are a work in progress so a tutorial book isn't practical now. But I find that making notes in a book works better for me than downloading the pdf text to a tablet and scrolling around (with the print large enough for these old eyes to read.)

    Tom
  • mindrobotsmindrobots Posts: 6,506
    edited 2014-01-20 09:56
    jazzed wrote: »
    I'm not writing the book, but I certainly am interested in the usefulness of it. I wanted to answer the question below.

    Rick you are welcome to use anything I write - well, things that are on topic that is :)




    Functions like printf and friends are specified by ANSI C to behave a certain way. We have printf and friends in the propeller-gcc library that are ANSI C compliant that you can use.

    Function print is not ANSI C compliant. It provides a subset of what printf offers. It also is small enough to use in the limited memory space of the propeller chip and doesn't have surprises like growing to fill all available memory when using floating point.

    Thanks, Steve.....I even use your off topic remarks, just not on this forum! :lol:

    I have a growing collection of C pearls from you guys that will be used extensively in anything I write about PropGCC. If I didn't use them, I'd have no technical knowledge about this subject!
  • mindrobotsmindrobots Posts: 6,506
    edited 2014-01-21 12:46
    Note to myself from another thread:
    Cool! I remember you mentioned that you're planning to implement that feature some time ago in the thread where we talked about the PMC and the issues I had. Now it's already implemented! :-)
    Btw: Is there a document describing how to start cogs in all different memory models?

    The info is mostly spreaded in different docs or just examples. A single howto foreach memory model would be good.

    For example:
    Starting a cogc program in LMM, XMM
    Starting a cog by handing over the address of a function in LMM, XMM
    Starting a cog in XMM mode and COG uses XMM cache driver
    ...

    Is the feature to have real XMM mode for more than one cog the default configuration when launching
    new cogs in XMM mode or is there a new way to start the cogs?

    Another question, a bit off topic in this thread... In a cogc driver, are there any local variables in cog memory by default or do I have to add the COGMEM tag?
  • David BetzDavid Betz Posts: 14,516
    edited 2014-01-21 13:29
    Yes, I need to write this up. I had to go searching through sources myself when I wanted to write a program that supported loading a COG image from external memory and couldn't recall how to do that. :-(
  • mindrobotsmindrobots Posts: 6,506
    edited 2014-01-21 13:33
    David Betz wrote: »
    Yes, I need to write this up. I had to go searching through sources myself when I wanted to write a program that supported loading a COG image from external memory and couldn't recall how to do that. :-(

    Even better!!! I was just leaving it as a note to myself for a topic to cover!! :lol:
    Thanks!
Sign In or Register to comment.