Industrial Intelligence Gathering

Csd is tracking the port of the palm OS to the ARM core. This work in being done in Dallas at Texas Instrument.

Looks like the Palm ARM port may be in a bit of trouble. Palm is still using the Motorola Dragonball.

ARM is a very expensive solution. And may not be as hardware extensible as the 80C52 cores!

There's a typo on on the chart below the picture. Not Philips #PDIUBD12 but PDIUSBD12.

Portinelligent, of course, is mechanized industrial espionage on an apparent international scale. Sunday April 21, 2002 09:07

UNDER THE HOOD

A PRODUCT TEARDOWN REPORT WRITTEN EXCLUSIVELY FOR EE TIMES

BY DAVID CAREY

A look inside the Palm 1705—the early-2002 replacement for the aging Palm VII—reveals an ever-cheaper design point for capable, but not necessarily blazing, data radios and their companion PDAs.

With the exception of limited circuitry associated with the monochrome liquid-crystal display panel, all electronics for the Palm i705 are contained on a six-layer circuit board. Studying the main assembly, the usual suspects for a Palm handheld appear: Motorola’s Dragonball processor, 8 Mbytes of Hynix SDRAM and 4 Mbytes of Fujitsu flash, along with a Philips USB controller, Maxim RS- 232 circuit and Analog Devices touchscreen digitizer.

Interface circuitry for the expansion memory card interface is handled through a Xilinx 64-macrocell complex programmable-logic device. Power-management devices from Linear Technology, Siliconix and Maxim are paired with two Sony lithium- polymer batteries to provide an estimated 3.9 watt-hours of power.

Key to the i705’s Mobitex-network- based wireless data connectivity is Motorola’s MCi 3760VF multiprotocol, multiband digital transceiver. The Bi- CMOS part integrates fractional-N synthesizers, a reconfigurable zero-IF receiver with programmable bandwidth, receive A/D conversion, multirate data interface to the baseband DSP, direct-launch digital modulator and full transmit support circuits. Ironically, Moto’s data sheet for the MC- 13760 outlines many supported protocols, but Mobitex is not among them.

The cast of supporting characters includes an Agere baseband processor, an RF Micro Devices power amp and a modest complement of RF modules and discretes. Internal multilayer ceramic antennas from Murata are used for independent receive and transmit propagation paths.

Our estimated cost-of-goods-sold for the 705 was below $100, less than 25 percent of the $449 retail price. Expect snappy price reductions and/or feature enhancements, since current i705 gross margins appear healthy. Color LCDs would be a sensible addition to provide a more compelling wireless Web-browsing experience— even in the “clipped” format mandated for the i705. Voice capability mirroring the competing Handspring Treo and RIM Blackberry 5810 should also be on the short list.

Meanwhile, our experience with the wireless connectivity proved disappointing, despite our being squarely within the advertised PaImnet] Mobitex coverage area.

Component advancements in the i705 point to a bright future for cost- effective, low-complexity data and voice radios, but the supporting infra structure and services must improve to make good on that promise.

DAVID CAREY IS CEO OF PORTELLIGENT (AUSTIN, TEXAS; WWW.PORTELLIGENT.COM), WHICH DOES TEARDOWN REPORTS ON PORTABLE ELECTRONICS SYSTEMS.

Electronic Engineering Times April 15, 2002

Csd is doing a low-level format of its screwed-up 20 gig in preparation for installing 98 then 2000 the correct way - no copy 98 from old disk to new. So this is posted while csd is waiting.

Csd has been a bit concerned about posting articles. No lawsuit threats yet. But we can handle this if it arises.

Evans Data is cited in the Industrial esponiage feed.

Csd is now on Evans Data email newsletter list!

Instead of lawsuit threats for posting, csd gets e-mail from authors expressing thanks for reading their articles and finding their articles important enough to post! Friday March 22, 2002 10:19

DEVELOPMENTS - MONTHLY NEWSLETTER FOR CLIENTS AND FRIENDS OF EVANS DATA CORP. March 21, 2002

HOOKING UP WIRELESS - There's plenty of attention paid to the devices, but have you wondered how developers working on wireless apps plan to connect them to backend applications or databases? We asked over 600 wireless developers worldwide in our Wireless Developer Survey. Find out what they said at http://www.evansdata.com/conn.htm

