HAL AVR vs. HAL DUE

Hi,


transferring some of my custom stuff from DUE to AVR i found we have no WRITE_VAR in AVR , also SET_OUTPUT seems to be different.

SET_OUTPUT in DUE Version can handle variables, AVR not.

So it´s no Problem at all for me , as i can change my code to make it work with the existing stuff, just wanted to let you know

Comments

  • Posts: 345

    so some more strange stuff :

    i use that code on DUE for unhandled MCodes , works fine

    but on AVR it doesn´t compile it just Returns :

    exit status 1
    initializer fails to determine size of '__c'


    CODE:

    bool Custom_MCode(GCode *com)
    {
     
      char buf[20];
      char buf2[20];
      uint16_t PIN,Speed,angle ;
     
      switch(com->M) {
         
      case 6:
             #if defined(SUPPORT_CNC) && SUPPORT_CNC
          if (Printer::mode == PRINTER_MODE_CNC)
          {
            if (com->hasT())
               {
                uint8_t Toolnumber = (com->T);
                sprintf(buf, "change Tool : T%d ", Toolnumber);
                sprintf(buf2, "Tool T%d push OK", Toolnumber);
                UI_STATUS(PSTR(buf2));
                Com::printFLN(PSTR(buf));
               }
             else
               {

  • Posts: 345

    forgot one error message :

    error: array must be initialized with a brace-enclosed initializer


    ist pointing to :    Com::printFLN(PSTR(buf));

  • Posts: 0
    PSTR is to have a line stored in flash printed. Also in print F is flash.
    Use Com::print(buf);Com::println(); instead.

    On due PSTR is just a dummy macro doing nothing.

    And yes, SET_OUTPUT is only vor fixed pins. Just the special implementation make sit work with variables on due. Use arduino function to set it as output if you need variable pin numbers.
  • Posts: 345

    OK,Thanks

    compiles now with using :

     UI_STATUS_F(buf);

    and

    Com::printF(buf);





  • Posts: 0
    But it will not work. buf is in ram and the F says search flash memory same address. For ram always use the non F functions!
  • Posts: 345
    OK, but seems there is some mismatch in UI_STATUS.

    if i use the non F version it doesn´t compile...

    see DisplayList.h  :

    #define UI_STATUS(status) uid.setStatusP(PSTR(status));
    #define UI_STATUS_F(status) uid.setStatusP(status);

    are the defines swapped?

    as you wrote before :

    PSTR is to have a line stored in flash printed. Also in print F is flash.


    shouldn´t it be :

    #define UI_STATUS(status) uid.setStatusP(status);
    #define UI_STATUS_F(status) uid.setStatusP(PSTR(status));

    hope you can take a look at that.
  • Posts: 0
    Both are for flash.. The one without F was for strings stored by Com:: in flash so no conversion was necessary. You want one of these

    #define UI_STATUS_RAM(status) uid.setStatus(status);
    #define UI_STATUS_UPD_RAM(status) {uid.setStatus(status);uid.refreshPage();}

  • Posts: 345
    OK, thanks for your help,

    can you recommend some literature to improve my programming knowledge as there are so many things i don´t know about...?
  • Posts: 0
    Not really. I read sometimes an article or browse through other peoples code to learn how they solve things. So over the last 30 years I accumulated a wide spread of ways to solve things. I do not think there is one good book that makes you a good programmer. You can use a book to learn a language or a library, but to improve overall skills you need to write much code, get into trouble and search for solutions. These solutions give you hints how you could do it. You can also google for design patterns which is more or less what I'm talking about. There are always several pattern solving same problem and some just work better in some situations and some are just personal liking and some only work with some languages.
  • Posts: 345
    thanks, so it´s just the way i do actually.
    did some basic programming in turbo pascal  and assembler during my technician education beginning of 1990´s .
    unfortunately i did not continue until 2014 , that´s where i started with the arduino stuff beginning from zero.
    so maybe i´ll see my improvements within the next 30 years :-)
Sign In or Register to comment.