ElectronicsPosted by condemned Wed, April 29, 2015 07:51:32
More progress on the Terminal. This time, I've overhauled the character-set and font system. It now not only handles the traditional G0/G1/G2/G3, GL/GR terminal buffers, but also understands UTF-8 encoded unicode. Oh, and I've added bold rendering...
That's a big 12x16 font...
Here's a similar thing at 6x8...
(note that the camera doesn't do "blinky goodness"justice)
Things get a bit silly when you go smaller than that, but might still be useful...
Things left to do:
per-row font sizing (and per-row double-height/double-width)
prototype board layout
ElectronicsPosted by condemned Sun, March 29, 2015 20:42:19
After a 2+ year hiatus on the tiny terminal emulator, I've picked up the project again! My aims are slightly different this time:
- OLED 128x64 (or possibly 128x32) monochrome screen
- Intended for output only (e.g. no buttons, on-screen keyboard etc.)
- TTL serial input (including auto-bauding)
- 10x4 character display (with large font)
- 32x12 character display (with tiny, barely readable font)
The only major hurdle at the moment is working out how unicode is dealt with. I've been naively assuming that VT200+ is all that's required, however modern linux doesn't seem to talk in G0,G1 pages... some investigation is needed.
Where would a blog post be without a picture?
That's a 12x16 pixel font.
ElectronicsPosted by condemned Thu, January 17, 2013 19:37:11
One of the Batsocks pups got some electronics stuff for Christmas. LEDs, battery boxes, breadboard, protoboard and a soldering iron.
For his first project, we decided on a night-light.
After beeping-out the breadboard to work out which holes were connected, he tested a simple LED circuit before committing to molten solder.
With a front-panel of cardboard and paper, the result is a superb looking (if rather sinister) Enderman
It's not quite what I'd choose for a bedside companion, but then I'm neither 8 nor minecraft
ElectronicsPosted by condemned Tue, August 28, 2012 11:50:52
I've been fiddling with my XMega based Tiny Terminal for some time now, and this birdsnest is where it's got to:
The breadboard holds:
One XMega PDI board
(and power supply via USB).
One 5-way button board.
Two tactile buttons.
One 1.8" TFT colour screen.
One FTDI header (for using with a USB->serial adapter)
One RaspberryPi flying header
One TellyMate Tiny TV output board
Whilst it all works nicely, and is a great way of proving that it all works, it's not very tidy. It'll be nice to move the development onto a prototype PCB that's due any time now
I'm just off to sit under the letterbox.
ElectronicsPosted by condemned Wed, August 08, 2012 14:00:59
I'm still catching up with some posts I should have made a few weeks ago...
A few days before the most recent Oxford Raspberry Jam, I had a parcel arrive in the post from China: A nice 1.8" colour TFT screen. 128 x 160 @ 18bpp.
I ordered it to use whilst developing my XMega based Terminal emulator.
The screen uses the same display controller as Adafruit's 1.8" TFT screen
, so I based my initialisation code on their arduino code - a great way of getting up and running quickly. The only changes I made was to use 'C' (rather than C++) and drop down to use the 12bpp communication mode.
Bingo. Colour Terminal.
The whole screen is redrawn from scratch each time, based on what the terminal's character cell array contains. Each cell holds the following information:
o The character to display
o The attributes (bold, inversed etc.)
o The foreground and background colour
Each row of pixels in the display is then generated, pixel-by-pixel, by looking at which character should be shown, which colours should be used, and refering to flash-based font data.
The output's really quite striking:
That's the tail of coloured 'ls' output, and some 'large text' generated by the alarmingly named utility 'toilet'.
However, to really test the parser's behaviour (and to nicely demonstrate the abilities of the terminal), I found some ANSI art files on the internet... This is a montage of four of them:
I've found that most ANSI art expects 80 columns. The screen is showing the left-hand 32 columns. 80x26 cells is pushing the 8kb of memory that I have to play with.
ElectronicsPosted by condemned Tue, August 07, 2012 15:14:21
For my XMega based Terminal emulator, I'd like to be able to output to several different sorts of LCD (or OLED) screen. So I did a bit of research. Here's a brief summary...
I'm only looking at screens that are mounted on their own 'breakout' PCBs at the moment. It drastically reduces the connection methods I need to consider.
I'm only looking at screens which have 'serial' (SPI / I2C) pins.
(these require far fewer header pins to connect to)
I've picked 6 screens to look at.Adafruit's 1.8" LCD breakout boardAdafruit's 2.2" LCD breakout boardITead's 1.8" LCD breakout boardITead's 2.2" LCD breakout boarda 1.8" LCD breakout board I found on eBayAn available from everywhere
nokia-5110 breakout board.
They all have single-row 2.54mm headers.
I had been hoping to find a common ordering of their pins, however, as you can see:
They're all different.
MOSI == SDA == DN == Data == data (to screen) line
SCLK == SCK == SCL == clock line
RS == D/C == (Data / Command) line
RST == RESET == Rst == Reset line
CS == LCD_CS == SCE == TFT CS == Screen Select line.
Vin == Vcc == Power in. Sometimes 5v, sometimes 3.3v
There's no way that a single pre-routed PCB header would be able to work with all of those variants.
Therefore, to avoid having to create a different PCB for each and every type of LCD screen, I've gone for a patch-panel approach, similar to that seen on Mayhew Labs' Go Between Shield
Here's my solder-jumper patch-panel as seen in Eagle:
Blue horizontal copper lines on the bottom.
Red vertical copper lines on the top.
A matrix of vias and solder-jumper pads allows the bottom (horizontal) lines and top (vertical) lines to be connected as required.
This should mean (in theory!) that one PCB design can be used with any of the above boards, just by putting blobs of solder across the appropriate pads.
After that, it's just software. Which is easy. Right?
ElectronicsPosted by condemned Mon, August 06, 2012 12:56:21
I'm going to try and post a little more frequently here.
I need to shake off my 'only post finished stuff' mindset.
unfinished stuff is just as interesting (possibly more-so - mistakes are useful!)
I've recently been working on an XMega based terminal emulator. The aim is to have something that's useful to plug into an embedded linux box.
I've previously posted on AVRFreaks
and in the Raspberry Pi forums
. These showed black and white output whilst running on a tiny XProtolab board
I went back to the fonts just after posting the above entries and discovered that a 4x6 pixel font actually looked better on-screen that the 5x6 font shown. I think that taller, narrower fonts are easier on the eye: 4x6 font
(the focus is a little off - sorry. 0.96" screens are really
Note that my counting of 4x6 includes spacing, so actually only 3x5 pixels are generally available. It's really not easy designing a font this small. Note the odd way that 'e', 'g' and 's' aren't actually complete. Note also that 'm' and 'w' need to rely on the overall shape of the letter, rather than the detail.
ElectronicsPosted by condemned Mon, July 02, 2012 22:33:50
I've just taken delivery of some XMega128A4U chips.
These are pin-identical to the lovely XMega32A4U chips, only with 128kb flash (up from 32kb) and 8kb SRAM (up from 4kb).
The increase in SRAM is important for me, as it allows me to use a higher resolution bitmap when I'm generating video.
So... I soldered myself a special version of an BreadMate AV XMega PDI board
with one of the 128s...
The 4kb in the X32A4 is enough to handle a black and white bitmap of 160 x 120:
whereas the the 8kb in the '128 will manage 320 x 180 comfortably.
I had to resort to a little subterfuge to get it working though...
Not all components of my toolchain know about the XMega128A4:
The programmer, avrdude, knows about the 128A4
The compiler, avr-gcc, doesn't Fortunately
, XMegas are really impressively orthogonal. With a little care, binaries compiled for one chip will run happily on another chip. Two main things to watch out for:
a) Chips with more than 128kb flash compile slightly differently to those with less.
b) Don't use peripherals that aren't there!
I therefore compiled the XTV bitmap demo
for an XMega128A3
Avrdude was happy to upload this to an XMega128A4
[edit: 11th Nov 2012. Atmel now have an AVR Toolchain for windows
and an AVR Toolchain for Linux
that supports the XMega128A4U]