Remora for RP2040

All the code is posted, it isn’t very complicated or anything. Really it is just sending keycodes and receiving a data packet with dro and state information. It uses rp2040.

Ok, hopefully we are happy with this one, I am more satisfied.

 

Also, here is the pinout of the RP2040 for reference.  Certainly interested if anything in particular will work better or worse.

 

The keypad uses I2C for data exchange.  It also has two additional I/Os for HALT and STROBE signals, both are active low.  The HALT signal is hard-wired to a dedicated button on the keypad for e-stop.  For any other button press, when the user presses a button, the STROBE signal is asserted (pulled down) by the keypad MCU which signals the host that a character code needs to be read.  The host reads a single byte from the device which contains the keycode - so there is a limit of 255 possible buttons/combinations of buttons (we do use shift-button for alternate functions on the keypad, plus diagonal jogging if two direction buttons are pressed simultaneously).  The pendant keeps the STROBE asserted as long as the user holds down the button.  This allows for things like continuous pushbutton jogging.

In addition to the above, the DRO is updated whenever the host writes the data packet to the pendant (this can happen at any time).  This is the format of the data here:
github.com/Expatria-Technologies/RT_Jog_...er/i2c_jogger.h#L248

You should be able to use the SDA/SCL as a UART (they can be given that alternate function) and the other two GPIOS should be able to implement the quadrature decoder for the handwheel.  You would need to implement a differential receiver via IC or termination, as well as deal with voltage translation.  3.3V and 5v are also available on the headers.

Nice!! I'll set-up the default config to match. The board looks great. Can't wait to get one for testing.

I'm having some weird issues with the Pico SDK..... I've been implementing the FlexiHal static config and for some reason the compiler is optimising out volatile pointers so the board crashes when trying to access a non-existent location. None of my research tells me why and I've had no luck changing compiler optimisation settings. 

The only way I found this was using the Pico Probe CMSIS-DAP debug probe that arrived.

I also had TFTP upload working and now not, with again some stuff being optimised away....??

I seem to spend more time figuring our issues then cutting code.
 

Getting closer with the RP2040. TFTP upload nearly working after head scratching and debugging.

For anyone interested, it's possible to read the flash memory using pyOCD.

pyocd commander -t rp2040 -c "savemem 0x10000000 0x1fffff test.bin"

Some really good progress to share. TFTP upload of the configuration file is now working. With two running cores this took a little figuring out along with the different flash erase and write requirements of the RP2040.

So, Remora for the RP2040 (with W5500) now has step generators and IO available and configurable to any available pin.

Latest code has been pushed to the repo.

Upload python script is the same as for the STM32 version of the NVEM boards.

TODO:
1. DMA transfer for W5500 SPI communications
2. Interrupt driven Ethernet receive
3. What other modules?

drewnabobber wrote:

Ok, hopefully we are happy with this one, I am more satisfied.

 

Also, here is the pinout of the RP2040 for reference.  Certainly interested if anything in particular will work better or worse.

 

The keypad uses I2C for data exchange.  It also has two additional I/Os for HALT and STROBE signals, both are active low.  The HALT signal is hard-wired to a dedicated button on the keypad for e-stop.  For any other button press, when the user presses a button, the STROBE signal is asserted (pulled down) by the keypad MCU which signals the host that a character code needs to be read.  The host reads a single byte from the device which contains the keycode - so there is a limit of 255 possible buttons/combinations of buttons (we do use shift-button for alternate functions on the keypad, plus diagonal jogging if two direction buttons are pressed simultaneously).  The pendant keeps the STROBE asserted as long as the user holds down the button.  This allows for things like continuous pushbutton jogging.

In addition to the above, the DRO is updated whenever the host writes the data packet to the pendant (this can happen at any time).  This is the format of the data here:
github.com/Expatria-Technologies/RT_Jog_...er/i2c_jogger.h#L248

You should be able to use the SDA/SCL as a UART (they can be given that alternate function) and the other two GPIOS should be able to implement the quadrature decoder for the handwheel.  You would need to implement a differential receiver via IC or termination, as well as deal with voltage translation.  3.3V and 5v are also available on the headers.

Any further progress? Would love to order one of these for testing.

Ethernet SPI DMA running with a 15% improvement in ping response time. Repo updated.

Not much to do until boards arrive. If they check out OK I am sure we can get one to you as I am not completely certain when I would have the whole package ready for public release.

Idea becomes reality.  Will try to get this fired up here and make sure that the basic stuff works.  At the very least, no smoke when just plugging things in  


 

Wow, looks great! I'll pull together a config.txt for it.