Shop OBEX P1 Docs P2 Docs Learn Events
SimpleIDE Error Codes — Parallax Forums

SimpleIDE Error Codes

DiscoveryDiscovery Posts: 606
edited 2014-11-09 11:29 in Propeller 1
I am developing product "C" code for the Propeller and have issues with output signals disappearing from a COG when main program code is expanded.

A plethera of compiler warnings are generated but the program does successfully compile. My suspicion is that as the compiler inserts default over rides, a problem occurs with the execution of the code.

It is not obvious to me how to correct the warnings. I want to eliminate the warnings and produce clean compiled code.

Is there a document that lists the warning error codes along with examples of how to fix the problems?

Discovery

Comments

  • Dave HeinDave Hein Posts: 6,347
    edited 2014-11-08 17:52
    You could probably google the warning messages you are getting and find suggestions that have been posted for common problems. Or you could just post the warning messages to this thread and we could suggest solutions.

    One problem you may be encountering is that you're running out of stack space in the main thread. Try calling this routine to see how much stack space you have.
    void CheckStack(void)
    {
        char *ptr = malloc(4);
        printf("Stack space = %d bytes\n", (int)&ptr - (int)ptr);
        free(ptr);
    }
    
    I haven't tested this code, but it should work.
  • DavidZemonDavidZemon Posts: 2,973
    edited 2014-11-08 18:04
    Dave Hein wrote: »
    You could probably google the warning messages you are getting and find suggestions that have been posted for common problems. Or you could just post the warning messages to this thread and we could suggest solutions.

    One problem you may be encountering is that you're running out of stack space in the main thread. Try calling this routine to see how much stack space you have.
    void CheckStack(void)
    {
        char *ptr = malloc(4);
        printf("Stack space = %d bytes\n", (int)&ptr - (int)ptr);
        free(ptr);
    }
    
    I haven't tested this code, but it should work.

    Wish I had that code snippet years ago! Putting that in the PropWare utils right away!

    I notice you're allocating 4 bytes to be assigned to a one-byte variable. Was that on purpose? If so, why?
  • Heater.Heater. Posts: 21,230
    edited 2014-11-08 18:06
    Discovery,

    What warning error codes do you mean?

    A typical compiler warning looks like this:
    hello.c:15:1: warning: control reaches end of non-void function [-Wreturn-type]
    

    This immediately shows a problem with the file "hello.c" at line 15 column 1. And an idication of what the problem is.

    Of course one may not immediately understand the text in the warning. Google is your friend. A search for that warning message will generally get you to a page on stackoverflow.com where you will mostly find an answer.

    Often the problem that caused the warning may not actually be in the indicated line. For example the warning above is saying that I have no return statement in a function that is declared to return some value. The fix could be to add a return statement or it could be to change the declaration of the function.

    Can you post some examples of the warnings you are getting?
  • Heater.Heater. Posts: 21,230
    edited 2014-11-08 18:16
    Dave,

    I have some reservations about that stack check.

    It assumes the heap is in low memory and the stack growing down from high memory.

    It assume that the 4 bytes that have been allocated are going to be on the top of the heap.

    What if your program has been doing a lot of mallocs, then frees some things low down in the heap?

    Then those four bytes maybe located low down in the heap and you will have live data sitting between there and the stack!
  • DavidZemonDavidZemon Posts: 2,973
    edited 2014-11-08 18:49
    Heater. wrote: »
    Dave,

    I have some reservations about that stack check.

    It assumes the heap is in low memory and the stack growing down from high memory.

    It assume that the 4 bytes that have been allocated are going to be on the top of the heap.

    What if your program has been doing a lot of mallocs, then frees some things low down in the heap?

    Then those four bytes maybe located low down in the heap and you will have live data sitting between there and the stack!

    Ugh :( Good points. I don't know any way around the fragmented memory issue.

    The only work-around I can think of is to provide a function that uses a binary-search-tree-like algorithm to attempt to allocate the largest possible free block of memory. I can put in the docs some basic limitations such as: if another cog is using malloc, that's obviously going to mess with it.
  • Dave HeinDave Hein Posts: 6,347
    edited 2014-11-08 19:55
    I notice you're allocating 4 bytes to be assigned to a one-byte variable. Was that on purpose? If so, why?
    malloc returns the address of the 4 byte chunk, which is then being assigned to a pointer. The pointer type is irrelevant. Also, the size of 4 is arbitrary. I'm just trying to get an indication where the heap is located. The heap grows toward higher addresses, and the stack grows toward the heap to lower addresses.

    Heater is correct that this code is not perfect. Only Discovery can tell us whether his code does any mallocs. If not, then my test code should work OK. However, the file system does malloc memory when opening files, so even if he does not explicitly use malloc, there will be malloc'ed buffers when a file is opened. In that case, the CheckStack function should be called after files have been opened, and before they are closed.

    I just want to get an idea if he is running out of stack space. If CheckStack prints a large number then his stack is probably OK. If it prints a small number that's less than a few hundred bytes he may be running out of stack space.
  • DiscoveryDiscovery Posts: 606
    edited 2014-11-09 07:04
    I checked the error codes and cleared the warnings.

    All the Plasma Cutter software is running correctly. All the mechanism control hardware is moving correctly.

    Clearing out the warnings did the trick.

    I did not have the need to run the suggested stack code function.

    Thank you all very much...problems solved.

    Discovery
  • Heater.Heater. Posts: 21,230
    edited 2014-11-09 11:29
    Well done Discovery.

    It might be useful if you told which warnings were causing the problem(s).
Sign In or Register to comment.