Uh Oh....

A "new fashioned" televisor, using an Arduino to drive the motor and display.

Moderators: Dave Moll, Andrew Davie, Steve Anderson

Re: Uh Oh....

Postby Andrew Davie » Wed Jun 07, 2017 1:21 am

For reference others have had similar problems and solved it using software serial. I seem to have a few pins free (see my Architecture documentation) so I might just try switching and see how I go.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1590
Joined: Wed Jan 24, 2007 4:42 pm
Location: Queensland, Australia

Re: Uh Oh....

Postby Andrew Davie » Wed Jun 07, 2017 10:00 pm

Andrew Davie wrote:For reference others have had similar problems and solved it using software serial. I seem to have a few pins free (see my Architecture documentation) so I might just try switching and see how I go.


Well I did start, but the decision has pretty much been made FOR me...
Code: Select all
Sketch uses 28844 bytes (100%) of program storage space. Maximum is 28672 bytes.


The code required for changing from hardware serial to software takes my program way over the size limit. I've already optimised savagely in my code; I can't see recovering a few hundred bytes, and so this pretty much kills any thoughts of using software serial. So it's back to hardware, which basically means that while testing under USB power there are going to be ugly issues with bogus data "seeming" to come from the Nextion LCD, when in fact they are coming from the PC side. Also, I'm going to have those reprogramming issues - but at least I know I can sort those by press/holding the reset button during upload.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1590
Joined: Wed Jan 24, 2007 4:42 pm
Location: Queensland, Australia

Re: Uh Oh....

Postby Andrew Davie » Thu Jun 08, 2017 12:00 am

I did some work on the serial communications in the Nextion library code. In particular, that code would attempt to read 8 bytes from the serial port, then check to see if the last three bytes were all 0xFF (255) and if so, then check if the first byte was a "variable value" marker and if that was the case then use the middle bytes to get the value of the variable. That means that if things aren't right, you've just lost 8 bytes of data. I changed it so that it first read just one byte and if it wasn't a "variable marker" to exit immediately - this leaves at least 7 bytes still in the serial buffer.

This seems to work. I think what's happening is that somehow this helps the process of "reset" from the PC get through to the monitoring code in the Arduino itself. It's not perfect, but it leaves me being able to develop stuff without having to reach through the wires and press the reset button every upload. In any case, it's much prettier code.

Speaking of "pretty code" it was with complete incredulity that I note that the library code supplied for the Nextion (C code) is full of "goto" statements. I am aghast - I had completely forgotten this language was even capable of such a thing. I never, ever, ever would use a "goto" in a high-level language. Funny how we are conditioned by our training.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1590
Joined: Wed Jan 24, 2007 4:42 pm
Location: Queensland, Australia

Re: Uh Oh....

Postby Andrew Davie » Thu Jun 08, 2017 2:24 am

Here's a picture of the new wiring. Much neater. The new jumper wires are thicker, more robust, and they grip to the breadboard much better. A huge improvement in connection reliability. Even though my problem ("dead Arduinos") proved NOT to be a connection issue, I'm glad I went through this process and re-did the wiring.

newwires.jpg
newwires.jpg (313.15 KiB) Viewed 12092 times
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1590
Joined: Wed Jan 24, 2007 4:42 pm
Location: Queensland, Australia

Re: Uh Oh....

Postby Andrew Davie » Thu Jun 08, 2017 9:29 pm

