MPG Project Status?

[ThatGuy435]

I'm not sure if there's a better way to inquire about the current status of this project, but where does it stand as of August 2022? Are the published PCBs working, and are there ways to program the MSP430G2553 without having the specific programming hardware?

[terjeio]

Are the published PCBs working

Yes, but consider them reference designs - and go for the Pi Pico version.

and are there ways to program the MSP430G2553 without having the specific programming hardware

Not yet, my longer term plan is to add code to the Pi Pico for programming the MSP430. And I can supply a preprogrammed MSP430 if of interest.

The MSP430 can be replaced with another MCU, e.g. an Arduino compatible one, but again I do plan to do that - I have had enough of the so-called Arduino IDE...

[ThatGuy435]

Awesome!

I'm in the midst of a conversion of a mini mill with one of Phil Barrett's GRBLHal teensy boards, and was hoping to be able to use it more or less like a manual for stuff like squaring up stock and other faster-without-programming operations. It seems like this MPG would give that functionality.

Is the JTAG programming interface for the MSP430 broken out on the board anywhere, or do I need an entirely separate programming board? Alternatively, what is the recommended hardware for flashing that chip? I'd probably rather have the equipment on hand to reflash myself in case I blow it up at any point.

[terjeio]

The JTAG interface is not brought out, the SWD is. You can use a MSP430 LaunchPad as a programmer, see the end of this readme for how to compile. I do not know if a J-Link or similar can be used.

Here is another link detailing how to program.

[ThatGuy435]

Awesome, thank you for the assistance!

[runryder912]

The MSP430 can be replaced with another MCU, e.g. an Arduino compatible one, but again I do plan to do that - I have had enough of the so-called Arduino IDE...

What kinda of funding do you need to help push this forward?

[terjeio]

What kinda of funding do you need to help push this forward?

Enough to hire somebody to do it? But then I do not know anybody who is familiar with the Arduino framework...

As I wrote above it is on my todo list to add code to the Pico so it can program the MSP430 from code embedded in the Pico flash, I'll rather get around to do this than spend more time on a programming framework that drives me nuts.

If you really want the code ported it will be far better to find someone whith experience with the 8-bit Arduinos, and there are likely projects out there that can be used as references - or with luck, more or less as-is.
The basic spec is quite simple: scan a key matrix^* and make a byte available to be collected via I2C when keys are pressed.
However, implementation is, IMO, not entirely trivial. Key debounce has to be implemented, and the different keypress modes as well. Short keypress, long keypress and key up/key down signalling - all via a single strobe output to interrupt the I2C master. Two-key rollover is nice to have but not required.

^* If the MCU has enough input pins to support the keys required using a matrix is not a requirement. Or matrix scanning/key input can be done on the Pico itself, again provided that there are enough free pins.

[M10CUBE]

Sorry @ThatGuy435 for hijacking your space but looks the correct place to place an idea that will profit our community here and give a boost the excellent job made by @terjeio .
One year ago I had an idea of designing an MPG PENDANT (more simplified that this fine piece designed by @terjeio )
After reading this thread I am wondering...
@terjeio on the Pi_Pico_Board what about substituting the MSP430 with another Pico module? Keeping all the user interface peripherals as is. Simplifies final user programming and have less cost.
In fact making the board a bit bigger (90X90 mm) can accommodate the 2XPICO. M10 PCB framework can be used . The build can have all the connectors ready for plugging with the framework already in the GRBL_MPG_DRO_BoosterPack (keyboards, switches, LCD etc)
It is obvious then to send data via WiFi to GRBLHAL as an option (later on when we have some free time)
I can help with the hardware if you can help with the firmware. May be more contributors may help on that
I for some reason feel that this post has no meaning please forgive and ignore it.
Thank you

[terjeio]

what about substituting the MSP430 with another Pico module?

Better to use a RP2040 chip? BTW I have started porting code for programming the MSP430 from the Pico - automatically. I want to see if I can manage to do this before porting the code to another processor.

[M10CUBE]

Better to use a RP2040 chip?

Well it is a thought but my experience says that quickest and fastest way to bring a product in the "market" is to use the ready modules mass produced. Your Nucleo breakout CNC board is an excellent example. That is if you have the real estate on board and the module have all the pins from the MPU to the edge.
Looks that Pico has almost all pins on the edge (chip has 2 more pins I think).
If you allow me, I can make a rough idea of the design examining 2 scenarios using the 2X Pico modules.
I will try to imitate it in hardware with the second Pico what you did with MSP430 chip.

In fact all the pin-outs to the Picos will be as a direct replacement of the Pi_Pico_Board.
All you have to do is upload to 1st pico the code already there and port MSP430 code to the 2nd Pico

That hardware can be implemented very easily and fast
In a later time If we feel confident we can recreate everything on a new board using 2xRP2040 chips and porting the same code.
Thanks to KiCAD 7 (now)

BTW I have started porting code for programming the MSP430 from the Pico - automatically. I want to see if I can manage to do this before porting the code to another processor.

Yes I sow that in a previews post. Go for it. Meanwhile i will study the Pi_Pico_Board preparing the 2 solutions I am thinking.
So please I like to here about that.

[terjeio]

Well it is a thought but my experience says that quickest and fastest way to bring a product in the "market" is to use the ready modules mass produced.

