I am not missing my Treo 680 at all, plus the Droid is half the thickness and a lot easier to carry around. I’m also greatly appreciating not dropping calls on Verizon Wireless like I was very often on AT&T Wireless (sorry, but it’s true - I do not live in the wilderness and was sick of dropping calls at my desk). But that’s just the beginning.

It is clear that the Droid has immediately taken a lot of Palm users like me. One of the best comments in the Motorola Support Forums is this one:

I’m sure you’ve noticed, but this is not a Palm. It isn’t an iPhone or a Blackberry either. Learn to use your the device the way it is and you will be a lot happier then just reminiscing about what your previous phone did.

That is so true. In the first few minutes you are a bit disoriented, but that passed for me pretty much as soon as I committed to move. As with any Google phone, it’s Gmail based, but the email for me is the least of my needs right this sec. My first need was to resync my contacts and calendar. By exporting a CSV, I quickly had Outlook 2007 on my Windows 7 laptop uploaded to Google contacts under my Gmail account. In a matter of minutes after that, Google syncs with the Droid over the air. No wires. No conduit. Same process to get calendar synced, CSV out of Outlook uploaded to Google Calendar (and there is a simple sync utility on the PC, so the calendar stays synced between all three places).

When you do go to a wire, there’s more fun. I plugged it into my USB port using the standard cable to charge it, and it’s recognized as a removable drive when you mount it by tapping on the screen. I happened to have Windows Media Player on at the time, and it also got recognized as a music device and synced up with my music (something my Palm was pretty idoitic at, and I’m not an iPod user so I had never seen that work).

And then there’s fun with apps. The phone is pretty easily used, as is the text messaging app. There are some cool choices when you get a call or a message; if you have other contact methods, depending on where you tap you can choose how to respond. For instance, one tap will call someone texting you. The calendar works the way a calendar should. The ringtones work pretty well, you can assign a general default and then a specific tone to an individual. (It did freak out on me once playing with ringtones and the volume went confused, but a soft reset later I can’t reproduce what happened. One nice feature the Treo had was it would ring with one tone for callers in your address book, and another for callers not in your book, which was handy, several folks have suggested that enhancement.) I haven’t done much with the camera and nothing with video yet.

Bluetooth seems to work very well, I’ve been able to move a call into and out of Bluetooth without incident, something the Treo lost its mind trying to do. Plus when you leave Bluetooth on, it doesn’t drain the battery the way the Treo did. I did hook the Wi-Fi up quickly to see that it works, too.

To extend the thing, there’s a button that puts you right into the Android market. Find an app you like and press download. I grabbed a stock quoter and Twitter Ride right away, both of which are pretty solid and fast. Twitter Ride has already download an update automatically. I didn’t have many Palm apps but expect I’ll find more on Android.

I’ve heard anecdotally quite a few people moving from Blackberry devices also, but I don’t have much of a reference there. I am getting questions from iPhone users. One of our iPhoners on staff grabbed the thing, went right to Google Maps, and said wow. There’s a pretty huge difference in screen resolution. For folks not previously GPS enabled, the Droid goes to where you are immediately in Google Maps, something I could use a lot when traveling. The Droid doesn’t have the pinch-and-stretch motion, but it does have the directional finger flick and that works great for scrolling, much better than the dreaded Blackberry ball.

Folks are also asking about both the onscreen keyboard and the physical keyboard. I’m getting used to the onscreen one. In portrait it’s a bit touchy for large fingers, but in landscape its very manageable. (Is it “nail friendly”? Dunno. Haven’t let my dog try it yet.) The physical keyboard is pretty solid, takes a bit of getting used to with thumb positions though. I haven’t tried the directional pad.

So, I’m an Android noob and I haven’t exercised a lot of the features of the Droid yet, but the first week has given me a sufficient rush to be happy with it so far. I’m sure I’ll find more things to like in the coming weeks.

PS … I also have too much fun with Verizon’s ringback tone service, so if you call me and hear random music, I did pick all that stuff out, and there’s only one Metallica tune of the eight I have in there right now. My daughter gets Avenged Sevenfold when she calls.

The news that Cavium Networks is acquiring MontaVista software just kinda showed up. The second part - MontaVista being bought - wasn’t that big a surprise. After all, we’d seen Intel take out Wind River and Mentor Graphics take out Embedded Alley so far this year, so it was just a matter of time before MontaVista had to pair up.

