nanogui: Thread: MyLinux Pocket Linux Workstation...

Greg,

I've lifted the Nano-X-Mozilla image from your site and Gimped them into
a "first cut" drawing of our plastics.  We should be ready to send you a
unit to start the port within about 2-3 weeks.  You can see our plastics
with the Nano-X-Mozilla image by pointing to:
http://www.azpower.com/mylinux

As you probably know, the MyLinux PLW has the following features:

* 133MHz-200MHz Hitachi 32-bit SuperH RISC Engine CPU
* 128MB of PC-133 SDRAM
* 64MB of FLASH (configurable as both system & user space)
* 2 PCMCIA Type II Slots (Ethernet/802.11b/CCD Camera/Modem/Hard
   Disk/Memory Card/etc.) Also Accepts 1 Type III or 2 Type I.
* 1 CompactFlash Slot (Memory Card/IBM MicroDrive/etc.)
* 1 USB Port (Keyboard/Hub/Mouse/etc.)
* 1 RS-232 Serial Port (PC Connectivity, Serial Mouse, Modem, etc.)
* 1 IrDA transceiver (Device-Device, Device-PC, Device-Printer, etc.)
* Sharp HR-TFT Active Matrix 240x320 (Portrait Mode) Color LCD Panel
   with Integrated Touch Screen and SwivelView (tm) 90/180/270 Degree
   Hardware Controlled Rotation and Picture-in-Picture
* 256-64K Color SED-1376 High Speed, Low Power Graphics Controller
* 1 RS-485 High Speed (to 11Mbit/s!) Dedicated Developer Serial Port
* 4 Programmable Function Keys
* N-Way Cursor Control (Joystick)
* Stereo Audio Input/Output Jacks
* Mic/Line-In Jack
* Mono Speaker & Integrated Microphone (Records Voice Messages, etc.)
* Approximately 3.3" x 6" Board Footprint for Palm-Sized Form Factor

The plastics image shown on the web site appears more "bloated" than it
actually is...our dimensions are as follows:

6-3/8" (162mm) Overall Length
3-1/2" (89mm)  Overall Width

We still have to place the battery in the unit before we have the exact
thickness of the unit.

Note that EmbediSource is our production organization label.

Thanks go out to all of our Open Source Contributors for making this
project such a tremendous success!

Will we be seeing you at Embedded Systems Conference in San Francisco
this April?

Take Care.

Rob!

: I've lifted the Nano-X-Mozilla image from your site and Gimped them into
: a "first cut" drawing of our plastics.  We should be ready to send you a
: unit to start the port within about 2-3 weeks.  You can see our plastics
: with the Nano-X-Mozilla image by pointing to:
: http://www.azpower.com/mylinux

Rob -
    Great, looks cool!  Can you give me a quick update
on what you actually have running?  Do I need to produce a
Microwindows for it?  I would suppose that the standard
2.4 16bpp epson display driver will work for the kernel
framebuffer, so this should progress quickly.


: 
: Will we be seeing you at Embedded Systems Conference in San Francisco
: this April?

Yep - I'll be in Red Hat's booth again as a third party vendor,
showing Microwindows running on a variety of systems, as well
as cool 7 second DOC boot stuff.  See you there.

Regards,

Greg

Greg Haerr wrote:
> 
> : I've lifted the Nano-X-Mozilla image from your site and Gimped them into
> : a "first cut" drawing of our plastics.  We should be ready to send you a
> : unit to start the port within about 2-3 weeks.  You can see our plastics
> : with the Nano-X-Mozilla image by pointing to:
> : http://www.azpower.com/mylinux
> 
> Rob -
>     Great, looks cool!  Can you give me a quick update
> on what you actually have running?  Do I need to produce a

We have the boot loader and 2.3.99 kernel running with a serial
interface driver.  By the time we send the unit, we should have a basic
8bpp Epson FB driver running with a 2.4.x kernel...we haven't started
looking cloesly at the 16bpp driver requirements yet, as I'm thinking
we'll need to write a DMA driver to use a portion of system RAM as a
display buf for higher color modes and shuttle 80Kbyte chunks to the
on-chip SRAM. We'll initially use the 8bpp driver and as we gain
momentum, build in the 16bpp custom driver...along with the SwivelView
and Picture-in-Picture bottom layers upto a higher level API into
something like Microwindows, if that wouldn't be a sin.  Ideally, we'd
have something like a Win32 wndclass called pinp or something, that once
called, it could utilize a hook into the driver code to bang open a
whole for dumping the new bits into.  A lot more investigation is
required before any of this spew will be properly invalidated :)

We should also have our USB keyboard driver working...but maybe not
right at the moment we're ready to send a unit out to you.
We should have at least raw IR working.
We should have PCMCIA working...at least at the boot loader level so
that we're not bound to serial downloads forever.  Note also that we
have a 485 part in the device, so if you have a 485 interface card such
as the Blue Heat, you can pump up serial downloads to 784Kbits/s...which
isn't too bad.  (Note that our chipset is capable of 11Mbits/s in
full-duplex, but the Blue Heat cards max out at 784Kbits/s.  We are
currently working with them to develop a full speed 485 card for Linux
that enables us to use our dedicated debug port at 11Mbits/s.)  Their
PCI cards are about $165...give or take.  The goal behind having a
dedicated peripheral for developer debug is to free up other I/O ports
for "product" I/O.  Additionally, since we felt that most developers
would want to test interconnection of the MyLinux "product ports" to
their Linux PCs, we didn't want to tie up any of the PCs ports with the
dedicated debug so they'd be free for the "product interface testing"
roles.  This does necessitate a custom board, which is an added expense,
however, for developers who are not building USB or PCMCIA, they can
always utilize one of those peripherals for debug of higher level apps
at high speed.

Note that our current USB transceiver switches at a slower 1Mbits/s rate
rather than the faster 12Mbit/s...with a maximum effective data
throughput rate of 568Kbits/s.  Half a Megabit per second should be
enough for most developers without any special hardware other than a USB
A-to-A cable, which we'll likely ship with the devices since our PC
"Synchronization" is designed around RS-232 serial or USB choices.

We'll try to have as much up and running as possible, but you may end up
getting of box of spare parts ;0



> Microwindows for it?  I would suppose that the standard
> 2.4 16bpp epson display driver will work for the kernel
> framebuffer, so this should progress quickly.
> 
> :
> : Will we be seeing you at Embedded Systems Conference in San Francisco
> : this April?
> 
> Yep - I'll be in Red Hat's booth again as a third party vendor,
> showing Microwindows running on a variety of systems, as well
> as cool 7 second DOC boot stuff.  See you there.

That's great!  As you probably know, we're using battery-backed SDRAM
for "instant on" in the MyLinux PLW.  Naturally, what we send you
probably won't have that much working...at least not correctly :)  One
of my guys is working on the touch panel driver and should have a good
start by the time we send it off to you.  We'll definitely want uWin on
it.  Note that Epson's config utility for their 1376 part has our HR-TFT
Sharp display as one of their supported panels...so it shouldn't go too
difficultly...I have additional Epson driver code if you haven't already
seen it.

> 
> Regards,
> 
> Greg

Take Care.

Rob!