[Revenge RVB2601 Creative Application Development] Dynamic loading model super test case: tearing up the Internet celebrity project small TV

cqcqwind

[Revenge RVB2601 Creative Application Development] Dynamic loading model super test case: tearing up the Internet celebrity project small TV [Copy link]

 

After the dynamic loading platform of 2601 was completed, HELLO WORLD, GPIO, U8G2, and DHT11 were tested, and all met expectations. Out of curiosity, I decided to transplant the popular project "Small TV" to test the speed and stability of MBRE in actual scale application development. (B station address https://www.bilibili.com/video/BV1Q44y1u7DL?spm_id_from=333.999.0.0)

• A brief introduction of the Internet celebrity small TV project:

The small TV project is a very interesting project developed on the Internet based on LeX's 8266. It realizes many functions such as NTP timekeeping, network acquisition of weather information, 240x240 TFT LED UI display, etc., and the completion degree is quite high. This project is developed using the Arduino framework. The author Yunmengze Creative (Q: 1036035597) generously provides complete open source hardware and code. Since then, many versions based on this expansion to 32 or modified interface have appeared in Lichuang's open source square. Because the small TV application covers udp, http, JPG decoding, TFT LED driver, TFT SPI graphics library, smooth font, JSON operation, network operation, etc., it almost covers all aspects of common SOC APP development. It is a very comprehensive application. (Here, I also recommend forum friends to understand and refer to this set of codes. Although the code is not perfect, you can learn a lot of knowledge). The following is a picture of the finished small TV. You can see that the interface is quite beautiful.

• Feasibility analysis of second-hand small TV

Because the MBRE dynamic loading system has previously only been used to perform some very small proof-of-principle examples, if the open source small TV project can be transplanted and MBRE is used throughout the entire process, it can be a good way to test the practicality and development convenience of MBRE. So let's do a simple feasibility analysis first:

1) Hardware feasibility:

8266: CPU TensilicaL106 32-bit RISC 160MHZ, FLASH 4M (512KB), user RAM 160KB, direct support for WIFI, with hardware SPI;

RVB2601: CPU RISCV E906 264(?220)Mhz, FLASH 4M(512KB), User RAM 256KB, External W800 WIFI, Hardware SPI

It seems that the 2601 is actually more powerful than the 8266, especially in terms of RAM, which is very important for dynamic loading. So running the small TV on the 2601 is theoretically feasible in terms of hardware.

2) Software feasibility:

The small TV is developed based on the Arduino framework, which is relatively mature (Lex has specially developed it for its series, and adapted the Arduino framework under its IDF framework), providing JSON, TFT SPI library (including smooth fonts), JSON, HTTP, UDP and other commonly used libraries. Many of these libraries are not directly provided on RVB2601, so they cannot be used directly. However, in terms of the underlying SOC, in addition to the large differences in hardware operations, the RVB2601 yoc sdk also basically provides upper-layer communication protocols such as UDP, TCP, HTTP, and C functions for GPIO/SPI interface operations that shield hardware details. Therefore, software porting is feasible.

3) Time feasibility:

Forum members who use CDK to develop RVB2601 should have realized that compiling and burning the machine is a relatively time-consuming process. A slight change of a parameter may lead to a long compilation and burning process; especially some forum members are involved in the modification of component layer code (for example, some forum members have modified NTP-related code), then the time for compiling and burning once should exceed 1 minute. This is very fatal for transplanting small TV-scale applications. Because there will be countless trial operations, iterations and incremental development, considering the end time of the 2601 project, the time budget for this small TV transplant is 2 weeks, and it is definitely too late to develop in the traditional way. Because the early dynamic loading test of MBRE was very smooth in DTH11, U8G2 and other aspects, proving the rapidity of development, so the time feasibility can also be guaranteed.

4) Decision to tear by hand:

Considering the above feasibility analysis, we decided to tear the small TV project by hand. The so-called tearing by hand means forcibly transplanting without reading the code carefully. This method requires a very fast iteration frequency and verification of each technical point, which is particularly suitable for proving the effectiveness of MBRE.

