Sharp's Upcoming Linux PDA 107
Bill Kendrick writes: "ZDNet reports that Sharp is getting ready to make its
Linux-based PDA available to developers in the next few weeks. They'll include a 206MHz StrongARM, 32MB (in the cheaper, developer edition), a JVM, the Opera web browser, and a slide-out keyboard. A profile of the device is available at LinuxDevices.com." We've mentioned this before, but it looks like it'll be here soon.
pull-out keyboard (Score:1)
Re:pull-out keyboard (Score:1, Interesting)
Re:pull-out keyboard (Score:1)
If this keyboard had been a little bit larger, (like the size of a Psion 5mx keyboard), the thumb typing becomes a bit cumbersome because you cant easily grasp the device while still keeping your thumbs free.
From the screenshots, it looks like this keyboard could be perfect!
Re:pull-out keyboard (Score:2)
The 5's have the best PDA keyboards there are. (Of course, I can't get one with color, or a big fat fast processor, etc.etc., hence my current bout of "new PDA lust".)
Thumb Keyboards (Score:2)
That said, I agree with you, there should be better solutions out there.... Who ever invents one that:
A) can be implimented without taking up a great deal of space (at least when compacted)
B) can be LEARNED relatively quickly
C) allow proficient users to type comfortably upwards of 40wpm [especially in PDA/road-type situations]
will be in a real position to dominate the PDA market....
Re:Thumb Keyboards (Score:1)
I'd like to see a very portable solution that will allow for this kind of speed, without a year-long learning curve, which can be stowed away in favor of handwriting recognition. If the device would have to be the size of a Newton or a bit smaller to make it happen, so be it. I don't want a laptop with fliptop, though.
Some kind of system similar to a stenography machine, with machine-assisted word completion, would be nice if it could get accurate enough at predicting one's patterns.
Good For.. (Score:1)
Linux....PDA market
The product doesn't look extra-ordinary, but looks like once Sharp goes on to promote it, it'd do better than the existing trends in the market. Good for all.
Any more information? (Score:2)
Sharp Zaurus PDA (Score:3, Interesting)
Re:Sharp Zaurus PDA (Score:1)
Not much there yet, but I imagine it will heat up after people get their hands on this device.
Sharp sign Amiga as content provider (Score:3, Interesting)
Amiga have been signed [amiga.com] by Sharp as a content provider for its new Zuarus platform. The Zaurus ships with Amiga's "AmigaDE", a platform agnostic digital environment which is hosted by the Linux OS.
Sharp demonstrated the Zaurus running AmigaDE applications a while back. Here's [amiga.com] the link.
Amiga have also been signed by Psion [psion.com] to provide its AmigaDE system for their NetBook products.
--
Ben.
Re:Sharp Zaurus PDA (Score:1)
amiga.com. [amiga.com]
The version of Java is from TAO Group, UK, in
concert with the AmigaDE.
Regards,
JK
206 mhz Strongarm VS 200 mhz pentium? (Score:1, Redundant)
I'm starting to think it's either time to upgrade my desktop, or consider using an embeded OS to speed things up.
Re:206 mhz Strongarm VS 200 mhz pentium? (Score:1)
However, since the linux operating system is
being used, that negates these factors.
Well, Linux was
originally created as a unix-clone that runs
efficiently on low-end (usually single user)
systems. Thus, performance and efficiency were
important when doing architectural / design
choices; scalability and scheduling fairness
(for example) were of lesser importance (and
that bit when trying to make kernel SMP-friendly)
Now,
obviously OSes designed specifically for ultra low-end embedded market (QNX?) are likely to
be even more efficient, but really, StrongArm
with ~200 mhz clock frequence has plenty of
power to spare, especially when it's only feeding
tiny display (like you said). OS overhead is
likely to be negligible.
Re:206 mhz Strongarm VS 200 mhz pentium? (Score:1)
Re:206 mhz Strongarm VS 200 mhz pentium? (Score:2)
I would guess that the performance difference has to do with issues such as tiny cache, lack of parallelism and pipelining in the CPU, slow narrow memory, software framebuffer, etc.
Re:206 mhz Strongarm VS 200 mhz pentium? (Score:1)
RC5: SA 270kkeys/s -> P5 200Mhz
DES: SA 470kkeys/s -> P5 110Mhz
OGR: SA 1.1Mnodes/s -> P5 233Mhz
BTW Ofcourse distributed.net is not ment for serious crossplatform benchmarking
BTW2 The iPAQ as a whole does feel slower (IMHO mainly due to the display)
I'll definitely buy it... (Score:3, Funny)
Re:I'll definitely buy it... (Score:1)
Looks good. (Score:5, Interesting)
I don't really see what Java and Linux bring to a handheld device. Development isn't that difficult for the Palm OS, even Pocket PC, which have each picked a niche in the handheld market (the Palm OS for basic PIM functions with lots of little add-on software, Pocket PC for built-in support of Office documents and multimedia). I have spent some time thinking about it, and the advantages of Linux (multitasking, different processor support, open source) don't seem as important in the handheld market. At least not yet. If Palm OS and the Pocket PC platforms weren't mature, I would definately think that using Linux would be a much better choice. Unfortunately, it is still quite immature, as one can quickly tell from reading through the Linux development mailing lists of the Agenda [agendacomputing.com]. Not to say it isn't useful, but on the same hardware it seems to be slower than the Palm equivalents, from the reports I have read.
Moving on, the choice of compact flash and lithium ion battery was very wise. Better than a proprietary expansion slot, in my opinion, but somewhat more limited. Handspring's sprinboards are capable of doing so much more than memory expansion and modem/ethernet devices - like a remote module, GPS, cell phone, wireless internet, etc. I am not sure how many of these things the compact flash design on this palmtop could support - with something sticking out the top. Seeing as this has a 206 Mhz processor and a color screen, the good rechargable battery will be quite needed. It would be nice if these are easily removable, so that those who don't get a chance to charge for quite some time will be able to pop in a second battery.
The sliding keyboard seems nice, but obviously useful mostly for "thumb-typing". Handspring just announced a clip-on sort of keyboard for their devices that does a similar thing - SnapNType [palmgear.com]. One thing that I wonder about this Sharp device - will it support handwriting recognition? The site claims the color screen has "touch panel support". Handwriting recognition is fairly difficult to code, as the Agenda creators have found. Grafiti is nice, especially for those that have learned it, but there is some sort of licensing with it.
All in all, this looks like a promising Linux handheld. They learned from the Agenda's mistakes, by including USB connectivity, a rechargable battery, and compact flash slot. With all these features it will definately be in the price range of the already-mature color Compaq's, which means a limited consumer base. I look forward to hearing how well the developer models work.
Re:Looks good. (Score:1)
Java is 100% about selling it to the corporate market. If you can sell the idea that your code-monkey's who just got all certified in Java to run your website can now swap over and start developing enterprise-wide handheld business applications, you're on to something. Also, any application you develop for this device with Java will be incredibly portable to any other device with Java like the iPaqs (same story as always with Java - it may not be 100% true, but it's good marketing.)
I should say that I use Java as my only programming language No C for me. To me the advantages are really clear that I can get up to speed programming on this device much faster than I could for the PalmOS or PocketPC.
-Russ
Compiler should take care (Score:1)
Re:Compiler should take care (Score:1)
Then again, I remember String and StringBuffer having some interesting smugs way of avoiding unnecessary copies (ie. sharing array for as long as possible), and perhaps even that could prevent excessive array allocations/copies.
Hmmh. Time to check out java decompilers again.
Re:Looks good. (Score:2, Informative)
"One thing that I wonder about this Sharp device - will it support handwriting recognition?"
I can help you a bit with those two questions with one url: xscribble [handhelds.org]
Re:Looks good. (Score:2)
Obviously this Sharp is aimed for the high end market. My main point was emphasized in my last paragraph - this high end market is already cluttered with mature devices like Compaq's and HP's. This is not to say the new Sharp handheld won't meet with some success, but that it will need to mature much more quickly in order to be successful, because too many high-end mature options exist now. Like I said, a few years ago this type of software would have a much better chance before Pocket PC got off the ground, and while Palm was even more primitive (not to say that it is a bad thing, like I mentioned, I am a very happy Visor Platinum user).
It requires more than just software to support good handwriting recognition - the touch screen must be sensitive enough to work well. I had an old Tandy handheld quite some time ago that "supported" handwriting recognition. The software was bad, but the touch-screen really was not designed to handle handwriting well. One could tap through things well, but the handwriting was quite inaccurate, caused by both hardware and software.
I cannot speak for xscribble, but I do know that the Agenda team had to revamp the handwriting recognition recently because it didn't work well (perhaps someone closer to the project could elaborate). I don't know if they based it off of xscribble code or not.
Re:Why thye chose Opera?` (Score:1)
Re:Why thye chose Opera?` (Score:1)
Mozilla is way too large both in footprint and running memory still. It's slow too.
Nanozilla on nanoX might be a lot better but that's a different story.
love the input options. (Score:2)
Please pardon. (Score:1)
Re:Please pardon. (Score:1)
good and bad (Score:1)
but as long as they keep making shiny things, I'll keep buying them.
now off to get some tin foil.... oooooo
maybe someone can answer this (Score:1)
Ruby on PDAs (was:maybe someone can answer this) (Score:2)
Then again, NetHack [delorie.com] and Apache [orasoft.org] are available on the Agenda, too.
StrongARM comments (Score:5, Interesting)
2) It is RISC rather than CISC, and having used a 200MHz StrongARM desktop I can tell you it FLIES. Much faster than a P2-266
3) You use gcc to compile on StrongARM because Linux runs on StrongARM (well obviously). ARMLinux has been around for years running on Acorn machines. You can also cross-compile to StrongARM using a x86 box - just
4) You can even use them for Beowolf [dnaco.net]
Phillip.
Re:StrongARM comments (Score:2)
Do you have any hard numbers to confirm this?? RISC processors at the same speed as a CISC processor are typically SLOWER because they do LESS work per instruction than a CISC processor.
Are you really comparing the speed of the processors or how the overall systems 'feels'... It's an invalid comparision, if you are comparing a fully installed Linux system on a P2-266, with all the extra processes and X, etc), to a stripped down StrongARM system with minimum processes and much smaller graphic display.
Re:StrongARM comments (Score:2, Interesting)
This would be true if RISC and CISC today ment
what they used to me. In fact many of todays so
called RISC machines have more powerful instruction sets, with for example three operand
instructions with multiple addressing modes. Mean while the
major architectual inivations from risc processors
like pipe-lining and superscalar are on all modern
microprocessors. For more info see this ars-technica article [arstechnica.com].
All this, plus the AMD vs INTEL megahertz wars, leads to a curious roll reversal where so called
RISC chips do more work per MHz, while so called
CISC chips (actually only the x86 is called CISC
these days), have the highest clock rates.
Re:StrongARM comments (Score:2)
Are you sure about the addressing modes?
I have not surveyed a lot of RISC designs. But as I recall, one basic feature was that there were very few instructions that could load and store to memory, and a limited number of memory addressing modes.
The three operands make sense. But aren't the risc instructions predominantly all register-to-register with a very large number of registers? A few register-to-memory instructions, and then you optimally schedule in your register-to-memory instructions at cricual points, rather than having to take where they fall "inside" of the CISC instruction? Basically you write several ops to "build" a CISC instruction. Then you take the overall stream of instructions and optimally schedule operations to keep all functional units busy. This is done in the compiler statically, rather than by trying to rearrange instruction execution dynamically in hardware, thus needing even more hardware. I've only read up on all of Apple's PPC propaganda during the early 90's, so I'm no expert here.
Back to addressing. Yes, I don't expect to see RISC instructions with an addressing mode such as: preindexed, double indirect, added to a register, indirected, then postindexed by another register and added to the phase of the moon.
Re:StrongARM comments (Score:2)
RISC processors at the same speed as a CISC processor are typically SLOWER because they do LESS work per instruction than a CISC processor.
That would be true if CISC instructions all executed on one clock cycle (as RISC instructions do) but that isn't true. CISC processory do MORE work per instruction. In fact, some (little used) CISC instructions can take hundreds of clock cycles. Advantages of having one cycle per instruction include efficient pipelining. The Intel Pentium is a strange hybrid. It has a RISC core which works on its own microcode, and 90% of the silicon is actually a hardware translator which converts the x86 CISC instructions to the Intel RISC microcode.
My basis was using a 200MHz RiscPC running RiscOS. From turning the machine on to the desktop running takes less than one second.
Phillip.
Re:StrongARM comments (Score:1)
Re:StrongARM comments (Score:2)
Less work per instruction, not less work per clock cycle.
RISC, with simpler design, are easier to put more functional units onto a chip of the same size with the same technology to deposit the same number of transistors per chip. Therefore RISC can do multiple instructions per clock with proper instruction scheduling. That is, as long as you can keep all the functional units busy. Thus, the compiler's instruction scheduling can make the difference between lousy and excellent RISC performance.
Re:StrongARM comments (Score:1)
As a sidenote, I've also noticed that floating point (on Linux and QNX, at least) seems to operate in big-endian, while other math ops are done little-endian. Test it for yourself, I verified it with a very small C program.
Re:StrongARM comments (Score:1)
Wouldn't that be due to the (industry standard) IEEE-mumble way of encoding floats and doubles? So it's not a big-endian vs. little-endian thing but a completely different encoding?
Re:StrongARM comments (Score:1)
Just a quick comment. Cross-compiling is not always as easy as it is. A lot of softwares out there are not packaged properly for cross compiling, even they're using stuffs like automake, autoconf, etc...
Secure Digital Expansion Slot?? (Score:1)
I see a slot for headphones, but I don't see a claim for "plays MP3s".
Re:Secure Digital Expansion Slot?? (Score:1)
But, is the "secure digital" expansion slot still a concession to the copyright nazis?
Zuarus PDA is AmigaDE enabled. (Score:1, Interesting)
Using Linux pieces does make sense though as you can use them freely and even gives you more news coverage. These devices are extremely cool, but NO way are they true Linux devices.
X on a PDA (was:Zuarus PDA is AmigaDE enabled.) (Score:1)
Actually, my 66Mhz, 8MB RAM Agenda PDA running Linux 2.4.10 and XFree86 works QUITE well, considering.
MPEG4 movies listed under features? (Score:1)
On http://developer.sharpsec.com/ [sharpsec.com] one of the listed features is "Headset Port", and the subtext is "Stereo headset port for listening to MP3 audio files or MPEG4 movies". Anyone know what that means in this case?
Re:MPEG4 movies listed under features? (Score:1)
Re:MPEG4 movies listed under features? (Score:2)
There's no room in the marketplace (Score:2)
Anyway, this is not the time, economy wise, to be trying to introduce a completely new product in a genre of questionable usefulness. My TRGpro spends only about one in five days out of its drawer, and I really like it, I just can't find a use for it that justifies lugging it around. (Particularly now summer is on it's way.)
Re:There's no room in the marketplace (Score:2)
On a slightly unrelated note, bluetooth was *everywhere*. This truly amazed me. Just about every device and manufacturer had shitloads of bluetooth stuff!! It seems the reports of its death are greatly exaggerated, at least over there!
Needs better connectivity (Score:2)
The USB is a nice touch, but it looks like it might get in the way of the CF slot.
I see the real possibilities in a Linux powered device like this is in integration into larger system and field based data collection. There's no way anybody is going to break into the PalmOS/WinCE dominated world.
The problem is when you start assembling systems to do things like field surveying systems, the features you get don't add up (e.g. you need a huge CF card to hold your maps files, but then yo have no way to connect your GPS). I do a lot of (simple) stuff with GPS hand PDAs -- I think every PDA should have a serial port!
Re:Needs better connectivity (Score:2)
There's no reason to believe you couldn't get a serial port dongle that clips onto the docking port as are available for palm pilots.
Two CF slots would make it rather large, but the prototype I've played with does have an MMC slot in addition to the CF slot.
The USB is a nice touch, but it looks like it might get in the way of the CF slot.
What the heck are you looking at? There's no USB port on the device except for the USB what runs through the docking connector.
Regardless, like most (all?) strongarm handhelds it's probably using the built-in USB on the strongarm chip itself. That means that it's target-only. The SA1110 is a USB device, not a USB host. You can't attach USB peripherals to it as it is a USB peripheral.
SA1110 usb also isn't very fast, it's a design limitation. But how fast does it have to be to copy a few megs of data to the host computer?
There are usb chips available that can be interfaced to the SA1110, but I haven't heard of a PDA that has one, given the voltage requirements. A USB hub has to be able provide 500mA of +5v to each device. Not practical for something that fits in your pocket.
The problem is when you start assembling systems to do things like field surveying systems, the features you get don't add up (e.g. you need a huge CF card to hold your maps files, but then yo have no way to connect your GPS). I do a lot of (simple) stuff with GPS hand PDAs -- I think every PDA should have a serial port!
It does have a serial port. The docking interface may provide the serial buffer chip but that's no big deal to build into a dongle. It just doesn't have a DB9 right on the case, which is perfectly reasonable.
Like i pointed out before, it does have an MMC slot on the side. MMC cards are not as cheap as CF or SmartMedia but they do exist, and if push came to shove you could put a 64 meg MMC card in the side and stick something else in the CF slot.
Keep in mind that while CF can be implemented as a storage-only interface, in order to be capable of hot-swap it is generally implemented as sortof a small formfactor PCMCIA. There exist LAN cards, modems, video confrencing cameras, and all manner of peripherals available in the CF formfactor. It's just like pcmcia, but smaller.
Remember the Yopy? (Score:1)
Sharp's Open Operating Website (Score:1)
Looks like Sharp have not embraced the Open Source movement beyond PDAs yet...
Guess they have to start somewhere
Developer Registration Prob (Score:1)
Error Occurred While Processing Request
Error Diagnostic Information
ODBC Error Code = 37000 (Syntax error or access violation)
[Microsoft][ODBC SQL Server Driver][SQL Server]Can't allocate space for object 'Syslogs' in database 'Zaurus' because the 'logsegment' segment is full. If you ran out of space in Syslogs, dump the transaction log. Otherwise, use ALTER DATABASE or sp_extendsegment to increase the size of the segment.
The error occurred while processing an element with a general identifier of (CFQUERY), occupying document position (19:2) to (19:49).
Date/Time: 10/08/01 09:20:41
Browser: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0; Hotbar 3.0)
Remote Address: 168.236.254.1
HTTP Referer: http://developer.sharpsec.com/join.cfm?Blue=RE
Template: D:\Inetpub\wwwroot\developer\join_writerecord.cfm
Please inform the site administrator that this error has occurred (be sure to include the contents of this page in your message to the administrator).
When do we get a Linux PDA for engineers? (Score:1)
There is already a plethora of PDAs for accountants and salespeople, but the niche for engineers remains largely unfilled. What a perfect spot for Linux! Give us something that will do the math, do the analysis, hook up to networks, and crunch the data without costing us $5,000.
Our group is very interested in a PDA network analyzer that can compete with the Flukes. Yet every damn PDA comes out as a clone of Palm. Get a clue folks... even the Palms aren't selling!!
It seems to me that a Linux-based PDA with appropriate interfaces (10/100 ethernet would be perfect) would find several niche markets. Out of the several Linux PDAs (and our firm has a couple of them) this Sharp is the ONLY one which has any useable connetivity. I wonder if the OS (based on Lineo's) is up to the challenge.