But Cavium Networks? Not a single person I know had that name on the list. What do we have, here?

First, realizing the playing field has changed and we’re no longer dealing with the usual suspects is important. A lot of folks expected someone like Freescale to make this kind of move (maybe they think they already had with MetroWerks several years ago). Cavium makes sense as a MIPS and ARM player needing a stronger Linux hand, for sure. It does put them on a different stage.

Second, this is affirming that it’s a software world, and a chipset maker that can’t comprehend software will be left with fewer places to play. And it’s not just an operating system, but it’s the middleware and application layers that are getting more important. (More on that tomorrow, join our MontaVista ecast on carrier grade Linux.) This is a pretty huge statement for Cavium to make.

Third, and this goes back to earlier posts, there have to be some customers now going nuts. Cavium designs run a lot of VxWorks - how’s that gonna work now, and going forward? Cavium has not only the high end Octeon multicore lines, which are the fit for carrier grade Linux, but the lower end Econa lines which call more for a Moblin solution - maybe all will be well post-transition.

I’m not going to pretend to analyze accretive revenue or anything like that. (You gotta like the 1yr CAVM chart up to now, but maybe there’s overhead at 22.) On the surface it makes sense for Cavium, and I’m assuming the team at MontaVista thought it made sense for them and their customers. Just saying, the competitive stance is very different today than it was yesterday.

Maybe it doesn’t matter. For many of the same reasons I cited that Wind River will remain independent, I’d say MontaVista will be able to as well, and be able to continue support multiple architectures. Better support for Cavium platforms is a given.

And what does this mean for the “many-core” environment? Will we finally start seeing the type of support that these very complex network processors can take advantage of? A tighter coupling between hardware and software is not only desirable, it’s mandatory.

And is Cavium now suddenly a bigger player at the lower end, where Econa lives? Against the likes of TI, Freescale, Broadcom, Marvell, and oh yeah, Intel, and a few others? This to me is the only question around this acquisition, because the network processors are just the tip of the pyramid - the volumes are at the lower end. If Cavium / MontaVista can execute, this would be the place. Do they line up with the likes of an Intel / Wind River? And did they just leapfrog a couple other players? It’s a big world. I don’t believe in the scarity or zero-sum theory. I believe in free market forces, may the best solutions win. But no doubt, this is an uphill battle for the new Cavium, and it’s a space they’re just starting to operate in and find out how it works.

I love surprises, but I’m not quite sure what to make of this one just yet. I would like to hear your thoughts on this in general. I’m watching with great interest.

“Microsoft was trying to focus on making a small number of customers successful”, according to Dearden, working with high volume phone makers like Samsung, LG, and HTC. He added that Microsoft can compete very effectively on the “wow factor” for these high volume customers.

But what’s left is still a very large opportunity for embedded designers.

There are many mid-volume phone customers which can benefit from Windows Mobile. Besides phones, many verticalized embedded devices like barcode scanners (Symbol, Psion Teklogix, Intermec) and data collection devices (Juniper, Fujitsu, Canon) can take advantage of the features of Windows Mobile.

According to Dearden, many creative ideas have been stifled because customers couldn’t obtain access to Windows Mobile due to volumes, couldn’t support particular chipsets that weren’t fully supported, and couldn’t customize to meet their requirements. By going to channel, Microsoft can enable these “smaller” customers - who ship tens of thousands to a couple hundred thousand units per year - and build broader acceptance for Windows Mobile.

I pointed out to Dearden that this reminded me of the early days of Windows CE, where access was limited and an integration partner was needed to service more customers - and Bsquare filled that role, too. “Many of our customers are already developing middleware for Windows CE that comes standard with Windows Mobile,” he noted. He also pointed out the embedded lifecycle advantages. While lifes on phones, netbooks, and PNDs tend to be shorter, the life on data collection devices are much longer and extended market support is essential. Not only is the upfront integration needed, but ongoing updates, security fixes, and the like are required.

Dearden is projecting that Microsoft will be focused on Windows Mobile 6.5 for the next couple quarters, then probably shifts activity to Windows Mobile 7.0 as it’s released. Bsquare will continue long term support of Windows Mobile 6.5 with full embedded lifecycle support, including engineering and integration work. “We’re already partnered with Qualcomm, TI, Freescale, and Marvell …. We’re looking at verticalized reference designs, for lower volume manufacturers - support for an SoC with Windows Media in a development kit,” he said.

