Store › Forums › Video Experimenter › Bugs/Problems › Weird behavior with SoftwareSerial and pin choices
- This topic has 3 replies, 3 voices, and was last updated 2 years, 10 months ago by dan-dan.
-
AuthorPosts
-
August 27, 2019 at 2:57 pm #11755PerryParticipant
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 5 years, 4 months ago by Perry.
August 27, 2019 at 10:28 pm #11758MichaelKeymasterHi 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.
August 28, 2019 at 1:20 pm #11762PerryParticipantThanks for the prompt response. I will look into the hardware serial option.
February 3, 2022 at 8:54 am #14480dan-danParticipantДобрый День! Вы решили проблему с передачей данных?
-
AuthorPosts
- You must be logged in to reply to this topic.