Stephen Wille Padnos wrote: > > Jon Elson wrote: > > >> > > 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. > OK, I have read a LOT more about the unavailable NXP ARM7 chips with the 10/100 Ethernet built in, and haven't gotten up to speed on the Atmel version. > >> 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). > Well, this is getting WAYYYYY deeper into this than I wanted it to get! I was hoping for a quick hack to basically extend my IEEE-1284 protocol through some kind of ethernet encapsulation, now we're getting into splitting EMC2 into several pieces running on different architectures. It would certainly be a great facility to have, but this way beyond the amount of time I have to devote to it. If I could do some of the hardware level stuff, like reworking an Atmel development board to just have what we need (like maybe some outboard RAM, Ethernet, parallel port that could be used for step generation or an interface to my controller boards, and the ADC and other features of the Atmel chip, I'd sure be interested in working on that. But, when I look at all the areas that might need work, such as hooking RTnet (or other RT-Ethernet driver/stack) to HAL, getting the same RT-ethernet driver ported to the Atmel chip, and now sawing EMC2 in half without killing it, just like the stage magician, I'm definitely getting overwhelmed. > >>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. > There are several Rtos packages for the ARM that are not anything near a Linux kernel. They are much closer to the old rt scheduler. > >>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 ;) Yeah, I know!
Jon ------------------------------------------------------------------------- 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
