Kirk Wallace wrote: >[snip] >Are you talking about reconfiguring the 5i20 after loading EMC and the >5i20 driver? Normally, I would think, you would create the new >configuration in a new driver. It certainly would be cool to be able to >dynamically configure EMC and the 5i20, but might not be good for people >like me to know about it. > Well, there are two things here.
First is hostmot2 and how something like that could work with EMC2. The Hostmot2 config has all sorts of I/O, but all of the advanced functions can be disabled. There are registers that select whether each port pin will be connected to the generic I/O function, or whether they'll be connected to the "alternate function". These are dynamically changeable in the FPGA. There are two ways for HAL to deal with this: 1) Many load-time parameters. The loadrt line in the hal file would have to specify which UARTS, SPIs, PWMs, quadrature counters, and stepgens are going to be enabled. Also, you need to specify which pins should be inputs and which should be outputs. This is what tells the HAL driver which pins to export. The driver would then configure the board as specified, and run from there. For maximum flexibility, you'd end up with a load line like this: loadrt hal_hostmot2 spien="0,0,0,1,0,1" stepen="0,0,0,0,0,0,0,0,1,1,1,1" pwmen="0,0,0,0,0,0,0,0,0,0,1,1" quaden="0,0,1,1,1,1" uarten="0,0,0,0,0,0,0,0" iodirmap="0xFFFFFF,0xFFFFFF,0xFF0000,0xFF00000" (I may have forgotten something there too) That might be the syntax to get 2 SPI ports, 4 stepgens, 2 PWM, 4 quadrature counters, no UARTs, and two I/O connectors that are compatible with the 7I37 (16 in + 8 out). 2) The HAL driver exports all possible pins for all functions. There would then be parameters that control which functions are enabled. Even something as simple as an I/O pin would have the following: pins: blahblah.0.dio.00-in blahblah.0.dio.00-in-not blahblah.0.dio.00-out params: blahblah.0.dio.00-invert blahblah.0.dio.00-mode When you have 72 or 96 I/O pins, this gets to be a very large number of mostly useless HAL pins. Now we add the fact that the SPI and other advanced functions are overlaid on top of I/O pins. For example, one connector has the SPI ports, so you'd also have these pins/params (at least, I haven't thought it through completely): pins: blahblah.0.spi.0.data blahblah.0.spi.0.busy params: blahblah.0.spi.0.baudrate blahblah.0.spi.0.numbits blahblah.0.spi.0.clk_phase blahblah.0.spi.0.clk_polarity blahblah.0.spi.0.enable As you can see, it gets mighty crowded mighty fast :) I just saw Pete's email, which has a reasonable third option, but the alternate functions would probably need to be moved around a bit. Doing things by connector would make it so you get 0 or 12 stepgens, since they're all on the same header. So if you want one quad counter, one SPI, one stepgen, one UART, and one SPI, you get no digital I/Os ;) It could be simpler for the load line as well, the parameters could specify only the count of each function, but that prevents you from choosing which ones to enable (to work around demaged pins, or to have some I/Os next to stepgens for amp enables, for example) So, that was the first part ;) The second way is to do it like the new configurable firmware. An FPGA designer might make a config with 6 stepgens, 6 quad counters, and 6 SPIs, for example. There would be a GUI tool (and likely command-line options as well) to allow a user to choose which functions should be enabled, and when there's an option, where the special functions get connected. The tools put this "selected configuration" information into the FPGA bitfile, and the program that programs the FPGA puts that data into a RAM area on the FPGA. The driver reads the RAM area, and exports the correct set of pins for the selected functions. This is a little different in that the FPGA must be programmed before loading the HAL driver, though that can be done in the same hal file with a loadusr command. It's not a simple problem to decide which way is "right". - 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
