On Fri, 30 Sep 2005 19:55:05 GMT, Richard wrote:> >> The next release of Openwatcom (1.4) has specific support for embedded >work, >> you do not need a locator anymore, the linker will do it for you. > >That is good news. I just had a quick look on the site and cannot see a >release date mentioned. Do you know roughly when this might be?"if it's finished" is the common answer. I don't think there's a specific date set, but my feeling that it's near. For the 'locator' functions, the enhancements were only in the linker. I think the linker will not change between now and the release, I can mail you the new linker if you want to try it. Mail be privately at my (mangled) email address in the header. Mat Nieuwenhoven
80186 free C compiler
Started by ●September 30, 2005
Reply by ●October 1, 20052005-10-01
Reply by ●October 1, 20052005-10-01
> Why 80186 (or 80188)? The architecture is obsolete, so > I'd avoid it in new designs. An ARM could do the same > with modern tools and plenty of more power.I would not call it obsolete, it is a mature core with mature tools very suitable for small non-battery operrated embedded systems and components. There exist various mutations still in production and one can also see on Lantronix website that this core is successfuly used in new products (like XPort and WiPort). Speaking of Lantronix, I quite like their DSTni-EX for the optimized instruction set and high amount of integrated prefipherals. However, I did not use it myself, just read the datashet.
Reply by ●October 1, 20052005-10-01
> > Why 80186 (or 80188)? The architecture is obsolete, so > > I would not call it obsolete, it is a mature core with mature tools > very suitable for small non-battery operrated embedded systems andRue McLanahan is a mature actress, but I wouldn't choose her to play the part of sex kitten in a new movie. Programming the 186 gets you all the disadvantages of real-mode x86 programming with none of the advantages of, well, anything really. ARM tools are mature and readily available, operating systems abound, and peers to ask for help are everywhere.
Reply by ●October 1, 20052005-10-01
larwe wrote:>>>Why 80186 (or 80188)? The architecture is obsolete, so >> >>I would not call it obsolete, it is a mature core with mature tools >>very suitable for small non-battery operrated embedded systems and > > > Rue McLanahan is a mature actress, but I wouldn't choose her to play > the part of sex kitten in a new movie. >Ahhh, it always comes back to sex. ;-)> Programming the 186 gets you all the disadvantages of real-mode x86 > programming with none of the advantages of, well, anything really. ARM > tools are mature and readily available, operating systems abound, and > peers to ask for help are everywhere. >
Reply by ●October 1, 20052005-10-01
> Programming the 186 gets you all the disadvantages of real-mode x86What of the real mode intimidates you ? Name some.> programming with none of the advantages of, well, anything really. ARM > tools are mature and readily available, operating systems abound, and > peers to ask for help are everywhere.However, ARM is off-topic in this thread.
Reply by ●October 1, 20052005-10-01
rziak wrote:> > Programming the 186 gets you all the disadvantages of real-mode x86 > > What of the real mode intimidates you ? Name some.Well damn, I don't need to go anywhere past the memory model or the scarce and narrow registers to make my point more than adequately. It's the 21st century now, I have my VIC-20s for nostalgia but don't use them for any production purpose.> However, ARM is off-topic in this thread.Welcome to the Internet, lad - here's a lemon-scented towel and a coupon good for two bananas and a ferret. Once you redeem it, maybe you can come back and see if you have any better luck controlling what is "on-topic" in a Usenet group, particularly when the content of the message is utterly appropriate to the group and merely doesn't agree with what you were thinking in a particular thread. Anyway, anyone asking about coming up on the 186 in this day and age had better be supporting a legacy project or working with an ASIC that has a 186 inside it. At a stretch, I could swallow a short-run design intended to use up a huge drawer full of dusty 186 parts. But there are so many other products so much better in so many ways that intentionally selecting a 186 except in the sorts of circumstances I illustrated is quite insane.
Reply by ●October 2, 20052005-10-02
larwe wrote:> rziak wrote: > >>>Programming the 186 gets you all the disadvantages of real-mode x86 >> >>What of the real mode intimidates you ? Name some. > > > Well damn, I don't need to go anywhere past the memory model or the > scarce and narrow registers to make my point more than adequately. It's > the 21st century now, I have my VIC-20s for nostalgia but don't use > them for any production purpose. > > >>However, ARM is off-topic in this thread. > > > Welcome to the Internet, lad - here's a lemon-scented towel and a > coupon good for two bananas and a ferret. Once you redeem it, maybe you > can come back and see if you have any better luck controlling what is > "on-topic" in a Usenet group, particularly when the content of the > message is utterly appropriate to the group and merely doesn't agree > with what you were thinking in a particular thread. > > Anyway, anyone asking about coming up on the 186 in this day and age > had better be supporting a legacy project or working with an ASIC that > has a 186 inside it. At a stretch, I could swallow a short-run design > intended to use up a huge drawer full of dusty 186 parts. But there are > so many other products so much better in so many ways that > intentionally selecting a 186 except in the sorts of circumstances I > illustrated is quite insane.Know any ARM operating systems that can boot in 500ms?
Reply by ●October 2, 20052005-10-02
On Sat, 01 Oct 2005 20:36:53 -0700, Jim Stewart <jstewart@jkmicro.com> wrote:>larwe wrote: >> rziak wrote: >> >>>>Programming the 186 gets you all the disadvantages of real-mode x86 >>> >>>What of the real mode intimidates you ? Name some. >> >> >> Well damn, I don't need to go anywhere past the memory model or the >> scarce and narrow registers to make my point more than adequately. It's >> the 21st century now, I have my VIC-20s for nostalgia but don't use >> them for any production purpose. >> >> >>>However, ARM is off-topic in this thread. >> >> >> Welcome to the Internet, lad - here's a lemon-scented towel and a >> coupon good for two bananas and a ferret. Once you redeem it, maybe you >> can come back and see if you have any better luck controlling what is >> "on-topic" in a Usenet group, particularly when the content of the >> message is utterly appropriate to the group and merely doesn't agree >> with what you were thinking in a particular thread. >> >> Anyway, anyone asking about coming up on the 186 in this day and age >> had better be supporting a legacy project or working with an ASIC that >> has a 186 inside it. At a stretch, I could swallow a short-run design >> intended to use up a huge drawer full of dusty 186 parts. But there are >> so many other products so much better in so many ways that >> intentionally selecting a 186 except in the sorts of circumstances I >> illustrated is quite insane. > >Know any ARM operating systems that can boot >in 500ms? >Linux. If I recall correctly there was a discussion on boot times for embedded Linux on comp.os.linux.embedded a while ago. Someone pointed to some work done by Samsung on shortning the boot time of Linux on their ARMs. They got this down to below 500ms. Most other OSes available for ARM should boot much faster than this. I agree with larwe. Choosing a 186 for a new design if there are not some sort of unusual circumstances is insane. Regards Anton Erasmus
Reply by ●October 2, 20052005-10-02
If you are building an embedded controller using standard parts then perhaps the 80186 is not the best choice, but if you are building your own FPGA/ASIC than it makes perfect sense to look at some of the mature cores like the 8051, Z80 and 8086. Although having said that, the old *obsolete* 8051 part is still in full production by Philips/Siemens/Atmel after 25 years! This can't be all for maintaining legacy designs, they must be selected for new designs as well? As Rziak were saying there are lots of good development tools available for the 86/186 not to mention the enormous amount of legacy code, also to test your code just open a DOS box on your 64bits desktop and run the code, works like a charm :-) I might be biased... http://www.ht-lab.com/freecores/cpu8086/cpu86.html :-) Hans PS I didn't know who Rue Mcclanhan was, but after a quick google search guess what? she played the sexy one in the Golden Girls TV series, so I guess given the success of the series she was a good choice :-) "larwe" <zwsdotcom@gmail.com> wrote in message news:1128191473.554276.253920@g47g2000cwa.googlegroups.com...>> > Why 80186 (or 80188)? The architecture is obsolete, so >> >> I would not call it obsolete, it is a mature core with mature tools >> very suitable for small non-battery operrated embedded systems and > > Rue McLanahan is a mature actress, but I wouldn't choose her to play > the part of sex kitten in a new movie. > > Programming the 186 gets you all the disadvantages of real-mode x86 > programming with none of the advantages of, well, anything really. ARM > tools are mature and readily available, operating systems abound, and > peers to ask for help are everywhere. >
Reply by ●October 2, 20052005-10-02
On 1 Oct 2005 19:41:21 -0700, "larwe" <zwsdotcom@gmail.com> wrote:>rziak wrote: >> > Programming the 186 gets you all the disadvantages of real-mode x86 >> >> What of the real mode intimidates you ? Name some. > >Well damn, I don't need to go anywhere past the memory model or the >scarce and narrow registers to make my point more than adequately.While I agree that programming a large single thread application in real mode can become quite messy, but using some kind of RTOS and allocating separate code, data and stack segments for each task and keeping each of them below 64 KiB should not be too hard in most cases. Common library calls would have to use far calls, but would automatically use task specific static data and stack areas etc. The task switching in the OS would be slightly more complicated and the communication between tasks would go through OS supplied communication primitives (which is usually considered a good thing rather than poking around in a foreign task data space :-). Paul