This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
wiki:v2:porting_guide [2018/07/05 21:08] pixycam |
wiki:v2:porting_guide [2019/02/23 00:11] pixycam |
||
---|---|---|---|
Line 3: | Line 3: | ||
We currently have software support for [[wiki:v2:Hooking_up_Pixy_to_a_microcontroller_-28like_an_arduino-29|Arduino]], and [[wiki:v2:Hooking_up_Pixy_to_a_Raspberry_Pi|Raspberry Pi and similar controllers]] | We currently have software support for [[wiki:v2:Hooking_up_Pixy_to_a_microcontroller_-28like_an_arduino-29|Arduino]], and [[wiki:v2:Hooking_up_Pixy_to_a_Raspberry_Pi|Raspberry Pi and similar controllers]] | ||
- | You may want Pixy2 to talk to a different controller and that's not a problem -- Pixy2 is easy to strike up a conversation with! Pixy2 has three separate methods of communication: | + | You may want Pixy2 to talk to a different controller and that's not a problem -- Pixy2 is easy to strike up a conversation with! It's easier than the original Pixy. Pixy2 has three separate methods of communication: |
* **Serial:** this includes SPI, I2C and UART interfaces. The serial interfaces all use a simplified protocol with a small code and memory footprint. The code is simple to port to different microcontrollers. This is the method that is used for communication with Arduino. Using the serial protocol, Pixy sends complete information about what it detects, and it accepts simple commands for setting the pan/tilt servos, etc. | * **Serial:** this includes SPI, I2C and UART interfaces. The serial interfaces all use a simplified protocol with a small code and memory footprint. The code is simple to port to different microcontrollers. This is the method that is used for communication with Arduino. Using the serial protocol, Pixy sends complete information about what it detects, and it accepts simple commands for setting the pan/tilt servos, etc. | ||
Line 37: | Line 37: | ||
- | {{wiki:v2:image_380.png}} | + | {{wiki:v1:image_743.png}} |
Line 46: | Line 46: | ||
* analog/digital x - this will output the x value of the largest detected object as an analog value between 0 and 3.3V on pin 8. It also outputs whether an object is detected or not as a digital signal (pin 1 of the I/O connector). | * analog/digital x - this will output the x value of the largest detected object as an analog value between 0 and 3.3V on pin 8. It also outputs whether an object is detected or not as a digital signal (pin 1 of the I/O connector). | ||
* analog/digital y - this will output the y value of the largest detected object as an analog value between 0 and 3.3V on pin 8. It also outputs whether an object is detected or not as a digital signal (pin 1 of the I/O connector). | * analog/digital y - this will output the y value of the largest detected object as an analog value between 0 and 3.3V on pin 8. It also outputs whether an object is detected or not as a digital signal (pin 1 of the I/O connector). | ||
+ | * LEGO I2C - this is a special protocol for LEGO Mindstorms EV3 brick. | ||
Note, the USB interface and protocol is always enabled, while each of the interfaces above can only be enabled one at a time. | Note, the USB interface and protocol is always enabled, while each of the interfaces above can only be enabled one at a time. | ||
Line 65: | Line 66: | ||
- Data bits are latched on the falling edge of SPI SCK | - Data bits are latched on the falling edge of SPI SCK | ||
- Slave select is active low | - Slave select is active low | ||
+ | - Uses SPI mode 3, as described on [[https://www.corelis.com/education/tutorials/spi-tutorial/|this page]] | ||
+ | - 3.3V outputs, 5V tolerant inputs | ||
Pixy2 also supports SPI with slave select (SPI with SS). | Pixy2 also supports SPI with slave select (SPI with SS). | ||
Line 107: | Line 110: | ||
Here's how to hook up your controller's UART to Pixy: | Here's how to hook up your controller's UART to Pixy: | ||
- | - Pin 10 ➜ your controller's ground signal | + | - Pin 6 ➜ your controller's ground signal |
- Pin 1 (UART RX) ➜ your controller's UART TX output | - Pin 1 (UART RX) ➜ your controller's UART TX output | ||
- Pin 4 (UART TX) ➜ your controller's UART RX input | - Pin 4 (UART TX) ➜ your controller's UART RX input | ||
Line 162: | Line 165: | ||
- | Communication with Pixy2 begins by sending a request packet. For example, here is a packet to request the hardware and firmware versions. (Normally, request packets are sent without using checksums.): | + | Communication with Pixy2 begins by sending a request packet. For example, here is a packet to request the hardware/firmware version data chunk. (Normally, request packets are sent without using checksums.): |
Line 173: | Line 176: | ||
- | Pixy2 will respond with the packet (or similar, depending on the hardware and firmware versions.) Response packets always have checksums so the receiver (your controller) can test data integrity: | + | Pixy2 will respond with the packet bytes below (or similar, depending on the hardware/firmware versions.) Response packets always have checksums so the receiver (your controller) can test data integrity: |
Line 241: | Line 244: | ||
If you can't get this request-response to work, spend some time trying to determine what might be going wrong. Try using an oscilloscope to see if your controller is outputting data as expected (first), and Pixy2 is outputting data as expected in response (second). The challenge with getting any communication interface up and running is the strict requirement that the wiring, connections, and code (everything) need to be correct in order for it to work. If any single detail is not correct, e.g. missed/swapped connection or incorrect initialization code, communication will not work (at all). So we start with this simple exchange. The good news is that once you get this working, the hard part is over, and the rest is quick/easy. | If you can't get this request-response to work, spend some time trying to determine what might be going wrong. Try using an oscilloscope to see if your controller is outputting data as expected (first), and Pixy2 is outputting data as expected in response (second). The challenge with getting any communication interface up and running is the strict requirement that the wiring, connections, and code (everything) need to be correct in order for it to work. If any single detail is not correct, e.g. missed/swapped connection or incorrect initialization code, communication will not work (at all). So we start with this simple exchange. The good news is that once you get this working, the hard part is over, and the rest is quick/easy. | ||
+ | |||
+ | |||
==== TPixy2.h ==== | ==== TPixy2.h ==== | ||
- | [[https://github.com/charmedlabs/pixy2/blob/master/src/host/arduino/libraries/Pixy2/TPixy2.h|TPixy2.h]] is a template class that can be easily reused, if your porting language is C/C++. If your porting language isn't C/C++, it's still a good reference for the port translation, as it contains request-response code for all possible requests and responses. [[https://github.com/charmedlabs/pixy2/blob/master/src/host/arduino/libraries/Pixy2/Pixy2CCC.h|Pixy2CCC.h]] and [[https://github.com/charmedlabs/pixy2/blob/master/src/host/arduino/libraries/Pixy2/Pixy2Line.h|Pixy2Line.h]] are also needed to round out the [[wiki:v2:full_API|Pixy2 API]]. | + | [[https://github.com/charmedlabs/pixy2/blob/master/src/host/arduino/libraries/Pixy2/TPixy2.h|TPixy2.h]] is a template class that can be easily reused, if your porting language is C++. If your porting language isn't C++, it's still a good reference for the port translation, as it contains request-response code for all possible requests and responses. [[https://github.com/charmedlabs/pixy2/blob/master/src/host/arduino/libraries/Pixy2/Pixy2CCC.h|Pixy2CCC.h]] and [[https://github.com/charmedlabs/pixy2/blob/master/src/host/arduino/libraries/Pixy2/Pixy2Line.h|Pixy2Line.h]] are also needed to round out the [[wiki:v2:full_API|Pixy2 API]]. |
- | TPixy2.h uses the LinkType class to communicate with Pixy2. It assumes some member functions and an implementation of millis() and delayMicroseconds(), as shown in the header code below: | + | We have a complete protocol reference below. It will be very helpful if you are porting to a platform in a language other than C++. But if you are using C/C++, TPixy2.h is a good starting point. It uses the LinkType class to communicate with Pixy2. It assumes some member functions and an implementation of millis() and delayMicroseconds(), as shown in the header code below: |
<code> | <code> | ||
Line 309: | Line 314: | ||
===== Debugging ===== | ===== Debugging ===== | ||
- | when attempting to get your link class integrated and everything working, problems may arise and you may have to track down the problem. A good place to start is in the getSync() in TPixy2.h of the code. Is it finding the sync codes from Pixy2? If not, why? Is it getting the correct bytes? If it is successfully getting the sync codes, there is a problem occuring after getting the sync. This will get you started. :-) | + | When attempting to get your link class integrated and everything working, problems may arise and you may have to track down the problem. A good place to start is in the getSync() function in TPixy2.h of the code. Is it finding the sync codes from Pixy2? If not, why? Is it getting the correct bytes? If it is successfully getting the sync codes, there is a problem occuring after getting the sync. This will get you started. :-) |
+ | |||
+ | If you need help, post on our [[https://forum.pixycam.com/|forum]] or send us an email ([email protected]). Happy coding! | ||
- | If you need help, post on our [[https://forum.pixycam.com/|forum]] or send us an email ([email protected]). Happy coding! | ||
+ | {{page>wiki:v2:protocol_reference&noindent}} | ||