Jon Elson wrote:
>Rafael Skodlar wrote: > > >>This brings up another option, build an open source EMC controller >>PCI[e] card with slow, medium and high speed ports that could be used to >>control buses. Speeds would need to be determined based on what is >>required for machine world. If build with an FPGA, it would be very >>flexible and handle a lot of logic and speed and could be programmed for >>different needs: use with lathe, 3D routers and torch machines, or even >>run real time functions. >> >> >This may be what Paul Corner has been ranting about for some >time. Port EMC(your flavor here) to one of the ARM all-in-one >CPUs, and keep the GUI on a PC. There are a bunch of details, >the biggest being how to access the G-code and configuration >files. It would probably require more memory than they >currently fit into such chips as the AT91SAM7X series, I think >256 K it the max. > There are 512k parts in the works. They may even be available already. > There apparently is a substantial speed >penalty for external memory. > I think the flash is actually slower than external memory access. The datasheet for one of these chips (don't remember which one) said that it was limited to ~55 MHz operating from flash, but 175-200 MHz from RAM. I don't recall if that was internal SRAM or external ram though. It's definitely prudent to stick high-speed ISRs in RAM though. > There would need to be some >process on the PC supporting file serving to the ARM, but I >suppose NFS would work. Without all the Linux OS overhead and >virtual PC nightmares of the current PC architecture, the 70+ >MIPS of the ARM processors might be sufficient. > > You don't need to serve files. The place to put the break between PC and motion controller is probably CANON/NML, not G-code. This eliminates the need to send G-code files to the embedded box, and it also makes G-code additions/modifications happen on the PC only (most of the time anyway). >Once the file serving question is handled, the only serious >remaining effort (I think) would be porting rtapi to one of the >competing ARM RTOS options. > > I don't know that the embedded processor needs to run Linux. That may be an unnecessarily large burden, though it seems simpler because you're then just networking two Linux systems, which works quite nicely. I suspect, though I don't have any recent experience with it, that ucLinux is pretty RT already, or could be made so pretty easily. >A very interesting idea, but it could be fairly time consuming >to deal with all the intricacies of such a big porting effort. >It would sure make a NEAT package, and the board could be quite >cheap. These ARM microcontrollers are in the $7 - 14 range, >they need an additional $12 or so of parts to implement >Ethernet, and maybe under $10 for extra memory. I would think >that pat could be done for under $100. Add an FPGA to do step >generation or PWM drive and a bunch of I/O connections, and you >are up to maybe $200 for a commercial product. > > $300, using pluggable terminal strips ;) - Steve ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