In a small but significant step, I decided to confirm that the Nextion communications code still operates correctly when there is NO USB connection. To do that, of course, I have to supply power to the Arduino other than through the USB (which has been its only source of power to date). So the long-term plan has been to supply it with the shared 12V supply that the motor is now using, and the (soon to come) LED 12V matrix will be using. Just a one-wire addition, the 12V from the motor board to the VCC on the Arduino. I removed all the debug diagnostics (which go through the USB to a serial terminal) and built a "stand alone" version of the code. Uploaded it (via USB of course) and then pulled out the USB cable. Still functioning - Arduino is definitely getting its power from the 12V.
The supply is slightly over 12V, which puts it just outside the recommended voltage for the uC (but only by 0.6V or so). The uC can supposedly handle up to 20V or so. Anyway, all appears to be working - the first completely stand-alone version of my televisor.
It's been playing Doctor Who in the background for the past 10 minutes or so, seems quite happy. I checked the menu functionality (which was always a bit dodgy probably because of the serial double-usage) and it seemed quite solid. Another small step - no longer needs a laptop to be connected to actually work :)



Edit: Has now been running for over an hour non-stop (Doctor Who on repeat) and still happy. That's the longest, by far, that the televisor has run continuously. I did a touch-test on heat; motor is warm but not hot; say 30C - the TIP122 is cooler, about 20C and the IRL540 is basically cool. The Arduino is putting out a bit of heat; I'd guess 40C. A touch warm, but not super-hot; I can keep my finger on it comfortably. So, all seems good!

Edit: I later measured the temperatures, and you can see the results here!
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1590
Joined: Wed Jan 24, 2007 4:42 pm
Location: Queensland, Australia

Re: Uh Oh....

Postby Andrew Davie » Fri Jun 09, 2017 10:50 pm

One of the things I thought I'd miss greatly when moving to stand-alone power (as opposed to through USB) was the ability to debug stuff via "print" messages to the serial port. But I realised I have this very capable LCD display on the machine! So now I'm throwing debug diagnostics up as text on the screen and don't need that pesky USB serial for debugging at all :)
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1590
Joined: Wed Jan 24, 2007 4:42 pm
Location: Queensland, Australia

Re: Uh Oh....

Postby Klaas Robers » Fri Jun 09, 2017 10:56 pm

Why shouldn't you have a separate board to program the Arduino, then place the chip onto the televisor board? In that way you split up programming and running. I assume the Arduino is in a socket on the PCBs.
User avatar
Klaas Robers
"Gomez!", "Oh Morticia."
 
Posts: 1656
Joined: Wed Jan 24, 2007 8:42 pm
Location: Valkenswaard, the Netherlands

Re: Uh Oh....

Postby Andrew Davie » Fri Jun 09, 2017 11:15 pm

Klaas Robers wrote:Why shouldn't you have a separate board to program the Arduino, then place the chip onto the televisor board? In that way you split up programming and running. I assume the Arduino is in a socket on the PCBs.


I can program the Arduino in-place. It's on a breadboard at the moment. The process you suggest would be program/insert/test. I am currently using program/test. The only advantage I see with what you suggest is not having to hold the reset button when programming - but as I have noted elsewhere that is now a "fixed" problem and I don't even have to do that. So, no advantage to what you suggest... I just program in-place.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1590
Joined: Wed Jan 24, 2007 4:42 pm
Location: Queensland, Australia

Re: Uh Oh....

Postby Steve Anderson » Sat Jun 10, 2017 3:34 pm

For the PIC processors I use I provide a 6-pin header where the programmer plugs in and connects to the micro. No need remove the micro from the board with the attendant risk of bending pins or simply wearing out he socket on the board. A large complex program can take hundreds of iterations in development and having to remove the micro from the board, program it separately, then re-insert it is a time-consuming pain. All recent micros, even humble 8-pin devices, have some form of ICSP (In Circuit Serial Programming).

You don't have to unplug the programmer from the micro either, leave it in-situ and run the program from the PC console. You can set break-points and examine registers/memory to see where things are not going quite as you expected.

In production equipment where the micro is soldered onto the board, ICSP is the only way to update firmware. Although it uses six pins (for the PicKit 3) only three directly connect to the micro, one is the programming clock, one for bi-directional data transfer, and one for the high-voltage programming signal (high? Well, 8-12V). The other three are ground/0V, supply and a 'no connection'. The days of having a separate programming unit and perhaps a UV box are thankfully gone.

