16/32 bit processor for OS development

If you can settle for using an existing RTOS, this book

formatting link
includes an example of creating a PC bootable floppy for running eCos.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)
Reply to
Stef
Loading thread data ...

With ~1 Billion ARM uC sold for mobile phones per year, that would be 1000 Billion Elan/EMC etc. Really wonder who is buying...

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

You are joking of course..?

I used them all the time for embedded data aquisition, well documented, plenty of mature development tools, easy networking.. .. inexpensive storage.... I know they don't fit the ultra low power minimal hardware and small form factor requirements.. but if one does not have such requirements, then it is a good simple platform to use.. oh yes, it is also quite cost effective too...

Reply to
TheDoc

Just use DOS as a program loader and have your program take over, clearing all RAM that isn't part of it and erasing DOS. You can, of course, do the same with Linux, using the standard bootloader to load your code instead of the Linux Kernel.

No. If the computer runs MS-DOS it can load and execute your program. You can ignore any peripherals and disable all interrupts. You can also ignore all CPU capabilities that did not exist on the 80486. Do that and it will run on any PC.

Jon Kirwan wrote up some instructions here: [

formatting link
]

He starts with having you boot to DOS, run DEBUG.EXE, and type in your program, which then takes over the machine.

He doesn't mention this because it would be stupid, but you

*could* use only the tools that come with DOS, loading DEBUG and piping a text file with your program to it, all in AUTOEXEC.BAT. Edit the text file, reboot, and Bob's your uncle.

He then shows you how to take over the using PC David Lindauer's GRDB.EXE, then with Microsoft's ML.EXE assembler and LINK.EXE linker.

He then goes on to explain how to turn your code into a MS-DOS

*.COM or *.EXE file, which is what I have been talking about doing.

All these methods put your assembly language program in control. You can call routines in the BIOS (or in DOS if you haven't nuked it from memory), but you can also ignore them and simply see a x86 CPU with some RAM. You can then learn how to interface with the various peripherals. I suggest starting with the parallel port. See [

formatting link
] for instructions.

--
Guy Macon
Reply to
Guy Macon

Bad advice. Smaller and more rugged versions of old PCs most certainly *are* used in embedded systems. Many times they are the best solution. Everything he learns on an old PC will apply directly to embedded systems such as these:

formatting link
formatting link
formatting link
formatting link

--
Guy Macon
Reply to
Guy Macon

A billion? I wasn't aware that they had shipped that many. Let me revise my estimate to perhaps 100 times as many.

Figures I grabbed off ov various websites: (I saw it on the Internet, so it must be true...)

Worldwide:

112 billion batteries 2.7 billion cell phones 1.5 billion TV sets 1.3 billion fixed landline phones 1.5 billion e-mail boxes 1.0 billion calculators 0.8 billion PCs 0.8 billion automobiles

(Each PC and some automobiles contain multiple uCs.)

I wonder what uC is in the SIM cards of those cell phones? How many have a seperate uC in the LCD driver chip?

Reply to
Guy Macon

depends on defition of "embedded system"

from wikipedia: "An embedded system is a special-purpose computer system designed to perform one or a few dedicated functions.[1] It is usually embedded as part of a complete device including hardware and mechanical parts. In contrast, a general-purpose computer, such as a personal computer, can do many different tasks depending on programming.

Since the system is dedicated to specific tasks, design engineers can optimize it, reducing the size and cost of the product, or increasing the reliability and performance. Some embedded systems are mass- produced, benefiting from economies of scale."

Of course PC based microprocessors are used in embedded systems when you require high processing power and have enough space, electical power.. But you cannot say they are suitable for embedded systems.

their sizes are generally bigger they are expensive they *may* require heat sink & fan no embedded resources & peripherals (flash, ram , adc , rtc , usb,spi, twi .....this list never ends...) (most important thing is here peripherals, I believe learning embedded systems mostly means that learning how to use peripherals..) you cannot easily solder them ;) you can easily do general purpose io with a microcontroller, it is not easy even turn on a LED with a pc, well at least i do not know...............

Reply to
tesla

Ignoring this argument, I'd say the suitability of an old PC depends on the OP's area of interest. If the OP is more interested in experimenting with operating system concepts (eg. tasks, schedulers etc.) I'd suggesting steering clear of PCs due to the amount of cruft that can be avoided entirely (eg. just setting up the whole real-mode/protected- mode switch). On the other hand, the same things do show the issues that real-world systems have to deal with and thus provide useful experience by themselves.

