Thread: Raspberry Pi
Hybrid View
-
09-07-2012 #1
-
09-07-2012 #2
There are many cheap ARM eval boards around, I set a goal to find the cheapest! The cheapest so far I have found is the STM32 discovery http://uk.rs-online.com/web/p/proces...-kits/7458434/ for £10. No wait, here is a cheaper one! http://uk.rs-online.com/web/p/proces...-kits/7587554/
I've got one of the former, haven't done anything with it yet. Instead I build one of the LPC1343 boards you can here http://code.google.com/p/micropendou.../Older_Designs. The nice thing about the LPC chips is they come with a USB bootloader built in, it loads likes a USB flash drive. You just need the GNU compiler and you can start using it.
I have been using it to make a Control Panel for a 3d printer, you can just make out the board here http://www.flickr.com/photos/4829929...in/photostream
There are some many options now, we are spoilt for choice. The only thing is if you are into DIY hardware, there are virtually no ARM chips in a DIP package, all LQFP or smaller. The '1343 board above is not too hard to build, I used the two soldering iron technique, a magnifier, and patience ;)
I have some spare blank PCB's if anyone wants one, most of the parts are available via RS or Farnell.
ETA; design files and sample firmware for my project is at https://github.com/bobc/bobc_hardware
-
09-07-2012 #3
-
16-07-2012 #4
So, I got a breakout module (a Cobbler, it was quicker/cheaper than putting my own together). I've been teaching myself Linux Kernel and module programming and playing with an GPIO library WiringPi . A quick bit of bit bashing and inspection with the scope has proven, as I suspected, the need for an external interrupt. The Pi can generate 100nS pulses (from C) but the jitter is horrible. I'm currently writing a module that'll take an interrupt from the GPIO and toggle a GPIO line every 'n' pulses, where 'n' is a value in user space. That'll allow me to see what the latency and jitter is from an interrupt.
-
16-07-2012 #5
Jitter is the problem with running an operating system which happily delays your interrupt service.
The ARM micro's come with numerous timer channels and you can prioritise the interrupts. However I like to use a single timer for stepping because it makes it darned easy to keep the accelerations/decellerations in synch. I buffer incoming data from the host PDQ then handle it in background so it doesn't interfere with the stepping.
Two timer interrupts per step, one to set the STEP lines for any steps required, one to step everyone who is primed to go. Makes for nice square pulses and good settle time on the direction lines.
I like to smash my arcs in to individual straight lines in a buffer to keep the timer interrupt fast and simple. The timer interrupt fetches the next when it exhausts the one it is doing.
A line has 3 seperate components, acceleration steps, constant speed steps and decelleration steps.
Lines also have 3 slope values, one for each axis. Basically a number which you add in to a tally and if the tally carries that axis steps.
If the PAUSE button is pressed things get a bit hairy, every step becomes a decelleration step. It tallies decellerations so it can update the buffer to get back up to speed if it gets unPAUSEd.
If you smash the arc into enough segments you keep within 1 step resolution. I check the angle at which individual lines intersect and use a table to guess-timate how fast it is safe to take the corner. My PC does the arc to line/speed conversion with no appreciable delay and I am sure the ARM is up for it.
My mill runs it very smoothly with an 8MHz, 8 bit micro crunching 24 bit numbers. With 32 bit registers it should be a doddle, I could do the whole interrupt in ARM assembler nil problemo.
-
17-07-2012 #6
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.
-
17-07-2012 #7
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.
-
17-07-2012 #8
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...
-
19-07-2012 #9
I think one of these would be better for development?
http://www.ebay.co.uk/itm/Brand-New-...ht_6416wt_1037
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.
-
19-07-2012 #10
That's the one I bought. Well I actually bought 2 so my brother got one which is always a good move. The preloaded program source did not compile but he did the spade work and sent me back a bare bones program to do the screen and touch panel all set up and ready to run with the "Eclipse" C compiler. I unzipped it, compiled it, uploaded it and it was fine and dandy.
I know this is cheating, but hey!
Thread Information
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)
Similar Threads
-
cnc print a raspberry
By george uk in forum General DiscussionReplies: 7Last Post: 13-06-2014, 01:13 PM -
Raspberry Pi as a PC + Mach3 .. very possible
By Fivetide in forum General ElectronicsReplies: 2Last Post: 05-09-2012, 11:18 PM




Reply With Quote

Bookmarks