Kart/Sensors

From FSI
(Difference between revisions)
Jump to: navigation, search
(FPGA design)
(FPGA design)
 
(28 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
{{TOC right}}
 
{{TOC right}}
  
[[File:Kart_sensors_module.jpg|center|1000px|Sensors module]]
+
[[File:Kart_sensors_module.jpg|center|700px|Sensors module]]
  
 
Various sensors can be mounted on the [[Kart/Motherboard|motherboard]] through the exposed [https://digilent.com/reference/pmod/start PMOD] connectors.
 
Various sensors can be mounted on the [[Kart/Motherboard|motherboard]] through the exposed [https://digilent.com/reference/pmod/start PMOD] connectors.
 +
 +
Any I/O can be connected on any PMOD connector (either by directly plugging them into the pin headers or through the IDC cables).
 +
Only the pins '''6, 7 and 8 of the PMOD8''' CANT be used.
  
  
Line 37: Line 40:
 
==== Operating procedure ====
 
==== Operating procedure ====
 
To enable and root the hall sensors, proceed as follow:
 
To enable and root the hall sensors, proceed as follow:
* Modify the '''Kart/Kart_Student''' package variable '''NUMBER_OF_HALL_SENSORS''' to the number of used hall sensors
+
* Modify the '''Kart/Kart_Student''' package variable '''STD_HALL_NUMBER''' to the number of used hall sensors
 
* Modify the .pdc file to root the halls to the desired pins
 
* Modify the .pdc file to root the halls to the desired pins
 
** <code>set_io {halls[1]} -pinname 86 -fixed yes -DIRECTION Input</code>
 
** <code>set_io {halls[1]} -pinname 86 -fixed yes -DIRECTION Input</code>
** ''{halls[n]} with n from 1 to NUMBER_OF_HALL_SENSORS''
+
** ''{halls[n]} with n from 1 to STD_HALL_NUMBERS''
  
 
==== FPGA design ====
 
==== FPGA design ====
[[File:Kart_hall_block.jpg|right|700px|hall sensors block]]
+
[[File:Kart_hall_block.jpg|right|500px|hall sensors block]]
  
 
To begin with, the [[Kart#FPGA_Design|design environment]] has to be downloaded.
 
To begin with, the [[Kart#FPGA_Design|design environment]] has to be downloaded.
Line 50: Line 53:
 
and an empty <code>hallCounters</code> block which is to be completed.
 
and an empty <code>hallCounters</code> block which is to be completed.
  
The <code>hallPulsesFilter</code> block does the following:
+
The <code>hallPulsesFilter</code> block is already implemented, doing the following:
 
* It receives the raw pulses from the hall sensors
 
* It receives the raw pulses from the hall sensors
 
* It debounces the input to avoid false-transitions
 
* It debounces the input to avoid false-transitions
Line 56: Line 59:
  
  
The <code>hallCounters</code> block then receives the <code>hallPulses</code> signal array (i.e. one signal per hall pulse sensor, from 1 to NUMBER_OF_HALL_SENSORS).
+
The <code>hallCounters</code> block then receives the <code>hallPulses</code> signal array (i.e. one signal per hall pulse sensor, from 1 to 2).
 +
 
 +
''Even if you only use one hall sensor, the second exists, just held to '0' at all time.''
  
 
The following behavior must be implemented:
 
The following behavior must be implemented:
* While '''zeroPos''' (also from 1 to NUMBER_OF_HALL_SENSORS) is '1' for a sensor, reset the pulses count
+
* While '''zeroPos''' (also from 1 to 2) is '1' for a sensor, reset the pulses count
 
* Then, if '0', the dedicated counter must be incremented on either:
 
* Then, if '0', the dedicated counter must be incremented on either:
 
** The '''rising edge''' of the pulse
 
** The '''rising edge''' of the pulse
Line 67: Line 72:
 
on each edge or '0' if counted only on the rising edge.
 
on each edge or '0' if counted only on the rising edge.
 
}}
 
}}
* The counters values must be concatenated to the '''hallCount''' signal (e.g. for 2 sensors : hallCount = (COUNTER2 << 16) + COUNTER1)
+
* The counters values must be concatenated to the '''hallCount''' signal (for the 2 sensors : hallCount = (COUNTER2 << 16) + COUNTER1)
 
{{WarningBox|content=
 
{{WarningBox|content=
The output '''hallCount''' must '''ALWAYS''' reflect the current counters values
+
The output '''hallCount''' must '''AT ALL TIME''' reflect the current counters values
 
}}
 
}}
 
* When '''zeroPos''' goes to '1', the corresponding counter value must be immediately reset on the next clock
 
* When '''zeroPos''' goes to '1', the corresponding counter value must be immediately reset on the next clock
 +
*''The signal '''hallChanged''' is unused.''
  
 
{{TaskBox|content=
 
{{TaskBox|content=
 
Draw the schematics of the <code>hallCounters</code> block.
 
Draw the schematics of the <code>hallCounters</code> block.
 
}}
 
}}
 +
 +
=== Testing ===
 +
See [[Kart/Sensors#Testing_3|Testing chapter]].
  
 
== Ultrasound ranger ==
 
== Ultrasound ranger ==
Line 98: Line 107:
  
 
==== FPGA design ====
 
==== FPGA design ====
 +
[[File:Kart_ranger_block.jpg|right|500px|hall sensors block]]
  
 
To begin with, the [[Kart#FPGA_Design|design environment]] has to be downloaded.
 
To begin with, the [[Kart#FPGA_Design|design environment]] has to be downloaded.
 +
 
It comprises the <code>sensorsController</code> block which contains the registers and events manager
 
It comprises the <code>sensorsController</code> block which contains the registers and events manager
 
and an empty <code>ultrasoundRanger</code> block which is to be completed.
 
and an empty <code>ultrasoundRanger</code> block which is to be completed.
  
The <code>rangerSubsignals</code> block is responsible to transmit the pulse internally only 3 times per second and to synchronize the signals to the beginning of the pulse.
+
The <code>rangerSubsignals</code>, already implemented, does the following:
 +
* It gets the raw '''distancePulse''' signal, continuously coming in as the sensor is configured to always take measurements
 +
* Around each 333 ms, it waits for a fresh measurement (i.e. '''distancePulse''' falling edge indicates the end of the current measure)
 +
* The '''countEnable''' signal will then rise to indicate we have to count the pulse
 +
* The '''countPulse''' will create pulses each 1 us, that must be counted (it is not possible to count the clock directly, otherwise the [[kart/serial link#Registers|register]] may overflow)
 +
* '''countEnable''' will then fall at the end of the measurement, then the block waits another 333 ms to repeat the process
  
It creates two signals:
 
*<code>countEnable</code>, which stays at '1' the length of the measurement
 
*<code>countPulse</code>, which are small pulses that must be counted, dividing the clock by a factor 10 (else the total count may be bigger than its corresponding [[kart/serial link#Registers|register]])
 
  
The block <code>ultrasoundRanger</code> has the following flow:
+
The block <code>ultrasoundRanger</code>, which must be completed, has the following flow:
* wait for the signal <code>countEnable</code> to be '1'
+
* Wait for the signal <code>countEnable</code> to be '1'
* when so, the pulses <code>countPulse</code> must be counted as long as <code>countEnable</code> is '1'
+
* When so, the pulses from <code>countPulse</code> must be counted as long as <code>countEnable</code> is '1'
* when it goes back to '0', the counter value must be output to the <code>distance</code> signal and the counter reset, waiting for <code>countEnable</code> to go back to '1'
+
* When it goes back to '0', the counter value must be output to the <code>distance</code> signal
 +
* The counter can be reset at the same moment or at the beginning of the next <code>countEnable</code> pulse
 +
{{WarningBox|content=
 +
The signal '''rangerDistance''' must be updated only when '''reset = '1'''' or when '''countPulse falls''', the signal being kept intact until the next measurement is completed.
 +
}}
  
 
{{TaskBox|content=
 
{{TaskBox|content=
 
Draw the schematics of the <code>ultrasoundRanger</code> block.
 
Draw the schematics of the <code>ultrasoundRanger</code> block.
 
}}
 
}}
 +
 +
=== Testing ===
 +
See [[Kart/Sensors#Testing_3|Testing chapter]].
  
 
== End of turn switch ==
 
== End of turn switch ==
Line 143: Line 163:
 
== LEDs / Low-consumption outputs ==
 
== LEDs / Low-consumption outputs ==
  
In addition to the [[Kart/Daughterboard#LEDs|3 indication LEDs present on the daughterboard]], one can use any PMOD to drive [https://digilent.com/shop/pmod-8ld-eight-high-brightness-leds/ LEDs]
+
In addition to the [[Kart/Daughterboard#LEDs|3 indication LEDs present on the daughterboard]], one can use any PMOD to drive up to 8 [https://digilent.com/shop/pmod-8ld-eight-high-brightness-leds/ LEDs]
 
or other outputs requiring either ON, OFF, or 50% duty cycle PWM (from 1 to 16383 ms) output.
 
or other outputs requiring either ON, OFF, or 50% duty cycle PWM (from 1 to 16383 ms) output.
  
Line 149: Line 169:
 
The consumption per pin cannot be higher than 8 mA.
 
The consumption per pin cannot be higher than 8 mA.
  
If needed, use a [https://digilent.com/shop/pmod-od1-open-drain-output/ driver extension board] to control voltages other than 3.3V or higher currents (through MOSFETs).
+
To counter this problem, a [https://digilent.com/shop/pmod-od1-open-drain-output/ driver extension board] has been provided to you to control either voltages other than 3.3V or higher currents.
 +
Before using it, carefully inspect and understand its [https://digilent.com/reference/_media/reference/pmod/pmodod1/pmodod1_sch.pdf datasheet].
 +
 
 +
'''Never ever''' wire a voltage different than +3.3V on J4 while JP1 is plugged in. If the jumper is plugged, J4 is used to OUTPUT +3.3V.
 +
Else, remove the jumper and wire the correct voltage to power the freewheel diodes. Check the MOSFETs characteristics too !
 
}}
 
}}
  
 
Check with your supervisor before wiring custom systems.
 
Check with your supervisor before wiring custom systems.
 
I/O lines are '''NOT''' protected against over current and voltage backfeed.
 
I/O lines are '''NOT''' protected against over current and voltage backfeed.
You are held responsible for the cost of repair in the event of destruction of the equipment (up to 50CHF per board).
+
You are held responsible for the cost of repair in the event of destruction of the equipment.
 +
 
 +
[[File:Pmodod1.png|250px]]
  
 
==== Operating procedure ====
 
==== Operating procedure ====
On the FPGA side, those outputs are called leds[n].
+
On the FPGA side, those outputs are called leds[n]
 
To root them, proceed as follow:
 
To root them, proceed as follow:
* Modify the '''Kart/Kart_Student''' package variable '''NUMBER_OF_LEDS''' to correspond to how many outputs are used
+
* Modify the '''Kart/Kart_Student''' package variable '''STD_LEDS_NUMBER''' to correspond to how many outputs are used
 
* Modify the .pdc file to root the leds to the desired pins
 
* Modify the .pdc file to root the leds to the desired pins
 
** <code>set_io {leds[1]} -pinname 78 -fixed yes -DIRECTION Output</code>
 
** <code>set_io {leds[1]} -pinname 78 -fixed yes -DIRECTION Output</code>
** ''{leds[n]} with n from 1 to NUMBER_OF_LEDS''
+
** ''{leds[n]} with n from 1 to STD_LEDS_NUMBER, max 8''
  
 
== Buttons / Digital inputs ==
 
== Buttons / Digital inputs ==
Line 174: Line 200:
  
 
By the design and use of a BLE system, the transmission channel would become congested.
 
By the design and use of a BLE system, the transmission channel would become congested.
 +
 +
To help with interfacing digital inputs, one can use the provided [https://digilent.com/reference/pmod/pmodcon1/start PMOD-CON1] ([https://digilent.com/reference/_media/reference/pmod/pmodcon1/pmodcon1_sch.pdf datasheet])
 +
or the [https://digilent.com/reference/pmod/pmodcon3/start PMOD-CON3] ([https://digilent.com/reference/_media/reference/pmod/pmodcon3/pmodcon3_sch.pdf datasheet]) boards.
 +
 +
''For the latter, the jumper '''MUST''' sit between VCC and VS '''only'''.''
 
}}
 
}}
 +
 +
[[File:Pmodcon1.png|250px]][[File:Pmodcon3.png|250px]]
  
 
==== Operating procedure ====
 
==== Operating procedure ====
 
On the FPGA side, those inputs are called endSwitches[n].
 
On the FPGA side, those inputs are called endSwitches[n].
 
To root them, proceed as follow:
 
To root them, proceed as follow:
* Modify the '''Kart/Kart_Student''' package variable '''NUMBER_OF_EXT_END_SWITCHES''' to correspond to how many inputs are used
+
* Modify the '''Kart/Kart_Student''' package variable '''STD_ENDSW_NUMBER''' to correspond to how many inputs are used
 
* Modify the .pdc file to root the inputs to the desired pins
 
* Modify the .pdc file to root the inputs to the desired pins
 
** <code>set_io {endSwitches[1]} -pinname 64 -fixed yes -DIRECTION Input</code>
 
** <code>set_io {endSwitches[1]} -pinname 64 -fixed yes -DIRECTION Input</code>
** ''{endSwitches[n]} with n from 1 to NUMBER_OF_EXT_END_SWITCHES''
+
** ''{endSwitches[n]} with n from 1 to STD_ENDSW_NUMBER, max 16''
 
** If needed, one can add <code>-RES_PULL Up</code> or <code>-RES_PULL Down</code> to use internal pull resistors
 
** If needed, one can add <code>-RES_PULL Up</code> or <code>-RES_PULL Down</code> to use internal pull resistors
  
== Proximity sensors ==
+
== Custom circuits ==
  
The [[kart/sensors/VCNL4000|proximity sensors]] are used to get the ambient light along the ''close'' proximity to an object.
+
One can use the provided [https://digilent.com/reference/pmod/pmodbb/start PMOD-BB] ([https://digilent.com/reference/_media/reference/pmod/pmodbb/pmodbb_sch.pdf datasheet]) board to test interfacing custom circuits.
They can be plugged in any PMOD.
+
[[File:pmodbb.jpg|450px|center]]
 +
{{WarningBox|content=
 +
Do not solder anything to the board. Rather, use the solderless breadboard block provided along.
 +
}}
  
'''''They are normally not used anymore and thus not tested in the current Kart project.'''''
+
Take into consideration the requirements given above before interfacing with the FPGA (i.e., test voltages and currents present no risk).
  
The sensor cable is to be connected as:
+
Get your supervisor approval and have fun creating mind-blowing systems !
:{| cellpadding="3" cellspacing="0" border="1"
+
! Color
+
! Pin
+
|-
+
| Orange
+
| 3.3 V power supply
+
|-
+
| Yellow
+
| SDA
+
|-
+
| Green
+
| SCL
+
|-
+
| Blue
+
| ground
+
|}
+
  
{{WarningBox|content=
+
== Testing ==
External pull-ups should be present on the sensor board I2C lines, else internal ones enabled on the FPGA side.
+
The Hall sensor functionality can be tested through the '''Sensors_test -> sensors_tb''' block.
}}
+
  
==== Operating procedure ====
+
[[File:Kart_sensors_tester.jpg|center|600px|sensors tester]]
To root them, proceed as follow:
+
 
* Modify the '''Kart/Kart_Student''' package variable '''NUMBER_OF_PROXIMITY_SENSORS''' to correspond to how many sensors are used
+
The corresponding simulation layout file for Modelsim is available under '''$SIMULATION_DIR/Sensors/sensors.do'''.
* Modify the .pdc file to root the SCL to the desired pin(s)
+
It will automatically run the simulation if it has not been modified.
** <code>set_io SCL_proxy -pinname 27 -fixed yes -DIRECTION Input -RES_PULL Up</code>
+
 
** ''if using multiple sensors and the SCL pins cannot be wired to the same output, root the <code>SCL_proxy</code> to multiple pins''
+
[[File:Kart_sensors_tester_sim.jpg|right|1000px|sensors tester sim]]
* Modify the .pdc file to root the SDAs to the desired pins
+
 
** <code>set_io {SDA_proxy[1]} -pinname 28 -fixed yes -DIRECTION InOut -RES_PULL Up</code>
+
* The '''blue''' header shows which test is performed
** ''{SDA_proxy[n]} with n from 1 to NUMBER_OF_PROXIMITY_SENSORS''
+
* The '''yellow''' signals are those generated by the tester
 +
* The '''purple''' signals are the one generated by your implementation
 +
* ''You can add and remove signals at will, they will not interfere with the tests''
 +
 
 +
=== Tests ===
 +
The following tests are performed for the Hall sensors:
 +
* For each sensor, a pulse of a fixed period (n times slower for each new sensor) is generated
 +
* The '''hallCount''' is compared to an internal counter, depending on the '''HALLSENS_2PULSES_PER_TURN''' constant
 +
* When '''zeroPos''' goes to '1', the '''hallCount''' should be reset
 +
 
 +
The following tests are performed for the Ranger:
 +
* A pulse of '''tbRangerDistanceTarget (1012) * (clockPeriod / 10)'''  will be generated
 +
* When the signal '''distancePulse''' falls, the '''rangerDistance''' should be a value within '''1011 to 1013'''
 +
 
 +
The '''transcript''' window gives you details on if tests passed or not:
 +
* For the '''hallCount''' signal, you get <code>Hall count ''n'' OK</code> or <code>Hall count ''n'' error</code>.
 +
* For the '''rangerdistance''' signal, you get <code>Ultrasound ranger OK</code> or <code>Ultrasound ranger error</code>.
  
 
[[Category:Kart]]
 
[[Category:Kart]]

Latest revision as of 13:56, 6 September 2022

Contents

Sensors module

Various sensors can be mounted on the motherboard through the exposed PMOD connectors.

Any I/O can be connected on any PMOD connector (either by directly plugging them into the pin headers or through the IDC cables). Only the pins 6, 7 and 8 of the PMOD8 CANT be used.


Hall sensors

One or two Hall sensors are used to track the distance driven by the kart.

The SS311PT/SS411P digital Hall-effect sensors are operated by a magnetic field and designed to respond to alternating North and South poles with their Schmitt-trigger output.

They can be powered between 2.7 Vdc to 7 Vdc, with an open collector output (which integrates a 10 kOhm pull-up resistor already).

Thus it can be operated through any PMOD by wiring it such as:

Color Pin
Red 3.3 V power supply
Brown Hall output
Black GND

Dialog-warning.png

No internal pull resistor should be enabled on the FPGA side.

Operating procedure

To enable and root the hall sensors, proceed as follow:

  • Modify the Kart/Kart_Student package variable STD_HALL_NUMBER to the number of used hall sensors
  • Modify the .pdc file to root the halls to the desired pins
    • set_io {halls[1]} -pinname 86 -fixed yes -DIRECTION Input
    • {halls[n]} with n from 1 to STD_HALL_NUMBERS

FPGA design

hall sensors block

To begin with, the design environment has to be downloaded.

It comprises the sensorsController block which contains the registers and events manager and an empty hallCounters block which is to be completed.

The hallPulsesFilter block is already implemented, doing the following:

  • It receives the raw pulses from the hall sensors
  • It debounces the input to avoid false-transitions
  • It finally transmits the filtered pulses


The hallCounters block then receives the hallPulses signal array (i.e. one signal per hall pulse sensor, from 1 to 2).

Even if you only use one hall sensor, the second exists, just held to '0' at all time.

The following behavior must be implemented:

  • While zeroPos (also from 1 to 2) is '1' for a sensor, reset the pulses count
  • Then, if '0', the dedicated counter must be incremented on either:
    • The rising edge of the pulse
    • Both the rising and falling edges of the pulse

Dialog-warning.png

Please modify the Kart/Kart_Student package variable HALLSENS_2PULSES_PER_TURN to '1' if the signal is counted on each edge or '0' if counted only on the rising edge.

  • The counters values must be concatenated to the hallCount signal (for the 2 sensors : hallCount = (COUNTER2 << 16) + COUNTER1)

Dialog-warning.png

The output hallCount must AT ALL TIME reflect the current counters values

  • When zeroPos goes to '1', the corresponding counter value must be immediately reset on the next clock
  • The signal hallChanged is unused.


View-pim-tasks.png

Draw the schematics of the hallCounters block.

Testing

See Testing chapter.

Ultrasound ranger

An ultrasound ranger can detect if there is an obstacle at the front or back of the kart.

It is based on the PMOD-MAXSONAR board from Digilent, and can be plugged into any one-row PMOD connector (beware not to wire on the +12V pin !).

The ranger will output a pulse named PW on the board whose length has to be counted to determine the distance to an object following the rule 147 us / inch. Since the start/stop pin is not reachable, the sensor will continuously output pulses between 0.88 and 37.5 ms, each 49 ms.

Dialog-warning.png

No internal pull resistor should be enabled on the FPGA side.

Operating procedure

To root the ranger, proceed as follow:

  • Modify the .pdc file to root the ranger to the desired pin
    • set_io distancePulse -pinname 63 -fixed yes -DIRECTION Input
    • The pin must correspond to the PW pin on the ranger board

FPGA design

hall sensors block

To begin with, the design environment has to be downloaded.

It comprises the sensorsController block which contains the registers and events manager and an empty ultrasoundRanger block which is to be completed.

The rangerSubsignals, already implemented, does the following:

  • It gets the raw distancePulse signal, continuously coming in as the sensor is configured to always take measurements
  • Around each 333 ms, it waits for a fresh measurement (i.e. distancePulse falling edge indicates the end of the current measure)
  • The countEnable signal will then rise to indicate we have to count the pulse
  • The countPulse will create pulses each 1 us, that must be counted (it is not possible to count the clock directly, otherwise the register may overflow)
  • countEnable will then fall at the end of the measurement, then the block waits another 333 ms to repeat the process


The block ultrasoundRanger, which must be completed, has the following flow:

  • Wait for the signal countEnable to be '1'
  • When so, the pulses from countPulse must be counted as long as countEnable is '1'
  • When it goes back to '0', the counter value must be output to the distance signal
  • The counter can be reset at the same moment or at the beginning of the next countEnable pulse

Dialog-warning.png

The signal rangerDistance must be updated only when reset = '1' or when countPulse falls, the signal being kept intact until the next measurement is completed.


View-pim-tasks.png

Draw the schematics of the ultrasoundRanger block.

Testing

See Testing chapter.

End of turn switch

The end of turn switch can be plugged into any PMOD connector, respecting the following:

Color Pin
Green PMOD I/O
Black GND

Dialog-warning.png

An internal pull-up must be enabled on the FPGA side.

Operating procedure

To root the switch, proceed as follow:

  • Modify the .pdc file to root the switch to the desired pin
    • set_io stepperEnd -pinname 97 -fixed yes -DIRECTION Input -RES_PULL Up

LEDs / Low-consumption outputs

In addition to the 3 indication LEDs present on the daughterboard, one can use any PMOD to drive up to 8 LEDs or other outputs requiring either ON, OFF, or 50% duty cycle PWM (from 1 to 16383 ms) output.

Dialog-warning.png

The consumption per pin cannot be higher than 8 mA.

To counter this problem, a driver extension board has been provided to you to control either voltages other than 3.3V or higher currents. Before using it, carefully inspect and understand its datasheet.

Never ever wire a voltage different than +3.3V on J4 while JP1 is plugged in. If the jumper is plugged, J4 is used to OUTPUT +3.3V. Else, remove the jumper and wire the correct voltage to power the freewheel diodes. Check the MOSFETs characteristics too !

Check with your supervisor before wiring custom systems. I/O lines are NOT protected against over current and voltage backfeed. You are held responsible for the cost of repair in the event of destruction of the equipment.

Pmodod1.png

Operating procedure

On the FPGA side, those outputs are called leds[n] To root them, proceed as follow:

  • Modify the Kart/Kart_Student package variable STD_LEDS_NUMBER to correspond to how many outputs are used
  • Modify the .pdc file to root the leds to the desired pins
    • set_io {leds[1]} -pinname 78 -fixed yes -DIRECTION Output
    • {leds[n]} with n from 1 to STD_LEDS_NUMBER, max 8

Buttons / Digital inputs

Buttons or other digital inputs can be wired to any PMOD as long as their levels are in the range 0-3.3V !

An event is sent to the smartphone each time the input is rising or falling.

Dialog-warning.png

Inputs are not suitable for signals faster than 5 Hz.

By the design and use of a BLE system, the transmission channel would become congested.

To help with interfacing digital inputs, one can use the provided PMOD-CON1 (datasheet) or the PMOD-CON3 (datasheet) boards.

For the latter, the jumper MUST sit between VCC and VS only.

Pmodcon1.pngPmodcon3.png

Operating procedure

On the FPGA side, those inputs are called endSwitches[n]. To root them, proceed as follow:

  • Modify the Kart/Kart_Student package variable STD_ENDSW_NUMBER to correspond to how many inputs are used
  • Modify the .pdc file to root the inputs to the desired pins
    • set_io {endSwitches[1]} -pinname 64 -fixed yes -DIRECTION Input
    • {endSwitches[n]} with n from 1 to STD_ENDSW_NUMBER, max 16
    • If needed, one can add -RES_PULL Up or -RES_PULL Down to use internal pull resistors

Custom circuits

One can use the provided PMOD-BB (datasheet) board to test interfacing custom circuits.

Pmodbb.jpg

Dialog-warning.png

Do not solder anything to the board. Rather, use the solderless breadboard block provided along.

Take into consideration the requirements given above before interfacing with the FPGA (i.e., test voltages and currents present no risk).

Get your supervisor approval and have fun creating mind-blowing systems !

Testing

The Hall sensor functionality can be tested through the Sensors_test -> sensors_tb block.

sensors tester

The corresponding simulation layout file for Modelsim is available under $SIMULATION_DIR/Sensors/sensors.do. It will automatically run the simulation if it has not been modified.

sensors tester sim
  • The blue header shows which test is performed
  • The yellow signals are those generated by the tester
  • The purple signals are the one generated by your implementation
  • You can add and remove signals at will, they will not interfere with the tests

Tests

The following tests are performed for the Hall sensors:

  • For each sensor, a pulse of a fixed period (n times slower for each new sensor) is generated
  • The hallCount is compared to an internal counter, depending on the HALLSENS_2PULSES_PER_TURN constant
  • When zeroPos goes to '1', the hallCount should be reset

The following tests are performed for the Ranger:

  • A pulse of tbRangerDistanceTarget (1012) * (clockPeriod / 10) will be generated
  • When the signal distancePulse falls, the rangerDistance should be a value within 1011 to 1013

The transcript window gives you details on if tests passed or not:

  • For the hallCount signal, you get Hall count n OK or Hall count n error.
  • For the rangerdistance signal, you get Ultrasound ranger OK or Ultrasound ranger error.
Personal tools
Namespaces
Variants
Actions
Navigation
Modules / Projects
Browse
Toolbox