- Posts: 19306
- Thank you received: 0
EMC2 running on Raspberry Pi?
mhaberler wrote: Not a good analogy - the Mesa 'base thread' is on the FPGA so that path doesnt need a host-side base thread
Ah, OK. For some reason I thought this was a scheme where a "waveform" was loaded into a buffer and then automatically written out. I don't know where I got that idea from.
Please Log in to join the conversation.
DMA continuously playing out a set of prerecorded step/dir 'tracks' from memory at some reasonable (and constant) rate, from a circular RAM buffer.
The 'base thread' rate is DMA rate in this instance.
The servo threads job here is to lay down the step/dir tracks ahead of the DMA 'player' so for example at a 5 KHz servo thread and 500 KHz DMA rate, ~100 memory locations would need to be updated every servo thread invocation.
One of the interesting things is that the stepgen comp should be able to be used almost as is.
its 'base thread' is simply called every time the 100 + memory locations are written. Basically this is just time base correction using the DMA to deliver the output data at a constant rate.
Please Log in to join the conversation.
mhaberler wrote:
Not a good analogy - the Mesa 'base thread' is on the FPGA so that path doesnt need a host-side base threadandypugh wrote:
That seems right, as it is also the case with a Mesa stepgen.mungkie wrote: All stepgen functions will run at servo_thread period INCLUDING MAKE_PULSES!!!!!!!!!,
see here: www.linuxcnc.org/docs/devel/html/man/man9/stepgen.9.html :
stepgen.make-pulses <---- this one should be on the base thread, i.e fast
stepgen.capture-position and stepgen.update-freq can be on the servo thread
you wont get far with make-pulses on the servo thread
- Michael
I am not sure you are correct, the whole idea of using the dma system is so that we do not need a fast base thread.
When make-pulses is called in servo thread it loops over the step creation loop 100 times (or whatever required) to generate the gpio pulse bit_patterns required by the dma buffer that writes to the gpio controlled by the pwm clock (i.e. actual gpio writing and timing is off loaded to dma program written in dma control block code).
Of course the step_gen could be run in the base thread and change the base thread to the same period as the servo thread.?
My problem is I am not sure on how linuxcnc handles things, I am starting to get the feeling I do not understand anything properly, and reading though all the linuxcnc code could take weeks to understand it.
Also the code I posted has some terrible bugs and when I tried running it yesterday it did not work at all, first thought was that I used a bitwise inversion when I should have used logical ( ~ when I must use ! i.e. current_buffer= ~current_buffer; ). but the code still does not work and I think this may be due to a deadlock when dma trys to access memory at the same time as the make-pulses code??
I really have no idea.
I think I need to add some extra dma control blocks in init_ctrl_data() at the start and halfway through the dma control block loop that write to the current_buffer (current buffer is just a flag to say which half of the buffer is currently being used by the dma program) memory so that make pulses knows which half of the buffer to write to.?
I am not sure what is going on with the code, and testing is not easy as I have only been able to guess what the gpio is doing by connecting a multimeter frequency meter to the gpio pin for testing.
I will have a bit more of a play with things tonight.
Please Log in to join the conversation.
- mhaberler
- New Member
-
- Thank you received: 0
sorry -m
Please Log in to join the conversation.
I think I have fixed some of the problems with the code, but not sure if there is a problem with the code or with the oscilloscope now.
Is there anyone here with a raspberry pi and a DSO that could run some tests??
I will post the code for a basic command line test of the system, all you will need is a rpi running raspbian a DSO and an 1/2 hour to compile the code plug things together and collate the results and post them back here.
From the oscilloscope I have it looks like the pulse generation is very good but then the pulses stop for a period and restart, I guesssed it could be problems with the test equipment triggernig , I know there are definitly faults with it since I got it off ebay, maybe should continue reviewing the code before asking others to do tests???
Anyone have any suggestions??
Also what sort of output wave should the step_gen pins have, I have programed the code so the pin toggles (I.e. always low unless a pulse is sent), i imagine some systems may require set/clr (i.e. once pulse is sent output pin stays at the set level until it is changed)
Please Log in to join the conversation.
I do have both, though I have barely even booted the Pi.mungkie wrote: Is there anyone here with a raspberry pi and a DSO that could run some tests??
Having just done so, it seems to be running Raspbian.
And a monitor and scope in the same roomll you will need is a rpi running raspbian a DSO and an 1/2 hour to compile the code plug things together and collate the results and post them back here.
I don't think any need that. Supporting Quadrature might be nice, and actually supporting all the patterns in the standard stepgen would be great. Some people are going to want to invert the sense of the pin (high most of the time, dipping low for the pulse length).Also what sort of output wave should the step_gen pins have, I have programed the code so the pin toggles (I.e. always low unless a pulse is sent), i imagine some systems may require set/clr (i.e. once pulse is sent output pin stays at the set level until it is changed)
Please Log in to join the conversation.
If there are any errors either you or I have made a mistake somewhere so post the errors here I will try to solve them.
If the code compiles without errors connect the DSO to pins 22,23,24 of the P1 gpio port on the rpi, then type 'sudo ./a.out'
The code should printout a list of the bit patterns on gpio pins 22/23/24 and let the DMA loop for 30 seconds then change the bit patterns.
What I would really like to know from the test is if there is any delay at the begining middle or end of the 200 sample buffer when the DMA loops back to the start of the buffer or changes the buffer position flag.
If the step generation looks fairly constant on the DSO then I will try and finish off the driver for linuxcnc (should only take an evenings work unless I have missed something).
Please Log in to join the conversation.
One thing that did occur to me is that if you have a conventional PC running LinuxCNC then you can halscope reading the p-port in the base thread as a DSO. You need the step length on the Pi to be longer than the base period of the PC, though.
Please Log in to join the conversation.
One thing that did occur to me is that if you have a conventional PC running LinuxCNC then you can halscope reading the p-port in the base thread as a DSO. You need the step length on the Pi to be longer than the base period of the PC, though.
Unfortunately I don't have a linuxcnc system that runs a base thread above 10khz I never really bothered trying to tune my linuxcnc setups as the stepper drives cannot run faster.
But I had a quick search and found an interesting link that may also be relevant to linuxcnc rpi gpio DMA drivers:
www.raspberrypi.org/phpBB3/viewtopic.php...b2d8a0cf16e&start=50
Seems the 'panalyzer' system runs on the rpi and can sample gpio at around ~20MHz, again using DMA but also I think some interupt masking maybe involved, and I think it looks like a system clock is used for better timing rather than the pwm (I am always unsure what other parts of the system maybe using clocks and interupts that may cause conflicts).
I am wondering if other parts of the linux kernel system maybe trying to use the DMA or causing interupts that effect the DMA, or maybe the scope is just faulty?
I am going to continue searching and wait on this for a while see what else turns up, there maybe easier or better ways to get gpio switched without effecting system performance.
Please Log in to join the conversation.
