A new version with two RPi Picos?

[Overlights]

Hi Terje,
I thank you for the great work you are carrying out.

About your GRBL MPG DRO system (which I really like), I was wondering if it could employ two RPi Picos (or a Pico and a Pico W) instead of the MSP430G2553 controller.
The latter is cheaper than a Pico (maybe by a couple of euros), but it seems more complex to manage in terms of programming.
The direct questions are:
1 - Does the MSP430G2553 have specific characteristics that make it more suitable than a Pico in this system?
(I read that you chose it because you know it well).
2 - If another Pico could replace the task of the MSP430G2553, do you think it would be better to remap only the functions
managed by the MSP on the new Pico (leaving the circuit of the Pico already present unchanged), or would it be better to review everything, based on two Pico onboard?
If a version with two Picos doesn't sound like a bad idea to you, I'd like to try making it.

[terjeio]

The latter is cheaper than a Pico (maybe by a couple of euros), but it seems more complex to manage in terms of programming.

My idea was to let the Pico program the chip with a binary blob, but sadly I have got around not to implement that yet.

1. Yes and no. The yes bit is that it is a small component and, for me, I had the keypad scanning code ready from another project.
2. Replacing the MSP430G2553 with a Pico (or another suitable MCU) should be fairly straightforward, it is a matter of reimplementing the I2C based protocol as seen from the current Pico, Basically the MSP430G2553 sleeps until a key (or key combination) is pressed, scan the keypad to figure out which and then debounce before interrupting the Pico so that it can fetch the keycode. And it also responds to a few commands over I2C to change the keycode -> key character map and drive the LEDs.

[Overlights]

Hi Terje,
Sorry for the delay.
I took some time to re-read some discussions in this repository.
It seems that the possibility of implementing two Picos has already been partly discussed and widely considered by you.
But some are more oriented towards a control that integrates most of the modules (buttons, LEDs, LCD, encoders) in a single PCB.
This leads to a more complex and expensive final device, which has a fixed layout of the controls (you may like it or not), therefore not very customizable according to your needs.
The way I interpreted your project, I think it should go in the opposite direction.
So:

