esp32 eeprom support

[arferdz]

First try uploading to esp32. Copied the contents of grbl folder to esp32/grbl. I encountered some errors which went away when i commented some lines on the following files:

line #82 on dns_server.c lines #1658 to #1663 on driver.c

I cant take away an error saying grbl_hal_t has no member named eeprom.

using platformio on vscode. just a beginner. please tell me wht i need to do.

thanks in advance.

[terjeio]

line #82 on dns_server.c

What is the error you get on this line?

I cant take away an error saying grbl_hal_t has no member named eeprom.

My bad, I have not updated the ESP32 driver code for the latest core changes. Sorry for that.

I will commit the changes a bit later, I am a bit busy now.

[arferdz]

thanks

for line#82 on dns_server.c

[terjeio]

using platformio on vscode.

Do you know if platformio is using cmake and thus CMakeLists.txt for compiling?

If not it could be that the code in dns_server.c should be excluded depending on settings in driver.h. An easy way to check this is to delete the contents of dns_server.c and recompile. If it then compiles this would indicate that cmake is not used.

Have you modified driver.h?

[terjeio]

I have brought the ESP32 driver in sync with the core and added a guard so that code in dns_server is excluded when not needed. Hopefully this will solve this issue.

[arferdz]

Do you know if platformio is using cmake and thus CMakeLists.txt for compiling?

afaik it does not.

Have you modified driver.h?

yes. i have enabled/disabled features with it thinking that cmakelist is not used.

[terjeio]

Do you know if platformio is using cmake and thus CMakeLists.txt for compiling? afaik it does not.

Then with luck the latest version should work. Please report back.

[arferdz]

i got some compile errors related o backend.c and commands.c.

i temporarily commented out the lines just to see if it can compile but i ran with some problems which i think is platformio's fault.

i will work on it later.

[arferdz]

i managed to remove above errors by editing out some functions and variables mainly on these two files: backend.c and commands.c

i was not able to successfully compile though because of these errors

[terjeio]

Ok, function names in esp32-hal-uart.c has to be changed and updated in driver.c to correspond. Add a prefix? Or change "uart" to "serial"?

Perhaps the same for sha1.c as well? This may be a bit trickier if the signatures differ from the platformio version signatures.

Can you try that?

[arferdz]

Success!

[arferdz]

can we revisit how to resolve these issues?

[terjeio]

Yes please, will it be possible for you to create a pull request so I can see what you have done? If not upload a zip with the changed code? I will have to verify that the changes are not creating problems for the idf build process.

[terjeio]

Oops, maybe I misunderstood a bit. To avoid the problems listed above I think I need to add a my_machine.h to this driver as well. I wonder if there is a #define symbol that can be used to check for the Platformio environment...?

Anyway, I am still interested in knowing what changes you have made.

[arferdz]

src.zip

i believe i made changes to those files.

as for the #define symbol, i really cant tell as i was just strting on it. i actually dont have any formal programming education too. just enough to get by. sorry.

[terjeio]

Thanks, I'll take a look.

sorry.

Nothing to be sorry about, everybody has to start from somewhere.

I will add my_machine.h to the driver and use that when compiling with Platformio, this will make setup easier.

[terjeio]

How are you going to connect to the controller? Via USB? WiFi? Which sender? Or will you use the WebUI?

Since you have EEPROM in the issue header I assume you will use that for storing settings data. Correct?

[arferdz]

i had successfully used a 3.5" rpi tft lcd using bart dring's esp32 grbl port though honestly there are some more features i still desire to put.

i hope i can replicate it here. i wish to use wifi or an sd card to store/send gcode files to the controller. storing/sending the gcode files on the contoller negates the need for the sender from another terminal

you are correct regarding the eeprom for storing the settings.

i see that you have a dro/mpg made for this. is it possible to transmit it's commands using a bluetooth serial to an esp32? I think its will be a nice pair.

[terjeio]

can you add the following lines to sha1.c and recompile after changing back to the original version?

#ifndef MBEDTLS_SHA1_H as the very first line and #endif as the last.

I suspect platformio drags in the whole idf framework, even unused parts. With luck this should work. Please report back if it works and if not I would like to see the error messages.

I have a my_machine.h file ready but want to find a solution for sha1.c before I commit to github. By the way the change you have made to sha1.c will break websocket communication.

