New Keypad integration wtih IR Remote

[5ocworkshop]

Terje,

Not an issue, just wanted to say thank you for the changes to the keypad.c plugin. Thanks for your recent updates.

I was able to set it for keypad mode, add it to my_machine.h and compile it in without any issue. I added a few lines of code to send the jog cancel command on IR key relase on the Pi that is hosting the remote control, and now jogging is improved and safer. More importantly, I don't require my modified module anymore. Everything just works, including the UART change to the uart driver.

I did have to move keypad.c to the bottom of my list below fans (even though I don't have other modules enabled) othrwise I got a bunch of compile time errors about only being able to have one UART related module. This seemed strange to me as I wasn't compiling in the modules throwing the error. It seemed to be when driver.c was being compiled. Is there an IFDEF I missed somewhere?

Here is what does work

-- SNIP -- //#define FANS_ENABLE 1 // Enable fan control via M106/ M107. Enables fans plugin. // UART is below fans and so is keypad so we use the new UART for the Pi interface for the IR remote

define UART_PORT 5 // See hardware definition in uart.c - updated code to support serial8 Teensy

define KEYPAD_ENABLE 2 // Set to 1 for I2C keypad, 2 for other input such as serial data

-- SNIP --

Is there a way to avoid having to add the #define for the UART to the my_machine.h?

[5ocworkshop]

On a semi-related note, as this is the first time I'm bulit an image since you added my status-light plugin to your plugins.h, I was able to add that trivially as well by including this new line in my my_machine.h:

define STATUS_LIGHT_ENABLE 1 // Enable RGB status lights plugin

And renaming my init function to match what is expected from plugins.h. I will update my github to reflect the change soon.

Everything worked perfectly so far. Thanks for the change as well.

[5ocworkshop]

Ah yes, I had to disable my VFD and MODBUS plugins in order to get the keypad.c to enable. I just put VFD and MODBUS back and get the following error:

In file included from src\driver.c:30:0: src\driver.h:125:2: error: #error "Only one option that uses the UART serial port can be enabled!"

error "Only one option that uses the UART serial port can be enabled!"

^ In file included from src\eeprom\eeprom_24AAxxx.c:26:0: src/driver.h:125:2: error: #error "Only one option that uses the UART serial port can be enabled!"

error "Only one option that uses the UART serial port can be enabled!"

^ In file included from src\encoder\encoder.h:26:0, from src\encoder\encoder.c:25: src\encoder../driver.h:125:2: error: #error "Only one option that uses the UART serial port can be enabled!"

error "Only one option that uses the UART serial port can be enabled!"

^ In file included from src\eeprom\eeprom_24LC16B.c:24:0: src/driver.h:125:2: error: #error "Only one option that uses the UART serial port can be enabled!"

error "Only one option that uses the UART serial port can be enabled!"

^ [.pio\build\teensy41\src\eeprom\eeprom_24AAxxx.c.o] Error 1 [.pio\build\teensy41\src\driver.c.o] Error 1 [.pio\build\teensy41\src\encoder\encoder.c.o] Error 1 [.pio\build\teensy41\src\eeprom\eeprom_24LC16B.c.o] Error 1 In file included from src\fans\fans.c:24:0: src/driver.h:125:2: error: #error "Only one option that uses the UART serial port can be enabled!"

error "Only one option that uses the UART serial port can be enabled!"

^ *** [.pio\build\teensy41\src\fans\fans.c.o] Error 1 In file included from src\enet.c:22:0: src\driver.h:125:2: error: #error "Only one option that uses the UART serial port can be enabled!"

error "Only one option that uses the UART serial port can be enabled!"

^ *** [.pio\build\teensy41\src\enet.c.o] Error 1 ======================================= [FAILED] Took 4.34 seconds =======================================

The positioning of the UART = 5 does not resolve this afterall. Any idea what is causing this?

[5ocworkshop]

My apologies, I had to duck out when this first happeened. It is clear where the issue is - line 125 of driver.c and I was able to temporary resolve it my removing the KEYPAD_TEST in that line.

It seems the logic needs to take in to account the use of an additional UART as a mitigating factor, but there is an order of operations issue there that needs to be resolved as well as where the secondary UART should be declared. What are your thoughts?

[5ocworkshop]

The cobwebs are leaving my brain. The issue is that there is currently no mechanism for having more than one additional UART, correct? So it seems we need a concept of UART_MODBUS and UART_KEYPAD as an example, then we could point them to the correct place?

[5ocworkshop]

I am looking through modbus.c and trying to determine if I can use MODBUS-SERIAL_PORT as the alternate way to tell it to user UART1 just for modbus traffic but it seems like maybe multiple parallel UARTs aren't fully added yet?

[terjeio]

but it seems like maybe multiple parallel UARTs aren't fully added yet?

Yes and no... I have recently added support in the core for registering and claiming (opening) UART ports, currently max four. The STM32F4xx has code for up to two ports, and a user has added a plugin for two additional ports for his specific needs (and he has the hardware to support that). Currently the iMXRT1062 driver has support for one port only, more can be added - but which MCU UART ports/pins to use? And should I spend time adding ports to drivers when there has been no requests for that?

Some techical details (I need to start writing more documentation) :

I have added a struct, io_stream_properties_t, that is used when registering UART streams with the core. This contains info about the properties of the port implementation that may be used by code to find and claim one with the required properties. There is also a instance field that is the "port number" that can be used to explicitly claim a port, e.g. as done by the modbus plugin by defining the MODBUS_SERIAL_PORT symbol. The streams are registered with the core by driver.c calling serialRegisterStreams() in uart.c which in turns calls stream_register_streams() in the core making the port(s) discoverable and claimable. The STM32F4xx code does a bit more as it adds pin info for the $pins command...

There is a chicken/egg issue when user plugin code adds ports - these ports can not be discovered until registered so code sequencing becomes important. Should there be a preinit call to each plugin or should code needing ports delay the claim until the startup sequence is complete? The latter option is what I would prefer.

So there is still work to be done but I believe the foundation is in place for the flexibility needed for configuring grblHAL and also for user plugins to add code that needs both I/O pins and UART ports.

[karoria]

@5ocworkshop I have recently developed a webUI optimized for medium size touch screens. The UI also features lots of keyboard shortcuts which can also be easily editable if you are familier with javascript. You can try the code at below link and give your comments. https://github.com/karoria/grblTouch

[5ocworkshop]

but it seems like maybe multiple parallel UARTs aren't fully added yet?

Yes and no... I have recently added support in the core for registering and claiming (opening) UART ports, currently max four. The STM32F4xx has code for up to two ports, and a user has added a plugin for two additional ports for his specific needs (and he has the hardware to support that). Currently the iMXRT1062 driver has support for one port only, more can be added - but which MCU UART ports/pins to use? And should I spend time adding ports to drivers when there has been no requests for that?

Good questions. The grblHAL2000 board has two UARTs in the design as well. Serial1 is connected to the Modbus interface and Serial8 is connected to the 40 pin RaspberryPi header. The purpose of the Pi interface is to provide an extensible interface for developing various extensions like alternative pendants, acoustic analysis of cuts, more complex camera related functions or possibly more complex ATC or other robotics functions in the event grblHAL is being used more broadly as a motion control system outside of classical CNC.

Some techical details (I need to start writing more documentation) :

I have added a struct, io_stream_properties_t, that is used when registering UART streams with the core. This contains info about the properties of the port implementation that may be used by code to find and claim one with the required properties. There is also a instance field that is the "port number" that can be used to explicitly claim a port, e.g. as done by the modbus plugin by defining the MODBUS_SERIAL_PORT symbol. The streams are registered with the core by driver.c calling serialRegisterStreams() in uart.c which in turns calls stream_register_streams() in the core making the port(s) discoverable and claimable. The STM32F4xx code does a bit more as it adds pin info for the $pins command...

I was attempting to work with MODBUS_SERIAL_PORT but I couldn't determine what the correct value was to use there and how it mapped to the UARTs, or perhaps I was just hitting the single UART restriction?

I can understand that it isn't a priority for you. I recently upgraded from a router to a VFD/Spindle and was using on the IR interface via the Pi for basic jogging/pendant functions. I'll take a look at the STM code and see if I can adapt something from that to enable a second UART on the board. I think, given the wonderfully extensible nature of grblHAL, that having two UARTs supported, one for MODBUS and one for an accessory plugin is a good starting point.

[terjeio]

or perhaps I was just hitting the single UART restriction?

You were.

I'll take a look at the STM code and see if I can adapt something from that to enable a second UART on the board.

Basically it is about duplicating most of the existing code and modifying that for the second UART. I have used the symbol SERIAL2_MOD to guard the code for the second port in several drivers, and have tried to standardize the function names as well. Most of the functions for accessing the port are now static and accessed via pointer struct so adhering to the naming convention for these is no longer that important, but I still generally do it anyway.

The extensibility of grblHAL makes it a kind of programming platform, I recently added a HPGL interpreter as a plugin - without changing a single line of code in the core. I did this for several reasons, one was as a proof-of-concept (or kind of acid test?) of the core extensibility.