Teensy 3.2 as HMI display (Editor development)

Status
Not open for further replies.
@FrankB My understanding there is a cap not grounded on the board? Are you going to fix or is it trivial to jumper? I need to order from OSH as this is moving forward.

Carter
 
HI,

yes, there is a GND area some 1/10mm away. Or, maybe, it works without the cap?

The ParallelFlash interface is tested, the lib (compatible to Pauls SerialFlash) is in the works. At the moment, i don't know wether it is faster than serial, or not:)
Display works, touch too, backlight pwm works (use a very low resistor (or an other FET?))

The only thing not tested is the (Parallel-)RAM - i think we don't need it. Maybe! i add it later (...and the software has to be done)
 
I tried to run the jar file under Ubantu 14.04 but java 8 not supported, it does run under windows 7.
 
On thing, maybe you should remove the SD-Slot on the display - this depends on how you solder the board - the Serial Pinheader is very near. Or use some kind of isolation.

Edit: The Board is intended for 2.8'' version of the display...
 
Last edited:
A little description what data we need to transfer to the Teensy (TCD-Editor = Teensy Controlled Display - Editor ...)

1. Several pages will be possible
2. a page contains the following:
  • page ID (unique)
  • background image or CSS style
  • optional title
  • opt. page browser (first/prev/next/last)
  • list of multiple control items
3. a control items contains the following:
  • item ID (unique)
  • (multiple) state images or CSS style (e.g. two images for "button pressed" and "button not pressed")
  • (multiple) dynamic bitmap snippets to allow moved controls like knobs, sliders etc.
  • label text (if not rendered in the image)
  • getter/setter for "value" (value is the data represented by the item)
  • validation for "value" (maxVal/minVal, zero pos, data type)
  • methods to hide/show
  • methods to add/remove
So there will be several steps of loading a new GUI (e.g. one page only):
- at first load the page data (id, image, text, pagebrowser)
- then add the items one by one (id, images, text)
- instanciate and arrange all items (the "sceleton" of the items must be implemented in the Teensy)
- start the "watchdog" (wait for items value changes or item value requests)

The essential will be a value change, which will result in a change on the screen - a switch toggles, a slider moves it's knob, a progressbar moves on etc.)

The communication between the operating Teensy and the TCD will be very lean (example for discussion):

Protocol description:
- "<command>" start/stop - starts or stops the reaction on commands
- "<command> <page ID> <item ID> <new value>" - "set_val pag2 but3 45" will write the value of button 3 to 45, showing page 2
- "<command> <page ID> <item ID> <new value>" - "get_val pag2 but3" will read the value of button 3 on page 2
- "<command> <page ID>" - "set_val pag3" will just change the page
- "<command> <page ID> <item ID>" - "hide pag3 slid3" will hide the Slider slid3 on page 3 (show will do the opposite)

With this little set of commands I believe we may create already good displays!

One question: is the Teensy powerfull enough to render a fast turning arrow by itself? (Drawing routines or small bitmap rotated in real time)?

Let's start to brainstorm ... :cool: ... and we need to define the data structure to be loaded into the Teensy ...
 
Last edited:
A new version of the TCD-Editor is availabe at my Github repository - be aware it's an early alpha version! There are some more steps to walk until some data might be generated and dumped to the Teensy ...
 
@Frank B: the board arrived today, THX! S0o I only have to wait for the display itself (I gave my last one to my son ...)

IMG_2754.jpg
 
The art of soldering...NOT :)

Well, at least all other connections and ParFlash should work. I could'nt test this particular board..

p.s. the 5v in is optional.
 
Last edited:
The art of soldering...NOT :)

Frank - are you using solder wire or paste? I got some paste and it has worked well if you 'properly' blob the pads then center and touch the iron. I've not tried much small stuff yet - but this frees up a hand and makes the mechanical manipulation part easier.
 
I use solder wire. In all the time, i've never managed to order some paste.
Which one are you using ? There are some low-temperature-pastes, right ?
Are they ok ? Can i use an old oven or electrical cooking-plate ?
 
To keep this on topic, which I'm watching - this looks like an interesting project! Frank - can you send me your OSH Eagle drawings? There is a new local guy starting up offering boards at $2.50/sq in - If I had working drawings it might be interesting to send him to see if I get usable products - and give him some paid practice. I think his requirements are the same: https://maker.works/
This is an ALPHA program: (Example: For $7.5 you can get 4 copies of a 3 square inch board. ) :: includes FREE first-class shipping