Bsquare certainly understands the high priority challenge designers face here. Dearden finished: “Tailoring BSPs for chips, and getting enhanced graphics and enhanced battery life, is number one on our agenda.”

Windows Mobile: it’s not just for phones. The advantages are there, the question is execution. It’ll be interesting to see where this goes versus Android and RTOS solutions, and what types of devices are announced in non-phone applications.

Jennifer Hesse’s series on in-vehicle infotainment continues to conclusion with part 2 on software, part 3 on a reference design, and the just posted today part 4 on new technologies. Really good reading.

Also, my series on digital signage started today with part 1 on make-or-break factors in signage apps.

First of all, there’s the power consumption and management. According to Terry Ngo, senior manager of the consumer connectivity business for Atheros, there’s a lot going on. “These are all CMOS mixed signal implementations, with no GaAs,” he pointed out first. He also indicated heavy usage of power domains to be able to lower voltages, and a lot of clock gating. Also, Atheros has spent a lot of time on things like a linearized power amplifier and an efficient implementation of the SDIO interface in these designs. The power consumption of the AR6003 is 20% lower than its predecessor, with more performance from 11n rates instead of just 11g rates.

A second point is the 1-stream 802.11n implementation, again balancing low power consumption with good performance. Also, in the case of the AR6133 shown below, Bluetooth and Wi-Fi are combined to work with a unified antenna, reducing device size and cost.

While designed for phones, designing around an SDIO interface means these chips are able to interface with a wide range of SoCs, working with more devices. Drivers are available for Linux under GPL, and for Windows Mobile, Android, Symbian, Chrome OS, and others.

There’s a lot more to the technical details of these announcements. As we see more and more devices going to Wi-Fi, and the demands of power and performance getting more challenging all the time, parts like these can make the difference in tough designs.

They claim the new microMIPS instruction set keeps most of the performance while reducing code size by a bit more than one-third. Both devices are fully compatible with the regular MIPS ISA. Using the new ISA can cut system costs through reduced memory requirements.

Along with a few other features, MIPS also took on one interesting feature that mostly gets overlooked: a flash accelerator block in the M14K.

One of the first things programmers often do is copy code over from flash into RAM for faster execution. It seems most architectures just let this exist instead of fixing the weakness. MIPS is taking a shot at accelerating flash performance with some pre-fetch capability - we didn’t get a lot of details but it’s worth a closer look if you’re interested. Obviously, if you’re generating a whole lot of misses, this might not help and you might still have to shadow some sections of code, but the idea of being able to execute out of flash better is an interesting one.

Also around these cores is extension capability. Optional units include CorExtend, which is a way to bolt in a co-processor in an SoC environment, and a User Defined Instruction (UDI) capability. Off core interfacing to peripherals is with the AHB-Lite interface.

Lastly, there are the iFlowtrace extensions for debugging - something we’re about to have a viewpoint from MIPS on in our November print issue.

These enhancements along with the new microMIPS ISA make this an interesting development.

This week, Wind River’s Ken Klein issued his first blog post on “Wind River’s Next Chapter“. Interesting reading. A couple other editors have commented on this post, so I thought I’d add maybe more than two cents.

The core of the conversation goes something like this: Wind River is part of Intel, therefore eventually only Intel technology will be supported by them. Anything’s possible, but that is a very highly unlikely outcome.

Ken used the word “firewalled” and we talk about that a lot in our industry, but if there are two companies that understand it, they would be Wind River and Intel.

Somewhere in my wayback machine:

• I am a recovering engineer, and I used VxWorks in the beginning when the kernel inside was VRTX. Yeah, Ready Systems. It wasn’t obvious until you really started digging around under the hood. The VxWorks we know today would have never existed if they hadn’t embraced VRTX and built on it, making a better development solution.
• One day years later, my boss called me into his office and said I should call this guy at Intel (who now goes by @Intel_Jim , you can follow him and me at @dondingee ). Jim and I spent many days and more than a couple nights on phones, in conference rooms, and in hotel lobbies and restaurants trying to figure out how to get Motorolans and Intel-ers to not only talk, but work together on embedded (er, applied) computing. It was total sacrilege at the time. We avoided more than one airstrike from Schaumburg, Santa Clara, and Austin. But the results were worth it (I think, ask Jim).

Things never get better if people aren’t bold enough to embrace an innovative solution.

