Remora - ethernet NVEM / EC300 / EC500 cnc board

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?

DMA stream works in circular mode. And yea, for each channel we must have a buffer of states for the GPIO BSRR register.

About inaccurate values of frequency.. It's all about timer's prescaler (16bit) and period (16bit) limits. Inaccurate duty cycle values - it's DMA bus latency related issue.

The number of Ethernet controllers supported by Remora firmware is increasing  . The Digital Dream EC500 is now 99% working with just the NVMPG and spindle analogue to resolve.

The owner of the board below will start testing soon. This board I hope (fingers crossed) will have the spindle analogue working as it uses the same components as the NVEM v3 I have. The EC500 board that I received looks to be an older version using a op amp for the analogue out.

 
 
With the number of boards increasing I'm proposing to change both the repo and the naming of the LinuxCNC component.

Propose to change / new repo to Remora-Novusun and have sub directories for the NVEM and EC500 etc.

The LinuxCNC Ethernet component to change to Remora-nv

Would this cause to many issues for people?