B166ER - Made in Cyberspace » Programming

Back To Personal Blogging

Shohat — Tue, 25 May 2010 21:47:26 +0000

It has been over two years since my last personal blog post. Like many bloggers, I have take a break from my blog… to do some serious blogging. The past two years have been hectic, web projects have come and gone, some crashed into oblivion while others grew to attract thousands of daily users.The largest proper blog I own turned out to be SC2Blog.com, which attracts over a hundred thousand monthly readers and established good relationships as well as a few signed contracts with quite a few gaming, hardware, advertising and media companies.

Real Time programming career has all but ended, and while I assist others with hardware programming, Web and Enterprise Application programming are my new flavors of choice. Hopefully my experience with Intranet Programming as well as leading large multi-tier Data/Web/Hardware projects and site development will come in handy.

.NET, here I come.

Bookmark to:

Starcraft 2

Shohat — Mon, 18 Jun 2007 18:49:19 +0000

I’ve been following Blizzard from the very beginning, and now it’s time to contribute something of my own to the community. I am helping with the TerranoZergus Project, and you can see the first parts of it here, right on the Starcraft 2 Blog. The Starcraft 2 forums are to be launched soon also, with a few more related sites.

Good luck to everyone in the TerranoZergus Project.

Bookmark to:

Nobody Cares About Software Engineering On a PC

Shohat — Thu, 17 May 2007 08:29:31 +0000

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:

Writing for NEC without CCS’s shift_left

Shohat — Thu, 15 Mar 2007 12:57:45 +0000

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: