Borland Turbo C

[WildW]

I'm brushing up on my old-school C programming skills, since I have a 2nd stage interview for an embedded coding job coming up. I figured a nice environment to mess about with C without getting lost in any object oriented temptions was to load up MS DOS and Borland Turbo C. Ahh, memories.

I have real MS DOS 6.2 and the now freeware Borland Turbo C 2.0. Something is broken with it though - the Edit drop-down menu is empty, and I'm unable to highlight and cut/copy/paste text at all. I'm sure this problem rings a bell somewhere in the dark recesses of my brain but I can't remember how to fix it. Maybe something missing in my config.sys/autoexec.bat? I'm able to cut/copy/paste/etc just fine in Edit and QBasic, just something is screwy with Turbo C.

Anyone have any ideas? I know I could use something more modern, but where's the fun in that?

 

[Cogman]

I don't see why you must program IN MS-Dos (other than for kicks and giggles). I would suggest using a modern compiler such and DJGPP and just writing your C code from your favorite code editor. You'd be amazed at what they get away with in embedded systems. It isn't unheard of to use C++.

 

[Emulex]

man i love borland - i'd love to see it support modern (php) libs and let me program old dos-emulation (or ncurses) style. that was so much easier for data entry than modern windows apps. full screen baby. (apple thinks its a great idea lol)

 

[WildW]

I eventually gave up with Turbo C and used a new Microsoft Visual Studio Express freebie. It was fine once I figured out how to deal with (i.e. remove) all the unicode variable types.

In the end my interview was a bizarre program-C-using-pen-and-paper affair. And I got the job

 

[Kirby]

I don't see why you must program IN MS-Dos (other than for kicks and giggles). I would suggest using a modern compiler such and DJGPP and just writing your C code from your favorite code editor. You'd be amazed at what they get away with in embedded systems. It isn't unheard of to use C++.

I'm writing embedded code now in C++ with gcc. :hmm:

 

[Cogman]

I'm writing embedded code now in C++ with gcc. :hmm:

my point exactly. There are even embedded systems out there using .Net... Crazy, I know.

 

[Markbnj]

my point exactly. There are even embedded systems out there using .Net... Crazy, I know.

Not crazy at all. As embedded systems follow the same performance curve we've seen in desktops and mobile systems developers will derive the same benefits from the increasing use of abstraction and frameworks. It's inevitable, since the costs of not using those tools are very high.

 

[Kirby]

Not crazy at all. As embedded systems follow the same performance curve we've seen in desktops and mobile systems developers will derive the same benefits from the increasing use of abstraction and frameworks. It's inevitable, since the costs of not using those tools are very high.

I think the curve will be a good bit flatter though, unless the cost of development goes above the cost in production. Some of the requirements of embedded systems don't really change in throughput or performance, so I wouldn't think they'd significantly upgrade the hardware in order to run a more modern framework.

1 million product * $1/product * (manhours w/o whizbang) < 1 million products * $3/product * (manhours w/ whizbang * .75)

This is just me speculating though and I could be completely off base. I work for the DoD, and with an older workforce they'd shit a brick if they had to use java or .NET for the embedded work. A lot of them think OOP and C++ are a fad.

 

[Cogman]

Not crazy at all. As embedded systems follow the same performance curve we've seen in desktops and mobile systems developers will derive the same benefits from the increasing use of abstraction and frameworks. It's inevitable, since the costs of not using those tools are very high.

Well, as you know, embedded systems are sort of a different beast from standard PCs. I doubt you will ever see the adoption of .Net and other abstraction layers on the embedded systems like you will see them on desktop systems, they just don't bring as much to the table.

Heck, Java has been available on embedded systems for quite a long time now, yet it hasn't seen widespread adoption. That is because the niceties the Java offers really aren't all that great for embedded work.

For embedded systems, as long as you got a good math library, a good interface library, you really can't ask for much more abstraction.


Though, I guess if your device is hosting a web server and doing lots of Network communication, then something like .Net does bring a lot to the table. I guess you could even feasibly completely develop and test the app on your computer without ever uploading it to the device, that could be useful as well.

 

[Markbnj]

The curve might be flatter, and embedded systems might evolve in complexity at a far slower rate, but I'm betting they will traverse the same path over time.

 

