B166ER – Made in Cyberspace

A few weeks ago I have received a brand new smartphone – the HTC S630 Cavalier. Despite actually having very little use for its Internet and 3G capabilities, I figured that this kind of hardware will have top-class camera, battery and speaker. The fact that it comes with WiFi and PC syncing capabitlities also meant that it will be handy on the road, especially with the 2 Gigabyte MicroSD storage card.

To make long story short: the Speaker is next to useless. The JOGGR touch interface is absolutely horrible – I had to disable it after a week, because it makes the phone nearly unusable. There is not a person in the world that would actually use the JOGGR scrolling bar on the right side of the S630.

But the device had two even bigger downsides : Reception and Battery life. The HTC S630’s battery hits 10%-30% after barely 18 hours, while barely being used. A good friend told me that switching from WCDMA to GSM would prolong battery life and improve reception. Of course then I would have to give up on all the features I don’t use anyway, so I gladly agreed.
And it worked. By disabling WCDMA, I got exactly what I needed – a great SMS machine with a good camera and a lot storage, decent battery life and great reception.

Bookmark to:

I have recently purchased an amazing piece of hardware: Logitech’s MX1000 Laser mouse. Quite frankly, it’s the best mouse I’ve ever owned – for plenty reasons; it’s somewhat heavy and comfortable, is rechargeable, has perfectly engineered sliding pads, and most notably – it measures its own movement using a laser. I happen to program real-time thermal and chemical controllers for a living, and I can really appreciate this fine piece of hardware . It’s controller chip program was probably very well written , hundreds of engineering hours put into it’s hardware and software design, and it was optimized for minimum power consumption by some of the brightest electrical engineers in the field. These are merely my assumptions, based on the mouse’s performance, but who knows, maybe there is a team of 100,000,000 monkeys that just happened to put it all together.

Just like the one that wrote the drivers for this amazing piece of hardware. It really seems that nobody takes time to optimize software these days, everything is built upon some API of API of a wrapper of some Library of an API . This is the only explanation I can find for having a 10 Megabyte resident mouse driver.
Now maybe it looks normal for kids that never saw software that had to FIT INTO A CERTAIN AMOUNT OF MEMORY or not be able to run at all. And regarding hard-disk space requirements…. Great games like Transport Tycoon fit into 11 Megabytes. If any so-called software engineer would re-write this game nowadays, it would take 550MB on the CD and 250MB memory for the world to run in .
I am not writing now about the “Good ol’ days” when men were engineers and women were secretaries. I am talking about less than 10 years ago, when software had to be efficient and compact , or at least avoid being overbloated beyond any proportion. Ten Megabytes for a mouse driver is ridiculous. If hardware engineers would be given the same treatment and level of compromise for their hardware design, my mouse would probably come with a 10 kilogram battery, a massive heatsink and would work on only surfaces within a certain reflective range.Oh, And would probably blind me permanently in case I’d flip it over to see the Laser thingy.

Bookmark to:

CCS is a very nice compiler for PIC family of micro-controllers – the compiler includes a fair amount of built-in functions, many of which deal with bit manipulation – crucial functions when it comes to communications. Too bad I have to write these manually when porting communication to the NEC 78f9418 .

Having a 7 byte bitfield and transmitting it via low-speed PWM is not complex, and this is how the original code looked like, for PIC :

for (i = 0; i < 56; i++) {
shift_bit=shift_left (&irm, sizeof(ir_packet), 1);
send_bit(shift_bit);
}

Simple – 7 bytes are 56 bits, shift_left then accepts the address of irm, which is a structure of type ir_packet, shifted 1 bit to the left. The bit is then sent on it’s way.
Writing this code without the shift_left function proved to be somewhat fun though

packetBytePointer=&(BYTE *)&irm+6;
for(o=0;o<7;o++)
{
transmittedByte=*packetBytePointer;
for(z=0;z<8;z++)
{
send_bit(transmittedByte&0x80);
transmittedByte<<=1;
}
packetBytePointer--;

}

The above piece of code first puts an address to the last byte of the structure into a pointer, then assigns the value that is at that address to a temporary parameter of type BYTE (it's just an unsigned char) , and then simply iterates through it by shifting left and applying the 10000000 mask to it.
When the iteration is done, the address of the pointer is decreased to the begin the procedure on the next (previous memory-wise) byte.
This implementation was actually better in my case than shift_left of CCS , because it does not alter the original structure, so if you are storing your operational parameters in a structure that fits the transmission packet (common for simple devices such as “dumb” thermostats and motors), you don’t need to make another copy of the structure.

Bookmark to: