Weird behavior with SoftwareSerial and pin choices

Store Forums Video Experimenter Bugs/Problems Weird behavior with SoftwareSerial and pin choices

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #11755
    Perry
    Participant

    I am creating a heads-up display that displays the arguments being passed to a motor controller (e.g. speed as a 0-127 value) and a bearing (N/S/E/W). For the moment, the bearing is hardcoded, but that should change once I actually get my compass chip.

    If I include a SoftwareSerial connection but don’t actually send any commands to the motor controller, the overlay works perfectly.

    If I send commands to the motor controller via the softwareserial connection, the video goes wonky.

    Here’s the weirdest part: the overlay changes depending on which TX/RX pins I use for the motor controller. Pins 2/3 get me very faint overlay that rolls. Pins 4/5 and 12/13 get me video that’s readable, but glitches to the lower right every few seconds.

    Any advice would be helpful.

    #include <TVout.h>
    #include <fontALL.h>
    #define TXPIN 12
    #define RXPIN 13
    #include "SoftwareSerial.h"
    // Create an instance of the software serial
    // communication object. This represents the
    // interface with the TReX Jr device
    SoftwareSerial pololu(RXPIN, TXPIN);
    
    #define W 136
    #define H 96
    
    TVout tv;
    
    char s[17];
    char h[1];
    void setup()  {
      tv.begin(NTSC, W, H);
      initOverlay();
      tv.select_font(font6x8);
      tv.fill(0);
      pinMode(RXPIN, INPUT);
      pinMode(TXPIN, OUTPUT);
    
      // Begin communicating with the pololu interface
      pololu.begin(19200);
      delay(5);
    }
    
    // Initialize ATMega registers for video overlay capability.
    // Must be called after tv.begin().
    void initOverlay() {
      TCCR1A = 0;
      // Enable timer1.  ICES0 is set to 0 for falling edge detection on input capture pin.
      TCCR1B = _BV(CS10);
    
      // Enable input capture interrupt
      TIMSK1 |= _BV(ICIE1);
    
      // Enable external interrupt INT0 on pin 2 with falling edge.
      EIMSK = _BV(INT0);
      EICRA = _BV(ISC01);
    }
    
    // Required to reset the scan line when the vertical sync occurs
    ISR(INT0_vect) {
      display.scanLine = 0;
    }
    
    void loop() {
    
    int i = 0;
      sprintf(s, "The speed is:%u", i);
      tv.print(0, 0, s);
      sprintf(h,"Heading:%c",'N');
      tv.print(0,85,h);
      SetSpeed(1,true,i);
     
    }
    void SetSpeed(int MotorIndex, boolean Forward, int Speed)
    {
      // Validate motor index
      if(MotorIndex < 0 || MotorIndex > 2)
        return;
    
      // Validate speed
      if(Speed < 0)
        Speed = 0;
      else if(Speed > 127)
        Speed = 127;
    
      // Send the "set" command based on the motor
      // Note that we do not accelerate to the
      // speed, we just instantly set it
      unsigned char SendByte = 0;
      if(MotorIndex == 0)
        SendByte = 0xC2;
      else if(MotorIndex == 1)
        SendByte = 0xCA;
      else if(MotorIndex == 2)
        SendByte = 0xF0;
    
      // If we go backwards, the commands are the same
      // but minus one
      if(!Forward)
        SendByte--;
    
      // Send the set speed command byte
      pololu.write(SendByte);
      pololu.write(SendByte);
      
    
      // Send the speed data byte
      pololu.write(Speed);
    }
    
    
    • This topic was modified 11 months, 3 weeks ago by Perry.
    #11758
    Michael
    Keymaster

    Hi Perry,

    It an be difficult to do serial communication when using the Video Experimenter due to the need to keep the video timing correct. The shield uses pin 2, so that explains why it interferes with the video when using that pin for your motors.

    Can you use hardware serial for the motor controller? Pins 0/1. There is a serial implementation that comes with the TVout library called “pollserial”. It does hardware serial by polling the serial line during the horizontal blanking interval. See example called NTSCserialTerm which implements a serial terminal using pollserial.

    You could write the motor commands with pserial.write().

    Sorry that the need to keep the video working causes problems with serial comms. This is a common problem.

    #11762
    Perry
    Participant

    Thanks for the prompt response. I will look into the hardware serial option.

Viewing 3 posts - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.