|
99 | 99 | ], |
100 | 100 | "module": "ht-nxt-smux", |
101 | 101 | "name": "ht-nxt-smux-port", |
102 | | - "notes": "\n[^port-name-prefix]: The full `port_name` is in the format:\n ^\n [<parent-port-name>:]mux<n>\n ^\n For example, if we are looking at port 1 of this mux plugged into\n input port 2 on the EV3, the port name will be `in2:i2c08:mux1`.\n \n ", |
| 102 | + "notes": "\n[^address-prefix]: The full `address` is in the format:\n ^\n [<parent-address>:]mux<n>\n ^\n For example, if we are looking at port 1 of this mux plugged into\n input port 2 on the EV3, the address will be `in2:i2c08:mux1`.\n \n ", |
103 | 103 | "num_modes": 2, |
104 | 104 | "prefix": "mux", |
105 | | - "prefix_footnote": "[^port-name-prefix]", |
| 105 | + "prefix_footnote": "[^address-prefix]", |
106 | 106 | "source_file": "drivers/lego/sensors/ht_nxt_smux.c", |
107 | 107 | "source_line": 39, |
108 | 108 | "url_name": "ht-nxt-smux-port" |
|
184 | 184 | "id": "EV3_OUTPUT_PORT_MODE_TACHO_MOTOR", |
185 | 185 | "name": "tacho-motor", |
186 | 186 | "name_footnote": "[^tacho-motor-mode]", |
187 | | - "notes": "\n[^tacho-motor-mode]: Configures the port to use the\n [tacho-motor] driver module. The default driver is the\n EV3 Large Motor (`lego-ev3-l-motor`). You can change\n the driver using the `set_device` attribute.\n ^\n [tacho-motor]: /docs/drivers/tacho-motor\n \n " |
| 187 | + "notes": "\n[^tacho-motor-mode]: Configures the port to use the\n [tacho-motor] driver module. The default driver is the\n EV3 Large Motor (`lego-ev3-l-motor`). You can change\n the driver using the `set_device` attribute.\n ^\n [tacho-motor]: /docs/drivers/tacho-motor-class\n \n " |
188 | 188 | }, |
189 | 189 | { |
190 | 190 | "description": "Load the [dc-motor] device.", |
191 | 191 | "id": "EV3_OUTPUT_PORT_MODE_DC_MOTOR", |
192 | 192 | "name": "dc-motor", |
193 | 193 | "name_footnote": "[^dc-motor-mode]", |
194 | | - "notes": "\n[^dc-motor-mode]: This can be use with MINDSTORMS RCX\n motors, Power Functions motors and any other 'plain' DC\n motor. By 'plain', we mean the motor is just a motor without\n any feedback.\n ^\n [dc-motor]: /docs/drivers/dc-motor\n \n " |
| 194 | + "notes": "\n[^dc-motor-mode]: This can be use with MINDSTORMS RCX\n motors, Power Functions motors and any other 'plain' DC\n motor. By 'plain', we mean the motor is just a motor without\n any feedback.\n ^\n [dc-motor]: /docs/drivers/dc-motor-class\n \n " |
195 | 195 | }, |
196 | 196 | { |
197 | 197 | "description": "Load the [led] device.", |
198 | 198 | "id": "EV3_OUTPUT_PORT_MODE_LED", |
199 | 199 | "name": "led", |
200 | 200 | "name_footnote": "[^led-mode]", |
201 | | - "notes": "\n[^led-mode]: This can be used with MINDSTORMS RCX LEDs,\n Power Functions LEDs or any other LED connected to pins 1\n and 2 of the output port.\n ^\n [led]: /docs/drivers/led\n \n " |
| 201 | + "notes": "\n[^led-mode]: This can be used with MINDSTORMS RCX LEDs,\n Power Functions LEDs or any other LED connected to pins 1\n and 2 of the output port.\n ^\n [led]: /docs/drivers/rcx-led\n \n " |
202 | 202 | }, |
203 | 203 | { |
204 | 204 | "description": "Provide access to low level drivers.", |
|
237 | 237 | ], |
238 | 238 | "module": "ms-ev3-smux", |
239 | 239 | "name": "ms-ev3-smux-port", |
240 | | - "notes": "\n[^port-name-prefix]: The full `port_name` is in the format:\n ^\n [<parent-port-name>:]mux<n>\n ^\n For example, if we are looking at port 1 of this mux plugged into\n input port 2 on the EV3, the port name will be `in2:i2c50:mux1`.\n \n ", |
| 240 | + "notes": "\n[^address-prefix]: The full `address` is in the format:\n ^\n [<parent-address>:]mux<n>\n ^\n For example, if we are looking at port 1 of this mux plugged into\n input port 2 on the EV3, the address will be `in2:i2c50:mux1`.\n \n ", |
241 | 241 | "num_modes": 2, |
242 | 242 | "prefix": "mux", |
243 | | - "prefix_footnote": "[^port-name-prefix]", |
| 243 | + "prefix_footnote": "[^address-prefix]", |
244 | 244 | "source_file": "drivers/lego/sensors/ms_ev3_smux.c", |
245 | 245 | "source_line": 42, |
246 | 246 | "url_name": "ms-ev3-smux-port" |
|
257 | 257 | ], |
258 | 258 | "module": "ms-nxtmmx", |
259 | 259 | "name": "ms-nxtmmx-out-port", |
260 | | - "notes": "\n[^prefix]: The full port name will be something like `in2:i2c3:M1`\n depending on what port the motor multiplexer is plugged into.\n \n ", |
| 260 | + "notes": "\n[^prefix]: The full address will be something like `in2:i2c3:M1`\n depending on what port the motor multiplexer is plugged into.\n \n ", |
261 | 261 | "num_modes": 1, |
262 | 262 | "prefix": "M", |
263 | 263 | "prefix_footnote": "[^prefix]", |
|
310 | 310 | ], |
311 | 311 | "module": "pistorms-ports-in", |
312 | 312 | "name": "pistorms-in-port", |
313 | | - "notes": "\n[^port-name-prefix]: The full `port_name` is in the format:\n ^\n pistorms:B<b>:<prefix><n>\n ^\n For example, if we are looking at the port labeled \"BBS2\" on the\n PiStorms, the port name will be `pistorms:BB:S2`.\n \n ", |
| 313 | + "notes": "\n[^address-prefix]: The full `address` is in the format:\n ^\n pistorms:B<b>:<prefix><n>\n ^\n For example, if we are looking at the port labeled \"BBS2\" on the\n PiStorms, the address will be `pistorms:BB:S2`.\n \n ", |
314 | 314 | "num_modes": 6, |
315 | 315 | "prefix": "S", |
316 | | - "prefix_footnote": "[^port-name-prefix]", |
| 316 | + "prefix_footnote": "[^address-prefix]", |
317 | 317 | "source_file": "drivers/lego/pistorms/pistorms_ports_in.c", |
318 | 318 | "source_line": 134, |
319 | 319 | "url_name": "pistorms-in-port" |
|
330 | 330 | ], |
331 | 331 | "module": "pistorms-ports-out", |
332 | 332 | "name": "pistorms-out-port", |
333 | | - "notes": "\n[^prefix]: The full port name will be something like `pistorms:BAM1`\n depending on what port the motor multiplexer is plugged into.\n \n ", |
| 333 | + "notes": "\n[^prefix]: The full address will be something like `pistorms:BAM1`.\n \n ", |
334 | 334 | "num_modes": 1, |
335 | 335 | "prefix": "M", |
336 | 336 | "prefix_footnote": "[^prefix]", |
|
350 | 350 | ], |
351 | 351 | "module": "wedo", |
352 | 352 | "name": "wedo-port", |
353 | | - "notes": "\n[^port-name-prefix]: The full `port_name` is in the format:\n ^\n usb<usb-path>:wedo<n>\n ^\n The USB path might be something like `1-1.3:1.0`. Read more about\n it [here](http://gajjarpremal.blogspot.in/2015/04/sysfs-structures-for-linux-usb.html).\n Run `lsusb -t` to help figure out the correct path for your WeDo hub.\n ^\n For example, this...\n ^\n /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/4p, 480M\n |__ Port 4: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M\n |__ Port 2: Dev 6, If 0, Class=Human Interface Device, Driver=wedo, 1.5M\n ^\n ...translates to `usb5-4.2:1.0:wedo1`. You can see how `Bus 05`,\n `Port 4` and `Port 2` result in `5-4.2`. The last bit (configuration\n and interface) will always be `:1.0`.\n \n ", |
| 353 | + "notes": "\n[^address-prefix]: The full `address` is in the format:\n ^\n usb<usb-path>:wedo<n>\n ^\n The USB path might be something like `1-1.3:1.0`. Read more about\n it [here](http://gajjarpremal.blogspot.in/2015/04/sysfs-structures-for-linux-usb.html).\n Run `lsusb -t` to help figure out the correct path for your WeDo hub.\n ^\n For example, this...\n ^\n /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/4p, 480M\n |__ Port 4: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M\n |__ Port 2: Dev 6, If 0, Class=Human Interface Device, Driver=wedo, 1.5M\n ^\n ...translates to `usb5-4.2:1.0:wedo1`. You can see how `Bus 05`,\n `Port 4` and `Port 2` result in `5-4.2`. The last bit (configuration\n and interface) will always be `:1.0`.\n \n ", |
354 | 354 | "num_modes": 1, |
355 | 355 | "prefix": "wedo", |
356 | | - "prefix_footnote": "[^port-name-prefix]", |
| 356 | + "prefix_footnote": "[^address-prefix]", |
357 | 357 | "source_file": "drivers/lego/wedo/wedo_port.c", |
358 | 358 | "source_line": 417, |
359 | 359 | "url_name": "wedo-port" |
|
0 commit comments