Stephen Wille Padnos wrote: >> >> > > 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 think they are working actively on it, and I think Jan uses it in something practical he is doing, so they should be continuing to improve. But, I have not actually tried running it, yet. > > > Oh. I didn't realize the NXP chips aren't real yet. I guess that > explains how hard they are to get :) > Many of the less complicated chips have been real for some time, but the ARM7 with 10/100 ethernet MAC on chip, plus CAN, USB device, and tons of other I/O are the ones they are having trouble with. These are DARN complicated chips, but PERFECT for what I want to do with it. They have two newer generations that may be pretty real (24xx, 28xx) but they are in 208-lead quads and ball grid arrays, which I want to avoid like the plague! > > > 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. > I am hoping to do the development on Linux with Gnu-Arm, and not have to buy expensive packages with insane licensing restrictions, etc. > > > 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 > Yes, it has some PWM channels, and the ADC would be a useful thing for a number of purposes. > > > The minimum ethernet frame is 512 bits (64 bytes), so you might as well > transfer all registers every time. Yes, after initial sensing/enumeration of the configuration, that's what I would do. It is how the ppmc driver works now, pretty much. The only time that rule is broken is when in the synch to index pulse mode and the index has been found, then you have to tell it to get out of index sync mode. 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. The first cut will probably use software-simulated IEEE-1284 protocol on the unmodified FPGA config. But, yes, with a couple inch cable, I can certainly reduce the delays in the FPGA to make the handshake go a lot faster, or just take out the handshaking completely. > 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) > Yes, that's what I had planned. (What it will actually turn into remains to be seen.) But, eventually, I will probably make a new board with the Atmel chip on the board. I will probably make that an option, so you could have a "master" board with the Atmel chip, ethernet MAU and RJ-45 jack populated, and slave boards with those components left out, and the (speeded-up) parallel interface daisy-chained to them from the master. (One advantage to doing it that way would be reduced net overhead, also the boards can sync E-stop and encoder latch in hardware, as they do now.) > > 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. > Well, it has to be more sophisticated than just a busy wait. You have to have an out if the board fails to respond, or the busy wait will lock up the system. > >>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.) > Yeah, no kidding! Is any of this in the works? I have done a fair bit of asynchronous system-level code back in my VAX/VMS days, so I'm not scared of semaphores, atomic read/modify/write operations, etc. I guess the big problem is what restrictions RTAI puts on what you can do. I haven't delved into that at all. > 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). Yes, this mostly would work, except that the driver right now doesn't really do much until it has the encoder positions and sense switch data read in. This all runs in about 50 us on the existing parport hardware.
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