NEW WIRELESS SURVEY SHIPS FRIDAY. Over 600 developers working on wireless apps answer extensive questions through in-depth interviews on subjects such as platforms, arget devices, operating systems, types of wireless apps, plans for deployment and more! See complete TOC at http://www.evansdata.com/WirelessTOC02.htm

ENCRYPTION CHIPS IN EMBEDDED SYSTEMS? Could there be any doubt? Find out how many embedded developers plan to use encryption chips and which ones in this excerpt from our brand new Emebdded Systems Developer Survey - over 500 developers interviewed just last month. http://www.evansdata.com/enc.htm


If you're interested in encryption, public key may have been broken without factoring in the 1991-2 time frame.

The National Security Agency began a rather hurried effort to remove public key from US weapons systems about that time.

Much to department manager Kent Parsons and our sponsor's surprise, we completed our hardware/software project ahead of schedule. Kent served as course advisor for several FORTH courses. He appeared surprised that more staff members did not use this software technology.

Csd is not particularly interested in encryption but can hook-up encryption chips to 80C52 microcontrollers. And has hooked a Cylink 1 2 Cy 1024 public key encryption to an 80C51 using mode 0 synchronous communications.


LINUX IS COMING The next volume of our continuing Linux Developers Survey will be released in two weeks to subscribers. Interesting topics this time include how Linux developers are planning for web services, views on security in OSS, thorough examination of tools, targets, etc. Request a FREE preliminary TOC from [email protected]

THE TYPICAL DEVELOPER PROFILE. He's a male, between 36 and 50 years old, that makes between $55K - $100K per year. How do you get him to listen to your marketing mesage? Find out which marketing methods he prefers at http://www.evansdata.com/way.htm

DO YOU NEED TO MARKET YOUR TOOLS TO DEVELOPERS? - Before you plan your next campaign be sure you order the ONLY in-depth study on tactical marketing methods and media for developers. In-depth interviews with over 500 developers examines purchasing patterns and authority, pricing, most trusted media, publications, e-zines, manufacturer's websites, best resellers, e-mail and Usenet, and WAY MORE! See TOC at http://www.evansdata.com/DMPTOC.html

Evansdata is involved in legal industrial espionage. This is interesting.  Friday March 8, 2002 19:53

Study: Most Software Developers Are Male

A survey by industry research firm Evans Data Corp. [www.evansdata.com] describes the typical software developer as a male between 36 and 50 years old, The study included interviews with 500 software developers. Of these, only 9% were women, down 3% over the last two years. According to the survey, developer salaries didn’t seem to be affected by the economy in 200 1—over 60% of developers still make over $55,000 per year, and almost 40% of them make over $75,000 per year. However, there has been some erosion in career satisfaction. The number of developers who would not switch careers for more money has dropped 9% since last year. Developers are now evenly split between those who would switch and those who would not. And 62% of developers do not lock themselves into one vendor’s solution when buying their tools, but prefer to get them from multiple vendors by purchasing “best of breed.”

PRINTED CIRCUIT DESIGN MARCH 2002 www.pcdmag.com

The Kirksey article was inadvertenly deleted this morning.

It's reposted along with the Lewis comment.

Also, watermarking uses a kind of steganography to encode copyright info.

--ted
Ted Lewis, Ph.D.
[email protected]
ph# 831-484-1240, -0730fax

We must all be careful that hardware or software doesn't contain features that we are unaware of.

This is a real problem. Thursday March 14, 2002 19:55


Back to Basics
by Kirk Kirksey


The Art of the Secret Message

Steganography, the ancient method of hiding messages in ordinary places, is still being used in the computer age; by hiding information in common files.

The ancient historian Herodotus tells the, story of Demartus, who warned his Greek compatriots of a coming invasion by hiding a secret message on something very common—wax tablets. Demartus avoided detection by scraping off the wax, writing his message on the underlying wood, and then covering the tablets with fresh wax.

The tablets appeared blank and were never questioned as they passed through enemy lines. The story of Demartus warning may be the first recorded example of steganography—hiding a message in something ordinary and easily overlooked.

