Thread: Raspberry Pi
Thanks for those thoughts Robin, pretty much mirrors what I had in mind. Have got an example interrupt procedure for the ARM/Pi so will have a go at rewriting/compiling/installing that tonight and driving it from the pulse generator output of the scope.
Working on ideas for two parallel solutions, one that does it all in software and one that uses a low cost external 'intelligent buffer' (a PIC Micro and not much else... ). I hope that the final solution can work transparently with either, the hardware solution handling higher step rates (>15000 steps/sec would be the likely x-over target) for a relatively low cost plug-in board.
Before we descend in to the nitty gritty I think we need the big picture.
If the Raspberry video is interrupt unfriendly, how do we get a screen display?
I use a Win7 laptop and wrote software to drive my mills through a USB, but that requires Visual Studio and makes the cheap solution expensive.
If we add a Linux PC to get the free compiler and upload the Gcode, it has a display and the Raspberry display would seem irrelevant.
As far as I can make out the video isn't interrupt unfriendly (at least I haven't determined that yet, but reading other's work suggests its ok in this respect) as its got a separate GPU acting on the frame buffer independent of the main CPU. But thats my next goal - to see the effect of throwing a few thousand interrupts at it... I'm sure others have done this already and moved onto the cleverer stuff but I think starting at the bottom and working up is a good way to learn... and if it doesnt work, then plan B or whatever...
My goal is to have something I can send a g-code file to over the network, remotely viewed via VNC, and set running... I dont plan to use the RPi for design or CADCAM etc... just a g-code interpreter, putting motion data into a buffer and playing out the buffer in 'real-time' to the hardware while providing some level of visualisation of the cutter location on the screen...
I think one of these would be better for development?
Then get a cheaper board without the LCD etc for the actual controller, or perhaps stick with the LCD as there's enough space there to display the important information.
I know this is cheating, but hey!
Nice n cheap and I might yet get one to play with but it doesn't have what i want on board, like the Ethernet...
Give me a few days and I should have something sort of working... just getting my head round this linux stuff...
Here's one that does:
I reckon I'll get one of those, not sure which...
But with only 512k rom/64k RAM you're going to have to do primarily bare-metal programming which is fine for a bit of bit-bashing, but (and I admit I've not done much research yet) I'd not want to write my own Ethernet software, web server, etc., etc. I guess there are examples of these around, but I want to focus on the CNC stuff not getting the basic platform up and running... a little googling suggests that there is limited info about this (compared to the Linux world) and a shed load of work even to do basic stuff like turn an LED on and off from a web page...
But don't let me stop you....
Have the bare bones of a program now that takes a buffer of step requests (# of steps, step rate, direction) in 4 dimensions X/Y/Z/A and outputs these under interrupt driven timing to the GPIO outputs. Without having to resort to a kernel level interrupt handler (which I will do when I've worked out how to get the Linux cross compiler to work) and using an out of the box user-space handler I am able to get 5,000 steps/sec on each axis with <10uS delta between channels (10kHz interrupt). That uses around 50% CPU on an unclocked Pi.
Next is to get a basic G-code interpreter running and do the vector maths to handle acceleration/deceleration.
I have a working G code reader written in C# for Microsoft Visual Studio if that would help?
It's only really interested on G0-3 and tool changes but could be expanded.