Closed justbuchanan closed 8 years ago
@justbuchanan @ChrisDoho Do we have an idea of what percentage of the logic gates we're using on the Spartan-3E with the 2011 stuff? I've seen where it outputs this during synthesis but can't recall what it was.
Communication with the FPGA will be very similar to what there is currently. After a packet is received, the values are translated into individual motor speeds and sent to the FPGA. At the same time, the FPGA sends back error checking information and encoder ticks. There should plenty of time for transactions between radio packets because it's the only other thing on the SPI bus.
The first SPI byte sent to the FPGA is a communication type identifier byte, and the FPGA sends back it's verilog version number. With the removal of the kicker signals from the FPGA, there's really only 1 transaction type now. However, the first addressing byte will still be used for allowing flexibility for the mbed's firmware. Nothing is finalized about this, but I'd expect 0x00 would be the address byte for the main motor update transaction type. The FPGA would reset the encoder counters everytime this is requested from the mbed. 0x01, 0x02, 0x03, 0x04 would be address bytes for each motor where everything the FPGA knows about a motor is sent back - for logging purposes mainly. This transaction type (and any others) would never reset the encoder counters. Depending upon if there's enough logic gates, an address of 0x05 would be a more experimental transaction that would act just like the transaction of type 0x00, except the values sent to the FPGA would be x, y, & theta (distance) values that would abstract the mbed firmware slightly for better use of the accel/gyro in on-board motion control. It would send back delta values of the same type. I think I actually have some VHDL of this exact thing somewhere on my computer...
I just checked out mbed-fpga
and ran synthesis again and got this:
Logic Utilization:
Number of Slice Flip Flops: 36 out of 1,920 1%
Number of 4 input LUTs: 102 out of 1,920 5%
Logic Distribution:
Number of occupied Slices: 98 out of 960 10%
Number of Slices containing only related logic: 98 out of 98 100%
Number of Slices containing unrelated logic: 0 out of 98 0%
*See NOTES below for an explanation of the effects of unrelated logic.
Total Number of 4 input LUTs: 180 out of 1,920 9%
Number used as logic: 102
Number used as a route-thru: 78
The Slice Logic Distribution report is not meaningful if the design is
over-mapped for a non-slice resource or if Placement fails.
Number of bonded IOBs: 10 out of 108 9%
Number of BUFGMUXs: 1 out of 24 4%
Don't entirely know what it all means, but we've got plenty of available available fpga.
The fpga transactions you were talking about sound good to me. @jjones646 are you getting this setup or @ChrisDoho? I've got the controls all setup in C++ code right now so that we input the current and desired (x, y, theta) velocities into it and it returns the voltages to send to the motors. For motion control as its setup now, we just need to be able to read encoders and send voltages to the fpga.
Is the IMU connected straight to the MBED or via the FPGA?
@justbuchanan I can get the SPI interface setup between the mbed and FPGA, and I believe @ChrisDoho is taking care of the other SPI interface going to each motor driver and the ADCs on the motor board. I started officially outlining the transaction types and should have that posted within 2 or 3 days. How many bits are needed for setting each voltage value?
The mbed over I2C and an interrupt line. Pin declarations are in the 'mbed-configs' branch
Done in #703
At fixed time intervals, we'll read encoder values (among other things) from the FPGA and use them to estimate robot velocity.
@jjones646, do we have a plan yet for the specifics and timings of communication with the FPGA?