NanoNotes and electronic dictionaries
paul at boddie.org.uk
Sat Aug 24 15:39:40 EDT 2013
On Saturday 24. August 2013 00.41.13 Werner Almesberger wrote:
> Paul Boddie wrote:
> > I imagine that one significantly different thing is the keyboard.
> I'd consider the keyboard the most difficult component. My
> hardware difficulty ranking would be, from hardest to easiest:
> 1) keyboard
> 2) case
> 3) WLAN
> 4) LCD
> 5) battery
> 6) audio
> 7) CPU and all the rest
It's perhaps a wake-up call that a lot of open hardware sits at number 7 on
that list, really.
> The ideal keyboard would not only work and "feel right" but it would
> also allow for relatively easy reconfiguration. E.g., by accepting
> keycaps or similar that can be manufactured or imprinted with a
> small-tech approach (CNC mill, 3D printer, laser cutter, etc.)
> suitable for low-volume customization.
When buying a nice little gadget that I will be interfacing to the Ben, I
found some interesting parts intended for arcade cabinets that had
interchangeable key or button caps:
None of the actual switches for which these things are suitable would be
appropriate for a small device, but I thought it was interesting to see such
things for sale. I had hoped that some of the smaller switches would also
permit customisation in this way, but I imagine that this is where "bespoke
solutions" companies make their money.
> Note that there are quite unusual approaches that work well. E.g.,
> the OQO 01/01+ had a keyboard with small round buttons under a
> plastic film. Unlike the Sinclair ZX80/81, which used a somewhat
> similar approach, with painful results, the OQO keys had very clear
> tactile feedback.
What surprised me when I started looking was how much membrane technologies
are used and how they have developed.
I had another look at the construction of the Ben, without actually taking
mine apart, and found the following images on the wiki:
Maybe you know more about this, but it seems that the first image shows the
dome switches being placed over the appropriate places on the circuit board,
with the second image showing the result and the actual keyboard assembly that
positions the keycaps above the switches. I couldn't find very much
information about the nature of the dome switches, but I imagine that they're
somewhat like that "carbonized rubber button" mentioned on the "USB BOOT mode"
page [*] but with a certain amount of tactile resistance to provide a "click"
when a key is pressed.
Looking around on the Internet and also taking things to bits, it looks like a
lot of devices settle for silicone rubber keypads/keymats with all the keys
provided on the same silicone rubber moulding and with the domes being
provided as part of the moulding. Remote controls for televisions and other
consumer electronics devices as well as home telephones seem to use such
solutions ubiquitously. An interesting site with some technical details is
Meanwhile, here's what the OpenPandora device uses:
I get the feeling that for those who work with this stuff, "everybody" knows
all of this, but it is impenetrable for the rest of us, especially without any
knowledge of the terminology.
> > Looking at screens, it seems pretty difficult to get one the same size as
> > the Ben's.
> Maybe not: go to http://www.ampire.com.tw then click on "TFT" in the
> side bar. The AM320480B looks quite reasonable for the Ben form
> factor: module size 87 x 58 mm, 480 x 320 pixels, 3.5" diagonal, 164
> dpi, 3:2 aspect ratio. This seems to be very similar to the iPhone 1
> and 3 display, so there ought to be a gazillion more.
> For comparison, the Ben's display: 70 x 51 mm, 320 x 240 pixels,
> 3.0" diagonal, 133 dpi, 4:3 aspect ratio.
http://en.qi-hardware.com/wiki/LCD says 3.0" (60mm x 45 mm), but I suppose it
is closer to 3.1".
> They're probably not too hard to source in the Chinese market.
> There are also some EU distributors that list it. Fun feature: the
> controller has its own frame buffer, so the CPU could stop screen
> refreshes when there are no changes and thus have more memory
> bandwidth available for other things.
I will admit to being lazy again and confess that I just looked at a local
distributor. I don't think it is too unusual for smaller displays to have
their own framebuffer: I have one of those colour LCD Arduino shields whose
display controller maintains its own framebuffer which is accessed by telling
the controller over SPI to update a window on the display using data that is
then sent as one long sequence of values by the Arduino.
Even the fairly low resolution involved when multiplied by the pixel depth
would demand a larger framebuffer than the Arduino's microcontroller could
provide, so we end up with the Arduino communicating with something that is
probably more powerful (an ARM7-based controller, I think). Another
interesting feature is support for vertical scrolling, suggesting that the
controller really was developed for mobile phones of the time with limited CPU
and RAM resources needing a colour display and smoothly scrolling menus.
Anyway, a quick search locally produces something like these:
For some odd reason, the "module dimensions" of these things seem to exceed
100mm in width, even though the module doesn't look that much larger than the
panel in the pictures or diagrams, but the interesting thing about the
datasheets is the way they have a dump of code in the appendix for
"initialization for reference".
> Data sheet of the "A" version of that display:
> The controller (RM68040) appears to be the same as the Ilitek
> ILI9481, with this data sheet:
> > What is interesting about the Ben is that the screen only takes up 75%
> > or so of the available space, which then makes one wonder whether the
> > case could accommodate a larger panel anyway.
> Yes, there's a lot of unused space there. Just about as much as the
> above larger display would fill. This is what a scan of the Ben's
> display frame looks like:
> This display is slightly asymmetric, so a symmetric placement would
> leave room for an RF cable on one side leading to an antenna in the
> top area of the display shell.
Has anyone done anything with CAD software for the Ben's case? I see that
there are DXF files as well as others, but I have been intending to mess
around with OpenSCAD, and it would be interesting to explore the matter of
machining cases for various things. Although the trend is towards 3D printing
for everything, practicality dictates the use of more established methods. In
the holiday period I read some articles related to model boats and aircraft,
and although people active in that field are enthusiastic to try everything
out that might make their hobbies easier and their output better, it appeared
that the more useful technology emerging in their scene was in fact computer-
controlled laser cutting.
Of course, casework for things like the Ben would probably demand something
else again, but it was interesting to see people using Inkscape to get their
aircraft parts into a laser-ready form as well as the availability of
increasingly inexpensive machines to do the physical work.
More information about the discussion