Tag Cloud

One thing that Me found very useful with blogs, e-mails etc., was tags and tag clouds. Irrespective of the volume of the blogs/ e-mails, tags provide a easy way of categorizing and accessing data.

A tagcloud, elaborated more in this article on Wikipedia, is a cloud full of words, the font size of each word and/ or color indicating how importance of the tag. Each tag, typically is a hyperlink that lists out all the items with that tag on them.

Now, Me really wished google provided a gadget for generating tag clouds on blogs hosted on www.blogger.com. Nevertheless, Me found this link, containing good instructions about how to create tag clouds on blogger hosted blogs. 

Me liked his implementations so much, Me had to leave a note on this site, to give him his due credit, hence this blog post.

Further reading:

Developing a tag cloud using PHP: http://www.lotsofcode.com/php/tag-cloud-v2.htm

Designing tag clouds on LAMP stacks: http://www.onlamp.com/pub/a/onlamp/2006/06/08/designing-tag-clouds.html

Design analysis of Tag Clouds: http://www.joelamantia.com/blog/archives/ideas/tag_clouds_evolve_understanding_tag_clouds_1.html

--Me.

OMAP - in brief

OMAP and DaVinci Software For Dummies - THE book for beginners:

Since a couple of weeks (or probably more), www.beagleboard.org has had a mention about a book called "OMAP and DaVinci Software For  Dummies". The companion website was pretty impressive too. Especially since Me was an absolute novice when it came to OMAP or any of TI's products, excepting the recent experiences with Beagle. Proceeded to order it thru myTI, expecting that it might cost me, that too in dollars. Was pleasantly surprised to see that the order went through without a mention of any charge at all.

A couple of weeks later, this nice little book dropped into my mail box. About 106 pages in all, it was written for absolute novices - who knew nothing about OMAP or DaVinci. And that, precisely, is what Me needed at this juncture.

The reading experience was a cruise. Took about a couple of hours of my train journey from Bangalore to Hyderabad. Apart from covering all major aspects of OMAP and DaVinci, this book also featured a good set of cartoons at few places - my fav one being "The 5th Wave" by Rich Tennant - "Oh come on... how fatal can it be?". Here's a copy of the cartoon - all credits to Rich Tennant. The authors - Steve Blonstein and Alan Campbell - did a pretty good job at striking a right balance between keeping the language simple and yet driving home the point about how sophisticated this stuff is. Worthy of mention are the icons that draw the attention of reader to some specific tit bits of information. There are a lot of TLA's dispersed around in the book - but are just right in volume - atleast Me didn't get driven away mad. ;-)

The book has three parts:

The first part starts with a good discussion about how multi-core architectures have come to be of such prominence in today's world, introduces the OMAP and DaVinci platforms, discusses the operating systems and kernels available, the various standards that TI had come up with to make the lives of developers easy and the software frameworks in place for these platforms.

The second part walks the reader through a hands-on. If followed through, the reader can end up with software that utilizes the video and audio parts of OMAP processor.

The last part - gather that this is a standard feature of all For Dummies books - gives very useful information - TI's recommendations for Codecs and pointers to resources that will help developers.

OMAP and DaVinci Platforms:

OMAP and DaVinci SOCs are hybrid in nature - they typically contain a GPP (General Purpose Processor) and a DSP (Digital Signal Processor). The task scheduler for the DSP is a lightweight scheduler called DSP/ BIOS. The For the GPP the SOC leverages the wonderful world of Linux (other operating systems can also be ported though.)

DSP/BIOS - there is apparently a perennial discussion about if this is actually an operating system or if it is a scheduling kernel - is ideal for the real time DSP task scheduling due to its key attributes - high scalability, high speed and low latency. The book prescribes Linux - community based or the commercial ones - as the right platform that can leverage the GPP in these SOCs to the best possible extent.

TI seems to have done tremendous work in the world of Codecs and addressed a lot of problems related to inter-operability, packaging and deploying quite efficiently. XDAIS, XDM, RTSC etc., seem to give a system integrator the freedom to try various Codecs and the scalability to switch between platforms easily.