The photo below shows the original MkI NBTV/SSTV-625 Up-Converter undergoing programming.

Steve A.
Attachments
Programming Write uC 1.jpg
Programming Write uC 1.jpg (102.04 KiB) Viewed 12074 times
User avatar
Steve Anderson
"Fester! Don't do that to 'Thing'"
 
Posts: 5360
Joined: Fri Mar 30, 2007 10:54 pm
Location: Bangkok, Thailand

Re: Uh Oh....

Postby Klaas Robers » Sat Jun 10, 2017 7:24 pm

I know Steve, I have and use the PICkit 2 now and then. However Andrew has the touch sensitive LCD display circuited in parallel to the USB programming data port. Once that is initialised it continues to send data to the port, which interferes with the programming information. At least that is how I understood what is happening. I fear that the same can also happen with the PIC controllers. I never had such a problem because I program them on a separate small programming socket that plugs into the PICkit 2.
User avatar
Klaas Robers
"Gomez!", "Oh Morticia."
 
Posts: 1656
Joined: Wed Jan 24, 2007 8:42 pm
Location: Valkenswaard, the Netherlands

Re: Uh Oh....

Postby Andrew Davie » Sat Jun 10, 2017 7:33 pm

Klaas Robers wrote:I know Steve, I have and use the PICkit 2 now and then. However Andrew has the touch sensitive LCD display circuited in parallel to the USB programming data port. Once that is initialised it continues to send data to the port, which interferes with the programming information. At least that is how I understood what is happening. I fear that the same can also happen with the PIC controllers. I never had such a problem because I program them on a separate small programming socket that plugs into the PICkit 2.


This is true; but parallel in terms of software, not hardware. I can software-configure the LCD display to any pins.
The LCD does not actively send data - it sits looking at the serial data and responds to certain command sequences. All command sequences consist of a control byte followed by a data packet followed by three FF bytes. So if the PC is sending data over the port and the LCD is listening, it's most likely that it will just do nothing because it doesn't receive a validly formatted command. What used to happen is that the LCD would grab great chunks of the incoming data if it didn't recognise what was happening. There are two basic "fixes". First, I changed the LCD OS/code to only take the minimal amount of data from the serial port. In fact I could probably change it to take NONE, but as is, it's minimal. Secondly, I can optionally hold down the physical reset button on the Arduino when I start a download. When that's done, none of the other stuff connected to the Arduino gets a look-in - it's pure and untainted. So, the worst-case - I have to hold down reset button and it always works. But as it is now, it always works even without the button pressed.

For reference, the Arduino does have the little 6-pin header for programming, but that's for programming the bootloader, which is different to the user program.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1590
Joined: Wed Jan 24, 2007 4:42 pm
Location: Queensland, Australia

Re: Uh Oh....

Postby Steve Anderson » Sat Jun 10, 2017 8:32 pm

Generally I try and leave the two major programming pins free for just that purpose, it depends on how many I/O pins you need, if you can afford this luxury all well and good. If you do need to use them I try and make them outputs where whatever is connected doesn't care, e.g. an LED or two, OK they'll flash during the programming process, no issue. As per Andrews display, if it receives what it thinks is corrupted or non-standard data it simply ignores it. In the MkIII up-converter programming may write rubbish to the RAM, but as soon as the program proper starts it's cleared/overwritten.

If as you say those same pins are used as inputs and the external device continues to send data during the programming sequence, you have make sure to disable the errant source during this process. This can be done with simple jumpers or a switch or if possible tri-stating the external device output during programming eliminating any contention.

Steve A.
User avatar
Steve Anderson
"Fester! Don't do that to 'Thing'"
 
Posts: 5360
Joined: Fri Mar 30, 2007 10:54 pm
Location: Bangkok, Thailand

Previous

Return to Andrew Davie's Arduino Televisor

Who is online

Users browsing this forum: No registered users and 1 guest

cron