BRT Community

Thank you for your recommendation. I adapted the suggested lines, both for the input and output file paths, and it worked.

You cannot view this attachment.

It doesn't work from the EAB 4.1.0 window, but it does work from the command line. I should assume that this part of the instruction: -q:v 4
sets the file conversion quality to 4, is that correct?

Thanks again for your follow-up. I sent a download link for the VAN.mp4 video that's having conversion problems to the email address you provided. I'll be waiting for your response.

Best regards and Happy New Year!

I've had some free time lately. I'm sharing the video processing results for version 4.0.1.

You cannot view this attachment.

You cannot view this attachment.

This is the content of the json file.

{
  "eab_version": "4.0",
  "chip_gen": "BT82x",
  "input_name": "VAN.mp4",
  "output_name": "VAN.avi",
  "output_size": 153075816,
  "type": "video",
  "format": "mjpeg",
  "compressed": "no",
  "width": 798,
  "height": 450,
  "pixel_format": "yuvj420p",
  "quality": 4,
  "audio": "yes",
  "playback_frequency": 48000
}
Since version 4.1.0 does not perform the conversion, no file with the JSON extension is generated. These are the processing results it generates.

You cannot view this attachment.

You cannot view this attachment.

Correct video processing with EVE-AB 4.0.1You cannot view this attachment.

Error with identical video file, in EVE-AB 4.1.0You cannot view this attachment.

I've already tried modifying the parameters in different ways to convert the file, but the result is always the same: conversion failed!



I reverted to version 4.0.1, which doesn't have this type of error.

GDSTx library in teensy 4.1 (teensyduino 1.60-beta2) and NHD 5" FT813, Arduino IDE 1.8.19. Loaded from the SDIO reader using SdFat V2.2.3. The memory used is a 256Gb Canvas Go Plus microSD, formatted in exFat. The two png files appear normal

I'm keeping an eye on this new BT822 chip. 

Has memory been increased from 1 Mb to 1 Gb on the new BT822?

I have been a fan of EVE chips for years, who has directed his efforts to thoroughly explore the 23X gameduino library, created by James Bowman. So far it has worked on FT800/FT801, FT81x and BT81x; I ask you so excited that I can barely type on the keyboard... will it be possible to use this new BT822 with the gameduino 23X library?

PD: If the GPS that I have built and improved for several years with an FT813 chip, has been able to handle things that I had been told could not be achieved... I can already imagine what can be achieved with 1 Gb of memory!!!!

https://www.youtube.com/watch?v=ni0_DRU5PAQ

They are improved variants of the first EVE: FT800/FT801, with the ability to play avi/jpg encoded videos and with the possibility of rotating the screen content; such as FT81x/BT81x series.

I have a BT817 from Riverd like that you refer to, so far it has worked very well with the GDSTx library in teensy 4.1.

In order to experiment with that situation that you mention, you will have a guide on how to use your library in the arduino ide environment (preferably 1.8.19, since 2 seems to me to be an unfinished job and with many errors still), wiring, and what extra device is required to be able to use the onboard flash memory that the display has?

What library are you using with your screen?

It seems to me that you should adjust the rotation of the TFT and its dimensions, immediately after the restart of the coprocessor

Thanks for taking some time.

The library for gameduino 23x has the file wiring.h as its axis of operation, within that file the starting of the EVEx chips occurs.

This is the library I've been testing with: GDSTx. You just have to place it in the libraries folder of the arduino IDE.

I uploaded the video examples, as evidence that it is possible to draw arc segments, not to test them; As I said, I have spent several years trying to understand the library and adapt it to be able to use it with teensy 4.1 and especially with its SDIO reader. Over time there have been several versions of the library, which is why I decided to upload the changes to Github to always have a backup. Unfortunately several examples were lost, when the hard drive I was working on failed a couple of years ago; only youtube videos remained.

I apologize for not being able to share the complete examples or the libraries, as I no longer have them.

I share the example for drawing arc segments, which resulted from all those experiments.

That example was only an approximation with simple mathematics, the editor can only handle basic things, more advanced examples can be achieved with relatively few instructions, but with slightly more complex mathematics that must consider that the TFT has the Y axis reference frame on the contrary, we must not forget that the EVEx graphics chip does all the drawing work, leaving the MCU only the calculation part.

MCU: teensy 3.6
TFT: NHD 5" FT813
Library: GDSTx (2023)
https://www.youtube.com/watch?v=LmyN9tgATtc

