FTDI's new Graphics Controller chip - FT800
jmg
Posts: 15,173
In a slight departure from the usual USB bridges, FTDI now have a QFN48 Graphics controller.
Specs claim 256K object memory and 2000 objects, and QVGA to WQVGA.
Targets LCD (as 6+6+6), but I imagine like the SSD1963, it could drive VGA Analog with the right DAC ?
http://www.ftdichip.com/EVE.htm
http://www.ftdichip.com/Corporate/Press/FTDIPR27-ENG.pdf
http://www.ftdichip.com/Corporate/Press/EVE%20Brochure.pdf
Looks cheaper and smaller than the SSD1963, and rather smarter.
Prop 1 + FT800 could give a stepping stone to Prop 2
I guess that depends on the final relative real silicon prices.
Specs claim 256K object memory and 2000 objects, and QVGA to WQVGA.
Targets LCD (as 6+6+6), but I imagine like the SSD1963, it could drive VGA Analog with the right DAC ?
http://www.ftdichip.com/EVE.htm
http://www.ftdichip.com/Corporate/Press/FTDIPR27-ENG.pdf
http://www.ftdichip.com/Corporate/Press/EVE%20Brochure.pdf
Looks cheaper and smaller than the SSD1963, and rather smarter.
Prop 1 + FT800 could give a stepping stone to Prop 2
I guess that depends on the final relative real silicon prices.
Comments
So I guess $5 for 10-100 units
It looks like it only uses Sprites.
Take a Prop1 and slap 256KB of qspi flash on it and dedicate 6 cogs to vga and 2 to audio/touch screen.
and I think you can do all what the EVE does (though at $10)
As Prop2 is only 2-3 months away, for Eve to be this fashionably late is just to bad for her.
Still, the inclusion of touchscreen driver and audio amp makes it very intersting.
Plus, includes some kind of graphics library...
I just happen to have a few hundred 3.5" LCDs that this would be perfect for.
Thanks for the tip, jmg. We'll see if the price is right...
SSD1928 can do jpg decode/encode and perhaps mpeg2 playback though...
Oops, yes, fixed the WVGA typo...
I think I read about some Chinese scopes with the bigger 800 x 480 screens, that had smaller cousins, and they simply pixel-doubled WQVGA to drive 800x480. (but forgot to mention that..)
Slightly sneaky, but it may give a LCD size choice not otherwise available.
I wonder if it would be worth it to parallax to have a driver so that the P1 (with or without FT800) or P2 can be supported by VisualTFT...
inexpensive middleware, but I'm impressed what that visual design software can do with minimal effort, taking burden off of the software programmer.
It can be a good graphic, TFT and audio interface for may Stamp and Propeller applications.
All it need is an SPI (1 propeller cog) object.
Regards
Many thanks info
Kamil
Thanks All,
Fred
http://www.ftdichip.com/Products/Modules/VM800B.html
- but FTDI forgot to be clear about the pixels on each of these displays.
Bezels seem to be back access only mounting ?
Kamil
P.S. this is ideal for propeller chip http://www.mikroe.com/add-on-boards/display/connecteve/
http://www.tigal.com/product/3521
This may be enough for most Unicode languages, but not the Holy Grail.
Still, I consider FTDI to be top-drawer in terms of producing chips. Where would we be without their USB to Serial products?
Clearly you cannot display all 7000 logograms at the same time. The resolution of the connecteve is 480 * 272 pixels. So the best you can do is 8 rows of 15 logograms. A total of 120.
Presumably for many applications the 2000 objects will be enough.
After that you just have to use the connecteve object store as a cache and swap logograms in and out of it as required. Might slow you down a bit but I think it will be fast enough. After all we are only talking about having to load the connecteve with 120 logograms at any given moment maximum.
Meanwhile your 7000 logograms are stored elsewhere anyway, say SD card, and again the MCU main memory is a cache for that.
P.S. Seems that with only 2500 logograms you can cover 98% of modern Chinese. So it looks like the actual amount of swapping you would have to do with the connecteve would be very small.
http://chineseculture.about.com/library/symbol/blccbasics.htm
I am happy to get this straight. The 256K is for the video display and seems it can be used to represent the actual display of text in 32x32 tiles. The text doesn't need to be 2000 characters in length... something like 25 lines by 80 at tops.
Of course you can cover 98% of modern Chinese with 2500, but some one will have a name that you need in the other 2% just because his family is very traditional... It is silly to not do it all as it would be the only way the Chinese would consider it worthwhile.
It isn't the family name, but the given name that might use the other 2%, and with over 1 billion Chinese names people can and do use everything.
So let's say you have 2000 logograms in the object store that gets 90% of the job done. Other logograms will have to be loaded on the fly as needed.
Where do they come from? I would imagine SD would be best at least in the Prop world.
connecteve is not going to get you a 80 by 25 display. In fact you are not going to get that anywhere short of a PC. 80 logograms at 32 pixels wide is 2560 pixels horizontally not counting the spaces between symbols. 25 rows is 800 pixels.
As I said connecteve can only do 8 rows of 15 symbols. Less if you need spacing.
Looks like the Prop II will be able to do better and for less money.
It would likely be too tiny for most Chinese readers and too much content on one screen. Eight rows of 15 symbols would be adequate for a Forth dumb terminal in Chinese as you would have much more of the Forth lexicon represented by single characters, not alphabetical strings.
I have been hoping that the Propeller 2 would do this and maybe it might be more accommodating as the other option is to use a Propeller 1, and this chip.
There is also the keyboard side of looking up characters from a group of 5 or less keycodes in combination and associating that properly with the Unicode designation. But it may be best to just start with a display, and later deal with the input side as a separate development. It has another huge lookup table to search -- the same 7000 characters associated with up to 5 keycodes, and a multiple byte Unicode representation for transmission over RS232 in a series of bytes.
My mind is boggling at the thought of it. Has that ever been done anywhere?
Actually Taiwan has one of the last active Forth Interest Groups that is meeting and doing things. They would likely see the merits of Forth in Chinese.
Is it really that hard to comprehend. Forth has a Dictionary with a search engine that just looks for strings of 8 byte codes to match, and then does what that code desires by working through a list of addresses to other code.
UTF-8 represents Chinese characters in 8-bit byte code.
So with a bit of care in coding, the Forth machine should just be satisfied using both Ascii and Chinese.
+++++++++++++++
The bugaboo is the Unicode Dumb Terminal with Chinese character display and Chinese keyboard input methods.
I know I said I wanted to do 'all 7000 characters', but now I find through searching for 32x32 bitfont availability on the internet that some vendors are offering a 'complete package' of over 100,000 Chinese characters.
In other words, a dumb terminal that can intelligently handle display and input of Chinese text has a huge search load to get items out via the keyboard and converted in to the video display.
It is more than an interesting project. I truly suspect that if the Propeller2 can manage the task of the UTF-8 Chinese Dumb Terminal, it would become a 'defacto standard' throughout the Asian language communities in the world.
For plant processes, that need a control terminal ... GUI is more than a waste of resources, it can be slower, more buggy, and a genuine hazard. While ASCII really works well in such a context, the operators much use A to Z, and in huge portions of the world, A to Z are not what represents the language
so the whole set of commands and the related language are very counter-intuitive to natives of those regions.
It is not only Chinese, Japanese, and Korean. Look at Arabic script, Hebrew, Russian Crylic, Hindi, and many other texts. There are a lot of univeristies and libraries that would love to use a Linux server, and have multiple UTF-8 dumb terminals provide users with services. But many limp alone with using whole PCs in the role of a dumb terminal just because they have to.
Anyway, that's nothing big really is it. Only 12.8MBytes of bit map data. Easily storeable on SD card.
If you can get the input from whatever into a number, the UTF-32 code point. Then you instantly know where in that 12.8MB file the character's bit map is and can read it.
That's going to be a bit slow so I'd go for caching the most commonly used logograms in RAM and pulling other in as needed. A simple hash table can be used to store that cache so look up there is very fast. Save the cache to a different file on SD for quick loading on start up.
You could load all of them to the SDRAM on the proposed Prop II board but start up time will be long I think.
Still, I'm wondering how anyone knows which logogram they want without search visually through a whole catalog of them.
Anyway. I'd want to prototype a terminal like you describe on a Raspberry Pi. Small, cheap, loads of RAM, high res HDMI output for your logogram terminal screen. Has enough RAM that no cache mechanism is required.
Sounds like an interesting challenge. Do you have a set of 32 by 32 logograms to play with?
Then later it would be taking strings of bytes and converting them to UTF-8 for serial transmssion.. another search task.
I haven't located a source of bit-mapped characters for free as of yet. My original thinking was 32x32 format, but data is available for as high as 48x48 format. And I am not married to bit-fonts if an alternative reduces the processing burden.
I think you begin to see, that it might be easy to suddenly have a market for 10,000 boards if this was cost competative. You might even have the blessing of the government of the P.R.C. In Washington, D.C., there is a lobby group call the US=China Trade Council, that might help out via the Chamber of Commerce for an American small business.
"search engine"? This is not google we are talking about. Just a simple look up in memory and/or file. Like finding any ASCII character in a font. Just a bit bigger.
As for generating the video. Again that is just a case of dropping the bit maps into a frame buffer like any other sprite or character display. Might be a bit hard on the Prop depending on what resolution and number of character rows and columns you need.
The Raspi could handle this with ease. A Prop II would have a good go at it I suspect.
I don't get what you mean here. Internally you may be working with your characters as UTF-8 anyway and that is just a string of bytes. If you are working with 16 or even 32 bit wide representations of characters (unicode code points) then streaming them out a UTF-8 is an easy algorithmic conversion, no searching involved.
A dumb terminal in Full Duplex, would just receive and display UTF-8 code and generate characters on the Rx side. While the keyboard would take up to 5 keystrokes and assign an UTF-8 for transmission of the Tx side.
In Full Duplex, the two tasks would ideally be independent. Would one data base of UTF-8 code. keystroke code, and bit-mapped graphic work well? Or would this require two separate databases in an SDcard and alternating access on demand? Or would two independent SDcards linked to different cogs be ideal?
It is a terminal, not just a video display.
Let's say we have 10000 or 100000 32 by 32 bit maps. All we have to do is store them in an array. Each element of the array being the 128 bytes of a logogram. Given a 32 bit unicode character point "cp" it's just a simple array access to get to the bit map you want: In a language like Spin you need something like: For values of "i" from zero to 127. If you are working on a byte array.
If your font is in a file on SD card it's much the same, just open the file and seek to the correct position "c * 128" and read the bytes there.
No searching is required.
If you don't have enough memory and working from SD is too slow put the common and currently used characters in a small memory cache. Again no searching is required to work with that.
Full Duplex or not you have two tasks going on here:
1) User input:
a) Read bytes, scan codes or whatever, from keyboard and turn those into unicode
code points. I imagine there is an algorithmic way to do that else we are into
am unreasonably huge look up table to decode 5 bytes from the keyboard.
b) Transmit those code points down the serial line as UTF-8. Easy.
2) Display:
a) Recive UTF-8 from the serial line.
b) Turn received characters into unicode code points
c) Use code points to look up bit map.
d) Read bit map and dump into correct position on screen.
Tricky part here might be "correct position on screen" if you want something like VT100 control codes to move the cursor position around, clear screen etc.
Seems like a few days work to do it on a PC or Pi or similar board. Given the spec's for all the details above.
Now, where is that logogram collection?
Starting here: http://wenq.org/wqy2/index.cgi?action=browse&id=Home&lang=en I managed to find this wqy-bitmapsong-bdf-1.0.0-RC1.tar.gz which contains the 16 by 16 bit map font in BDF format.
I know you want 32 by 32 but looks like this is a good place to get started.
There are nice because BDF is a simple human readable text file format from which one can extract the bit maps easily.
I'm counting 41295 characters in that font file.
As you can begin to see, for Chinese the data comes in some odd lumps... over 5000 character OUTSIDE the Unicode specification.
The reason for the free download might be that it isn't of much commercial use.
At some point, there seems to be a real possibilty that using Unicode alone would not be enough. I have to take a good look at my prefered keyboard input system for an idea of how many characters it claims to include.. and where they fit into a UTF-8 scheme.
Unicode just might be of use for ANYTHING BUT Asian languages.
I have long suspected that the written Chnese language was a primary tool for keeping farmers in the rice fields. One could join the wealthy classes by merely passing the imperial examinations. But unlike English with 26 letters, one had to be able to write the thousands of characters and use them correctly. No wonder China didn't advance in science. Everyone was too busy trying to read.
The good news is that Chairman Mao was an angry librarian that became a revolutionary in part to reform the written language system ... so Mainland China has the Simplified Character set that just might be far more reasonable to apply UTF-8 to. I was thinking of Tradional Chinese, but I fear that will creep into Ancient Chinese and pretty soon bog down the whole project.
16 x 16 might be pretty good for simple LED signs, but one quickly finds that one has to avoid using more elaborate characters. Parts of a character may include a reduced size of a larger simpler character... reduced to 25% or smaller. It may be easy to know what to write, but it can be very hard to represent in a 4 X 4 grid.
I have actually learned this and it works quite well. If one already touch types the alphabet, one can quickly learn to associate each letter with a Cangjie item. The first two are Yin and Yang as Sun and Moon that represent A and B, the next five are the five elements used in the I-Ching and Chinese medicine and it goes on from there.
Simplified Cangjie would actually require more computer resources to deploy as it needs a GUI and related data bases for partial entries. It works well on a PC, but I really want the smallest system possible.
I am looking for my Cangjie textbook as it has a complete listing of all the codes and Characters represented. Of course that is all on paper... not quite ideal for programing. It seems that Cangjie supports somewhere around 10,000 or more Chinese characters in keycodes.
My Palm Zire 72 has Pleco dictionary that can accept Cangjie input just fine.
I have always maintained that all this internationalization of computers and programs was a huge waste of time. It add enormous complexity to everything. It bloats out the size of documents and the programs, libraries and operating systems that have to deal with unicode. It adds a lot of inconvenience for computer users and is never going to work anyway.
What you are saying is that it does not work even after two decades of development. And we have all been put to great expense and inconvenience for nothing.
I suspect there is huge globs of space in the unicode number space for the Chinese to assign characters to and get them standardised if they can be bothered.
Don't be so cynical about that free download. It's an attempt to build opensource Chinese font's. Just what you want. May not be perfect yet but they invite you to help make it so. They have more that the 16 by 16 bit map font files. Modern vector, scalable formats as well.
Now, I can extract all the bit maps from that file like below. Can you tell me if it's backwards or not?
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *I found another Chinese bit mapped font at 24 pixels wide. Only it looks worse to me:
*** * * ** ** *** ** ** ** ** ** ** * ** ** ** ** ** ** ** ** *** ** ** ** ** ** ** ** ** ** ** ** * ** * ** ** ** * * * * ** *** ** * ** ** * ** * ** *** * ** *** * * ** ** * ** * **The Chinese characters don't look backwards to me... just too low in resolution for clarity.
Early CangJie actually had a graphics engine that built characters from components in the form of a hardware board, but that role has been taken over by the added power of a PC.
It might be feasible to revive the CangJie graphics engine approach as the 26 letters of the alphabet represent the 26 components and they might be better represented with vector graphics.
Nothing easy about Chinese on computers. It is a lot of data. And quite possibly, Chinese held out on conformity with Unicode.. at least too some extent.
I set my sights on UTF-8 unicode because Linux supports it and Linux also supports multiple users sharing a Linux server via dumb terminal. But Chinese might still be a stretch in software development. I was unaware that there was an 'extention' to Unicode for Chinese.
There is an alternative Big5 characters system that has been in operation before Unicode.
Am I getting too deep into the weeds to create a Propeller UTF-8 dumb terminal? I am not sure, it might be easier to set aside Asian languages and provide support for the rest of the world first.
Simiple IDE is having trouble in Linux and it may be hitting the same issues from a different angle. Microsoft created a separte UTF-16 and UTF-32 to meet their needs. It all seems like a significant fork in code.