There is no one company that can keep up with all the aspects of both the technology and the business acumen needed, and let’s talk the biz side for a second. I happen to think that Wind River will remain a independent subsidiary for one big reason: the Intel sales force and the Wind River sales force are two different animals, and will probably stay that way. Sure, competent sales people share some traits and skill sets. But the two selling cycles are completely different. While the sales teams might roll up strategies to the Intel side (Intel is big on the two-above-your-box matrix boss concept, so Wind River types will find themselves matrixed to an Intel type soon) they won’t integrate into one entity easily - and their customers probably won’t allow it, because of the types of support they’ve grown used to.

There is no doubt the Wind River offering will get a lot better on Intel architectures, and Intel’s software strategy gets more important every day. But as long as Wind River plays the business side right and develops the right type of technology for the markets, I see no reason to disbelieve they can remain an effective provider for both Intel and non-Intel processor technology.

If you think beyond these two companies for a second … consider this. Adobe could not possibly exist unless firewalls worked. Neither could Mentor Graphics. Neither could TSMC. For every Apple Computer that builds a self-contained environment, there are 100 companies that figure out how to work with multiple competitive camps in their customer bases and ecosystems.

For the competitors that want to try to spin this story that a customer can’t possibly work with Intel/Wind River because they can’t play fair … be careful. If you’re ready to compete on your technology and business relationship, that’s the right place to go.

For customers, do your homework. Consider both the technology and the business relationship you want. You might not be comfortable with this relationship, and it’s ok. But don’t rule something out if you see this relationship providing the right technology but are squeamish about the biz side. If you need legal advice to increase your business comfort level, get it. If you need more information, ask for it. And if you like the relationship, tell them that, too.

Ultimately, everyone has the right to choose between Intel/Wind River solutions and many others, and the right providers listen and will win - and so do their customers.

I might be wrong, and I’ll see you in the sanitarium if I am. But I’ve seen (and lived in) this show, and I think I can guess how it goes. Change can be fun, deal with it. Shoot back a comment with your views and experience with how this change is going from your desk.

Also news from TechCon3 by ARM on the new Cortex-A5 MPcore processor, targeting embedded devices. Better perf than ARM1176JS-S, but power and footprint of AMD926EJ-S - twice as power efficient. Includes TrustZone security and NEON multimedia engine. MPCore increases multicore scalability while containing power consumption. Fully Cortex-A8 and -A9 compatible so lots of software.

Core to the ReNu system is the ReNu panel, a freestanding power module containing solar cells, a rechargeable battery and an intelligent user interface. The panel can be hung or placed in direct light to capture energy. When replenished by sunlight, a user can drop a ReNu panel into one of a series of Regen extensions to utilize the energy they have created. ReNu extensions include a phone charging system, personal audio, and task lighting. The ReNu panel can also charge an iPhone, iPod or USB device directly.

There are lots of ideas in designing green embedded devices and applications in each issue of our Embedded E-letter featuring the Deep Green department. Don’t miss out … subscribe now, and pick E-letter under Embedded Computing Design. Here’s a sneak preview from this month’s issue.

Synopsys has just announced Synphony HLS, which takes on that exact question. HLS stands for High Level Synthesis, and integrates M-lanuguage and model-based synthesis to increase design and verification activity dramatically over RTL flows in complex, algorithmic applications.

One of the big problems with high-level design is designers go nuts and design stuff using their favorite tool - which usually speaks floating point. Unfortunately, when that design is translated to fixed point for implementation on an FPGA, unexpected and even bad things happen that take a perfectly good algorithm and trash it up.

Chris Eddington, director of marketing for system-level products at Synopsys, put it this way: “Designers start out in M-language, and just get it working. They don’t worry about precision, fixed-point, architecture, or implementation details …. A high percentage of developers use M-language, then throw it away … when they create a fixed point model for implementation.” This causes coding in M-language, recoding in C, recoding in RTL, recoding for FPGA specifics, and re-verification every time. “Going from algorithm to RTL can take 3 to six months,” according to Chris.

So why not take M-language and drive the fixed-point implementation directly? And also integrate that flow with other tools for synthesis, verification, and power optimization? Exactly what Synopsys is doing here, and a lot more that helps get complex algorithms onto FPGAs and ASICs faster and more reliably.

There is a lot to this release, so take a look using the link to the press release. Very interesting.