-a

Reply to
ammonton

In article , Guy Macon writes

SIMS used to be mainly 8051 and some AVR. Not sure what the majority are now.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

Ever hear of PC104?

Actually, they give you a choice. A MINI-ITX motherboard is far cheaper than any embedded board that has the same processing power. Or you can get a more rugged system at a higher cost.

Ever hear of PC104?

Ever look at a list of available PC104 peripherals?

Ever look at PC104 prototyping boards?

Look at the tutorials I linked to yesterday. They end up with you controlling the parallel port -- perfect for blinking an LED.

I believe in selecting the right tool for the job. I have made toys with

Reply to
Guy Macon

I have several old PC's (and laptops) from ebay bought for pennies :o) Even used one to implement a USB device by bit banging an I2C USB chip through the parallel port (don't ask why).

Why use assembler though? I boot using FreeDOS

formatting link
, then use OpenWatcom
formatting link
to compile c/c++. You can replace the DOS tick function with your own to get real time control - and chain to the DOS tick if you also want to maintain that. OpenWatcom provides _dos_getvect() and _dos_setvect() for this purpose.

Its fun, and very cheap (not as cheap as using a Luminary Micro evaluation board with GCC and Eclipse though :o)

--
Regards,
Richard.
 Click to see the full signature
Reply to
FreeRTOS.org

still too big man still tooooo wayyyy bigg..

Reply to
tesla

you have got to open your mind, tesla old boy!

I've seen (or worked on) PC's or equivalent in applications like

  • HVAC control
  • manufacturing workstation control
  • typesetters
  • medical test equipment (ok, that last one really was a SUN machine, but same idea)

The key point is, as I like to phrase it, that an embedded system looks like a "whatever" device to the end user. The end user should not perceive that there is a computer involved. They might be aware there is a computer used but they do not interact with the device like they do a PC. That's what makes it embedded, not the size, cost, realtime constraints, custom peripherals or other contstraints.

Ed Prochak

Reply to
Ed Prochak

Yup.

Steve

formatting link

Reply to
Steve at fivetrees

Hi, Steve. I hadn't been reading this thread but I do take the time to read you. Anyway, I think this remains a matter of from whose perspective the question is asked. If you are asking about it from a user's perspective, then all the above seems true enough. If you are asking about it from a programmer's perspective, then the question of "what is embedded" takes on a different frame to me. I'll explain.

The above definition, using the user's perspective, might be somewhat meaningful when you are talking to non-technical folks. In other words, they often have an idea about computers. If you are using 'embedded' with them to admit the fact that there is a computer inside, but to also point out that it's not like their "home computer" in the sense that they don't notice it being there (for example, as in a new, green energy washing machine) then I suppose the term has value for that. An end user can "get it" that there probably is a computer in there and they might like to hear more, now that they know it. (You might like to tell them that it is, for example, a cpu that is capable of playing video games sitting inside their washer. They might like to hear that and could understand the idea.)

But in that case, embedded is just another way of saying that a user doesn't immediately recognize the presence of a computer. Which you can already say by simply saying it, instead of adding another meaning to the word and then having to teach it to user after user after user. In other words, it's not a term users use much and they don't need it, really. They can say the same thing to each other without ever knowing the word, by just telling each other about the "computer in there." Trying to say that the word, embedded, should be defined by the needs of end users for such a term, and I mean end users otherwise unfamiliar with the idea, is really nonsense to me. They don't need that word, would take education to get them to user it properly, etc. Why bother, at all?

Now, on the other hand, the term has a great deal of practical need and everyday use within the programming world. Why? Because of the tool differences involved, programming proximity to as well as personal hardware familiarities required, mathematical and signal processing skills not uncommonly required, etc. In other words, it's not like prorgamming a very general purpose minicomputer or workstation. In that arena, the term has real purpose to it in dividing those with and without good experience here (a lack of which, of course, does not reflect in any way their experience in other arenas.) You might actually want to hire an embedded programmer and, by that if you are using the term without conflating it to the point of near uselessness, you usually mean someone who isn't unfamiliar with the range of skills and background associated with programming closer to hardware than those using general purpose operating systems often do. This often includes, for example, understing a little more about the linking process. Just as an example of what I'm talking about.