[tatteredpotato]

The curve might be flatter, and embedded systems might evolve in complexity at a far slower rate, but I'm betting they will traverse the same path over time.

This is true because of the nature of the market. As fabs move to newer processes, they need something to do with the older fab equipment, which usually ends up being SRAM and embedded processors.

The economics do work differently in embedded systems though. You can get a consumer to pay for a faster processor in his or her PC, however they won't pay for a faster processor in their thermostat.

 

[tatteredpotato]

For embedded systems, as long as you got a good math library, a good interface library, you really can't ask for much more abstraction.


Though, I guess if your device is hosting a web server and doing lots of Network communication, then something like .Net does bring a lot to the table. I guess you could even feasibly completely develop and test the app on your computer without ever uploading it to the device, that could be useful as well.

Also the term "embedded system" has become a pretty wide classification these days covering everything from water heaters to (by some definitions) cell phones running full blown operating systems. If you're using a system with 8K of RAM and limited ROM then you might not want any extraneous libraries floating around taking up space. However if you are on more advanced hardware that can handle the higher level abstractions then it's a pretty obvious choice IMO.

 

[Cogman]

Also the term "embedded system" has become a pretty wide classification these days covering everything from water heaters to (by some definitions) cell phones running full blown operating systems. If you're using a system with 8K of RAM and limited ROM then you might not want any extraneous libraries floating around taking up space. However if you are on more advanced hardware that can handle the higher level abstractions then it's a pretty obvious choice IMO.

IDK, I don't really count smart phones as being embedded systems any more. When something can take advantage of mutli-programming, that is about where it crosses the line for me and becomes either its own market or a dumb version of the PC.

For the libraries, it depends. I was thinking more in the terms of static linking rather than on chip libraries.

 

[Exirion]

The curve might be flatter, and embedded systems might evolve in complexity at a far slower rate, but I'm betting they will traverse the same path over time.

From a technology point of view you're right. However, in the area where embedded systems are applied, the economical aspect counts too. Smart phones have >1GHz Cortex A8/A9, same goes for car multimedia systems, but it's a different story in devices with higher volumes and lower margins. I work at an innovation lab where embedded systems for the industry are designed and built, and our main focus is on Cortex M0 and Cortex M3 that hardly consume any power and are used in systems where every penny counts. Therefore, any task that can be done on a cheap lower power system with ANSI C, will be done in ANSI C rather than in Java or .NET on a heavier platform. No matter how fast platforms become, efficient coding remains important.

I've been saying this since people predicted that Java would soon rule the world, back in 1995 :biggrin:

 

[Cogman]

From a technology point of view you're right. However, in the area where embedded systems are applied, the economical aspect counts too. Smart phones have >1GHz Cortex A8/A9, same goes for car multimedia systems, but it's a different story in devices with higher volumes and lower margins. I work at an innovation lab where embedded systems for the industry are designed and built, and our main focus is on Cortex M0 and Cortex M3 that hardly consume any power and are used in systems where every penny counts. Therefore, any task that can be done on a cheap lower power system with ANSI C, will be done in ANSI C rather than in Java or .NET on a heavier platform. No matter how fast platforms become, efficient coding remains important.

I've been saying this since people predicted that Java would soon rule the world, back in 1995 :biggrin:

What about the evolution from assembly to C? Now, I realize that the gains for writing hand crafted assembly are pretty slim, but they still exist.

With a constantly shrinking power requirement, eventually the difference between a microcontroller with .NET capabilities and a one without will probably be something like 110 mW vs 100 mW. Heck, the .Net version may some day become cheaper as well.

But, then again, you're right, Java capable microcontrollers have been available since 1995, yet they have never been all that popular. Java and .NET are really about on the same level of abstraction.

 

[tatteredpotato]

What about the evolution from assembly to C? Now, I realize that the gains for writing hand crafted assembly are pretty slim, but they still exist.

With a constantly shrinking power requirement, eventually the difference between a microcontroller with .NET capabilities and a one without will probably be something like 110 mW vs 100 mW. Heck, the .Net version may some day become cheaper as well.

But, then again, you're right, Java capable microcontrollers have been available since 1995, yet they have never been all that popular. Java and .NET are really about on the same level of abstraction.

