Pico GrblHAL?

[phil-barrett]

Raspberry Foundation microcontroller - Raspberry Pico. The board costs $4. Crazy stupid cheap. It is a bit like a fast SAMD21 with lots of memory.

Anyone want to take a whack at a port? I will be happy to design a breakout board for it but am not able to do a port.

For what it's worth, I think this is just the first in a line of microcontrollers from the PI Guys. I'd expect a wifi version soon and probably an M3 or M4 one. Maybe even a RISC V version.

[flynneva]

id be down to help out where I can with this, but i probably dont know enough about grblHAL (only familar with plain old grbl) to do this on my own. just ordered a few of those pico pi's though. should get here in the next few weeks.

[terjeio]

Should we split the task of creating a driver? I set up a basic one with empty functions and perhaps serial comms working?

[flynneva]

@terjeio so just being totally honest this is the first time ive written a driver on the micro side. ive only written device drivers on the workstation/computer side so all of this will be pretty new to me. anything that might help me get up and running more quickly would be greatly appreciated.

[phil-barrett]

If you have written device drivers, working with grblHAL will be fairly familiar. I predict you will do just fine.

[flynneva]

i do have a functional grbl 3-axis cnc already though thats running on openbuilds blackbox hw. was planning on using that to test whatever we make here with this.

[Volksolive]

I've got mine today, but slowly getting up to speed on how to code/flash/debug etc.. (documentation has been mainly made for coding from an RPI 4 to the Pico). Regarding floating point computation, the bootrom has libraries that support and speed up the floating computation while reducing code space footprint. I can try to program a PIO to generate the steps/dir signals but I will have to familiarize with the RP2040, SDK and this peripheral first, I also don't have a lot of "hobby time" right now ...

[phil-barrett]

Hmmm, an interesting thing about PicoPi, the Flash is in an off chip QSPI device and can be treated as a USB drive. It looks like the program actually runs out of RAM like the Teensy 4.x's iMXRT1062. Since there is more Flash (2 MB) than RAM (264KB), flash can be used for additional thing. But, I love the idea of being able to just drop a new version of grblHAL on a drive to update the system.

[phil-barrett]

A quick and dirty pin assignment to see what is possible and get people thinking. The Pico (and RP2040) is pretty pin limited. This assignment doesn't take into account any pin restrictions, I just wanted to see how many pins we could use and determine any tradeoffs that might need to be made. Several questions spring up.

• 4 axes - I can't imagine going to 3.
• only a global step enable is possible
• that leaves 3 gpios - I2C+strobe? UART? or something else? I might put some flexibility on the board to choose.
• do we really need 2 coolant outputs? for "real" systems yes but for a low end system, probably not.
• maybe drop spindle direction?
• the RUN pin is a reset, pull it low to reset the Pico. Could we just use that for the Reset input and save a pin? I suspect no but smarter heads than I should weigh in.

This is pretty much the bare minimum for a CNC controller.

Now, if we could use an IO expander, that would open up a lot of possibilities by freeing up gpio pins: UART channel, SPI interface (TMC stepsticks). Worth considering. We could probably put step enable and direction pins on an expander which would liberate a lot of gpios. Spindle enable and direction, similarly. I know there are some complexities to that so it may not be a good idea.

[phil-barrett]

There will only be one Enable for steppers, like on the Arduino Grbls.

I think we should toss mist or cool - very few machines use both. Spindle direction is another possibility but a lot of lasers use direction. Still, could use enable instead.

A cheap SPI-ish SR (74xx595, for example) is output only and would cost 3 pins. An I2C expander would take 2. It supports input and output. Interrupts would cost another pin.

[terjeio]

Spindle direction is another possibility but a lot of lasers use direction.

AFAIK they do not use the output pin, M4 is used for enabling automatic PWM on/off for cut moves and rapids.

There is no EEPROM on-chip so IMO an I2C port for that is a must. I want 3 pins including strobe input.
Stepper enable should at least be two pins, Z and XYA. If I disable Z on my router the spindle drops down...
Nice to have:
SPI port for SD-card, 4 pins.
UART port for MPG or VFD, 2 or 3 pins. 3 pins if a direction signal for RS485 is needed (via crossbar?).

Is this the first processor we should implement a run-time configurable crossbar for some of the signals?

"Hardwired":

• Step and dir XYZA. A to be made optional?.
• Limits XYZ.
• Control signals: Reset/Estop, Feed hold, Cycle start, Door?
• I2C
• UART and SPI, compile time configurable?

Crossbar - with I2C expander support:

• Stepper enable. Depends on board - if Polulu style drivers then needs to be "hardwired".
• Coolant.
• Door?
• Limit A.
• AUX signals.

PCA9654 is one expander candidate - it is bidirectional so can handle inputs.

I am a bit concerned about the lack of timers - at least one is needed for generating the main stepper interrupt. It seems that step pulse generation can be delegated to PIO so no problem for that?
Could one of the systick timers be used for the main stepper interrupt? PWM (there is only one interrupt line available)? PIO?

Interrupt code should be flagged for execution from RAM, same as ESP32. Code is run from a 16K cache updated from flash as needed.

[phil-barrett]