• A relatively inexpensive remote control, but quite simple to dial.
• Which can be programmed easily and within the expected functionality, it can be extensively customized and configured.
  Another aspect that I consider important (better to say fundamental), it's the layout of the controls.
  A remote control for a CNC should be solid, ergonomic, with controls in intuitive and easy-to-reach positions, clear texts and a large display (in proportion to the user's age ;-)
  An excellent example is your Lathe control:
  https://github.com/terjeio/GRBL_MPG_DRO_BoosterPack/blob/master/media/IMG_8515.jpg
  created by composing the parts according to your taste and needs.
  Thanks to that photo (and to you who made it) I was able to search for similar buttons on Aliexpress and purchase them.

Going to the version with two Pico modules, as you say, the I2C protocol of the MSP should be reimplemented on the second Pico.
I would be happy to do it myself, but unfortunately I'm not a programmer.
I also have no idea how much effort it takes to do this, but I'm sure you know.
Could you consider it?
(calmly, without haste :-)

In the meantime, if you agree, I could start preparing a new scheme, which integrates two Pico modules (I use Kicad 5).

I was forgetting something.
The choice to compose the control using separate buttons (therefore without using Keypad) certainly reduces costs and allows maximum customization, but rewiring the correct 5x5 matrix on about twenty buttons fixed to a panel is not exactly simple.
For this reason I thought of creating a small connection interface that simplifies the wiring work between the key matrix and the various buttons.
At the beginning I had also inserted some Header pins, next to each Terminal Block. But then I took them off, they were useless.
This "KeyMatrix - Buttons" connection interface retains the same position of the switches that you set (but I didn't understand why you numbered the sequence of buttons by columns, rather than by rows).
Prototype of GRBL MPG DRO KeyMatrix Breakout Board:

The PCB measures 80x80 mm. and the distance between the fixing holes is 71 mm. both horizontally and vertically.
The screw terminals are of the KS350 type, therefore with a 3.50 mm pitch. On Aliexpress, a batch of 50 pieces costs just over 3 euros.
As an alternative to screw connectors, you can simply solder the cables directly to the Pads.

In the afternoon I ordered the board from JLCPCB. Their classic 5 pcb offer has a particularly advantageous shipping cost.
Less than 5 euros for 5 pieces, shipping included.

This is the project in Kicad 5 version:
GRBL_MPG_DRO_2Pv_KeyMatrix_BB_v02.zip
(I'm also self-taught about Kicad, but I don't think anything is missing)
This is the gerber file, ready to print:
GRBL_MPG_DRO_2Pv_KMBB_Gerber.zip

I hope you don't mind this (arbitrary) initiative.
I find it a really interesting project, it would be a shame not to be able to exploit its potential, just due to MSP programming difficulties.
However, it's just my opinion.
Best regards,
Marco

[terjeio]

I have now committed a new version with the MSP430 code embedded as a blob together with code that checks for the keypad controller firmware version and flashes it if it is missing or out of date. This solves the issue of compiling and flashing the MSP430 keypad code.
BTW the 20 pin variant can be used with the same firmware if LED output is not needed (if I am not mistaken).

I will put porting the code to another processor such as the RP2040 on my longer term todo list, but will appreciate if somebody else comes up with with a port before I do.

A relatively inexpensive remote control, but quite simple to dial.

FYI it should be possible to use Bluetooth (or Wifi) for communicating with a grblHAL controller, I have changed the stream handlers to allow that - but I have not yet gotten around to test the change.

I hope you don't mind this (arbitrary) initiative.

No, not at all - I simply do not have enough time to keep all the projects I have started (and not yet started) up to date so I am happy that someone can make use of what has been done and move it forward.

[Overlights]

Hi Terje,
Thank you very much for the work done!
(almost a miracle, in so few hours...)

BTW the 20 pin variant can be used with the same firmware if LED output is not needed (if I am not mistaken).

Good to know.
But I imagine that most of those who will make it will prefer to implement all the features, simply by printing the pcb of your already published Kicad version, with the 28 pin MSP430.

I will put porting the code to another processor such as the RP2040 on my longer term todo list, but will appreciate if somebody else comes up with with a port before I do.

I understand it perfectly, and it's already a step forward.
Thanks for this too. :-)

FYI it should be possible to use Bluetooth (or Wifi) for communicating with a grblHAL controller, I have changed the stream handlers to allow that - but I have not yet gotten around to test the change.

This is also good news. I hoped so.
A trick not to forget to implement it, will be to create a non-metallic case, or in metal, but with one side in plastic material (the USB connector side of the Pico, where the antenna is located).

I will notify you here of any new updates to the project.

You are fine!
Marco

[M10CUBE]

Hi @Overlights Is any news about making the MPG solely with Picos?

[Overlights]

Hi M10CUBE,
No, the version with two Picos is a path that I haven't followed since Terje updated the firmware for his board, making it easier to program the MSP430 through the Pico.
At that point, rather than redesigning a new board with two picos, I preferred to optimize the Terje board, so as to be able to use keypads and/or individual buttons, and alternative LED resistors, to have the possibility of freely customizing the layout of the control.
The 0.1C revision of the Terje board is currently described here:
#21 (comment)
I printed some prototypes a while ago, but haven't had time to test it yet.

[terjeio]

making it easier to program the MSP430 through the Pico.

"easier" means automatic, the Pico will program the MSP430 when there is no firmware on it, even update it if there is a newer version.

but haven't had time to test it yet.

I have done some initial tests and it seems to work, at least in UART mode. And the MSP430 was programmed on first startup as it should.

[M10CUBE]

OK guys I see. Having everything considered I have an idea and I like your opinion.
I post it here:
#21 (comment)
Probably you know it.