All Projects β†’ RudolphRiedel β†’ FT800-FT813

RudolphRiedel / FT800-FT813

Licence: MIT license
Multi-Platform C code Library for EVE graphics controllers from FTDI / Bridgetek (FT810, FT811, FT812, FT813, BT815, BT816, BT817, BT818)

Programming Languages

c
50402 projects - #5 most used programming language
C++
36643 projects - #6 most used programming language

Projects that are alternatives of or similar to FT800-FT813

Platformio Core
PlatformIO is a professional collaborative platform for embedded development πŸ‘½ A place where Developers and Teams have true Freedom! No more vendor lock-in!
Stars: ✭ 5,539 (+6823.75%)
Mutual labels:  avr, esp32, risc-v
forth-ft800
Forth bindings for the FTDI FT800/Gameduino2
Stars: ✭ 20 (-75%)
Mutual labels:  ft81x, ft813, bt81x
Blog
A set of various projects based on ESP8266, ESP32, ATtiny13, ATtiny85, ATtiny2313, ATmega8, ATmega328, ATmega32, STM32 and more.
Stars: ✭ 198 (+147.5%)
Mutual labels:  avr, esp32, stm32
MySQL MariaDB Generic
This MySQL_MariaDB_Generic library helps you connect your boards directly to a MySQL / MariaDB server, either local or cloud-based, so that you can store / retrieve data to / from the server. Supported boards are ESP8266/ESP32, WT32_ETH01 (ESP32 + LAN8720A), nRF52, SAMD21/SAMD51, STM32F/L/H/G/WB/MP1, Teensy, SAM DUE, Mega, RP2040-based boards, P…
Stars: ✭ 35 (-56.25%)
Mutual labels:  esp32, stm32, rp2040
CorePartition
Universal Cooperative Multithread Lib with real time Scheduler that was designed to work, virtually, into any modern micro controller or Microchip and, also, for user space applications for modern OS (Mac, Linux, Windows) or on FreeRTOS as well. Supports C and C++
Stars: ✭ 18 (-77.5%)
Mutual labels:  avr, risc-v
EthernetWebServer SSL
Simple TLS/SSL Ethernet WebServer, HTTP Client and WebSocket Client library for for AVR, Portenta_H7, Teensy, SAM DUE, SAMD21, SAMD51, STM32F/L/H/G/WB/MP1, nRF52 and RASPBERRY_PI_PICO boards using Ethernet shields W5100, W5200, W5500, ENC28J60 or Teensy 4.1 NativeEthernet/QNEthernet. It now supports Ethernet TLS/SSL Client. The library supports …
Stars: ✭ 40 (-50%)
Mutual labels:  stm32, rp2040
WiFiNINA Generic
Enables WiFiNINA network connection (local and Internet) for SAM DUE, SAMD21, SAMD51, Teensy, AVR Mega, STM32, RP2040-based boards, etc. in addition to Arduino MKR WiFi 1010, Arduino MKR VIDOR 4000, Arduino UNO WiFi Rev.2 , Nano 33 IoT, Nano_RP2040_Connect. Now with fix of severe limitation to permit sending much larger data than total 4K
Stars: ✭ 32 (-60%)
Mutual labels:  stm32, rp2040
stm32 i2c to usb hid multitouch
i2c to usb hid multi touch with stm32
Stars: ✭ 55 (-31.25%)
Mutual labels:  touch, stm32
Xpcc
DEPRECATED, use our successor library https://modm.io instead
Stars: ✭ 177 (+121.25%)
Mutual labels:  avr, stm32
EByte LoRa E22 Series Library
Arduino LoRa EBYTE E22 device library complete and tested with Arduino, esp8266, esp32, STM32 and Raspberry Pi Pico (rp2040 boards).. sx1262/sx1268
Stars: ✭ 67 (-16.25%)
Mutual labels:  stm32, rp2040
UPnP Generic
A simple library that implements port mappings to router using UPnP SSDP for Arduino boards, running on nRF52, SAMD21/SAMD51, STM32F/L/H/G/WB/MP1, Teensy, RP2040-based boards, WT32_ETH01, Portenta_H7, etc. besides ESP8266/ESP32, using ESP WiFi, WiFiNINA, Ethernet W5x00, ESP8266/ESP32 AT-command WiFi, Portenta_H7 Murata WiFi or Vision-shield Ethe…
Stars: ✭ 14 (-82.5%)
Mutual labels:  stm32, rp2040
Piconomix Fwlib
open source bare-metal C firmware and documentation for microcontrollers
Stars: ✭ 226 (+182.5%)
Mutual labels:  avr, stm32
Logic Analyzer
Logic Analyzer, for Arduino, AVR, ESP8266 and STM32 with a very nice working processing interface, you could run it also on any Android device.
Stars: ✭ 203 (+153.75%)
Mutual labels:  avr, stm32
FASTUSBasp
This is the fast avr programmer for AVR MCUs based on cheap stm32f103c8t6 board with usb-to-serial support.
Stars: ✭ 78 (-2.5%)
Mutual labels:  avr, stm32
Open-SAE-J1939
SAE J1939 protocol free to use for embedded systems or PC with CAN-bus
Stars: ✭ 120 (+50%)
Mutual labels:  avr, stm32
pikascript
Ultralightweight Python engine that can run with 4KB of RAM and 32KB of Flash (such as STM32G030C8 and STM32F103C8), and is very easy to deploy and expand.
Stars: ✭ 855 (+968.75%)
Mutual labels:  esp32, stm32
Modbus-STM32-HAL-FreeRTOS
Modbus TCP and RTU, Master and Slave for STM32 using Cube HAL and FreeRTOS
Stars: ✭ 272 (+240%)
Mutual labels:  stm32, dma
Awesome Cpus
All CPU and MCU documentation in one place
Stars: ✭ 1,602 (+1902.5%)
Mutual labels:  avr, risc-v
Marlin
Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. | Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
Stars: ✭ 12,217 (+15171.25%)
Mutual labels:  avr, esp32
rpi
Microcontroller projects (RPi, Arduino, ATTiny85, ESP, Pico, STM8/32)
Stars: ✭ 76 (-5%)
Mutual labels:  stm32, rp2040