Steganography has tamed up in some mighty odd places. Messages have been tattooed on shaved heads. After the hair grew back, the message, was hidden, and could be read only after a courier had an appointment with the barber. Invisible inks are also a form of steganography. Spies have used milk, vinegar, fruit juices and urine to record messages to their compatriots. These substances disappeared as they dried, but darkened again when subjected to heat.

A 'more modem example of steganography involves hiding a secret message in text. Here's a real example taken from a message sent by a German spy. in World War II. The original message was:

Apparently neutral's protest is thoroughly discounted and ignored Isman hard hit. Blockade issue affects pretext for embargo on byproducts, ejecting suets and vegetable oils.

This was the real message:

Pershing sails from NY June 1.

The technique is called "word shifting." Take the second letter of each word in the original text, and you can easily see how the message was hidden.

With the speed and sophistication of today's computers, techniques, like word shifting can be easily detected. Have modem computers done away with steganography? Not by a long shot. Take another look at that GIF, or listen carefully to your favorite WAV file. Everything looks fine? The music sounds good? Perhaps. Then again, there could be a secret message, right there under your nose. No—steganography is alive and well in the computer age. Here's a bit about how it works, and how you can use it.

Encryption vs. steganography

Encryption and steganography are easily confused. Encryption is the art, of scrambling a message so that it becomes unreadable. Before computers, both the sender and receiver needed the same secret code to unincrypted the message. Young boys in the I 930s commonly used the. Captain Marvel decoder ring to send and decode secret messages. This is called symmetric encryption. When computers came along, symmetric encryption was not practical.

This problem led to the development of asymmetric encryption. For asymmetric encryption, the sender needs one type of secret code to scramble the message, and the reader needs another key to decode the message. The scrambler code is called the "public key," and can be used by anyone wishing to encrypt a digital message intended for a particular individual. The message can be unscrambled only by using a "private key," which is known only to the receiver.

Steganography is not message-scrambling or encryption. In the computer age, steganography is the art of hiding a message in a common file. This file, when accessed by an unsuspecting user, may look or sound innocent., The real meaning emerges only after processing the file with special software. This message may be "human readable" or encrypted. Believe it or not, common hiding places for steganographic messages are innocent looking GIF, JPEG, and WAV files, spreadsheets, and even word processing files.

Steganography methods

There are several methods used by steganography software to hide messages. Take the electronic version of this article, for example. When my editor loaded the word processing file into her computer and accessed the file, she was looking at the same words you are—plus all the bad grammar she had to correct. To the human eye,' the white space between words looks normal. However, steganography software could embed a secret message by slightly altering the space between words. This difference would go unnoticed by the casual reader. When processed, however, the variations in word spacing could be translated into a secret message.

GIF picture files are one of the most common hiding places for secret messages. This technique uses something called the LSB (Least Significant Bit) method. Here's' how it works. All colors in a GIF image are derived using the RGB (red, green, blue) palette. When a GIF image is loaded, every' screen pixel is assigned three RGB values. The combination of the three values determines the color of the particular pixel. For most GIF image's on the Web today, the three RGB values are held in an 8-bit number (a combination of just eight 1s and 0s). Under this scheme, 256 colors are possible because the maximum 'value of an 8-bit binary number is 256. Here are some examples of 8-bit binary numbers and their decimal equivalents:

00000000 0
00001101 = 13
01010100 =84
11111111=255

The right bit or. number in the binary number is called the LSB. In our example, the LSB of 00000000 (decimal 0) is 0. The LSB of 00001101 (decimal 13) is 1. Changing the LSB will have the smallest effect on the binary number. Altering the exact value of a binary number may be critical in precise mathematical calculations, but it is not so important when it comes to displaying a GIF image on a Web page. The reason is simple. When viewing an image (any image), the human eye is not capable of detecting very minute changes in color. This is especially true considering light and intensity variations caused by typical computer screens.

It's easy to see how steganographic software can use the LSB to hide messages in a GIF file. First, the secret message is converted to' its binary form. Then the GIF image is processed. For the RGB value of each pixel, the true LSB is replaced with a binary digit from the secret message. Color changes caused by this bit-fiddling cannot be detected 'when the image is viewed. The message is decoded by processing the GIF file, and extracting the LSB from each pixel. Unlike Humpty Dumpty, steganographic software reassembles the bits, and voila—the secret message is revealed.

