The wheels of academia have begun to turn and I've been approved to start my thesis project in the Center for Wireless Communication (CWC). I can't give out many of the technical details yet, but let me just say that it's insanely cool and has to do with the Eyeborg Project.
If you've never heard about the Eyeborg Project, please check out their channel on vimeo and visit their homepage (www.eyeborgproject.com).
20100119
Fake USB Flash Drives
Hi folks,
For the last couple of years, there seems to have been a huge influx of so-called 'fake' USB flash drives. Why they are called fake, is
Although I purchased my 4GB USB storage device a long time ago, I always keep electronic records of my purchases. This unit was purchased on Amazon.de, from a 3rd party reseller called MemoryWorld.de . I highly suggest that Amazon should blacklist this vendor for selling fake or counterfeit USB flash storage devices.
My particular device has USB vendor ID (VID) 2008 and USB product ID (PID) 2018. I'm not really sure where you would look for this in Windows, however, in Linux (using lsusb) this device will show up as 2008:2018 .
I'll post some detailed photos of the device later, but I just opened the casing and the USB transceiver is an UHC2008. The company that makes this is called "Shenzhen Sea Song Microelectronics Co., Ltd". The label on the storage chip is SFO8BGTP. I'm not quite sure who this belongs to yet though.
Just in case anyone has the same device, there are some instructions for how to fix and verify the device here. Unfortunately, the instructions assume that you are a Windows user. Hopefully I'll be able to find out if there is an equivalent tool for Linux.
For the last couple of years, there seems to have been a huge influx of so-called 'fake' USB flash drives. Why they are called fake, is
- they report a storage size larger than they can actually store
- maybe they use compression internally
- maybe they just allow data to be overwritten without warning
- they often cannot be used as a bootable USB device
Although I purchased my 4GB USB storage device a long time ago, I always keep electronic records of my purchases. This unit was purchased on Amazon.de, from a 3rd party reseller called MemoryWorld.de . I highly suggest that Amazon should blacklist this vendor for selling fake or counterfeit USB flash storage devices.
My particular device has USB vendor ID (VID) 2008 and USB product ID (PID) 2018. I'm not really sure where you would look for this in Windows, however, in Linux (using lsusb) this device will show up as 2008:2018 .
I'll post some detailed photos of the device later, but I just opened the casing and the USB transceiver is an UHC2008. The company that makes this is called "Shenzhen Sea Song Microelectronics Co., Ltd". The label on the storage chip is SFO8BGTP. I'm not quite sure who this belongs to yet though.
Just in case anyone has the same device, there are some instructions for how to fix and verify the device here. Unfortunately, the instructions assume that you are a Windows user. Hopefully I'll be able to find out if there is an equivalent tool for Linux.
20100108
Picasa for Linux, Multi-touch, and Software Patents in General
I should state this clearly at the beginning of my post, just so I don't come off the wrong way. I do appreciate everything that Google has done and how they have contributed back to open-source software. The same is for Apple - I am grateful that Apple helped to revolutionize the user experience and to inject a fusion of art and technology in their designs. However, there are some issues (mainly revolving around the concept of software patents) that prevent many wonderful, Google-created applications from being wonderful on Linux.
Three examples come directly to mind:
1) Picasa for Linux: does not support viewing or uploading of video files.
2) Android: does not have a 'playmp3' binary when built from source.
3) Android: does not support mulit-touch (using the commercial ROM). update: Newer Android devices do support Multi-Touch, with open drivers. Thanks Google!
With respect to my first issue (and I'm sure that anyone who has a child and a Cannon point-and-shoot digital camera will agree with me) I make a heck of a lot of videos. In some cases, I make more videos than still photos. Picasa (for Linux) does not support videos at all because many video codecs (although there are free implementations) require royalty payments to be made to some patent holder. Maybe Apple and Microsoft do make these royalty payments, and thus can provide the video codec binaries to applications for their platforms. I can't even use PicasaWeb to upload videos of my toddler, and in that case Google wouldn't even need to redistribute any royalty-encumbered software. There's something wrong with this, but let me address the other two points before beginning my rant.
As for the second issue, I believe its a similar situation. Perhaps Google does make royalty payments to Fraunhofer (the 'owners' of the mp3 format patents), which allows them to distribute a device with an mp3 decoder. I would certainly hope that Fraunhofer provides Google with the code, because if they're just using ffmpeg or lame, then there is definitely something wrong with that situation as well.
Lastly, with respect to the third issue, Apple holds patents for mulit-touch and has requested that Google intentionally cripple the Android UI. I can fully understand that a patent could and should be granted for the physical device that senses multiple points of contact, but as far as Apple having a patent on software to read that device (i.e. the driver) and software to interpret that device for a user-interface, that's just absurd.
What all of these issues have in common, is that they all revolve around the same concept: the patentability of software. Along with 90% of the world, I do not believe that software should be patentable. Typically, a patentable 'device' should be 1) novel, 2) useful, and 3) non-obvious. In at least 50% (but more likely 80 or 90%) of software 'patents', they rarely satisfy any of those three conditions, at least in this day and age.
Historically, patents were introduced in order to encourage innovation. A company bringing a new invention to the world was awarded the patent in order to prevent others from wasting their time trying to come up with the same, patented product. This encouraged competitors to come up with different or better inventions. A company awarded a patent was therefore awarded adequately for their hard work, with their physical design being preserved for a limited time. After that limited time, competitors could begin to offer similar inventions on the market. Seems pretty fair to me.
However, software (in the truly scientific sense of the word) is math. Math is a collection of ideas. Patenting ideas has never officially been supported by any patent system. I really think that the only law that should apply to software is that of trade-secret and copyright. Surely, if one company copies the software of another and pawns it off as their own, then that is illegal.
On the other hand, if another entity can legitimately show that the software (be it a signal processing algorithm or device driver) had been cleanly reverse engineered, then that other entity should legally be allowed to sell or redistribute their version of the software, especially if it more adequately suits some population of recipients or users (i.e. if it fixes bugs, works faster, etc). In the same sense, I don't consider it a crime to decipher encrypted transmissions.
I find it tragic that authors of free software are not allowed to distribute their work, and help others, because the patentability of software is accepted in 2 countries on earth. I do believe that physical things should be patentable if they are novel, unique, and non-obvious, but I don't believe that inquisitive minds should be limited.
Three examples come directly to mind:
1) Picasa for Linux: does not support viewing or uploading of video files.
2) Android: does not have a 'playmp3' binary when built from source.
3) Android: does not support mulit-touch (using the commercial ROM). update: Newer Android devices do support Multi-Touch, with open drivers. Thanks Google!
With respect to my first issue (and I'm sure that anyone who has a child and a Cannon point-and-shoot digital camera will agree with me) I make a heck of a lot of videos. In some cases, I make more videos than still photos. Picasa (for Linux) does not support videos at all because many video codecs (although there are free implementations) require royalty payments to be made to some patent holder. Maybe Apple and Microsoft do make these royalty payments, and thus can provide the video codec binaries to applications for their platforms. I can't even use PicasaWeb to upload videos of my toddler, and in that case Google wouldn't even need to redistribute any royalty-encumbered software. There's something wrong with this, but let me address the other two points before beginning my rant.
As for the second issue, I believe its a similar situation. Perhaps Google does make royalty payments to Fraunhofer (the 'owners' of the mp3 format patents), which allows them to distribute a device with an mp3 decoder. I would certainly hope that Fraunhofer provides Google with the code, because if they're just using ffmpeg or lame, then there is definitely something wrong with that situation as well.
Lastly, with respect to the third issue, Apple holds patents for mulit-touch and has requested that Google intentionally cripple the Android UI. I can fully understand that a patent could and should be granted for the physical device that senses multiple points of contact, but as far as Apple having a patent on software to read that device (i.e. the driver) and software to interpret that device for a user-interface, that's just absurd.
What all of these issues have in common, is that they all revolve around the same concept: the patentability of software. Along with 90% of the world, I do not believe that software should be patentable. Typically, a patentable 'device' should be 1) novel, 2) useful, and 3) non-obvious. In at least 50% (but more likely 80 or 90%) of software 'patents', they rarely satisfy any of those three conditions, at least in this day and age.
Historically, patents were introduced in order to encourage innovation. A company bringing a new invention to the world was awarded the patent in order to prevent others from wasting their time trying to come up with the same, patented product. This encouraged competitors to come up with different or better inventions. A company awarded a patent was therefore awarded adequately for their hard work, with their physical design being preserved for a limited time. After that limited time, competitors could begin to offer similar inventions on the market. Seems pretty fair to me.
However, software (in the truly scientific sense of the word) is math. Math is a collection of ideas. Patenting ideas has never officially been supported by any patent system. I really think that the only law that should apply to software is that of trade-secret and copyright. Surely, if one company copies the software of another and pawns it off as their own, then that is illegal.
On the other hand, if another entity can legitimately show that the software (be it a signal processing algorithm or device driver) had been cleanly reverse engineered, then that other entity should legally be allowed to sell or redistribute their version of the software, especially if it more adequately suits some population of recipients or users (i.e. if it fixes bugs, works faster, etc). In the same sense, I don't consider it a crime to decipher encrypted transmissions.
I find it tragic that authors of free software are not allowed to distribute their work, and help others, because the patentability of software is accepted in 2 countries on earth. I do believe that physical things should be patentable if they are novel, unique, and non-obvious, but I don't believe that inquisitive minds should be limited.
20100101
Could Google's Nexus One be Available as Soon as January 5th?
Just as many of you have undoubtedly read, Google released a new handset before Christmas to all of its employees for testing. The device is called Nexus One. A decent video introduction can be found here. One thing to note is that the 3D gaming demo (2nd video) shows Qualcomm's logo, which leads me to believe that the Nexus One most likely packs a 1GHz Snapdragon SoC under the hood. I'm very interested to say the least and am eagerly awaiting the rumored January 5th release date.
20091214
Android ARMv4T Donut Patch (revisited)
Several people have responded to my previous ARMv4T patch for the "Donut" branch of Android, and have provided excellent feedback.
I recently checked out the code again, and thought that it would be wise to do some rigorous testing of all native binaries on the Android filesystem.
Please find an updated (but still incomplete) patch for ARMv4T here.
I've thrown together a small script to disassemble and check binaries for invalid opcodes. You can find the output here.
The output shows which executables and shared libraries still have non-ARMv4T machine code, and currently only 103 of 160 components pass the test. Therefore, there is still quite a bit of work to be done. For the remaining 57 components that fail, the illegal (non-ARMv4T) opcodes are also revealed.
NB: Just in case you find diffs generated with 'repo diff' just as annoying as I do, you can use this utility to automate the patching process.
update-20091215: The build system is doing "ok", but its still not perfect. Independent of compile-time issues are, of course run-time issues. The most major issue is the subject of dynamic code generation and you can read some of my thoughts here. To address the issue, I will be working with the android-on-freerunner people. For any further discussion about this topic, I suggest you join the android-on-freerunner mailing list.
I recently checked out the code again, and thought that it would be wise to do some rigorous testing of all native binaries on the Android filesystem.
Please find an updated (but still incomplete) patch for ARMv4T here.
I've thrown together a small script to disassemble and check binaries for invalid opcodes. You can find the output here.
The output shows which executables and shared libraries still have non-ARMv4T machine code, and currently only 103 of 160 components pass the test. Therefore, there is still quite a bit of work to be done. For the remaining 57 components that fail, the illegal (non-ARMv4T) opcodes are also revealed.
NB: Just in case you find diffs generated with 'repo diff' just as annoying as I do, you can use this utility to automate the patching process.
update-20091215: The build system is doing "ok", but its still not perfect. Independent of compile-time issues are, of course run-time issues. The most major issue is the subject of dynamic code generation and you can read some of my thoughts here. To address the issue, I will be working with the android-on-freerunner people. For any further discussion about this topic, I suggest you join the android-on-freerunner mailing list.
20091209
Google Chrome Beta on Gentoo Linux
I had already tried the Google's Chrome browser (the developer edition was called Chromium) and thought it was great, aside from a few minor bugs. For example, sometimes drop-down lists would not have any entries, the menu for the flash plugin would not respond, etc. It looks like yesterday, Google released a beta version for Linux that fixed several of the minor bugs that I noticed.
I modified an ebuild to download an install Chrome from the debian package. In any event, you can put it in your own portage overlay under www-client/google-chrome-bin/, and it should do the trick. You might have to add 'www-client/google-chrome-bin' to your /etc/portage/package.keywords file. To install Chrome, just run PORTDIR_OVERLAY="/path/to/my/portage/overlay" emerge -av google-chrome-bin.
Overall, the Chrome experience is quite good. It's very fast, and I haven't encountered any errors or bugs so far. Most pages render perfectly. You might also want to install FlashBlock.
I modified an ebuild to download an install Chrome from the debian package. In any event, you can put it in your own portage overlay under www-client/google-chrome-bin/, and it should do the trick. You might have to add 'www-client/google-chrome-bin' to your /etc/portage/package.keywords file. To install Chrome, just run PORTDIR_OVERLAY="/path/to/my/portage/overlay" emerge -av google-chrome-bin.
Overall, the Chrome experience is quite good. It's very fast, and I haven't encountered any errors or bugs so far. Most pages render perfectly. You might also want to install FlashBlock.
20091205
Dalvik VM Internals
To anyone who is interested in Android, I would highly suggest that you check out this video if you haven't already, called "Dalvik VM Internals".
The video was probably published a long time ago already, but it shows just how much work went into the Dalvik VM by Dan Bornstein and others who worked on the project with him. Particularly, it really explains why it's necessary to think how code will be executed on a machine, even when writing in a high-level language such as Java, which is something C++ gurus have also been emphasizing for years.
Luckily, I do most of my work in C ;-) but I do periodically try to rewrite chunks of software in lower-level languages to mitigate certain overhead. That would involve, for example, converting pure Java or C++ image processing code to C or ASM. The topics covered in this Video do a good job at explaining ways to implement the features of higher-level languages essentially in machine code.
Very good presentation.
The video was probably published a long time ago already, but it shows just how much work went into the Dalvik VM by Dan Bornstein and others who worked on the project with him. Particularly, it really explains why it's necessary to think how code will be executed on a machine, even when writing in a high-level language such as Java, which is something C++ gurus have also been emphasizing for years.
Luckily, I do most of my work in C ;-) but I do periodically try to rewrite chunks of software in lower-level languages to mitigate certain overhead. That would involve, for example, converting pure Java or C++ image processing code to C or ASM. The topics covered in this Video do a good job at explaining ways to implement the features of higher-level languages essentially in machine code.
Very good presentation.
20091128
Alternative Browsers for Linux
All I can say right now is wow. Having been a long time user of Firefox, it's been a while since I last used a different browser under Linux... well... because there really weren't any better alternatives for a long time.However, since webkit-gtk has been stabilizing lately, I decided to check out a couple of alternative browsers that were mentioned in the Linux Browser Shootout - namely Midori and Epiphany. I already tried Chrome (Chromium) a while ago and was quite impressed. What I really liked about Chrome was a) that it was blazingly fast, and b) that it did a great job of importing my Firefox preferences and bookmarks. There are still a few other issues with Chrome though. For example, some Flash functionality does not work properly. I'm sure that will be sorted out eventually.
So anyway, on to the good stuff. Most people are familiar with Epiphany (formerly Galeon) when it used the Gecko rendering engine (from the Mozilla project). Epiphany is the official browser of the Gnome desktop, if I'm not mistaken. Back when it was based on Gecko, it was good but just seemed like a less featured version of Mozilla or Firefox. Ever since they changed the default rendering engine to WebKit, it has been blazingly fast. Epiphany still suffers from having too few preference settings for the 'advanced' user. Also, when in full screen mode (which I tend to use frequently while browsing on my EEE 701) there is an annoying button at the top-right that says 'Leave Fullscreen', and it doesn't go away (until you leave fullscreen), which becomes bothersome when trying to actually view / click something that is underneath the button. Epiphany accomplished its goal of providing a very simple and easy-to-use browser for the Gnome desktop, but it really lacks appeal for advanced users.
Next, I tried Midori - and was really impressed. Not only was it fast (using the webkit-gtk engine), but it also had a few more settings that Epiphany was missing. Furthermore, it didn't have an annoying 'Leave Fullscreen' button to get in the way of things. There are a couple of issues I've found with it still, such as random cursor placement in a text area after pressing End / Left / Right / Down, etc, but I'm sure those will get ironed out eventually too.
I'm actually writing this entry using Midori, and have to say that it's very responsive and feels extremely light-weight. There is practically zero load time when going through GMail or Slashdot. Considering the Midori project has had less time to reach maturity than either Firefox or Epiphany, and has had less manpower, I would have to give it the best review overall.
Now, I am a huge fan of Firefox - Mozilla and its contributions to the Linux community have been fantastic over the years - but I have to admit that the webkit-gtk engine will probably take the GNU/Linux Desktop Browser crown once mature whether that is in Chromium, Midori or (with little likelihood) Epiphany.
20091108
Simple Fortran Cross-Compiler for ARM
That's probably the first thing that comes to your mind after seeing the title of my latest post - but with the power of ARM processors of today, why wouldn't we run Fortran programs on them?
Fortran was (back in the 70's ... and arguably still is) the scientific computing language of choice for many academics and engineers. It became the basis for many of the most advanced matrix-algebra math libraries available to date, including BLAS, LINPACK, and LAPACK, which are used by the most powerful number-crunching machines in the world, not to mention all of the banks and stock-exchanges! What I find more interesting is that the popular math engine known as MATLAB makes heavy use of BLAS and LAPACK, as does a free MATLAB-like environment called Octave.
I should take a step back and say, that the simple cross-compiler I have devised is not in-itself a cross compiler, but a two-step solution using F2C and your friendly-neighborhood cross-GCC ;-) That is, the Fortran code is first translated to C code, and then cross-compiled into machine code. Although many people swear that a well written Fortran code pushed through a good Fortran compiler will always blow away C code (and they probably are right), it's always true that something is better than nothing. The advantage of using F2C is that you don't need to link your programs to libgfortran, and having fewer dependencies is always good in embedded systems.In any event, F2C (and the resultant libf2c) were authored by several friendly and very smart people who were kind enough to make their software available to the general public on NetLib.Org.
Using a popular perl script called Fort77, and my tiny patch, you should be able to cross-compile Fortran code to object code (.f -> .o) just like you would with C (.c -> .o). You'll need a libf2c.so compiled for ARM as well as f2c.h installed and in your cross-compiler's default search paths. I built the cross-compiled libf2c using an armv5tel-softfloat toolchain using Gentoo's crossdev, and created a small overlay for the package, available here.
I have something special on my evil agenda for this... and will hopefully be announcing something about that within the not-to-distant future!
Lastly ... for all of the gadget-geeks that are reading this... what sort of devices are you hoping to find in your stockings this holiday season? I'm fairly infatuated with the Qualcomm Snapdragon / MSM devices, but the Nokia n900 (with an OMAP chip also looks very tempting).
20091008
Stmpe2401 Linux Driver
The STMPE2401 is a multi-function device from ST Microelectronics intended for mobile, low-power applications. It provides an I²C interface for up to 24 extra GPIO lines, each with independent interrupt generation capabilities. Up to 20 of those lines can be used with the integrated 8x12 matrix keypad controller. Another 3 pins can be used for programmable PWM channels, and 3 other pins can be used for a rotator input. All of the subsystems can operate together, at the same time, and each subsystem also provides additional interrupt capabilities.
This device appears on the Peek handheld, among many others. I wrote this driver for another device which I am still unable to mention (sorry about that).
There's actually a newer chip, called the STMPE2403, I believe, which makes a couple of improvements over the original. Namely, it has an automatic sleep function that ensures the lowest power consumption possible, but it's still capable of running in 2401 compatibility mode.
In the linux kernel, this should eventually show up under drivers/mfd, with sub-components showing up in drivers/gpio/chip, drivers/input, and so on. Currently, I've only implemented the keypad functionality but have provided lots of structure for the other subsystems. Here is the patch.
Enjoy!
Subscribe to:
Posts (Atom)