EVE2 / EVE3 / EVE4 code library

This is a code library for EVE2/EVE3/EVE4 graphics controller ICs from FTDI/Bridgetek:

http://www.ftdichip.com/EVE.htm
http://brtchip.com/eve/
http://brtchip.com/ft81x/
https://brtchip.com/bt81x/

It contains code for and has been used with various micro-controllers and displays.

Controllers

I have used it so far with:

  • 8-Bit AVR, specifically the 90CAN series
  • Arduino: Uno, mini-pro, ESP8266, ESP32 (DMA), Metro-M4 (DMA), STM32 Nucleo_F446RE (DMA)
  • Renesas F1L RH850
  • Infineon Aurix TC222
  • ATSAMC21E18A (DMA)
  • ATSAME51J19A (DMA)
  • ESP32 (DMA)
  • RP2040 (DMA) - Raspberry Pi Pico
  • S32K144 (DMA)

I have reports of successfully using it with:

  • ATSAMV70
  • ATSAMD20
  • ATSAME4
  • MSP430
  • MSP432
  • some PICs
  • ATxmega128A1

Displays

The TFTs tested so far:

This is version 5

This is version 5 of this code library and there are a couple of changes from V4.

First of all, support for FT80x is gone. The main reason is that this allowed a nice speed improvement modification that only works with FT81x and beyond. Then there is a hard break from FT80x to FT81x with ony 256k of memory in FT80x but 1MB in FT81x. The memory map is different and all the registers are located elsewhere. FT810, FT811, FT812, FT813, BT815, BT816, BT817 and BT818 can use the exact same code as long none of the new features of BT81x are used - and there are plenty of modules with these available to choose from

As a side effect all commands are automatically started now.

Second is that there are two sets of display-list building command functions now: EVE_cmd_xxx() and EVE_cmd_xxx_burst(). The EVE_cmd_xxx_burst() functions are optimized for speed, these are pure data transfer functions and do not even check anymore if burst mode is active.

Structure

This library currently has nine files that I hope are named to make clear what these do:

  • EVE.h - this has all defines for FT81x / BT81x itself, so here are options, registers, commands and macros defined
  • EVE_commands.c - this has all the API functions that are to be called from an application
  • EVE_commands.h - this contains the prototypes for the functions in EVE_commands.c
  • EVE_config.h - this has all the parameters for the numerous supported display modules, here is definded which set of parameters is to be used
  • EVE_target.c - this has non-portable specific code for a number of supported controllers, mostly to support DMA
  • EVE_target.h - this has non-portable pin defines and code as "static inline" functions for all supported controllers
  • EVE_target.cpp - this is for Arduino C++ targets
  • EVE_cpp_wrapper.cpp - this is for Arduino C++ targets
  • EVE_cpp_wrapper.h - this is for Arduino C++ targets

Examples

Generate a basic display list and tell EVE to use it:

EVE_cmd_dl(CMD_DLSTART); // tells EVE to start a new display-list
EVE_cmd_dl(DL_CLEAR_RGB | WHITE); // sets the background color
EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
EVE_color_rgb(BLACK);
EVE_cmd_text(5, 15, 28, 0, "Hello there!");
EVE_cmd_dl(DL_DISPLAY); // put in the display list to mark its end
EVE_cmd_dl(CMD_SWAP); // tell EVE to use the new display list
while (EVE_busy());

Note, these commands are executed one by one, for each command chip-select is pulled low, a three byte address is send, the data for the command and its parameters is send and then chip-select is pulled high again which also makes EVE execute the command.

But there is a way to speed things up, we can get away with only sending the address once:

EVE_start_cmd_burst();
EVE_cmd_dl_burst(CMD_DLSTART);
EVE_cmd_dl_burst(DL_CLEAR_RGB | WHITE);
EVE_cmd_dl_burst(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
EVE_color_rgb_burst(BLACK);
EVE_cmd_text_burst(5, 15, 28, 0, "Hello there!");
EVE_cmd_dl_burst(DL_DISPLAY);
EVE_cmd_dl_burst(CMD_SWAP);
EVE_end_cmd_burst();
while (EVE_busy());

This does the same as the first example but faster. The preceding EVE_start_cmd_burst() either sets chip-select to low and sends out the three byte address.
Or if DMA is available for the target you are compiling for with support code in EVE_target.c / EVE_target.cpp and EVE_target.h, it writes the address to EVE_dma_buffer and sets EVE_dma_buffer_index to 1.

Note the trailing "_burst" in the following functions, these are special versions of these commands that can only be used within an EVE_start_cmd_burst()/EVE_end_cmd_bust() pair. These functions are optimized to push out data and nothing else.

The final EVE_end_cmd_burst() either pulls back the chip-select to high.
Or if we have DMA it calls EVE_start_dma_transfer() to start pushing out the buffer in the background.

As we have 7 commands for EVE in these simple examples, the second one has the address overhead removed from six commands and therefore needs to transfer 18 bytes less over SPI.
So even with a small 8-bit controller that does not support DMA this is a usefull optimization for building display lists.

Using DMA has one caveat: we need to limit the transfer to <4k as we are writing to the FIFO of EVEs command co-processor. This is usually not an issue though as we can shorten the display list generation with previously generated snippets that we attach to the current list with CMD_APPEND. And when we use widgets like CMD_BUTTON or CMD_CLOCK the generated display list grows by a larger amount than what we need to put into the command-FIFO so we likely reach the 8k limit of the display-list before we hit the 4k limit of the command-FIFO. It is possible to use two or more DMA transfers to the FIFO to build a single display list, either to get around the 4k limit of the FIFO or in order to distribute the workload better of the time necessary between two display renewals.

You could for example do this, spread over three consecutive calls:

EVE_start_cmd_burst();
EVE_cmd_dl_burst(CMD_DLSTART);
EVE_cmd_dl_burst(DL_CLEAR_RGB | WHITE);
EVE_end_cmd_burst();
EVE_start_cmd_burst();
EVE_cmd_dl_burst(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
EVE_color_rgb_burst(BLACK);
EVE_end_cmd_burst();
EVE_start_cmd_burst();
EVE_cmd_text_burst(5, 15, 28, 0, "Hello there!");
EVE_cmd_dl_burst(DL_DISPLAY);
EVE_cmd_dl_burst(CMD_SWAP);
EVE_end_cmd_burst();

But you need to check with EVE_busy() before each of these blocks. Maybe similar like this never compiled pseudo-code:

thread_1ms_update_display() { static uint8_t state = 0; static uint8_t count = 0;

count++;

if(EVE_busy() == E_OK)
{
    switch(state)
    {
        case 0:
            update_first();
            state = 1;
            break;
        case 1:
            update_second();
            state = 2;
            break;
        case 2:
            if(counter > 19)
            {
                update_last_swap_list();
                count = 0;
                state = 0;
            }
            break;
    }
}

}

Remarks

The examples in the "example_projects" drawer are for use with AtmelStudio7. For Arduino I am using PlatformIO with Visual Studio Code.

The platform the code is compiled for is automatically detected thru compiler flags in EVE_target.h.

The desired TFT is selected by adding a define for it to the build-enviroment, e.g. -DEVE_EVE3_50G There is a list of available options at the start of EVE_config.h sorted by chipset.

  • Provide the pins used for Chip-Select and Power-Down in EVE_target.h for the target configuration you are using

When compiling for AVR you need to provide the clock it is running at in order to make the _delay_ms() calls used to initialize the TFT work with the intended timing. For other plattforms you need to provide a DELAY_MS(ms) function that works at least between 1ms and 56ms and is not performing these delays shorter than requested. The DELAY_MS(ms) is only used during initialization of the FT8xx/BT8xx. See EVE_target.h for examples.

In Addition you need to initialize the pins used for Chip-Select and Power-Down in your hardware correctly to output. Plus setup the SPI accordingly, mode-0, 8-bit, MSB-first, not more than 11MHz for the init. A couple of targets already have a function EVE_init_spi() in EVE_target.c.

A word of "warning", you have to take a little care yourself to for example not send more than 4kB at once to the command co-processor or to not generate display lists that are longer than 8kB. My library does not check and re-check the command-FIFO on every step. This is optimized for speed, so the training wheels are off.

Post questions here

Originally the project went public in the German mikrocontroller.net forum, the thread contains some insight: https://www.mikrocontroller.net/topic/395608

Feel free to add to the discussion with questions or remarks.

New: Github has a discussions feature as well: https://github.com/RudolphRiedel/FT800-FT813/discussions

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].