TI apparently also has a whole lot of supporting software for these platforms - various VISA codecs, DVSDKs, Code Composer Studio, QualiTI, packaging tools - that make the lives of a system integrator far easier that what it was before. The best part, most of these software are available free for the community. The platform specific packages, Me gathers, leverage the potential of open source communities to a good extent.

All in all, a wonderful book for beginners. A perfect ten on ten for the way the material is presented - simple and interesting. Gave me a good list of things to try on Beagle. A must for everyone starting off on OMAP or DaVinci platforms.

Me's never bothered to check, so far, what TI has been upto with its products, in detail. The more Me learns about their products and their passion towards keeping things open - Me's becoming quite a fan of TI.

Me.

Further reading:

Dummies Book online: www.ti.com/dummiesbook

USB-OTG - A brief

Dealing with the USB OTG on Beagle has been quite a learning experience, especially, since my knowledge of USB was very minimal. This is Me's attempt at providing a brief about USB OTG.

USB was first introduced to address desktop's connectivity with various peripherals - printer, mouse, keyboard, serial, parallel, PS2 etc. It was quite successful - so much so that almost all peripherals and devices that need PC connectivity these days use USB.

USB has further been extended to other devices, mobile phones in particular and the functionality has been extended from mere PC connectivity to include charging, transferring video etc.

The USB master/ slave architecture that USB generally used - where a host acts as a protocol master and a USB device (peripherals) act as the slave - were sufficient to address most usage scenarios. The host always initiated the configuration/ data transfer from the peripherals in these cases.

Specifically, a usage model started emerging - the one where a device needed to either act as a host or a peripheral based on the situation. A typical example would be when two mobile phones could be connected for data transfer - where one would act as a device and the other as a peripheral. The same mobile also needed to act as a peripheral when connected to a PC. A need to have one connector on the mobile for all purposes - charging, to connect audio headsets, for data transfer - also played an important role in the introduction of USB OTG during late 2005 - early 2006 timeframe. The miniature nature of these devices also resulted in mini USB connectors to suit their form factors.

USB On The Go - USB OTG in short - introduced  two new protocols: SRP - Session Request Protocol and HNP - Host Negotiation Protocol.

SRP allows both communicating devices to control when the link's power session is active. This was not available in the standard USB spec - only the host was capable of doing so. This fine control over the power consumption resulted in significant power savings in battery operated devices like cameras and mobile phones.

HNP allows the two devices to exchange their Host/Device roles, provided both are OTG dual-role devices.

USB OTG protocols cannot pass through a standard USB hub - since they are based on physical electrical signalling.

USB OTG defines two roles of devices: OTG A-device and OTG B-device. The terminology defines which side supplies power to the link, and which is initially the host.

OTG A-device is a power supplier, and an OTG B-device is a power consumer. The default link configuration is that A-device acts as a USB host and B-device is a USB device. The modes may be exchanged later by using HNP.

USB OTG standard introduces a new plug receptacle called mini-AB. It can accept either a mini-A connector or a mini-B connector. USB OTG also adds a fifth pin to the standard USB connector called the ID-pin.

The mini-A connector has the ID pin grounded (connected to GND), while the ID in the mini-B connector is floating (non-grounded).

A device that has a mini-A plugged in becomes an OTG A-device and the one that has mini-B plugged in becomes a OTG B-device. The type of the plug inserted is detected by the state of the ID pin.

Beagle Context:

Beagle has a mini-AB connector and has both modes of operation. When connected to a PC it is a peripheral and when it is connected to other devices like a USB hub, keyboard, mouse, USB Ethernet etc, it playes the role of a host. When Beagle is required to play the role of a host, the cable that is required would need to be in the OTG-A mode.

In the market, almost all USB cables with a mini-AB connector are of OTG-B configuration. Me had scourged the local markets in Bangalore and Hyderabad, and couldn't find a cable that was made in a mini-A configuration. What makes matters worse that none of these cables had any indication about whether the cable has OTG-A or OTG-B configurations. The shopkeepers would hardly understand OTG, complicating things a little further.

