Jon Elson wrote: >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 talked to some folks who had gotten RTNet to work for their application (power substation monitoring, I think it was). Apparently it wasn't quite right "out of the box", and they had problems getting answers from the developer. This was about 18 months ago though, so things may have changed since then.
>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. > Oh. I didn't realize the NXP chips aren't real yet. I guess that explains how hard they are to get :) >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. > The development board seems pretty well outfitted. I haven't installed the software yet because my Windows PC doesn't have a DVD-ROM drive, and the support software is on DVD. (same problem with the Spartan-3a devkit) Lame excuse, I know. >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. > > At least! I'd be surprised if it couldn't handle packet data over all the ports - serial, USB and ethernet. Also, it should be able to provide additional I/O points, like PWM outputs and A/D inputs >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. > The minimum ethernet frame is 512 bits (64 bytes), so you might as well transfer all registers every time. I think the payload size is 46 bytes with a minimum-size packet. Although the time to do the ethernet transmission is low (512/100M ~= 5 microseconds in each direction), the ARM board still has to communicate with the PPMC over a "parallel-port-like" interface. I don't know if you would want to make a special FPGA config that might be faster than the normal EPP one or if this would just be a shim to go between ethernet and a standard PPMC. If you want it to work with stock PPMC/USC/UPC cards, then it will only add to the read/write time. (probably 3 ethernet packets - read command, read response, write, though you could also have the interface board continuously reading, and have it provide the latest data when requested) >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. > The way the PPMC driver works now actually lends itself very well to this. Since there's a buffer of data to read and write, and the only functions that actually deal with the hardware are the read and write functions, those should be the only thing that need rewriting. It would suck to have to busy-wait in the read function, but that is a possibility, and it shouldn't be much worse than the present read function, which busy-waits by virtue of wait staates on the parallel port. >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? > > Of course people have ideas! :) I think the ideal way to solve this problem and several others is to implement interrupt threads in HAL. Essentially, these would be asynchronous threads that run when an interrupt occurs (like now, except the only interrupt presently supported is the periodic timer). There are a lot of issues with this concept, which is probably part of the reason it isn't in there now. (not least of which is atomicity - HAL only needs to be pseudo-atomic at the moment, because (a) high priority threads always run to completion without interruption and (b) a given priority thread always runs in sequence. If you suddenly allow anything to be interrupted, you have to be much more careful about updating related pieces of data, locking, critical sections, etc.) Another possibility is to have a "request read" function, then run anything else that doesn't depend on the data from the PPMC, then a "get-response" function that runs later and busy-waits if needed. It's the same scheme used for double-frequency step output (parport.write and then parport.reset). Just more food for thought. - 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
