标签云

微信群

扫码加入我们

WeChat QR Code


There are easier and more objective ways of gathering this information. If it is subjective opinion or a popularity poll you are after, then that is what you are likely to get in response to this question. You might even get someone ot do all the research for you and post it!

2018年09月27日43分29秒

I completely agree! But keep in mind that I'm more interested in collecting possible OSes. We'll put this down as no OS :-) Also keep in mind that some 8-bit processors allow 512K or even 1M of RAM space...space for complex enough...

2018年09月27日43分29秒

I don't think that the question is about antique computers or processors. It's about 8-bit devices used in embedded systems (as tagged).

2018年09月27日43分29秒

I was merely stating that it could work on the Commadore 64. It can run on modern 8-bit processors as well.

2018年09月26日43分29秒

On one project, I had a AVR Atmega16, that was doing many things at once including UI (LCD+knobs) and radio messages. It was a mess until I've switched to a OS (FreeRTOS, in this case). It's an abstraction level that greatly simplifies your code and reduces potential errors.

2018年09月27日43分29秒

I think it's mostly an exercise in using good patterns. A main loop that does nothing but check flags and call task-specific subroutines is sort of a primitive scheduler. The rest is discipline... the OS enforces some abstractions that you should have already anyway. It then almost invariably goes further and enforces stuff you don't need. There's no reason what you describe couldn't be contained in subroutines from main called "process_ui()" and "process_radio()". (expanding as needed)

2018年09月26日43分29秒

Take an OS which expects you to write drivers for say the LCD, knobs, and radio. That can clean up some spaghetti code, but then so can just cleaning it up by moving functions to "lcd_", "knob_", and "radio_*" access functions. Think about encapsulation, it's important. It's a whole lot better in my opinion to develop solid design processes and patterns that work for ANY microcontroller you use (which makes your code more portable) than to use half a dozen RTOSes for the dozen different micros you're using. (Or pay insane fees for the bigger RTOSes which work almost everywhere)

2018年09月26日43分29秒

I think there's definitively a difference between the state-machine approach and (preemptive) multitasking. No artificial preservation of the state across calls. This can get rid of a LOT of nasty stuff - it's simply gone (if you can pay the price, that is performance + memory).

2018年09月26日43分29秒

Well, true. This is probably down to developer preferences... objectively they both sound like fair approaches. Personally, the avoidance of an added dependency and being able to use the same patterns everywhere are way more important to me. An OS needs to give me a huge benefit to entice me to use it... I do use TI's DSP/BIOS, for example. The integration with the IDE (among other things) is awesome. On most other processors I don't use an RTOS. Being required to work with a wide range of processors has something to do with it. If I almost always used AVR say, I might go with the RTOS.

2018年09月26日43分29秒

Were any of the multithreading flavors available for the 6800 or 6801? If so, you might have written the first 8-bit multitasking OS. There's a question about this over at: retrocomputing.stackexchange.com/questions/4537/…

2018年09月26日43分29秒

Yes, they were, but no, I didn't write the first 8 bit multitasker for the 6800. While I was at TRW Advanced Product Labs in 1974, John Liberty implemented a dual processor 6800 (each CPU used one half the symmetric clock to do its memory access); one CPU did general purpose work, the other often did real time single bit I/O to things like mag tapes. A fellow named Dick Moran wrote the multitasking, multiprocessor "BKOS" (Basic Kernal OS) that handled both CPUs using atomic locks and the whole bit. These CPU boards went on to become the core of May Company POS terminals. ...

2018年09月26日43分29秒

... IIRC, the Intel 8085 came out before the 6800. Most of the CPU boards for that couldn't take an interrupt to save their lives, so it didn't make much sense to build an RTOS for those. .... But ... some did. I'm sure some soul wrote a multitasking OS for the 8085. I remember talking to a Raytheon missile engineer who I think had done this. Late 70s, I did what I thought was a pretty nice mulitasking OS for the Z80 but by that point I was probably just one of a crowd of guys who had done that.

2018年09月26日43分29秒

The Rabbit development environment includes uC/OS-II. It was previously sold separately, but is now included with the base compiler.

2018年09月26日43分29秒

...but the question is tagged embedded. Did you ever see MSX in an embedded system?

2018年09月26日43分29秒

could you combine this answer with your previous one. You are talking about the same thing...

2018年09月26日43分29秒

I don't think MSX figures highly in embedded systems (question tagged "embedded"), MSX was essentially a desktop OS/Architecture.

2018年09月27日43分29秒

Just as cheap, but perhaps more power hungry?

2018年09月27日43分29秒