Teensy 3.2 as HMI display (Editor development)

Status
Not open for further replies.

fms1961

Well-known member
So let's start a dedicated project thread here as a fork of the first thread.

... last posts ...

Why not make the editor like platform independent software (à la java) and let the teensy controller load the "true" display lib and do the rendering? Thus, support for new display models wouldn't affect the editor, just the f/w of the teensy controller, depending on the attached display type.

Yes, but this will be done by the editor, so you don't have to play around and look which library the Teensy needs ... it's all handled by the editor.

Great idea, if it works! :cool:


It will, why not? In the first stage, I propose we create a *.ino file which will be compiled and uploaded to the Teensy, later we may integrate this function in the editor.
 
That means that each time the display "content" will be edited, the full "firmware" has to be compiled and uploaded, too. That looks a bit heavy to me.

I imagined a clear separation between the firmware in the teensy's flash and the display/touch macros and content in the separate flash which Frank planned on the PCB. But possibly, your method could save the extra flash memory. The only question is if the Teensy's internal flash will be big enough, especially when a display shall have multiple pages with different hi-res background images.
 
I think the effort to achieve this goal is way too big compared to the small gain. As the act of editing some "GUI" for Arduino/Teensy is part of the project development, there is no need to speed up the process if there is no special need. It's the same process when programming with the Arduino IDE - after compiling, the whole compiled code will be uploaded. You are proposing a process, where the Teensy itself will have to compile the uploaded code and bind it to the existing part - how would that work? I believe, that this is not possible in this way, and if we look, the Nextion itself uploads the whole compiled "firmware" in the display controller. They made some mistakes there, so it's extremely slow - but this is the way we may "feed" the Teensy, I see no other possibility.
 
I don't think that the Nextion editor uploads the whole compiled firmware, since there is an extra firmware update port. I rather think that their Editor generates some hardware independent macro code which is then interpreted and rendered by the firmware at runtime.

When I write this now and here, that does not mean that I think that this procedure is optimal. I just try to consider every possible variant. But I must admit that the idea to separate content and rendering seems still appealing to me. It's a bit like html/css code where just tags are transmitted and the client's browser cares about the rendering.
 
In this case we should implement a HTML renderer and use HTML/CSS to describe the elements. No joke ... But I think, the Teensy will be overloaded with processes like this ... interpreting and rendering? This will be extremly slow ...
 
If there isn't a more efficient language to describe the small element set which we put on such a display and which allows quick rendering at runtime, I pull back my considerations.
If I understood well, you have such a Nextion display. Can't you create something in their editor, export the .hmi and the .tft files and have a look onto these with a text or hex editor? It is perhaps not necessary to re-invent the wheel...

Since I haven't yet received my Nextion, I can only guess that one of both files contains packed resources, and the other the corresponding addresses and some "action script".
 
Last edited:
I found a nice way to send data to the Teensy. We need that to fill the external flash or transfer other huge amounts of data (one can use it to write to the SD-Card, too)
I remembered the old DOS times :)

It's a simple COPY FILE COM6
Blazing fast. Advantage: We don't need to write any software for the PC-Side. Works with any operating-system.

For the teensy-side, i have written a little lib (only two functions) - it's not limited to any special use-case:

Example to trigger the LED with it (to show how it works):
Code:
#include "simpleUpload.h"


void ledOn(void) { digitalWrite(13,1); }  
void ledOff(void) { digitalWrite(13,0); } 


void setup() {
   pinMode(13, OUTPUT);
   ledOn();
   simpleUploadListen(1,ledOn);
   simpleUploadListen(2,ledOff);
}


void loop() {
  simpleUpload();
}

echo ^A > COM3
to switch the LED on,
echo ^B > COM3
to switch it off.


To show, that it can handle large files too, i wrote this short test-sketch which displays a RAW-Picture on the ILI:
Code:
#include "simpleUpload.h"
#include "tower.h"
#include "SPI.h"
#include "ILI9341_t3.h"