It's going to come down to software development costs. Software costs roughly the same amount of money to produce per source line of code regardless of language. Comparing ASM to C, ASM requires many more SLOC to produce the same functionality as C. Even though the engineering is a one-time up front cost, depending on volume you can use it to justify using more expensive hardware (and thus higher recurring costs) to offset the engineering cost.

 

[EagleKeeper]

<snip>
This is just me speculating though and I could be completely off base. I work for the DoD, and with an older workforce they'd shit a brick if they had to use java or .NET for the embedded work. A lot of them think OOP and C++ are a fad.

You been looking into my background? :'(

 

[Fallen Kell]

If you want to get some USEFUL skills in getting ready for an interview (hint, a business won't care if you know a 15-20 year old product, they want to know if you know the one that came out 2-3 years ago which they just migrated their development environment to), go download Eclipse (free), get the C/C++ Toolkit for it, and get familiar with it. If you know a little more about the company (might even be in their job listing), see if you can get the same thing they are using. Obviously clearcase will probably not be something that you can get, but if they still use CVS, Git, Bitkeeper, or some other RCS, you may be able to get familiar with it without paying a dime.

 

[Cogman]

If you want to get some USEFUL skills in getting ready for an interview (hint, a business won't care if you know a 15-20 year old product, they want to know if you know the one that came out 2-3 years ago which they just migrated their development environment to), go download Eclipse (free), get the C/C++ Toolkit for it, and get familiar with it. If you know a little more about the company (might even be in their job listing), see if you can get the same thing they are using. Obviously clearcase will probably not be something that you can get, but if they still use CVS, Git, Bitkeeper, or some other RCS, you may be able to get familiar with it without paying a dime.

Embedded coding is not like regular c/c++ coding. Programming in dos isn't a terrible idea.

As for Eclipse... YUCK. I'm sure it has its niceties for Java, but for c++ it really just does not do well. Code::block, Visual studios express, and net beans are all better IDEs IMO.

 

[Kirby]

Embedded coding is not like regular c/c++ coding. Programming in dos isn't a terrible idea.

As for Eclipse... YUCK. I'm sure it has its niceties for Java, but for c++ it really just does not do well. Code::block, Visual studios express, and net beans are all better IDEs IMO.

I know Atmel uses their version of Eclipse as the IDE for their 32bit line of processors. So it may not be a horrible idea to get used to it.

Microchip uses MPLAB, which I'd rather take a beating than use.

If the OP had enough time, maybe he could pick up one of those TI microcontrollers they were selling so cheap a while back and play around with it.

 

[IHateMyJob2004]

Not crazy at all. As embedded systems follow the same performance curve we've seen in desktops and mobile systems developers will derive the same benefits from the increasing use of abstraction and frameworks. It's inevitable, since the costs of not using those tools are very high.

Except for the higher paid morons that don't adapt to new technologies (and evolutionary things like faster processors). C/C++ in GCC will be around for a while because of older people's tendency to resist change.

 

[Cogman]

I know Atmel uses their version of Eclipse as the IDE for their 32bit line of processors. So it may not be a horrible idea to get used to it.

Microchip uses MPLAB, which I'd rather take a beating than use.

If the OP had enough time, maybe he could pick up one of those TI microcontrollers they were selling so cheap a while back and play around with it.

There is just something about the hardware industry that demands we use crappy software (well, at least crappy interfaces).

 

[Markbnj]

There is just something about the hardware industry that demands we use crappy software (well, at least crappy interfaces).

It may be the .0002 percent profit margins.

 

[tatteredpotato]

Embedded coding is not like regular c/c++ coding. Programming in dos isn't a terrible idea.

As for Eclipse... YUCK. I'm sure it has its niceties for Java, but for c++ it really just does not do well. Code::block, Visual studios express, and net beans are all better IDEs IMO.

For me when I do C/C++ my favorite development environment is Vim, this is especially true after I found out about the ":make" command

 

[EagleKeeper]

Except for the higher paid morons that don't adapt to new technologies (and evolutionary things like faster processors). C/C++ in GCC will be around for a while because of older people's tendency to resist change.

Faster processors are also at a higher cost.

Change has to be validated and that is expensive.