Perhaps we can then drop the Dir pin (or put it on the expander?)

Good point about Z enable.

It might be possible to emulate EEPROM in the QSPI Flash. If we have I2C then true EEPROM could be optional.

I am familiar with crossbar switches in FPGAs and such. Is that what you are suggesting? How does that work in this situation?

PCA9654 is a nice part. Pretty pricey though. What do you think of the XRA1201PIG24TR? Twice as many I/Os and almost half the cost. Runs at 400 khz I2C bus. I am not sure what kind of performance we can expect from either of them. Need to understand that.

[terjeio]

Perhaps we can then drop the Dir pin (or put it on the expander?)

It should be available in the crossbar as an option. With careful layout an expander could be made optional.

It might be possible to emulate EEPROM in the QSPI Flash.

It is, there is code in the bootrom for programming the flash.

I am familiar with crossbar switches in FPGAs and such. Is that what you are suggesting? How does that work in this situation?

I believe a software crossbar can be made by binding functions dynamically to pins by using function pointers. Config, read, write, event...

What do you think of the XRA1201PIG24TR?

To be investigated - I suggested PCA9654 because I have used that earlier. 16 extra I/O pins is over the top?

[Volksolive]

The PIO can be used as timer as well as generating step/dir with delay, PIO state machine can be synched by the use of IRQ, either system IRQ so the processor can also by in sync or State Machine specific IRQ to sync one or multiple stater machine to another one. I think I can try to start playing with that today. Maybe one Core can decode the Gcode, creates motion planning and fill the stepper buffer while the other one takes care of the steps, limits and control inputs so that interruption as shared on both core

[Volksolive]

I start to have some success with the PIO programming, there is some info missing in the docs and a lot of things that if you don't know you don't know ...
But

I can generate dir and steps with delay between dir and step and precise step pulse. delay and pulse length can be dynamically changed. (not very useful for pulse length and not sure it is needed for dir delay?) Regarding the timer, I have also created one with the PIO but I am not sure it is the best solution, because it will only be updatable every full cycle, meaning the IRQ should write the new value as soon as possible in order to get the best timing, else there is going to be some additional delay of some tens to hundreds of nano seconds, the more instructions are performed before updating this value, the more delay.

[Volksolive]

1us makes a step frequency of 1Mhz isn't that enough? The Drivers I am using are limited to less than 300KHz except the TMC2130 and motion controller like the UC300eth is max 400Khz step frequency.

[terjeio]

Could you explain me when is the delay used or what it is used for?

It is for ensuring the drivers are set up up correctly before a step signals arrive. If the signals are too close then the actual direction the motors move may wrong.

[Volksolive]

Ok exactly what I thought, so my code right now generate the dir and then after a delay generate the step. and this delay can be set dynamically so we could remove it when there is no direction change. we could also have a fix 0.5us delay like you said you have for the ESP driver.

If the delay and the pulse lenght can both be selectable during compilation time to be between 0.5us and 32*0.5us => 16us or maybe even less then I can make the PIO code even more simple by using the internal PIO delay, Also then we could attribute the Pin and Dir to 8 contiguous pins but any order instead of having 4 contiguous pins for dir and 4 for step. I don't think that changes anything for the breakout board though, but it give more flexibility.

[terjeio]

Setting the dir pins can/should be done with regular writes to gpio, there is IMO no need to handle that via PIO if that is what you do now. Here are some code snippets from the ESP32 driver:

grblHAL/drivers/ESP32/driver.c

Lines 500 to 517 in db60fdc

	// Set stepper direction output pins
	// NOTE: see note for set_step_outputs()
	inline IRAM_ATTR static void set_dir_outputs (axes_signals_t dir_outbits)
	{
	dir_outbits.value ^= settings.steppers.dir_invert.mask;
	DIGITAL_OUT(X_DIRECTION_PIN, dir_outbits.x);
	DIGITAL_OUT(Y_DIRECTION_PIN, dir_outbits.y);
	DIGITAL_OUT(Z_DIRECTION_PIN, dir_outbits.z);
	#ifdef A_AXIS
	DIGITAL_OUT(A_DIRECTION_PIN, dir_outbits.a);
	#endif
	#ifdef B_AXIS
	DIGITAL_OUT(B_DIRECTION_PIN, dir_outbits.b);
	#endif
	#ifdef C_AXIS
	DIGITAL_OUT(C_DIRECTION_PIN, dir_outbits.c);
	#endif
	}

This code resets the RMT channels involved and initiates a pulse output:

grblHAL/drivers/ESP32/driver.c

Lines 619 to 636 in db60fdc

	// Set stepper pulse output pins
	inline IRAM_ATTR static void set_step_outputs (axes_signals_t step_outbits)
	{
	if(step_outbits.x) {
	RMT.conf_ch[0].conf1.mem_rd_rst = 1;
	RMT.conf_ch[0].conf1.tx_start = 1;
	}
	if(step_outbits.y) {
	RMT.conf_ch[1].conf1.mem_rd_rst = 1;
	RMT.conf_ch[1].conf1.tx_start = 1;
	}
	if(step_outbits.z) {
	RMT.conf_ch[2].conf1.mem_rd_rst = 1;
	RMT.conf_ch[2].conf1.tx_start = 1;
	}
	}