Want to try your hand at a little steganography? Try Stego at www.stego.com. It's one of the best steganography products around and—best of all—it's free! Happy hiding.

Did you know...?

Spanish scientists in Belize have discovered a fungus capable of eating the metal surface of compact discs.

Contact Kirk at:
[email protected]


ComputerScene March 1, 2002

Here's an interesting email from the mechanic on Sun, 3 Feb 2002 08:57:09 -0800 (PST) to a response by csd.

Espionage is getting information is easiest way possible.

Direct questions may be a good way. Provided the questionee doesn't get a bit suspicious.  Monday February 25, 2002 19:17

> Friday 2/1/02 9:48 AM >

> We did what we did at sandia with forth to save ourselves from bad software
> experiences. Others who didn't use an operating system on the target micro
> simply did lots of work and their codes didn't work very well.

Digging yourself into a very deep hole is quite easy. And that's not fun, it's HARD WORK.

> I do lots better financially writing c/c++ dll and wdm drivers along with vb
> apps, than I do with forth.
>
> My customers make all of the money with the forth machines! It doesn't take
> me long to do forth software and forth is super-reliable in the field.

> What now intrigues me is what cypress has done. When I do forth I do forth
> I do LITTLE PROJECTS ... not exeeding, say, 150 screens.
>
> I see a need for a CHEAP INTERACTIVE rtos on the cypress development board.

I think the main challenge there (and to a large extent an oxymoron) is "INTERACTIVE". Interactive and RTOS (at least as I think of "RTOS", a multithreaded/tasked service-provider/supervisor) don't seem to be compatible paradigms. But I understand how forth is interactive, and when non-interactive is/can be a RTOS.

> Keil software is too expensive and too main frame oriented in operation.

The K.I.S.S. concept seems seldom applied to software. As I know you are aware, such huge beasts will never come any closer to perfection than they are: the time spent refining them is typically not as much as the time spent developing new features for them; marketing people have to have something to sell. More bloat, less documentation per feature (after all, anything that responds to mouse clicks is practically self-documenting, right?!)

> With the fast usb 2.0 communications, I see that the computations can be
> done on the pc side either in ring 0 or 3, not on the peripheral side.

But then there is the apparent move to a "controllerless" paradigm in USB (I think I read this on your website?): USB periphs being usable w/o a PC to control/supervise them. If the PC is removed, how does this affect the above strategy?

> Computing biz is a bit slow so I'm going to try to port the forth in my book
> to the cypress development system. And update the old dos environment to a
> windows app and associated dll and wdm drivers.

I'm quite curious how much yout forth for 8051 has changed from 1990 until now. And what your plans are for moving both the PC host and the target code "into the new millenium". Since writing the 8051-Forth book, have you ever used _non-8051_ Forth in a product development?

> I need to learn about usb drivers. I have the Compuware/Numega usb code and
> now I'm studying the cypress ezusbsys.c code. And comparing both.

I have DriverStudio 2.5 sitting here, but had some install troubles; I might take a look at this myself...

> I agree with your view about forth. That is one reason we supply all source
> code. The development system generates itself from source.

This is both intriguing and daunting: the concept is magical, but understanding it (fully) takes dedication and comittment (as you mention on one of your web pages:) YEARS worth of it. As long as the effort pays off, OK, but if it's a rathole...

> So one doesn't have to rely on anybody to get the system working.

As you may have gathered from my "text editor" story, I am very much in favor of being self-reliant, sticking to tried and true, and leveraging my skills maximally while building my own tools.

<The mechanic>

