Stephen Wille Padnos wrote: > I have an interest in getting serial, ethernet, and USB drivers that > work in at least pseudo-realtime, but it's not the highest thing on my > priority list at the moment. Wow! I have been looking at RT-ethernet, there is a package by Jan Kiszka that looks like it does what we would need. http://www.rts.uni-hannover.de/rtnet/ I have no idea how we would tie it into EMC, or what a driver would look like that used this function to communicate with external hardware. I have been looking at ethernet-capable microcontrollers. I first started looking at the NXP LPC2368, but NXP is having some problems debugging their silicon, and these chips apparently won't be ready until next year. Atmel has the AT91SAM7X256, which is in a 100-pin LQFP, is around $10 in very small quantity, and looks like it would do as well. I'm still looking at development boards and software. This has ethernet 10/100 MAC on chip, plus USB device, several serial protocols, and a bunch of pins for parallel I/O. I think the 256 Kb version (...7X256) can support a web page for config settings, and UDP for the EMC2 I/O.
I'm looking first to use this to make my PPMC driver talk to one or more of my parallel-interfaced boards over ethernet. I envision a scheme where a UDP packet is sent from the driver saying "read/write the contents of these registers". If there are any registers to be read, then a reply packet will be sent back with the values read. The code to accomplish this on an ARM processor should be short and run pretty darn fast. The actual net overhead at 100 Mbits/sec should be just microseconds. Exactly how you hack a real-time driver that is doing X86 CPU I/O instructions with an immediate, atomic I/O operation into a driver that ships a command packet out to rtnet, and then waits for a response from rtnet, I have only the very foggiest idea. It seems most logical, from a systems aspect, that you give up control of the CPU until the response comes back. But, that isn't how the regularly-scheduled RT processes work on EMC. If you give up control, you can't get it back until the next servo cycle. I need to send a command packet, wait for the encoder position to be returned in a response packet, and then send another packet with the velocity commands, all in one servo cycle. Anyone have any ideas about this? 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