• The transplantation process of the three small TVs

1) First, port the display driver library TFT-ESPI. The display driver is the core of the APP, and all UI displays need to be supported. TFT-ESPI is a well-known open source library under the ARDUINO framework. It is particularly suitable for small application development because of its easy use, exquisite design, low memory usage, and simple API. Compared with LVGL, LVGL is suitable for applications with strong industry characteristics, such as specialized industries, instruments, etc., which require the development of commercial UIs. It is relatively bloated and occupies a large area. TFT-ESPI can be compared to the color screen version of U8G2. It has the lightweight characteristics of U8G2, but provides many rich and practical advanced features such as smooth fonts and SPRITE compared to U8G2. Several transplantation points: a) The hardware-related driver main code is in the TFT_Drivers directory. Please select the appropriate driver code according to your screen. I use an ILI 9341 240x320 TFT screen; b) The processor-related code is in the Processors directory. You can select the TFT_eSPI_Generic type in the early stage of transplantation. c) Make relevant configurations in User_Setup.h and User_Setup_Select.h; After completing the basic transplantation, the screen is lit, and then optimize it. I use a 4-wire serial port screen. After preliminary optimization, the screen clearing operation is about 57ms once, and the FPS is about 16-17.

2) NTP transplantation: The NTP code in the APP is very simple. When transplanting, the NTP code in the 2601 SDK was slightly modified (special thanks to forum friend ylyfxzsx for providing the w800 AT code modification). Because the small TV uses NTP to synchronize time and then keeps time by itself, there is no need to involve the RTC part, so the transplantation is relatively simple;

3) HTTP transplantation: YOC SDK provides HTTP WSESSION operation, which is quite easy to use. Based on this, the HTTP class used by the small TV is adapted. Please note that there is a minefield in the HTTP of YOC SDK. The UA processing is hard-coded, so please pay attention to modify it.

4) JASON processing transplantation: This can be done with cjson. The jason processing in the small TV is too heavy and can be simplified.

5) JPG module transplantation: very smooth, the code basically does not need to be modified, and it works well with TFT ESPI

6) Arduino common API transplantation: The small TV uses a lot of Arduino APIs, such as pinMode, pinWrite, etc. It is too troublesome to modify them one by one, so a simple Arduino common function framework is written.

7) Business logic transplantation: With the above basic functions, the business logic can be verified function by function, such as NTP time synchronization, HTTP acquisition of city code and weather, electronic clock display, date and other text display, astronaut animation display, etc.

8) Dot Matrix Font Library: The small TV uses the smooth font of TFT ESPI. This font file is too large, more than 260K. After the MBRE main program code is written, there is no way to put the font file into FLASH, which requires special processing. The solution I adopted is to use smooth fonts to display the date and temperature information; the real-time weather information is displayed through the dot matrix font library. The 16-dot font of 2100 commonly used Chinese characters is only more than 70K in total, which is easy to put into flash. Here, pay attention to modifying the drawstring code of TFT-ESPI to add support for fixed dot matrix fonts.

• Four transplant results

• 

  

  
  

• Five conclusions

The whole transplantation process took 2 weeks and was very rewarding. Because of the rapid iteration and immediate testing of small changes, the frequency of dynamic downloads was about 50 to 150 times per day. If the traditional development method is used to burn the machine, the compilation and burning time will definitely consume more time. Through the dynamic development of MBRE, the actual number of FLASH burning (i.e. modifying the MBRE main code, embedding font resources, etc.) in 2 weeks did not exceed 30 times, and the main burning problem was to find some YOC bottom-level mines. I will find time to write a summary later and talk about my views on RVB2601 and CDK.

lugl4313820

This is a great project. It seems the author has put a lot of thought into it for two weeks. I admire you!

nmg

For the submission instructions of the final work, please refer to this post

https://bbs.eeworld.com.cn/thread-1201527-1-1.html

soso

Nice interface, looks comfortable.

流行科技

Good, the interface is very good

search

copy