That depends on whether you indent to have the board ready made or components soldered by the buyer. If ready made it will be easier to have the chip(s) presoldered. Like this pendant.
For the RP2040 it will still be an issue for how to program the keypad controller chip though.

[M10CUBE]

That depends on whether you indent to have the board ready made or components soldered by the buyer. If ready made it will be easier to have the chip(s) presoldered.

Both have advantages and disadvantages. Considering that there is not going to construct thousands of boards
I will try to write here some but lets correct them in the process.
Pico module advantages
Ready of the self. Highly available. Can be used for other projects. Ready WiFi or Ethernet available. Cheap and easy DIY construction and fast to market time. As an option user can provide his own Raspberry Pico from his stock
Pico module disadvantages
More real estate on the mother board. Some pins are missing on the edge of the module (but used in favor of the WiFi chip).
Time needed to solder or to plug in the module.
More expensive than using the discreet components ?

Discreet components advantages
Better arrangement on the board. Less real estate and compact processional design. Ready board with no soldering from the user. Cheaper?
Discreet components disadvantages
Extremely difficult and time consuming to solder by the user in case of user populated.
Very careful design and proper selection of the materials fro the fab factory. Time consuming on the design to send for fabrication. When shortage of materials difficulties irises. Difficulty on the revisions
More expensive contraction?

One intermediate solution for the Pico module scenario is to have presoldered from the FAB factory on the board other components like resistors, transistors, LED etc...

Finally if the Pico module solution goes well (and that will be fast) and use shows that the discrete solution must be case we can design a discrete one having all the experience from the Pico module

Like this pendant.

Nice design but the revised GRBL_MPG_DRO_BoosterPack will have much more capabilities

For the RP2040 it will still be an issue for how to program the keypad controller chip though.

I may missed something here. The idea is to substitute the MSP430 with a RP2040 chip. Right? Thus the second RP2040 with do what the MSP430 was doing on the initial design. Board has no MSP430 chip. All the code from MSP430 will be ported on the second RP2040 module. I thing we have enough pins to cover all function dune by the MSP430 chip
Is this a problem?
I am already trying to make one new design (only schematic on KICAD7) coping and pasting from your GRBL_MPG Pi_Pico_Board to see what can be done. If revised and agreed we will go to design the PCB.
Is that OK?

[terjeio]

Is this a problem?

A RP2040 module is simple to program via the inbuilt bootloader that exposes it as a flash drive - just drag&drop the binary.
If using a RP2040 chip for the keypad processor it has to get its own USB connector (and boot button) to allow this, if not it has to be programmed via the SWD interface.

I am already trying to make one new design (only schematic on KICAD7) coping and pasting from your GRBL_MPG Pi_Pico_Board to see what can be done. If revised and agreed we will go to design the PCB.
Is that OK?

Yes. But be aware that I have plans for a new version that aims to support two MPG encoders and a SD-card, this by removing the I2C keypad interface and some GPIO lines (to the controller). And possibly a variant that would support larger displays with a parallell interface.

[M10CUBE]

A RP2040 module is simple to program via the inbuilt bootloader that exposes it as a flash drive - just drag&drop the binary. If using a RP2040 chip for the keypad processor it has to get its own USB connector (and boot button) to allow this, if not it has to be programmed via the SWD interface.

Thus the idea of using the Pico module in the first attempt it will have easy firmware downloading as a bonus. That goes to advantage for the Pico module vs the discreet MPU

Yes. But be aware that I have plans for a new version that aims to support two MPG encoders and a SD-card, this by removing the I2C keypad interface and some GPIO lines (to the controller). And possibly a variant that would support larger displays with a parallel interface.

Nice to hear that. it means we are moving forward.
Look @terjeio . To me it is just an hour of coping and pasting your module to find out here we stand at this point having 2XPico on board. Thanks to Kicad. No PCB routing.
Then your additions will come alive when ready.
Having the two designs in KiCAD schematics, it will be easy to have a mixture of the two. You can post your progress here or elsewhere if you like. In a new thread maybe?
To be honest last year as you know we proposed with Olivier in the WIZnet's contest the Pico CNC board as well. There we had an early view of the pendant (called it remote control).
In fact a prototype have been constructed and Olivier wrote some firmware for the keypad and display. But as he Volksolive has no contact anymore the project abandoned. Petty I am worrying what happened to him. I hope he is just fed up with the project and nothing else. He just vanished.
Attached is the "abandoned" project I have in my lab and the KiCAD schematics. As I said only keypad and LCD is working.
That was an attempt to mimic the commercial ones "one hand holding" modules but having advanced hardware on it.
images are just for inspiration since as said having partly build one prototype the idea stalled.
Firmware done so far by @Volksolive can be posted as well.
In real life photo is the prototype using the Pico Wiznet Ethernet, TCP/IP modbus communication (green cable). The flat cable is for power. The idea was to have POE as well. But Wifi is better with 2x18650 batteries.
A final note on our design. We had in mind to build a modular system. The module carrying the keyboard and the LCD could be used as a general purpose HMI in a home Automation system or elsewhere. Adding the encoder PCB can be used as an MPG.
Building blocks to to other jobs as well. A "Lego" concept. Saving the planet that way with a reusable modules.
What about that "green" idea? Can you inspired?
Having said that I think cooperating and contributing something nice will came out. ASAP
let us enjoy the ride


M10HM01-19.pdf


M10HM02-19.pdf