MCU: Nucleo STM32F767ZI
TFT: Riverdi FT813 5"
https://www.youtube.com/watch?v=Yb60PmJu5S0

MCU: Arduino Due
TFT: 4DSystem FT843 4.3" (FT800)
Library: gameduino 2
https://www.youtube.com/watch?v=FOhaWL84bKU

I've been modifying the library for gameduino 2 for some time with the permission of the good James Bowman, to be able to adapt it to STM32 or teensy 4/4.1 boards; with the idea of ​​being able to apply the full potential of the library with faster MCUs than AVRs. The project is called GDSTx, the repository is on Github.

In a chat with chatGPT, with the idea of ​​fine-tuning some parts of the project I'm working on, I asked him to indicate what the code would be like to draw an arc of variable length, using GDSTx, after an exchange of corrections, this was the result:

#include <GDSTx.h>

long previousMillis = 0;
long intervalo = 250;
int valor=0;

void setup()
{
  GD.begin();
}
void loop()
{
  GD.ClearColorRGB(0x100020);
  GD.Clear();

  GD.SaveContext(); //Guardamos los parámetros de color y transparencia
  GD.Begin(LINE_STRIP);
  GD.ColorRGB(0xFFFFFF); //Color del arco
  int x, y;
  unsigned long currentMillis = millis();       
  if(currentMillis - previousMillis > intervalo)
  {
   previousMillis = currentMillis;         
   valor=GD.random(0,359);
  }
   
  for (int i = 0; i <= valor; i++) {
    x = 400 + 100 * cos(i * PI/180 );
    y = 240 + 100 * sin(i * PI/180 );
    GD.Vertex2f(16*x, 16*y); //Se ajustan las dimensiones en pantalla
  }
  GD.RestoreContext(); //Restauramos los parámetros de color y transparencia

  GD.SaveContext(); //Guardamos los parámetros de color y transparencia
  GD.ColorRGB(0xFFFFFF); //Color del texto
  GD.cmd_text(0, 455, 26, 0, "Coded by chatGPT/FT81xmania"); //Texto del título
  GD.RestoreContext(); //Restauramos los parámetros de color y transparencia

  GD.swap();
}

I have noticed when connecting screens like the FT813, on AVR boards like the MEGA, the 3.3V regulator turns out to be not so efficient, from 5" the power demand by the backlight begins to make the MCU suffer. I have seen that screens like the FT813-5" or the FT813-7" from Riverdi behave erratically and sometimes disconnect the arduino MEGA from the PC. The original library for gameduino 23X is designed to take full advantage of AVR boards, but using selected screens for its low consumption.

The boards that have turned out to be the most stable so far are: teensy 3.6, teensy 4, teensy 4.1, black STM32F407VG, black F411CE, even the bluePill F103CB performed very well. In all of them it is convenient to power the backlight through an independent USB line, if possible, a USB-C adapter can be used, with the idea of ​​being able to use a USB cable of this type

MicroUSB to USB-C


NHD 7" on teensy 4.1


I can test with a teensy 3.2, which fails with a 4.3" FT813 NHD screen, when I connect the backlight to the teensy, I plan to spring a section of a microUSB cable and install a USB-C adapter, with the idea of ​​powering the backlight and teensy 3.2 with a single USB-C cable. As soon as I get the missing parts I share the result, I trust it will work based on the result with the 7" NHD screen.

Cross your fingers

In relation to the library to control screens of the EVEx families, the version I have worked on for some years is this: GDSTx

I chose to center it on teensy 4 and 4.1 MCU, although it can also work with 3.5 and 3.6. With 3.2 it works to a limited extent, since I haven't found a way to use the SdFat library with a reader on the SPI bus. It also works with STM32 boards, setting the proper pins for each board for correct access to the microSD reader, on a secondary SPI bus, the TFT goes on SPI-1.

The screens with which I have been able to test it are:

- FT813: 3.5, 4.3 and 5" NHD
- BT815: 5" Matrix Orbital
- BT817: 5" Riverdi
- FT800: 4.3" FT843 4DSystems

Regarding STM32, these are the boards that I have been able to test: Black F407VG, Black F411CE, Core7XXI (F746), F767 core, bluePill C103, M4-DEMO (F407ZG), M3-DEMO (F103ZG) and F429-DISCO.


MCU: Teensy 4.1@528MHz
TFT: EVE-50G (BT815, 5", Matrix Orbital)