Remora - ethernet NVEM / EC300 / EC500 cnc board

Did you ever figure out what that unidentified IC was? I wonder if its an eprom with axis count info. I flashed my device with somebody else's ( hydroid7) firmware and the same axis count came up. Its must me pulling this info from somewhere during boot. Not unless hydroid7 firmware upload is 3 axis also. Just trying to figure out if axis count is in firmware or hardware.

We've never figured out what the mystery IC is but it is definitely how they restrict the number of axes available. I've just got a Digital Dream EC500 3 axis, it has all the componentry needed for 6 axes and I've got Remora running 99% with all 6 axes available.

So in future people should save the $ and buy 3 axis versions and use Remora firmware.

Yeah, the axis and serial info must be stored somewhere. I did several full chip erases and the same serial number and axis count came back up. I got your firmware up, playing with it now.

Currently I'm working on my own Ethernet controller (two stm32 black pills and a couple of cheap modules). And when I started a firmware part, I found an old project (firmware + LinuxCNC driver) of mine for the NVEM controller. This project can make a stable 200 KHz output for all 6 axes. I decided to deep into firmware to find out a new methods for the steps output. After a few weeks of testing I found two new methods and combined them into new firmware stepgen module. And now stepgen can outputing steps at 1 MHz rates (for the XY axes) and at 400 KHz rate (for the ZABC axes).

MX_Master, I'd love to know more if you are willing to share? The software DDS accumulator is great and useable for most application but is definitely limited. Are you using a timer to trigger DMA transfer to the IO port registers? Super curious and I love to keep learning.

NVEM developers made a hardware planning mistake, so we can't output pulses directly using STM's timers. But yea, we can use timers + DMA to write data to the GPIO BSRR registers. One problem here - we can use only timer 1 and 8 to do the trick because only those timers has a transfer requests for the DMA2 controller. DMA1 controller has no access to the GPIO BSRR registers. So after a first look we have just 2 stepdir channels for the high speed pulses generation. After second look I found out that we can use timer 1 and 8 for the other stepdir channels too. To do that we must use other timers to generate softly (inside IRQ handler) unused DMA transfer requests for the timer 1 and 8. As a pulses counter we using DMA transfer counter.

And now we got two methods:
FAST (timer1,8 -> DMA2 request -> DMA2 stream -> GPIO BSRR) - up to 1 MHz of pulses;
SLOW (timer3,4,6,7 -> IRQ handler -> DMA2 request -> DMA2 stream -> GPIO BSRR) - up to 400 KHz of pulses.

I can't show the sources because I'm using some parts of the code for the business. But this short description will help to understand the tricks.

Hi all, I tried to check the entire thread, but unless I missed it, is there no intro, how to copy the tool setup ? I installed STM32CubeIDE, but any pointers, how to import the project and compile ?
I am pretty experienced with some development tools, however have never used the STM environment.

Thanks

I used Scott's precompiled bin file and used ST-Link software. I was able to get it up in a few minutes.
www.st.com/en/development-tools/stsw-link004.html

kevin_allein wrote:

Hi all, I tried to check the entire thread, but unless I missed it, is there no intro, how to copy the tool setup ? I installed STM32CubeIDE, but any pointers, how to import the project and compile ?
I am pretty experienced with some development tools, however have never used the STM environment.

Thanks

Hi, as fintech has mentioned. The easiest is to use the pre-compiled firmware bin file. However, if you would like to compile from source:

1. Clone the Github repo
2. Open STMCubeIDE
3. File -> Open Projects from File System
4. Select the cloned repo directory
5. Click Finish
6. Remora-NVEM should now be visible in the Project Explorer
7. The source code is under Core/Src and Core/Inc
8. Clicking the build button (Hammer) will compile the code. Use the release version as the debug version will have a lot of overhead that will crash the base thread.

 

MX_Master wrote:

NVEM developers made a hardware planning mistake, so we can't output pulses directly using STM's timers. But yea, we can use timers + DMA to write data to the GPIO BSRR registers. One problem here - we can use only timer 1 and 8 to do the trick because only those timers has a transfer requests for the DMA2 controller. DMA1 controller has no access to the GPIO BSRR registers. So after a first look we have just 2 stepdir channels for the high speed pulses generation. After second look I found out that we can use timer 1 and 8 for the other stepdir channels too. To do that we must use other timers to generate softly (inside IRQ handler) unused DMA transfer requests for the timer 1 and 8. As a pulses counter we using DMA transfer counter.

And now we got two methods:
FAST (timer1,8 -> DMA2 request -> DMA2 stream -> GPIO BSRR) - up to 1 MHz of pulses;
SLOW (timer3,4,6,7 -> IRQ handler -> DMA2 request -> DMA2 stream -> GPIO BSRR) - up to 400 KHz of pulses.

I can't show the sources because I'm using some parts of the code for the business. But this short description will help to understand the tricks.

Thanks MX_master! Shame your code is not open source but enough pointers to get me thinking. I'm guessing you are using a ring buffer or similar to hold the step pattern? 

I see a slight difference in the requested frequency and the output. Is this due to the underlying DMA frequency or because it is a digitally synthesised frequency?