Any 80x86 assembly language jobs in the US ?

In my opnion, if you want to stick with x86, you'd best learn C++. It seems to be the lingua franca of the 32-bit (and larger) world.

C is still good for the 8/16-bit world, but I don't think the old 8088/188 is being used much for new stuff. If you don't want to learn C++, then you better start learning other CPUs.

Not where I work. C++ and Java are only used to maintain older applications. C# and VB with VS.NET are used for all new development and are in highest demand. C# to do all the work and VB for the UI. But you also need to know at least two dialects of SQL, and be comfortable with ADO, DCOM, MTX and most of the other Micro$oft acronyms. Job applicants will not be considered unless they have some knowledge of .NET. Yes, it's an MS-Windows world out there.

Bob McConnell N2SPP

And what exactly is the product or service that requires such inefficient high-level languages?

Right. And all this knowledge is required for writing device drivers and firmware, which is really the only "embedded" arena that abuts such high-level applications.

Not in the embedded sector, as a rule. But then it isn't an x86 world in the embedded sector either, as a rule.

I do see a few ads for .NET, but I see more for C++/Java. .NET is certainly not something commonly used in the embedded world and not all Windows developers have embraced .NET just yet.

*** post for FREE via your newsreader at post.newsfeed.com ***

Acronyms is right, what does database stuff have to do with actual embedded development ?? Frankly it sounds like managers hearing buzzwords and acronyms and saying we gotta use this stuff because it's the "in" thing. Also I was under the impression that small, fast code was still important in the embedded world. If so then using the object-oriented languages like C++, Java, and particularly the M$ things like VB would seem counter-productive and contrary to the goal of having tight optimized code.

Another question I have is why is Windows even wanted in the embedded world ? Considering you generally don't have the typical UI as on a PC what does really Windows offer ? Seems like Linux/Unix without X-Windows or even DOS in some cases would be a better choice. Heck many bank ATMs still use some version of OS/2.

Ok, what processors are generally used in the embedded world ? Intel x86 assembly happens to be what I know best but I also know some of the older 8-bit microprocessors like Z-80 and 6809. How does one get a foot in the door ? I know several assembly languages and I could easily pickup another but I would need a chance. I certainly understand the desire to hire people already experienced in a particular area but how does one get started initially ? Given that I've been a BIOS engineer and have done a lot of low-level development on the PC platform in x86 assembly and C should count for something shouldn't it ?

-----= Posted via Newsfeed.Com, Uncensored Usenet News =-----

- The #1 Newsgroup Service in the World!

-----== 100,000 Groups! - 19 Servers! - Unlimited Download! =-----

You would think. There certainly are embedded systems around using PC style hardware in PC/104 form factor (see

and You might try grabbing a PC/104 kit and play with it. Contact PC/104 makers and ask if any of their customers need programmers.

Older 8-bit micros are still around some.Look at

and you'll find the Z80 is still around (with 24-bit registers!). The 6800 instruction set still forms the basis for Motorola's 68HC05/08/11/12 microcontrollers.

And new assembly languages, again, get a demo or eval kit. Zilog has their eZ8 (no relation to Z80) eval kit for $50. Motorola has a bare bones eval kit for the HC08. Texas Instruments has an MSP430 eval kit for $99. Microchip Technology has their PICDemo boards for around $99 and another $99 for their ICD2 low-end in-circuit debugger. Plenty of inexpensive ways to learn different assembly languages.

SFA IMNSHO .

Yes, but "embedded" covers a very wide range. The .NET maven to whom I replied may be working on something like a POS terminal that's an entire Windows PC, and that reasonably might want to talk to a database backend to maintain stock levels, look up prices, etc. Or he might be making a multimedia kiosk. Or an airport Internet terminal. Or a specialized piece of PDA software for warehouse workers. There are many possibilities. But the technologies he is talking about are not much to do with what people would traditionally think of when "embedded systems" are mentioned.

It almost never is. Despite what a few vehement (psychotic might be a better word) people will tell you, Windows CE (and even more, XP "Embedded") have very little foothold if you look at percentage of total embedded systems deployed in a year. They don't even have a majority percentage when you exclude systems that don't have the hardware resources for such OSes.

Mainly - availability of cheap programmers who are experienced-ish with the Windows API. Of course, this doesn't mean they are any use for embedded programming, but management cannot be expected to understand this.

Well, Linux is not always the answer. There are a spectrum of other OSes, depending on the market. Symbian, QNX, etc...

Yes, OS/2 1.x :)