// Normal Connections
//#define TFT_DC       9
//#define TFT_CS      10
//#define TFT_RST    255  // 255 = unused, connect to 3.3V
//#define TFT_MOSI    11
//#define TFT_SCLK    13
//#define TFT_MISO    12


// Alternate Connections with Teensy Audio Shield
//#define TFT_DC      20
//#define TFT_CS      21
//#define TFT_RST    255  // 255 = unused, connect to 3.3V
//#define TFT_MOSI     7
//#define TFT_SCLK    14
//#define TFT_MISO    12


ILI9341_t3 tft = ILI9341_t3(TFT_CS, TFT_DC, TFT_RST, TFT_MOSI, TFT_SCLK, TFT_MISO);
  uint16_t line[321];
  
void picture(void) {
  int m = millis();
  int x = 0;
  int y = 0;
  int a; 
    tft.fillScreen(ILI9341_RED);  
    for (;;) {   
     a = Serial.available();  
     if (a > 63) { 
       do {     
          line[x] = (Serial.read()<<8) | Serial.read();    
          x++;          
          if (x > 319) {      
            x=0;                              
            tft.writeRect(0,y,320,1,line);            
            y++;
           if (y > 239) return;
          }        
          a = a -2;
       } while (a);
       m = millis(); 
     } else {        
       if (millis()-m > 1500) return;
       yield();
    }
  }
}


void setup() {
   initTower();
   tft.begin();
   tft.setRotation(3);
   tft.fillScreen(ILI9341_BLACK);   
   simpleUploadListen(1,picture);
}


void loop() {
  simpleUpload(true);
}

I did'nt measure it, but i have a feeling that 150KB for a fullscreen-picture are transmitted in far less than a second. INCLUDING the SPI-transfer to the display.

Github link follows.

i upload the examples tomorrow.
Edit:
https://github.com/FrankBoesing/simpleUpload


 
Last edited:
In this case we should implement a HTML renderer and use HTML/CSS to describe the elements. No joke ..

???? argh... i this case, i'm out... :)

No, why not use commands a la 'display image #0 at postion x,y' or "fillrect" or "lineto" ? The nextions does not more than this. (i think it has an additional record in memory, which tells him coordinated and sizes of the resources to display whole screens)

And yes, with "fixed" firmware on the teensy.
 
Last edited:
In the first stage, I propose we create a *.ino file which will be compiled and uploaded to the Teensy, later we may integrate this function in the editor.

Sounds not bad. We could use a makefile to build it.
But then we have to do two uploads:
- one to the teensy
- one to the external memory (flash)

..which is a problem, because the the teensy must already run a program to be able to write to the flash.
That's why i prefer a fixed firmware.
(of course it can be another version for other displays..!)

The Teensy has not enough memory for the resources. It can hold one single picture @ 320*240*16
Even the next Teensy 4 or 3.xx does not have enough memory. So we need to use an external chip.
 
Last edited:
Sounds not bad. We could use a makefile to build it.
But then we have to do two uploads:
- one to the teensy
- one to the external memory (flash)
Let's do it step by step ...

At first I'm developing the editor's GUI - after some testing, I chose JavaFX as GUI - because its useable as standalone UI and as Web- and iOS/Android UI as well. Sounds promising. And the JavaFX Scene Builder is a lot more comfortable to use than all Swing based Designers I know. And the UI description is written in a XML format, so changes could be entered manually as well - and will be re-interpreted by the Scene Builder. Its nearly as comfortable as in the glorious Delphi days ... :cool:

When there is something to test, you'll find it on Github (I will press the "buzzer" though)
 
Checking in to see it this is still in the works? Frank have you got your OSHPARK boards? Let me know if they work and I will get 3 headed my way :)
 
Checking in to see it this is still in the works? Frank have you got your OSHPARK boards? Let me know if they work and I will get 3 headed my way :)