Lewis [bill's phd student] wrote The Crash of 2000.

Lewis was a bit off on AOL Time Warner's economic troubles. Try 2002.

Japan Inc is not in good economic shape.  

Masanori Fushimi  has an autographed copy of Embedded Controller Forth personally delivered to him in Tokyo .  And a copy of the SAND report 4 too *#@!.  

Richard Hanson worked with Masanori and suggested that bill contact him.

 

Japanese feel Americans don't apologize enough.  

Here's Masanori's meishi [business card].

There may be lots of high tech people doing something else for a living by the end of this year.

But Csd is optimistic about the economic future of hot 80C52s, USB 2.0 and even 80C52 forth.  Friday February 22, 2002 07:40

The mechanic appears to be up to something.  

Csd later learned that the mechanic puchased Compuware/Numgea DriverStudio 2.5.

The mechanic emailed csd some very perceptive comments about forth perceptions in silicon valley.

We all might wonder with such negative comments about forth why the mechanic is doing what he apparent is doing.

Csd posts redacted, a legal term, portions of the mechanics comments. Their veracity are well worth considering.

But there are the "Yeah, but ..."s too.

It is extremely important to get all views out there so you can decide on what you want to do.  

It's your money and your future!

This is why we post what we post ... and do some high tech consulting and contract work too!

We should all be in this to make money, not lose money.

Let's hope experience helps us do this. Friday February 7, 2002 08:04

The mechanic bought a copy of Embedded Controller Forth.

The mechanic emailed Sunday January 13, 2002

Hello, I purchased your book awhile ago and was seeking soft copies of any related files. I found http://www.nmol.com/users/billp/forth.htm , but the links to the files shown as downloadable (at the top of the page) are broken.


Do you have any other places online where these files can be obtained? Thank you!

Cheers,
"the mechanic"

P.S. I amazed where you find the time to do device-driver development and still maintain your automobile (which seems to no small task), AND document all of the above online. In fact, reading your excellent stories motivated me to go out and fix a problem on my "antique" (1987) vehicle. Building an "intimate long term relationship" with one's car is fairly rare (at least here where I live in "Silicon Valley", where the focus is so heavily on on-the-job-work), it was cool to read of your travails and creative, thoughtful solutions. As to lawyers? Kill 'em all!

The csd received a really interesting email from the mechanic on February 1, 2002.

> why are you interested in 8051 forth?

There is a reason I am interested in it. ...

All of the stuff I work with is 32/64-bit MIPs, on a Linux or ThreadX platform (ie. C language); embedded applications. We won't be making millions of what we're designing, so cost of HW, while not ignored, is not our top minimization priority. Plus we need massive processing power (compared to 8051).

> why are you interested in 8051 forth?

Remember, you asked!

Let's just say I have a long-time, distant appreciation/curiosity that someday I might find an opportunity to use it. I kind of have a "love-hate" relationship with forth. The kernel of the idea is tremendously elegant, and (given sufficient hardware, which I don't think of the 8051 architecture as being) efficient. The interactive nature of the language, the "do-it-yourself", "no limits" attributes, (etc.) are appealing (but are usually double-edged blades). As someone who has spent 16 years of my life writing real-time (embedded) software, I am always looking for ways to reduce complexity, improve software quality, and make my job easier w/o incurring substantial runtime cost.

When I find a good idea (not often), I make a substantial investment in it (an example below). Becoming fluent in Perl is an example of an investment that has paid off hugely for me. Forth has never succeeded in crossing over the threshold from "gee that's cool" to "wow, this is something I should really dig into! Look at what I can do!".

What I don't like: Forth is almost "a way of life", and the total freedom it gives programmers is often abused (to the point of write-only code). Idiots (and there are many developing software) coding in C cannot submit (for a shipping product) program code that does not compile. The code may be bad, but it does follow rules. There are code formatting conventions that are actually followied by most of the prople I had shared code with. With Forth, there are "screens" and funky editors. If I wanted to use a funky editor, I'd learn vi!

Also, my C/C++/Perl/Awk programming skills are fully portable to a new problem and/or employer (this has been proven by 8+ different jobs in these past 14 years). These are the lingua franca of my field, where I have spent my time adding knowledge.

Forth is a "blind alley" by comparison: Forth knowledge, due to the mutability and non-standard-ness of forth, is IMHO less portable than the above skills, and the lifecycle considerations of forth tend to be crippling (my manager: "if I choose to do this project in forth as you advocate, who will pick up the job if/when you leave/die riding your motorcycle?". My answer: "[duh?] I don't know any other forth programmers"; vs. "well, C (or ASM) programmers are a dime a dozen"). A parallel case: a consulting job I've been handling for the past 6 years is written in Modula-2; if/when I give up the job, the client will be hard pressed to find another who can support him. Someone made a poor decision many years ago...

