Nextion LCD panel

[Andrew Davie]

But I got the idea that reading an SD-card can be stopped and continued at will, isn't it? I hope that you can read byte by byte. Then it is easiest to have the buffer most of the time filled by 99% with "new" data. Only if the data cannot be found fast enough, due to the internal architecture of the card, you need the buffer.

I do indeed read byte by byte and yes, I have the buffer most of the time filled with 99% new data. But because there is little RAM on the Arduino (about 2.5K, but I can only really afford about 1K for audio/video buffers) and because there are 100ms (or more) delays on reading from the SD card, this means that I sometimes don't have enough data. Currently data is 4 bytes per sample (audio 16 bits plus video 16 bits). With a 512 byte buffer that means at best I have 128 samples which from a 22050Hz stream is roughly 6ms of data. If I hit a 100ms delay from the SD card... that's 1/10th of a second, so 2205 samples.... and I am screwed! It doesn't happen frequently, but it does happen too often. MOST of the time the delta (bytes needing to be read from SD card to fill the buffer) is around 10, but occasionally it jumps to 400 and very occasionally it overflows and I get a video glitch.

By reducing audio/video to 8 bit and doubling the buffer size (to 1024) I will effectively significantly reduce the problem to 25% of what it is now.

As to sound - well, it's either just going to have to glitch, or I am going to have to separate out the audio and sound into different files and handle them differently, perhaps with a larger buffer for the audio. I'll cross that bridge when I come to it!

[Andrew Davie]

Here's the Nextion Instruction Set

[Andrew Davie]

Well a tiny bit of progress on this - I've gone to a stand-alone testbed and managed to get two-way communication with the Nextion. I'm able to send text and have objects on the screen display that text and update. I moved the TX/RX from the dedicated lines to pins 10/11 (per a downloaded sample) and that works. I'm not sure but apparently there could be a clash between hardware TX/RX and programming the Arduino with the USB port. Moving the Nextion to a different pin set allows you to have them both hooked up at the same time. Apparently. Anyway the testbed works so I need to graft it onto my main televisor code. Soon - not for today.

Another issue will be the dreadfully slow communications over serial (9600 baud). I currently have my video "buffer stuffer" running in the main loop, so if I slow this down by including talking to the Nextion, my video is going to go to pieces. I'm going to have to move the "buffer stuffer" to an interrupt somehow, or find a clever way to talk to the Nextion during an interrupt. That's probably going to take me a bit of thinking/reorganisation.

But at least I'm talking to the Nextion, and can make changes to the display. As a preliminary I might just go ahead with leaving things in the main loop and just putting up with the video glitches while I get the basis of the UI working (brightness/contrast/seek/gamma).

[Andrew Davie]

Now successfully "grafted" into my televisor code, so the Nextion is talking to/with my televisor. I switched to the hardware RX/TX pins, and it's working OK. Now that I switched the wires around so TX-->RX and RX-->TX ... duh! But as expected, comms with the Nextion totally kills the video. I'll soldier on - limit talking to the Nextion to an occasional thing and put up with video glitches until I'm more familiar with the device usage. Still, a step forward!

[Andrew Davie]

Now successfully "grafted" into my televisor code, so the Nextion is talking to/with my televisor. I switched to the hardware RX/TX pins, and it's working OK. Now that I switched the wires around so TX-->RX and RX-->TX ... duh! But as expected, comms with the Nextion totally kills the video. I'll soldier on - limit talking to the Nextion to an occasional thing and put up with video glitches until I'm more familiar with the device usage. Still, a step forward!

I successfully moved the "video buffer stuffer" from the main loop to its own interrupt, which meant that the main loop could now be as slow and as complex as it wants. So I hooked up the Nextion handler and put a brightness slider variable in there. Then I hooked up the brightness variable into the playback video interrupt code - and wow - I have a functional touchscreen UI controlling the brightness! This is fantastic, actually - really pleased with just a few minutes' work. Amazing what you can get done when your mind is clear.


youtu.be/gbWetgN9mNA

I really needed three hands to shoot this video, so apologies for the wobblyness.

[Andrew Davie]

I'm fast running out of / have already run out of / RAM.
I'm only using a few hundred bytes (of the 2.5KiB). The culprit is the libraries I'm using - the SD card reader, and more particualrly the Nextion LCD display. These are each using something like 30% - 40% of available RAM. This isn't reasonable, and I'm going to have to either dump the libraries or cull a subset of them. Unfortunately there's some complex code inside and it's all strung together with lots of dependencies.
I know it's a solvable problem, but it's going to take a fair bit of work to fix. Although 2.5KiB is the limit, I start to get unstable behaviour on the Arduino when I get up to about 85% of that (the compiler explicitly warns of instability above this figure). It's probably because dynamic ram is allocated on top of "allocated" RAM, and the dynamic ram requirement is variable and indeterminate. So I have to get RAM usage down - way down. And it's not my fault.

[Andrew Davie]

Well, I finally sorted the Nextion RAM issue. It's been an annoying few days, to say the least. Though the company did help me sort the problem, I went through several Windows installations, and many many Arduino IDE installations to prove there was a problem. I made how-to videos showing exactly what I was doing - and in the process had a "first strike" warning from YouTube for inappropriate content (I have appealed). Just a really frustrating and annoying and unproductive time really. Although the company was very responsive on the forums, I got the feeling I was regarded as a newbie idiot when they started explaining to me what bytes and word alignment was all about. I pulled out my credentials, which shows how annoyed I was. I did clean vanilla installs on multiple OS's and got the same RAM usage every single time. They said they did the same as me and got very low RAM usage. For the same IDE, for the same source code. It just didn't make sense. Only after I officially gave up and said thanks for all the help, one of their staff suggested I delete a couple of files from their library source. I did this and my RAM usage basically magically plummeted. It seems that the Arduino IDE was not culling unreferenced object files, which is a bit of a surprise - and a bug - and hardly the manufacturer's fault. But it brings home the fact to me that when you're testing something you really need to follow the EXACT steps that have been described, not just assume that what you have is close enough. This problem could have been caught days ago but it wasn't - because I always always got high RAM usage, and they always always got low RAM usage. They weren't following my step-by-step, and of course I was. It just turns out they weren't using the same compiler link options (courtesy the IDE). Anyway, nobody's "fault" and I do appreciate their responsive help. They were not obliged to help me in any way. I'm just a bit frustrated at the process.

Here's the current machine running with the Nextion - RAM usage has reduced from 93% to 62% - a huge difference.


youtu.be/95pYw1hGSjA

[Andrew Davie]

"Dear Andrew Davie:

Thank you for submitting your video appeal to YouTube. After further review, we've determined that your video doesn't violate our Community Guidelines. Your video has been reinstated and your account is in good standing.

Sincerely,

— The YouTube Team"