i hope i can replicate it here. i wish to use wifi or an sd card to store/send gcode files to the controller. storing/sending the gcode files on the contoller negates the need for the sender from another terminal

Should be doable. Storing to the SD card via wifi should also be possible as the code is already there. But please do not modify any code in the grbl folder! Write your code as a plugin.

i see that you have a dro/mpg made for this. is it possible to transmit it's commands using a bluetooth serial to an esp32? I think its will be a nice pair.

The code as it is now is written for a Texas Instruments Tiva C processor, no on chip Bluetooth available. Either a Bluetooth to serial adapter has to be added or the code has to be ported to ESP32 or another Bluetooth capable controller/card.

[arferdz]

here is the result after reverting back to the original sha1.c and sha1.h files and including the #ifndef and #endif.

[arferdz]

Should be doable. Storing to the SD card via wifi should also be possible as the code is already there. But please do not modify any code in the grbl folder! Write your code as a plugin.

i still need to learn how to do that. hope you can give me some heads up where i can read up on how to do it. i will also check how you did those pulg ins.

[terjeio]

here is the result after reverting back to the original sha1.c and sha1.h files and including the #ifndef and #endif.

So esp-idf ships with more than one sha1 version... The one compiled in is not compatible with the one I use. And I want my code to be portable between processors so I am not going to switch to the esp-idf version.

Luckily it seems it should be possible to exclude the esp-idf supplied version from compilation, I googled "platformio exclude path" and found some topics such as this that may be of help. The path to be exclude is likely to be components\lwip\lwip\src\netif\ppp.

i still need to learn how to do that. hope you can give me some heads up where i can read up on how to do it.

The encoder plugin is perhaps the best example to start from.

It saves a local copy of and redirects the grbl.on_realtime_report function pointer to the encoder_rt_report() function. When this has completed processing a call to the original function is done via the local copy. The grbl.on_realtime_report function pointer is not the best to hook into as it requires a sender issuing real time requests for its function to be called. A likely better candidate is grbl.on_execute_realtime as this gets called continually with a very high frequency.

hal.get_elapsed_ticks is a new hal entry point that I recently added, this can be used to get the time elapsed in milliseconds since startup, this if you want to time writes to the display. Note that this is not yet universally available and may be unset. It is on my todo list to add this to all drivers. Note that any processing done in grbl.on_execute_realtime should be as quick as possible in order not to interfere with normal execution. Time consuming tasks should be split up into small pieces or if possible delegated to DMA.

hal and grbl entry point definitions can be found in grbl/hal.h.

[arferdz]

Ok. I will try excluding the esp-idf version. Then work on making a plugin which i feel i over my head at the moment.

Thanks

[terjeio]

Then work on making a plugin which i feel i over my head at the moment.

I took a quick look at your code, you are using a event driven UI library it seems- similar to what I use for my MPG/DRO. This means the hard work is already done.

A "heads up" skeleton of a plugin code that should get you started:

#include "grbl/hal.h"

static on_execute_realtime_ptr on_execute_realtime;

static void lv_task_handler (uint_fast16_t state)
{
   static uint32_t elapsed = 0;

   unit32_t ms = hal.get_elapsed_ticks();

   if(ms - elapsed >= 5) {
        lv_tick_inc(5);
    elapsed = ms;
   }

   on_execute_realtime(); call previous function in chain
}

// add a call to my_plugin_init() at the end of driver_init() in driver.c.
my_plugin_init()
{ 
  // Add HW init to set up the GPIO pins etc. for used for display?

  // "hook"  the lv_tick_inc  call into the grbl core by wrapping it in lv_task_handler()  and call it every 5 milliseconds
  on_execute_realtime = grbl.on_execute_realtime; // save current function
  grbl.on_execute_realtime = lv_task_handler;     // and redirect to lv_task_handler

  lv_init();

  // create your UI here
}

Note that hal.get_elapsed_ticks() is currently not available for ESP32, I will add that in the next commit. sys_now() orxTaskGetTickCount() can be used until then.

[terjeio]

There is no need to change any source files at all if you name the init function my_plugin_init, this can be used from the last commit. See the changelog for details.

[arferdz]

thanks. i will line this up on my to do list when i work on this project again.

you have helped so much. i appreciate it.