[Brief digression: I (by accident) practically taught a class in Forth in the mid-80's while I was in college (the teacher knew less than I did, so deferred to my "expertise" regularly). As with everything else worth mentioning, I am self-taught in Forth: I read voraciously. And this is to say: I _like_ forth; I have a collection of (by definition) old Forth books, and I occasionally dig them out; my favorite is "Thinking Forth", which is not really Forth specific anyway. But forth has never achieved critical mass for me]

Forth also has a bad reputation in the industries I circulate within: it is percieved as more of a religion than a useful, common (in many senses of the word) tool. I visit various websites which crow about Forth being used in this or that project, but I am generally not swayed: a list of projects written in Forth does not even begin to counter the tens thousands of projects NOT written in Forth. The percentage of products delivered written in forth (IMHO) must be well under 1%. So, yes, you can deliver using Forth, no doubt. But ditto for ASM (but who except a masochist would want to?). What does that prove? There are other considerations, as you well know.

Last reason for being interested in your website: you are doing what I dream of doing: NT/WinWDM device drivers (I have taken a univ class on this 3 years ago, got an "A" (and had fun!), so I have a clue about it), combined with embedded programming (clearly, something I find enjoyable; there's too much headache involved in this area to stick with it if you don't enjoy the challenges and the "clean slate" design opportunities unavailable when working in Windows, etc.). As a consultant, you have to focus on delivering, knowing yourself, your skills, making the sale, then delivering. So this is an area I'd like to pursue (in my dreams). But technology moves SO FAST, and nowadays with a family and young kids, I have little enough time to spare s it is. I've done a little consulting, always succesfully, but somehjow it never seemed to come close to transitioning into a career. I guess I just never pushed it.

Last reason for having avoided doing any major projects in Forth: the development side of Forth is (like everything else about Forth) a world unto itself: bizarre editors, strange file formats. I wrote a tiny Perl program the other day to convert Forth .SCR files into ASCII text format, so I can read them using "normal" text file tools. I have been using the same programmer's text editor for 15 years (supported and extended only by myself; the vendor never offered any support for it, and to this day I have never found another editor that offered the reverse-polish style that I came to love the first week I started using it). My editor is wired into my brain. I think of new features to add to it, and I can (and do) add anything I can think of (I have reverse engineered the entire editor from a Win32 .EXE file, starting from no source code, and currently write extensions (or correct what few internal bugs remained) in C/C++, Delphi (Pascal) and compiled AWK). This editor has given me power-editing capabilities that have easily supported my work in C/C++, ASM, Perl, Modula-2, Pascal and Awk (after all they all have the common input of ASCII text source files) and general data analysis. Needless to say, I _don't_ use "IDEs". People who watch me work are blown away by what I can do, but like learning a musical instrument, I've put a substantial portion of my professional life into developing the skills and the tools. The return on this investment of mine is correlated to the amount of investment made, which is why for me personally, moving to a totally new environment is a bigger and bigger difficulty as time goes on. Also, the power of tools like Perl cannot be brought to bear in a forth world; it's forth or nothing. And that myopic situation is unfortunate (but real).

So, if you've been able to follow my long rant, you'll understand me (as a software developer) pretty well. I hope I've answered your question!

Cheers,
The mechanic

The mechanic's future emails get even more interesting.

es-pio-nage n. Fr espionnage espionner, to spy; espion; It spione; spia, spy; Gmc speha, akin to OHG spehon: see SPY 1 the act of spying 2 the use of spies by a government to learn the military secrets of other nations 3 the use of spies in industry or commerce to learn the secrets of other companises

Spying, of course, requires social skills, like the ones the mechanic seems to exhibit above.

Stay tuned, csd may have to post some even more interesting emails.

Spy stuff, of course, is interesting. 0 0a 1 2 3, especially now that we're all now communicating  on internet 1 2.  

If success of a spy project is measured in terms of dead kids, this was clearly a winning project. 0

But we have more imporant things to do than the spy nonsense. Try to make some money and have some fun doing the work.  

We have to port embedded controller forth to the cypress 3761 and 3861 development systems.  So we don't have to send several thousands of dollars to Keil in Germany for a mainframe mentality development system.

We want to go modern.  Incremental compiles and assembles on the target - not the PC.  Dynamic loads and links. Destructors and constructors on the 80C52.

Yeah but, we need the reliability, interactivity, low cost, quick app development time source code generation of 80C52 forth connected to Windows!

Hosted by www.Geocities.ws

1