grblHAL/drivers/ESP32/driver.c

Lines 682 to 699 in db60fdc

	IRAM_ATTR static void stepperPulseStart (stepper_t *stepper)
	{
	if(stepper->dir_change)
	set_dir_outputs(stepper->dir_outbits);
	if(stepper->step_outbits.value) {
	#ifdef USE_I2S_OUT
	uint64_t step_pulse_start_time = esp_timer_get_time();
	i2s_set_step_outputs(stepper->step_outbits);
	while (esp_timer_get_time() - step_pulse_start_time < i2s_step_length) {
	__asm__ __volatile__ ("nop"); // spin here until time to turn off step
	}
	i2s_set_step_outputs((axes_signals_t){0});
	#else
	set_step_outputs(stepper->step_outbits);
	#endif
	}
	}

If the delay and the pulse lenght can both be selectable during compilation time

These has always been run-time configurable. I have moved a lot of compile-time settings to run-time settings, it would be a step backwards to move some back again.

[Volksolive]

If the dir are set/reset by the PIO it can then be possible to have (on 8 contiguous pins) step and dir in any order, if it is managed by the GPIO then step will have to be on contiguous pins. Anyway it is almost the same to write to the PIO than to the GPIO codewise.

I think there could be a way to configure delay and step pulse at run time by rewriting the PIO part of the code that contains the delay, however, with the PIO internal delay we are limited to a range from PIO clock (0.5us in my code right now to 32*PIO clock (= 16us in my code), the PIO clock can be changed to anything by dividing the system clock (Fs = 125Mhz(up to 133Mhz) / 16bits,8bits/256) but this means that the time each instruction takes will be impacted. So is 0.5us to 16us enough for delay/step pulse or should it be a bigger range which can be achieved by not using the PIO internal delay and using instead a counter that the PIO decrease every PIO clock, as I have done it in my actual code?

[terjeio]

A driver to start with is now available in the test branch. I have attemted to code serial over UART but I do not yet have a board to test with so a small miracle if it actually works. driver.c has been copied over from the STM32F4xx driver and a lot of code has been removed or commented out. It compiles - on my RPI4.

Should we set up a task list for who does what?

[terjeio]

I have updated the driver with a few fixes. I compiled against an earlier version of the core than was published and made some mistakes in serial.c...

Should we also work on the pin layout?

Yes. Nothing is off the table. The I/O expander should be optional, this as the generic board map should IMO be for a basic 3-axis configuration without it. Here is a list of things to do, in no particular order. Who want to do what?

• Skeleton driver
• UART interface
• USB CDT inteface
• Step, dir and enable signals - @Volksolive
• Timers for stepper interrupt and ms delay
• Limits and control signals handling - @Volksolive
• Software debounce for input signals (PIO?) - @Volksolive
• Coolant and spindle signals including PWM output - @Volksolive
• Flash interface for settings incl. reserving heap if needed
• Pin map files

Lower priority:

• I2C interface
• SPI interface
• FatFS low level driver
• Run time configurable crossbar for some signals
• Use both cores - maybe this has to be moved up?

[Volksolive]

I can take care of PWM, step timer, limits, as I have a board I can also test the serial. For soft debounce, I need to look further the datasheet but there is already available a schmitt trigger on the input and also some kind of sync system, so maybe there is nothing to do there except configuring the right input system.

Regarding the crossbar, how do you see this working exactly?

Usage of both Cores IMO is low priority, I think it is better to try to have GRBLHal working on one core first and then try to split between the 2 cores with all available resources like FIFO, mutex, semaphore, etc.

[terjeio]

I can take care of PWM, step timer, limits, as I have a board I can also test the serial.

Great. I would like to see @flynneva and others involved in coding too.

For soft debounce, I need to look further the datasheet but there is already available a schmitt trigger on the input and also some kind of sync system, so maybe there is nothing to do there except configuring the right input system.

A schmitt trigger is not of much help for debouncing as there may be several milliseconds where the input may go everywhere. A typical delay in grblHAL drivers is 40 ms after the initial interrupt before reading the input.

Regarding the crossbar, how do you see this working exactly?

From a set of "free" pins let the user select the function (from a list) that is wanted. By binding each pin function to a set of function pointers that can be dynamically changed a pin this should be possible without much overhead. The entry points needed in this set are, IMO, config, read, write and event. I have not tested this idea yet but I believe it is possible to make it work.

[Volksolive]

The Schmitt trigger will help the deboucing with proper RC circuit. but yes deboucing is needed if no RC is used. I'll look into that to see what is the most efficient way to do it, whether it is through the PIO or not.

Ok I think I understand the crossbar idea. The user will have some free pins he can assigned to output like Flood, mist, Spindle EN, Spindle PWM, Spindle Dir or control input like Door, Feed hold, Cycle start, etc. and probably these settings will be stored in EEPROM (flash) and modifiable through the $xx parameters.
If that is what you are thinking, we should define pins that can only be output and pins that can only be input so that if the user changes the configuration in run-time, he doesn't change an input which is connected to a switch to an output and can potentially short the pin.

[phil-barrett]

An RC LPF will help but those cheap bouncy switches need a very aggressive cut off frequency.

[flynneva]

@terjeio apologies for being silent here.....i just received some picos in the mail on Friday last week and was still just getting up and running with them over the weekend. ill chime in again once I feel comfortable with just working with them & grblHAL as well.

[terjeio]

I've been silent too, and quite busy, so nothing to apologise for. I just got a note that my Picos has been shipped, I'll get back to this as soon as they arrive. A priority for me is to get communication up and running so that we can communicate with grblHAL, then it will be easier to proceed.

[Volksolive]

I have tested the serial and made modification to it to make it work. I can now connect with LaserGRBL throught the UART. I haven't looked into the USB. I will now start working on the Step timer and step pulse, I have already made the PIO code and need to try it when I have a bit of time. Should I create a pull request ?

[Volksolive]

Yes the PIO is really a nice feature but the description in the RP2040 and SDK datasheet are not always 100% clear and the SDK has no IRQ functions for the PIO which is a bit annoying. Also the SDK does not always give a clear info on what a function do or set/reset so you have to try to place some functions in different order to get it to work. To clear the Interrupt in the ISR, have you tried writing a 1 to the PIO IRQ register flag bit + an irq_clear(PIO0_IRQ_0)?

[terjeio]

The documentation is surely not as fantastic as some claims...

To clear the Interrupt in the ISR, have you tried writing a 1 to the PIO IRQ register flag bit + an irq_clear(PIO0_IRQ_0)?

I have tried a few things without luck, the IRQ register is the one I would think should be used, but this does not match the interrupt enable register as it is only 8 bits wide. IRQ 0 in the PIO code maps to bit 8 in the IRQ0_INTE register, so maybe some other bit in the IRQ register if not a silicon (or documentation) bug? Maybe clear all bits in the IRQ register to see if that works?

BTW I have just uploaded a version with stepper dir and a single motor enable pin enabled, it should thus be possible to move motors now. I have also tuned the PIO code for the stepper timer, adding a JMP to start on a period change will ensure the next timeout uses the new value. This since the SDK reset function you used did not restart the PIO code from the beginning...

[Volksolive]

As I understand it, the 8 bits wide IRQ register represent the 8 flags available to the State Machine and only the 4 lower flags can generate a system interrupt through IRQ0 and/or IRQ1, that's why in the PIO ASM there is the command IRQ 0 which set the flags 0 (which then trigger the IRQ0 that has been enabled with INTE register bit 8 -> State Machine 0).

Regarding the SDK restart function, here is a proof again that the documentation isn't quite clear because I thought that "Restart a state machine with a known state." would mean that the program counter is reset. Also I just checked and there isn't any function to simply reset the program counter. Seems like the only way to reset the PC is to use the function "pio_sm_init" and re-enabling the PIO SM ... or maybe it can be done using the register "SM0_INSTR" by sending a JMP instruction to the start of the program.

Anyway jumping to start is also working but then the udapte is always delayed by one period since the update is done in the IT and the PIO program will have already started counting a new period. maybe a way to avoid that is to use a IRQ WAIT 0 instead so that the PIO program wait for the IT to be reset before continuing?! or a JMP instruction to the beginning of the program directly executed from the INSTR register?!

But great job making the step and EEPROM working !

[terjeio]

Here is the latest PIO code.

I have just tested (but not yet uploaded) that setting bit 0 in the IRQ register clears the interrupt. This is not documented anywhere that I am aware of...

or maybe it can be done using the register "SM0_INSTR" by sending a JMP instruction to the start of the program.

It can and is how I did it. See the source.

a way to avoid that is to use a IRQ WAIT 0 instead so that the PIO program wait for the IT to be reset before continuing

Not neccesary and IMO bad, this since the period is only reset at the start of a new block (every 5ms or so).
To have perfect timing the current delay should be subtracted from the first iteration of the timer loop only. But this is not critical? What could be done though is to save away the period and not reset the program if there is no change.

[Volksolive]

I will try to get the reset of the interrupt in the ISR instead of in the PIO ASM by changing:

static inline void stepper_timer_irq_clear(PIO pio) { // pio->irq = PIO_INTR_SM0_BITS; // pio->intr &= ~PIO_INTR_SM0_BITS; }

with

static inline void stepper_timer_irq_clear(PIO pio) { pio->irq = 1; // Reset the PIO Flag 0 irq_clear(PIO0_IRQ_0); // Reset the System IRQ 0 }

and remove the irq clear 0 in the PIO ASM

To have perfect timing the current delay should be subtracted from the first iteration of the timer loop only. But this is not critical?

Since the period setting is in the first 10 line of code of the ISR I don't think it would really make a big difference to subtract the delay but it can be tested.

What could be done though is to save away the period and not reset the program if there is no change.

That's a good idea ! The function stepper_timer_set_period would save the previous period and only update if the new one is different, it could also be done in the GRBL but I guess it is better/easier to do it in the driver part.

I have also looked at what you've done for the step_pulse but I am not sure to understand why you used 6 pins ? is that for 6 axis ? I was using out and set and pulling only 3 times (steps, delay, pulse) because I was thinking to use the GPIO pads OUTOVER function to do the inversion of polarity, so that it would be done only once at system startup or at EEPROM parameters update and save the masking at every step generation (though probably not very time consuming).

Something else I wanted to do is to use the SDK function clock_get_hz to set the PIO (and other peripheral) clock divider so that tweeting the system clock (to 133Mhz instead of the set 125Mhz for example) would not influence the PIO and other peripheral clock. What do you think about that?

[phil-barrett]

I'd like to start laying out a breakout board but it looks like we are already close to being out of pins based on generic_map.h. Including StepA, there is 1 pin left and we haven't yet allocated SPI for TMCs or I2C.

I think an I2C expander is the only way to make this work. Move limits and inputs to the expander? Frees up 8 but loses 3 to the expander so we would net up 5 more pins for a total of 6. SPI will cost 3 (maybe 4). UART takes the other 2?

With a 16 GPIO expander, we could free up 9 inputs/limits. not sure it is necessary. For what it's worth, JLCPCB (the proto house I frequently use) has quite a few 8 GPIO I2C expanders - listed here. Note that they have a lot more listed but at 0 stock levels and I would never spec in a chip that they don't keep stocked. There is still a risk that chips they show having stock today may not get reordered. I bias toward the higher inventory ones. To get a datasheet, copy the LCSC C-number, go to lcsc.com and search with that number.

[Edit: I realized I didn't mention something important. I will get a set of boards made with all (or most) of the SMD parts on it and will give one to each contributor for the cost of postage. I reserve the right to define "contributor" but basically, if you add code, you fit the category.]

For what it's worth, the TCA6408APWR looks like a good choice - lots of stock, 5V tolerant inputs, voltage translation. Only big limitation I saw from a brief read of the DS is 400 kHz only. It's a TSSOP package so soldering by hand can be challenging to some.

I would also want to see if there are other expanders that are pin compatible to allow alternate choice without a board redesign.

Part	LCSC	Description	Manufacturer	Stock
CH423S	C111663	I/O Expansion 8 I2C, SPI SOP-28_300mil RoHS	Jiangsu Qin Heng	2960
CH422G	C57543	I/O Expansion 8 I2C, SPI SOP-16_150mil RoHS	Jiangsu Qin Heng	880
TCA9534APWR	C206010	I/O Expansion 8 I2C TSSOP-16 RoHS	Texas Instruments	5177
TCA6408AQPWRQ1	C201668	I/O Expansion 8 I2C, SMBus TSSOP-16 RoHS	Texas Instruments	816
PCA9554APW,118	C86803	I/O Expansion 8 I2C, SMBus TSSOP-16 RoHS	NXP Semicon	119
PCA9557PWR	C201547	I/O Expansion 8 I2C, SMBus TSSOP-16 RoHS	Texas Instruments	420
PCA9557PW,118	C141380	I/O Expansion 8 I2C, SMBus TSSOP-16 RoHS	NXP Semicon	1768
PCF8574AT/3,518	C86832	I/O Expansion 8 I2C SOIC-16_300mil RoHS	NXP Semicon	796
TCA6408APWR	C206177	I/O Expansion 8 I2C, SMBus TSSOP-16 RoHS	Texas Instruments	12624
PCF8574T/3,518	C7605	I/O Expansion 8 I2C SOIC-16_300mil RoHS	NXP Semicon	5223
PCF8574TS/3,118	C57790	I/O Expansion 8 I2C SSOP-20 RoHS	NXP Semicon	388
PCF8574APWR	C94361	I/O Expansion TSSOP-20 RoHS	Texas Instruments	1054
MCP23008T-E/SO	C145701	I/O Expansion 8 I2C SOIC-18_300mil RoHS	Microchip Tech	449

[Volksolive]

You are right, I think it is a good idea to continu developing a generic version with possibly 4 axis if there is enough GPIO for it.
Maybe limit A could be removed as IMO there is no need for it (of all the machine I have I don't have a need for it) or it can be connected in // to one of the XYZ limit input and homed after XYZ are done.
Also safety door could be shared with feed hold as on the Arduino uno and limited comms so no SPI and shared UART/I2C pins as GRBL comm can be done with the USB.

But it is also worth defining a board mapping for Phil breakout board. Maybe that should be discussed into 2 different conversations: Generic Pico GRBL and Phil Breakout board GRBL?

[fireup924]

Was wondering if SPI out to HTC595 shift registers for Step/Dir pins be added to free up pins for other purpose? might able to achieve 5 or 6 axis with this approach. Also the HTC595 can drive 5V logic and driver boards with opto's directly without additional buffer chips.

[terjeio]

Was wondering if SPI out to HTC595 shift registors for Step/Dir pins be added to free up pins for other purpose?

Sure can, but perhaps PIO code to shift out data would a better choice than using a SPI peripheral? Are you planning to make a breakout board?

[fireup924]

Either way will be fine, shifting using PIO or built-in SPI. I've already made a breakout board for Bart's ESP32 that uses I2S and won't be hard the modify it for RP2040.

[asteppke]

The TCA64xxx series is great on the feature side. Maybe it is worth considering the TCA6416A instead? For the same price 16 IOs, and for any CNC-like machine even just a few more status LEDs can eat available pins very quickly.
If the reset pin is wired up as well, together with the noise filters on the SCL/SDA lines this should also provide a robust solution in case of strong EMI.

[phomann]

Hi Phil,

I'd strongly suggest you look at and use SPI IO expanders instead of i2c, as the latter is susceptible lockups due to EMI noise. Not a good thing for CNC and industrial control.

Cheers,

Peter

[phil-barrett]

I am taking the I2C lockup stuff seriously. Haven't found an app note or similar from a manufacturer discussing it but there are a few postings about lockup problems on various forums. Most appear to be software error related or due to long I2C lines. Several talk about using low value (stronger) pullup resistors. On the Teensy board, I use 2200 ohm, which is already pretty low. Worth experimenting with the lowest possible value.

While SPI takes 4 lines vs 3, there is a strong desire to support it for using TMC stepsticks (TMC2130, TMC5160) so one alternate approach is to get rid of I2C completely. Then there are 5 SPI pins: SCK, MISO, MOSI, CSexp, CStmc.

I was only half kidding about blinkie lights. There are regular asks for more LED status outputs. I think it could be a cheap way to distinguish this board from the others.

[Volksolive]

I have experienced I2C lockup with a RTC. When the system would be shutdown in the middle of an I2C comm, as the RTC was always powered by the button cell battery, it would forever wait for the comm to end. New comm or stop condition alone would not reset its state. So the solution was to generate in software some clock pulse and a stop condition to get it to work again. I find it crazy that for an RTC there isn't a comm watchdog.

So I2C lockup do happen but there is way to deal with it, also I2C wouldn't be used so broadly if lockup would happen so often but using a SPI I/O expander is also fine. However Terjeio will not be able to continu testing on his CNC boosterpack if we go this way.. I don't think it is a major issue though !

IMO I would keep I2C and SPI even if we go for a SPI I/O expander. I2C alone is only 2 pins..

I was only half kidding about blinkie lights. There are regular asks for more LED status outputs. I think it could be a cheap way to distinguish this board from the others.

yes there is needs for blinky light but also for casing light, cooling fan output, vacuum cleaner output but also water cooling, air assist, smoke assist for CO2 laser for example, so having extra AUX output is a good idea !

[terjeio]

Someone (@phomann ?) has to tell me what makes I2C lines more susceptible to EMI than SPI lines. IMO I2C is more robust if handled correctly as corrupted data might hang the bus or result in a transmission error. SPI not so, to ensure correct transfer the data has to be read back and compared with the expected result to be sure it was received correctly or at all.

If taking this really serious then one should switch to checksum based protocols such as ModBus or CAN? And only support UART based Trinamic drivers since the protocol for these supports checksums unlike the SPI based drivers?

Then there are 5 SPI pins: SCK, MISO, MOSI, CSexp, CStmc

Add EEPROM, keypad and SD-card CS lines to those...

[phil-barrett]

To me, being serious is about due diligence, not going whole hog. (Sorry for using an obscure American idiom but it seems to fit.) I move that we table the question of SPI expanders. Reopen if more info comes to light. I will keep looking. The RTC example is typical of what I found out there, by the way.

yes there is needs for blinky light but also for casing light, cooling fan output, vacuum cleaner output but also water cooling, air assist, smoke assist for CO2 laser for example, so having extra AUX output is a good idea !

Yes! (Says the guy that put 3 Aux outputs on a breakout board.)

By the way, Vac/Dust Extractor output doesn't need an output pin, just gang to the spindle enable. Fan outputs can be likewise. Or maybe just to power on. A lot can be done without using a GPIO (processor or expander).

[Volksolive]

By the way, Vac/Dust Extractor output doesn't need an output pin, just gang to the spindle enable. Fan outputs can be likewise. Or maybe just to power on. A lot can be done without using a GPIO (processor or expander).

Completely right, but we both agree that having extra output always come in handy !!

on the I2C VS SPI topic, anyway if EMI would be so bad as to interfere with a onboard I2C or SPI signal then there would be way worse interference on the lines that goes from the breakout board to the stepper driver, endstop and VFD...

The RTC example is typical of what I found out there, by the way.

Yes this happen mostly with RTC as they stay powered while the board and MCU can be shutdown unexpectedly.

[phomann]

Sorry for the delay, I was busy on other things going on.
My comments were from personal experience, only. I designed an expansion board for my Modbus controller using I2C with the Microchip MCP23008T-E/SO. I did use a 3" 10-Way IDC ribbon cable to connect the two boards.

I was experiencing intermittent lockups of the i2C bus that I narrowed down to EMI from a spindle motor. I could have eliminated the effects of the EMI, but it highlighted an issue with i2C. If one of the i2c slave devices gets into an incorrect state, it gets difficult to reset the device without cycling its power. The advantage of the SPI bus is that the slave select line resets the devices comms.

For this application, I'm not sure that the speed advantage of the SPI bus is not a consideration.

Cheers,

Peter

[Volksolive]

Was there other signals on your ribbon cable that could have interfere with the I2C ?
In this case, the I/O expander will be on the main board directly connected from the MCU to the IO expander chip with short connection between the 2, so there is less risk for EMI interferences but it is true that I2C lockup can happen if no special care for interferences is done. But lockup can be handle without cycling power by generating enough clock , explained here https://www.pebblebay.com/i2c-lock-up-prevention-and-recovery/
Also as Terjeio mentioned, even if SPI does not have the lockup issue, if the EMI are bad enough to influence I2C, then there would be corrupted data on the SPI which is also not a good situation.

[Volksolive]

I have started looking at limits pins init and debounce and noticed that the control input (except safety door) are not debounced, would it be interesting to also debounce those ?
Just to be sure, if you get a limit input and start debouncing but a safety door or other limit input arise while debouncing, the timer is reset, which make the debounce on the first limit extended, is that right ? I don't think it is an issue because this would almost never happen but just want to be sure that it's the way it is today and it is working fine.
Else I could create a debounce buffer that records all the inputs (that need debounce) and always put the right debounce delay.

[terjeio]

I have created a pull request for the control, limit, safety door and probe management

Great - thank you for that. I have now merged the PR in the new repo, and the driver in this will no longer be maintained. Testing should be done with the driver from the new repo as I have tweaked the code a bit. Tweaks are mainly adding some missing initalizers and readding the dir signals outmap - currently unused but could be handy if dir outputs are not on consecutive pins in any new maps that may be added.

It seems like the port is getting fairly close to usable. Is generic_map.h the preferred mapping?

Since GPIO is on one 32 bit wide port I see no reason to stick to the generic map if moving pins will make routing simpler. The limitations are that UART, I2C and SPI ports are only available on some and step outputs has to be on consecutive pins.

I'll make a simple "unkit" board (with all the glue logic, optos and such) based on that and get a bunch made up.

Which features will it have? I2C io-expander? EEPROM or FRAM? SPI port for SD-card? ...

FYI I have HAL'ified my MPG & DRO, written driver code for RP2040 and made a prototype PCB. It still has a MSP430 for keypad/LED control but to make it simpler for possible end users I want to program it from the RP2040 with a precompiled blob...

I will start a separate discussion entry on this if people think the timing is good.

Best to do that at the new repo?

[Volksolive]

I haven't found how to start a discussion on the new repo

[terjeio]

I haven't found how to start a discussion on the new repo

The New discussion button the right panel is not visible for you on the driver discussions page?

[Volksolive]

I was looking at the top page and not the driver specific page ... stupid me ..

[phil-barrett]

Started discussion there.

[langwadt]

unless you need to count how many times you push a button I don't much point in debouncing

[terjeio]

It depends... I would like to see at least two inputs having a SR flip-flop buffer in code, where set is immediate and reset is delayed. These are the probe and door inputs - especially the door input is tricky to handle if there is a lot of switch bounce...

[phil-barrett]

Sparkfun Thing Plus RP2040 - They claim 30 GPIOs which may be enough to avoid an I/O extender. Though I think supporting I/O extenders in grblHAL is a good idea in general. The Thing Plus (who names these? terrible name) lists for $18 USD but is back ordered. [editorial - I'd use a Teensy 4.0 before that].

There is very little on how they get to 30 GPIOs - there are only about 20 I/O pins around the edge of the board. There is a 2x6 1.27mm header that must be the source of the additional I/Os. No info on that at all.

[Volksolive]

I think they refers to the RP2040 chip having 30 I/O, their board only have 18I/O as per their description Besides the Thing Plus or Feather footprint (with 18 GPIO pins), the board also includes an SD card slot, 16MB (128Mbit) flash memory, a JST single cell battery connector (with a charging circuit and fuel gauge sensor), an addressable WS2812 RGB LED, JTAG PTH pins

[phil-barrett]

The 18 GPIOs is for the feather footprint. Later they talk about 30 GPIOs. There is a 1.27mm 2x6 header that adds another 12 for 30? But I can see how it is a bit misleading.

[Volksolive]

The 2x5 header is the JTAG PTH, which probably include the Prog pins and some power, also there is this note at the bottom. Note: GPIO 08 is not included in this count, as it passes through the WS2812 addressable RGB LED first. GPIO 07 and GPIO 23 are counted as a single GPIO because they are tied together So I doubt the 30 pins are available. I don’t see in their features list the 30 I/O being mentioned in the board features but only in the RP2040 General features.

[phil-barrett]

OK, that makes sense. They need to fix the description.

[phil-barrett]

Performance of the Pico. As expected, the Cortex M0 chip is at a disadvantage to the M4 (and M7) chips. The video linked below discusses this in the context of the Arduino IDE/Compiler but the results should be similar for any IDE/Compiler. Fast forward to 2:20 if you don't care about Arduino. Results at about 3:00 and shown here. Note that these tests do not reflect any benefit of PIO which may be significant in some cases but certainly not when it comes to floating point performance. Double FP does not matter here, I believe.

The net result is the Pico performs above an STM32F10x, below an STM32F4xx, well below an ESP32 and WAY below the iMXRT10602 (Teensy 4.x).

https://www.youtube.com/watch?v=-XHh17cuH5E

[asteppke]

And for a bit more context: the original Arduino (ATmega328p), which is the baseline for grbl, achieves approximately 10 VAX MIPS. The Arduino Due (Cortex-M3) reaches 45 VAX MIPS.

[ysfherdem]

I want to draw a CNC Control board for RP2040 but i guess the software is still not usable. Are you going to use an additional component to duplicate the pin? When do you plan to prepare the map file for PCB drawing? Thank you

[terjeio]

The latest version at the new grblHAL repo should now be usable or only require minor changes before it is.

Are you going to use an additional component to duplicate the pin?

Currently there is support for both an I2C I/O expander and shift registers to add additional pins. The shift register based PicoCNC board designed by @phil-barrett adds a whopping 24 outputs and uses PIO code for handling them.

When do you plan to prepare the map file for PCB drawing?

I guess you mean a PCB layout. If for the PicoCNC board see this discussion.

[toreniebuhr]

Hi guys. I am really excited about this project. Would it be possible to use it on the Arduino Nano RP2040 Connect?

[terjeio]

@toreniebuhr It should be possible, but I guess you'll have to create a map file for it.
WiFi/Bluetooth connectivity will require coding. If lwIP drivers are available for the WiFi module then the networking plugin should be useable with a bit of glue code.

[toreniebuhr]

Cool! I am currently using GRBL on a nano and just want the benefits of a faster chip. I wont use the BL or Network anyway 🙂 Is it possible to compile with Arduino software or do you recommend VS?

[terjeio]

I am currently using GRBL on a nano

With which breakout board? Are the step pins consecutive? The current PIO code requires that.

Is it possible to compile with Arduino software or do you recommend VS?

You have to use VS - and the latest code from the new repo.

[toreniebuhr]

The original 8 bit nano is on an Eleksmaker 3 axis board with TMC 2209 stepper drivers.It's from a chinese laser engraver. I bought the Arduino Nano rp2040 because it has the same pinout as the original. In GRBL i use the Atmega map, and that works.

[terjeio]

Ouch - if I am not mistaken that means the current PIO code cannot be used to generate the step signals. D2-D4 are used for those in the Atmega map, and they are mapped like this on the Pico:

Not consecutive... This can be solved by adding a new timer for generating a step pulse reset interrupt and using "normal" GPIO, like most of the other drivers do, or by having two separate PIO programs, one handling the X-axis and one Y and Z.

[toreniebuhr]

Thank you so much for taking your time to reply. This might be out of my teach 😅 I might want to give it a try anyway. Sounds like it's easier to make my own board instead 😂

[terjeio]

Do you have a (link to) schematic of the Eleksmaker board? There could be a problem with voltage levels. The Nano is a 5V device, the Pico is 3.3V.
If 3.3V compatible it should be fairly trivial to add PIO code support as the PIO program used for direct to pin output is quite small and it is, AFAICT, possible to start more than one instance of it with different pin configurations.

[toreniebuhr]

Hi! Sorry for the late reply. I believe the rp2040 pico is advertised as a Arduino Nano swap, but I am way too noob to know it for sure. The board is a Eleksmaker 3.2 and the only schematic is this picture. I dont know anythimf about PIO, so this might be too hard for me. I cant den get it to compile with Studio. The Arduino RP2040 with the pico chip is meant to be compiled in Arduino IDE with libreries. Do you know of there is any board working with GRBLhal is a Arduino Nano swap compatible? Otherwise I guess I am a bit stuck. man. 20. sep. 2021 18.37 skrev Terje Io ***@***.***>:

…

Do you have a (link to) schematic of the Eleksmaker board? There could be a problem with voltage levels. The Nano is a 5V device, the Pico is 3.3V. If 3.3V compatible it should be fairly trivial to add PIO code support as the PIO program used for direct to pin output is quite small and it is, AFAICT, possible to start more than one instance of it with different pin configurations. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#206 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AVUP4NFS7KBCELMCSW2E2NTUC5PMRANCNFSM4WNMF62A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[Volksolive]

The Arduino Nano RP2040 is only 3.3V compatible so it is not swappable with a Nano without signal conversion.
I have an Eleksmaker Mana SE board with 2 drivers, I can check if any pin is receiving 5V from the board but I don't think so.
However, if you have endstops, for instance, connected to +5V it is going to be an issue (resolvable though). Also the board does not provide a 3.3V source.

The Arduino RP2040 with the pico chip is meant to be
compiled in Arduino IDE with libreries

I haven't used Arduino IDE to compile GRBLHAL but it should be feasible since it seems Arduino has integrated the Pico SDK in the Arduino core. However, I don't know if Arduino manage the Cmakelists and PIO assembler the same way VS does.

Do you know of there is any board
working with GRBLhal is a Arduino Nano swap compatible? Otherwise I guess I
am a bit stuck.

I have developed an Arduino Nano swappable board based on the STM32F103 mcu that should support GRBLHAL but I think @terjeio mentioned a possible issue with memory space.
However this board is not available on the market, I just made a bunch for myself but I can share the design files though.

Another solution could be to design an adapter PCB that will connect between the Eleksmaker board and the Pico and map the Pico pins to the right nano GRBL pinout. It looks like it could fit on my board without interfering with anything.