The short of it is that I don't see allowing a user perspective to define a word they frankly don't even need. On the other hand, we programmers DO need the distinction and to my mind that need is what should shape the meaning of it. Users can go get their own words for needs they really do have. ;)

Jon

Reply to
Jonathan Kirwan

End user perceive that there is a computer involved if you are talking about HVAC, medicals, scada etc... there is generally display and keyboards, and you can set/program those panel PC s .

I did not say PC cannot be used as embedded computer. what i said : "Of course PC based microprocessors are used in embedded systems when you require high processing power and have enough space, electical power.. But you cannot say they are suitable for embedded systems. "

Size, cost, peripherals,power consumption always matter when you design an embedded system. embedded system phrase covers HVAC, medical applications, scada... but %1 embedded system covers handheld devices, STBs, %80,

so the op did not dive specific application. we have to talk generally, and generally embedded systems are small !

Reply to
tesla

Your point totally taken. My earlier one-word response was obviously a tad minimal ;).

My take: to the user, it's a black box. Whether the implementation is fully analogue, fully digital, or a CPU and code, is of no interest. It does the job. The contents are a matter of economics and pragmatism.

To the designer, yes, it's a whole nuther ballgame. I'm actively wary of allowing programmers from a desktop background loose on an embedded project. For me, the key difference is not in the technicalities of linkage or tools (although these of course matter), it's in the degree of code quality needed. The malloc issue comes up. Exception handling comes up. My maxim of "It Must Not Crash" comes up ;). If the product were fully analogue or fully digital, and it crashed, it would be considered broken. The same MUST apply to the CPU+code platform. This is often very alien to the desktop people who have become immune to BSODs ;).

... All of which I've said many times before. Still, I hadn't yet had my daily rant ;).

Steve

formatting link

Reply to
Steve at fivetrees

Yes, it is less a matter of the tools used and more a matter of tooling the mind of the programmer. The guide I always use (which is not mine, but comes from ancient programming history) is this: It's not how well it works when it works that matters. It's how well it works when it doesn't work that is the real issue.

A program with poor memory management works fine in unit and initial integration testing, but that memory leak will show in the field when the product is running continously for months and years at a time. You can't always ask the user to have to reboot(or power cycle) the product to gloss over your memory leak.

What does you process controller do when a sensor that is never supposed to fail sends spurious signals? (e.g. the engine controller getting signals from a bad O2 sensor)

Embedded is only a word for defining the kind of programming. It entails, as Steve points out, a unique mindset. The measure of our success, IMHO, is the extent to which the end user can totally ignore the fact there is a computer involved.

Ed

Reply to
Ed Prochak

I gues we'll have to agree to disagree. At least you agree those larger system are embedded systems. My point is only that learning to control PC hardware at the lowest level is a good step in learning to be an embedded programmer. Is it the best step? maybe/maybe not. I just don't dismiss it as a step.

have a good day. Ed

Reply to
Ed Prochak

Because the person asking the question specified assembly language? C seems to be moving to smaller and smaller uCs every year, so it would be another good choice.

I like FreeDOS a lot. Do the executables from the OpenWatcom compiler have the ability to take over the computer, erase all traces of FreeDOS in memory and thus run with no Operating System?

To digress a bit from the original question... One interesting idea that I am just starting to explore is to run FreeBASIC under FreeDOS (It also runs under 32-bit Windows and Linux). What is most interesting about FreeBASIC is that it is written in FreeBASIC, thus making it easy for BASIC programmers to modify/extend the language. I am pretty good at assembly language and modern, structured BASICs, and can find my way around FORTH, but my C/C++ skills are something to be pitied, which means that extending or modifying the OS or the compiler tends to blow up in my face. :( I have in the past wriiten programs in PowerBASIC with BASIC code for the grunt work like putting something on the screen, reading the mouse/keyboard and printing and saving files, and inline assembly language to do the real work. Alas, PowerBASIC is Windows-only, and I seem to be spending more and more time in Linux, only using Windows for things like AutoCAD and OrCAD. If it works out as I hope it will, I will be able to do the same sort of thing using the FreeBASIC inline assembler in all of my favorite OSs.

See [

formatting link
].

--
Guy Macon
Reply to
Guy Macon

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.