I got the info from OSH that they were shipped yesterday. To Germany, add one more week, minimum..
 
...But i have the transfer-utility for the external (not serial ;)) flash ready.
 
Last edited:
Wow.. can't await a preview :)
maybe - (i don't know if i can find the needed components in my chaos) i solder a flash to an adapterboard - then i can start& test programming the flash/ram library this weekend.
 
Last edited:
Well, a first peak ... written in Java with JavaFX as GUI. I love it more than Swing, because of the very easy to use GUI functions.

Screenshot 2016-03-25 15.32.35.png

For the Teensy, there will be a background plane with all static data and dynamic items with a specific behavior which will be drawn dynamically (like pointers, knob noses, button states etc.)

For the moment I will try to complete the (basic) editor with possibilites to load/save a stage (also multilayered), to integrate the bitmaps in the code and to provide a property panel to define the item as we like. There is some work to do ...

And we must accelerate a little - others won't sleep as well ... look here: Cleo - the smart display for Arduino

Edit: a Github link will follow as soon as a little more functionality is testable ...

- Manfred
 
Last edited:
Well, a first peak ... written in Java with JavaFX as GUI. I love it more than Swing, because of the very easy to use GUI functions.

View attachment 6842

For the Teensy, there will be a background plane with all static data and dynamic items with a specific behavior which will be drawn dynamically (like pointers, knob noses, button states etc.)

For the moment I will try to complete the (basic) editor with possibilites to load/save a stage (also multilayered), to integrate the bitmaps in the code and to provide a property panel to define the item as we like. There is some work to do ...

And we must accelerate a little - others won't sleep as well ... look here: Cleo - the smart display for Arduino

Edit: a Github link will follow as soon as a little more functionality is testable ...

- Manfred

That Screenshot looks really good !
Let me do the flash interface.. when it is done, we should talk about programming the teensy-side ...
Any thoughts regarding the ram ? I'm not sure anymore wether it it would be useful or not..
 
The Boards arrived.

At leastt he display and backlight works - i havn't tested the other components so far... (tomorrow).

Some Pictures:

20160330_165342kl.jpg
20160330_165354kl.jpg
 
The Boards arrived.

At leastt he display and backlight works - i havn't tested the other components so far... (tomorrow).

Some Pictures:

View attachment 6883
View attachment 6884

Edit: A lower resistor-value for the backlight works much better, 10 OHM is too high. I tried 2.8OHM, which is better but still too much. I don't have lower values in 0603 on stock.. perhaps i try a wire this evening.. the FET has some resistance, and the display has a resistor on board, too.
Then, here is a minor issue with C3, it's somehow not connected to gnd (but this survied the check in Eagle?) But this is no Problem!
 
Last edited:
Ha ! ParallelFlash works :)
Code:
Read Chip Identification:   JEDEC ID:     EF 60 18

   Part Number: W25Q128FV
   Memory Size:  16777216 bytes
   Block Size:   65536 bytes
 

 Reading Chip...
 

 Writing 32 signatures
 

 Double Checking All Signatures:
   all 8192 signatures read ok
 

 Checking Signature Pairs
   all 4095 signature pairs read ok

 

 Checking Read-While-Write (Program Suspend)
   write 256 bytes at 1280

   write time was 405 microseconds.

   read-while-writing: 00 00 00 00 15 F5 95 4B 
   test passed, good read while writing
 

 Checking Read-While-Erase (Erase Suspend)

   erase time was 204215 microseconds.
   erase correctly erased 65536 bytes
   read-while-erasing: 00 00 00 00 15 F5 95 4B 

   test passed, good read while erasing

 

 All Tests Passed  :-)
 

 Test data was written to your chip.  You must run
 EraseEverything before using this chip for files.

JEDEC ID: EF 60 18 ("60" means QPI Mode)
 
Status
Not open for further replies.
Back
Top