So, to get USB on my Beagle working, Me had to choose between meddling with the board and modifying a cable. For obvious reasons, Me choose to modify the cable. Lucky for me the connector opened up pretty easily. But unfortunately, unlike the other pins, the ID pin was trimmed off making it very challenging to connect it to the GND pin.

After a whole lot of struggle, ended up with a connection as shown in the picture here. Had to take a small strand from a USB cable that Me had opened up earlier, use the solder to firm it up, and then put up a struggle to connect it between the ID and GND pins, making sure that it didn't touch any of the other pins.

Me's opinion - USB standard or atleast the cable manufacturers should come up with a standard way of indicating the OTG configuration that the USB A to mini-AB cables are made of. If not anything, that'd save some time and effort for folks who scourge the markets for specific cables.

-Me.

Further reading:

USB OTG on Wikipedia: http://en.wikipedia.org/wiki/USB_On-The-Go

USB OTG on the USB.org website: http://www.usb.org/developers/onthego

Maxim's app note on USB On-The-Go Basics: http://www.maxim-ic.com/appnotes.cfm/an_pk/1822

Serial Communication - a brief

Thought Me'd just scribble a few notes about serial communication - all that Me discovered after the first experiences with booting up Beagle and getting RS232/ serial communication working. 

Serial communication, in a nutshell, is a process of sending one bit at a time, sequentially, over a communication channel, usually a computer 'bus'. Historically, this mode of communication has been used for long haul communication. Offlate, serial computer buses (like USB) have become more common, 'cause of the advantages they have over another mode of communication, the parallel communication.

The most extensive usage of serial communication in history has been to network computers using modems. A serial port on the PC was designed to be connected directly to an external modem. Thus, it is termed as "Data Terminal Equipment" (DTE) and the modem is called "Data Communications Equipment" (DCE). 

RS232 is a standard developed by the Electronic Industries Association (EIA) and other interested parties, specifying the serial interface between Data Terminal Equipment (DTE) and Data Communications Equipment (DCE). The RS232 standard includes electrical signal characteristics (voltage levels), interface mechanical characteristics (connectors), functional description of interchange circuits (the function of each electrical signal), and some recipes for common kinds of terminal-to-modem connections. The most frequently encountered revision of this standard is called RS232C. Parts of this standard have been adopted (with various degrees of fidelity) for use in serial communications between computers and printers, modems, and other equipment. 

The serial ports on standard IBM-compatible personal computers follow RS232C, and are full-duplex devices, in that they can send and receive data at the same time. They are both male connectors, as given in the pictures below. These serial ports, typically, use two separate lines for transmitting and receiving data.

The pin assignments for the above connectors in both roles (as DTE and DCE) are as follows:

RS232C, however, does not define bit rate, character framing, communication protocol, character ecnoding, data compression and error detection, which must be agreed by both sending and receiving equipment for a successful transmission. These are typically manifested as settings in the software/ serial communication clients that are used by either ends.

The most commonly found and simple usage of serial communication is found in communication using Null modem cables. In this communication, the RxD of DCE is connected to TxD of DTE and vice versa, and the common grounds (G) are connected together.

Lately, serial ports are being deprecated in the latest platforms, and USB is taking its place. However, there are USB to serial adapters widely available, that make interactions with legacy systems possible. 

Beagle, exposes a RS232 port, to which an IDC10F to DB9M adapter can be connected to expose out a serial interface. The reference manual, very cleary indicates the wiring that's required on such an adapter. Me's had some trouble regarding this, as outlined in my earlier post.

More resources:

Maxim's app note: http://www.maxim-ic.com/appnotes.cfm/an_pk/83/

TALTECH: http://www.taltech.com/TALtech_web/resources/intro-sc.html

Wikipedia: http://en.wikipedia.org/wiki/RS-232

--

Me.