If you had to pick one 32-bit platform to learn, it should be ARM.

I would think so, yes. I followed a fairly similar path. I had been working primarily in DOS/Win3.x/Win9x device drivers, doing mostly crypto stuff, with some embedded work as my "moonlight job". I was hired over here to work on 4- and 8-bit systems, then the company branched out into some much more powerful systems, and that allowed me to learn about PA-RISC and ARM. More importantly, it put the requisite years of "experience with ..." on my resume that I could apply for ARM-specific jobs now. Oh, and I wrote a so-far-reasonably-successful book about introductory-level ARM development, which helps the resume, too :)

If you're looking for 32-bit embedded jobs, I think your existing experience does sound very relevant. Perhaps indicate a familiarity with an ARM-cored product (a portfolio project would help) and that could get you in the door.

*** post for FREE via your newsreader at post.newsfeed.com ***

Not that it's important but I'm surprised that they're using really old OS/2

1.x, I thought they were using at least OS/2 3.0 (the first Warp version) or even 2.x for that matter. I suspect that ATMs are the only use of OS/2 left which is too bad since OS/2 definitely had potential and was more stable than anything that ever came out of Redmond. Anyway I read that many banks will be switching their ATMs to windows by 2005, now there's a scary thought - go to get some cash and get a blue screen instead.

I have no experience with ARM or any other RISC architecture, all of the jobs I've in recent years have dealt with PCs so that's Intel x86 Assembly and C and stuff like BIOS, DOS, PC chipsets, PCI, power management, etc, basically a lot of low-level and register-level programming. I've also worked with the AMD Elan processors but not the old 80186/80188 (I've worked with every other x86 processor though). I'm certainly willing to learn a RISC architecture but I don't see a way to get a foot in the door. I think that my knowledge of CISC processors, particularly x86 which is very likely the most complex of them should be worth something but the majority of recruiters and managers don't understand that. Basically I'm out of work and have been so for a while unfortunately and I'm looking for anything that matches my skills or is reasonable close so if a BIOS, DOS, or similar low-level PC development job came up then great, but I'm also willing to get into something new but along the same lines like embedded but I need someone to give me a chance and that's apparently hard to find since most people don't seem to understand that if you know one or more assembly languages (particularly if one is x86) you can easily learn another.

-----= Posted via Newsfeed.Com, Uncensored Usenet News =-----

- The #1 Newsgroup Service in the World!

-----== 100,000 Groups! - 19 Servers! - Unlimited Download! =-----

A whole new breed of "embedded" programmer is here now. Most of them have little to no concept of discrete electronics components. They are forming their own new traditions.

That's fine, but I think that some formal division of the word "embedded" is then called for. Perhaps "integrated-PC" would be a better phrase to describe these very high-level applications. They're "turnkey", yes, but not "embedded".

Anyone who works solely in the application layer is not, IMO, an "embedded" programmer. All this talk of databases and BASIC is clearly rooted in the app layer.

Think Humpty Dumpty. As long as you pay the word enough, it can mean anything you want it to mean. Setting a Windows-based SBC up so that it loads a fullscreen Flash animation at boot is "embedded" programming.

I would have thought it's very difficult (next to impossible?) to do much embedded programming without a decent knowledge of hardware?

Mike Harding