This is what I got and had good luck with: SRA-Low-Temperature-Lead-Solder-Paste

I use very little very infrequently. The needle was easily clogged - so I plugged the needle with wire and just remove/unscrew the needle tip and squeeze out a needed pile on a sheet of paper. Then scoop it onto the desired pad. Seal up the needle tip and dispose of the paper.

I've used it to put SMD caps on onehorse pins (ESP in development), solder one of your CONNECTOR boards, solder a onehorse 9DOF to the under pads, solder RAW ESP-8266's to adapter boards. For practice I put an ATTINY 85 onto an adapter board - but never tested it.SolderPasted.PNG The picture shows some of Franks connector board and one of the SMD Caps and some 30ga Wire wrap wire in place. I used this Connector board to connect to ALT Serial2 pins and it worked of course to talk to the ESP as the early version was wired to Serial3.

<edit> I posted this elsewhere - I used the paste to fix this USB Flash drive that was kicked pulling up and cracking the PCB traces - the paste spread easily and melted fast.
 
Last edited:
I've done a speedtest and compared the speed of SerialFlash to ParallelFlash.

I loaded a 2.5 MB File to the flash an wrote a short sketch to read that file (F_CPU = 120MHz, GCC 5.3, -O2)

Parallel:
Code:
Read 2572956 Bytes in 628 Milliseconds = 3.907264 Megabyte / Sec

Serial:
Code:
2572956 Bytes in 1531 Milliseconds = 1.602718 Megabyte / Sec

The SerialFlash.h is a bit unoptimized...
 

Attachments

  • parflash_benchmark.ino
    1.3 KB · Views: 87
  • parflash_benchmark_ser.ino
    1.3 KB · Views: 72
Last edited:
I've done a speedtest and compared the speed of SerialFlash to ParallelFlash.
Parallel:
Code:
Read 2572956 Bytes in 628 Milliseconds = 3.907264 Megabyte / Sec

Nope. I did some simple changes.. now 1MB/S more: 4.8 Megabyte / Sec. @ 120MHz.

Edit:
Code:
2572956 Bytes in 450 Milliseconds = 5.452805 Megabyte / Sec
 
Last edited:
A quick question aside - as the development of the editor is frozen a little because the lack of time on my side, I wonder, if someone might know about the tool "PaintCode" für the Mac (for Swift, Objective C or C#) which also allows to generate GUI elements and export them as drawing routines in code or SVG.

Screenshot 2016-04-21 11.39.34.png
 
Last edited:
Oh, that looks good!
But how to display the SVG on a teensy ? (Is there a lib we could try to port..?) Or do you convert it to an other format ?
 
Hm ... it's silent in this thread, so I'm asking myself if this little "project" is worth looking into and adding some more effort, or will it just "dry out" because of the lack of interest?

So my questions are:

- is there an interest in such an own HMI display solution?
- must we write the editor complete by ourselves?
- or may we use (commercial) toosl liek code paint, which will lower the effort a lot?

Perhaps now this will start a more lively discussion ... because I believe we all have a only little time to share, so it would be nice to use this resource wisely ... and not for some hardware or code no one is interested in.
 
I was already wondering about the silence in this thread but I assumed that things were well progressing in the background.

I'm actually under pressure to show a prototype of my current development mid-July, so I decided to go with the itead HMI solution for the moment, but it's a real pain in the ass. Thus I'm really looking forward to having a Teensy based HMI solution.

If using third-party tools like codePaint directly or as a base for an own optimized SVG2Code parser might at least partly prevent from re-inventing the wheel, I'm not against that and if there was an initial financial investment, I'd be happy to contribute. The only problem I see is that the passive GUI design can obviously be parsed from an SVG, but what about interaction like touchable elements which would send parametrable event code back?
 
Currently building an HMI on a Raspi ( to control a teensy with audio board ) using QT. Having stuck my toe in that pond I am finding it quite cold, the process on the Raspi is to just use the .ui file and parse that through a python post processor to generate python code, would something similar work teensy native?
 
The thought was to use the QT ui designer as the front end tool, parse that ( I think the output from QT is XML ), upload the resulting ( code, description file,....?) to the teensy HMI board. Sorry for the way I think ( express myself ), lots getting lost through the language barrier :)

The workflow would be design the HMI in QT Creator, parse the *.ui file, upload result to teensy HMI board.
 
Status
Not open for further replies.
Back
Top