Announcement

Collapse

Technology Forum Has Moved!

The FIRST Tech Challenge Technology forum has moved to a new location! Please take a look at our forum blog for links and instructions on how to access the new forum.

The official blog of the FIRST Tech Challenge - a STEM robotics programs for students grades 7-12.


Note that volunteers (except for FTA/WTA/CSA will still access their role specific forum through this site. The blog also outlines how to access the volunteer forums.
See more
See less

REV expansion hub serial ports

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • REV expansion hub serial ports

    The REV expansion hub has two UART ports. The documentation said it is "Debug Only". Does it mean I can't use them to connect to serial port sensors? If I can use them, are they 5V ports? What class should I use to access them? I found a SerialPort class but it seems it may be for USB serial, not UART serial.

  • #2
    No, you cannot connect sensors to them. If you hook up an FTDI to it, you can read the Hub's internal log on your computer. Other than that, you can't do anything with them.

    Comment


    • #3
      Unfortunately, not usable at this time. See this reddit thread.

      Comment


      • #4
        That's interesting that they provided TWO UART ports. You just need one to get the internal log?!

        Comment


        • #5
          They log different things

          Comment


          • #6
            FWIW, this (or something equivalent) is the device you would need to connect the EH debug ports to USB:



            Port 3 is a port to which information regarding various events in the FW is intermittently written. The verbosity of said information can be adjusted with LynxModule#setDebug. Port 4 is a relatively voluminous data stream of comma-separated data sourced from various subsystems of the FW.

            In practice, the information coming through these ports is quite unlikely to be of significant utility other than to those who actually develop the firmware.

            TL;DR: it's probably not worth your time.

            Comment


            • #7
              I am not interested in debugging the firmware. I am just trying to see if it can be an alternative port for sensors/devices such as Ultrasonic Sensor/Pixy camera. Having an alternative port for communication is helpful if one doesn't work, the alternative port can be used to verify if the device is dead or it is a problem with software/port.
              For example, in FRC, we have code to access the Pixy cam from both I2C, SPI or UART. We are porting that code to FTC and was wondering if we can keep the UART code. It looks like we can't.

              Comment

              Working...
              X
              😀
              🥰
              🤢
              😎
              😡
              👍
              👎