On Jul 10, 12:36=A0pm, n...@puntnl.niks (Nico Coesel) wrote:> >That's absolutely untrue, starting with the difference between double- > >and single-buffered UARTs, buffered vs. non-buffered PWM peripherals, > > Perhaps but -for instance- all UARTs work the same. Provide someHardly! And in any case, few UARTs are pure UARTs, most are USARTs with other functionality bolted on; I2C, SPI, CAN, LIN, ... ...> straightforward. It only takes a few reads from specific sections from > the user manual to get a peripheral going.I wish I lived in your world, it must be a very simple and stress-free place.> >especially for larger chips (I'd like to see you try this on something > >like an i.MX21). > > An i.MX21 is a SOC, not a microcontroller!Nitpicking. You could call an 8051 with onboard LCD controller and keyboard muxer an SoC too.
Hi-Tech Software bought by Microchip - no more other compilers
Started by ●July 6, 2009
Reply by ●July 10, 20092009-07-10
Reply by ●July 10, 20092009-07-10
Nico Coesel wrote:> Perhaps but -for instance- all UARTs work the same. Provide some > settings, create an interrupt routine and ready to goHeh. The UART came up pretty fast, but getting the clock generator to generate the right assortment of clocks is not something a Z180 ever needed done. Nor PIC. And not enabling the /Reset pin too soon because the power-up sequence assumes that the firmware is *using* it to control startup of outside peripherals. I like this chip, but getting really familiar with it did take some time. Mel.
Reply by ●July 10, 20092009-07-10
On Thu, 09 Jul 2009 23:07:18 GMT, nico@puntnl.niks (Nico Coesel) wrote:>The problem with commercial tools is that each MCU has a different >crappy IDE and a different toolchain. That is why the combination >Eclipse, GCC en GDB is so powerful. You learn the tools once and can >apply that knowledge to any target. Besides, Eclipse beats most IDEs >hands down.Eclipse is still far from the best IDEs, but it has potential ... somebody with a lot more time than me could potentially develop an Eclispse based code browser as useful as Smalltalks or a debugger as good as Wind Rivers. BTW: GDB sucks and GCC is just a decent compiler - not a really good one. Apart from these points, I agree that some kind of a standard tool chain is desirable. Or at least a plug and play tool chain with standardized intermediate formats so you can choose compiler, linker, debugger, etc. and they all interoperate. George
Reply by ●July 10, 20092009-07-10
"Joel Koltner" <zapwireDASHgroups@yahoo.com> wrote:>"Walter Banks" <walter@bytecraft.com> wrote in message >news:4A574681.1A6D66@bytecraft.com... >> We encourage and support our customers to use the IDE they are familiar >> with (most have company standards on IDE's). > >Really? I've yet to work at any company that standardized on a particular >IDE -- they are just too many bits and pieces that don't typically interface >"nicely" to a generic IDE. I mean, can you actually debug PICs or AVRs or >MSP430s using Eclipse with a standard interface that gives you source code, >diassembly, breakpoints, watch windows, registers, etc.? > >The vast majority of microcontroller programmers I've met just use the IDE >that comes with the tools. I'd even go so far as to say that no more than 1 >user in 50 uses the more advanced features of any given IDE such as scripting.Well, I use Eclipse for almost everything except 8051. But I never use debugging except for Windows and Linux (which I also use to debug software that goes into embedded platforms). There is not much use in debugging a microcontroller. The non-realtime stuff is easier & faster to debug when run on Windows or Linux. The realtime stuff can't be debugged because the moment you halt there is no more realtime... -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... "If it doesn't fit, use a bigger hammer!" --------------------------------------------------------------
Reply by ●July 10, 20092009-07-10
Joel Koltner wrote:> "Walter Banks" <walter@bytecraft.com> wrote in message > news:4A574681.1A6D66@bytecraft.com... >> We encourage and support our customers to use the IDE they are familiar >> with (most have company standards on IDE's). > > Really? I've yet to work at any company that standardized on a particular > IDE -- they are just too many bits and pieces that don't typically interface > "nicely" to a generic IDE. I mean, can you actually debug PICs or AVRs or > MSP430s using Eclipse with a standard interface that gives you source code, > diassembly, breakpoints, watch windows, registers, etc.? > > The vast majority of microcontroller programmers I've met just use the IDE > that comes with the tools. I'd even go so far as to say that no more than 1 > user in 50 uses the more advanced features of any given IDE such as scripting. >Debugging and simulation are often difficult to integrate with IDEs (the only standard is gdb, but even there you can often have to do some work to get things like proxies or hardware interfaces to start up nicely with the IDE's gdb front end). And if you want thinks like gui boxes for picking compiler options, rather than using makefiles, then you need extra integration. But for the basic work of editing, searching, project management, and often running makefiles and interpreting the errors and warnings, then you can mix and match programmer's editors or IDEs and compiler tools.
Reply by ●July 10, 20092009-07-10
nospam wrote:> David Brown <david.brown@hesbynett.removethisbit.no> wrote: > >> Of course, I have to agree that porting Delphi (and other Borland tools) >> would have been a big help too. >> >> But the death of OS/2 had little to do with lack of software (almost all >> DOS/Windows software at the time ran fine on OS/2, > > OS/2 was a dead man walking long before it could run DOS/Windows software > fine. > > I died because of IBM's insistence it ran on brain dead 286s (to satisfy > their hardware customers who had purchased lots of expensive PS/2 boxes > with brain dead processors). >My experience with OS/2 began with Warp (OS/2 3.0), which was a very different OS than OS/2 2 (which again was very different from version 1). It was only with Warp that OS/2 gained significant followers, and it needed a 386 or better.> At the time Microsoft embraced the 386 which really could run Windows and > DOS programs fine. >At the time of Warp, Windows was at 3.11 (or the very rare NT 3.51), and could run many DOS programs reasonably (and obviously current windows programs). However, Windows was in reality single-tasking (since it was a co-operative multi-tasking system, and windows programs were not co-operative), although it could do some limited DOS multi-tasking. OS/2 was vastly better, and could properly multi-task windows software and DOS software. In particular, it was much better for DOS since it allowed more flexible graphics and significantly better memory management.> IBM chose hardware backward compatibility over software backward > compatibility - very very dumb. >The main cause of death was that that MS told IBM that if it wanted OEM discounts on its windows PCs, it had to install windows on *all* its machines. If it shipped PCs with OS/2 pre-installed, they would have to pay full customer prices for every PC it shipped with windows. IBM said "fair enough", and installed windows on all its PCs.
Reply by ●July 10, 20092009-07-10
On Fri, 10 Jul 2009 16:50:57 +0100, nospam <nospam@please.invalid> wrote:>[OS2/] died because of IBM's insistence it ran on brain dead 286s (to >satisfy their hardware customers who had purchased lots of expensive PS/2 >boxes with brain dead processors). > >At the time Microsoft embraced the 386 which really could run Windows and >DOS programs fine.And then, for years, gave us a shared memory process model with cooperative multitasking. Windows, too, was originally designed for the 286, and it retained that unfortunate legacy for nearly 10 years. Windows 1.0 was introduced in 1985. Windows/386 in 1989 was the first to use the 386 in 32-bit protected mode. Windows 3.0 was the first version that was actually useful - it used 32-bit mode internally but only drivers could use it that way - all GUI programs shared a single 16-bit VM. It wasn't until 1993 with the introduction of NT and Win32 on Windows that the average programmer could write real 32-bit software. OS/2 was better than Windows until NT4 appeared. George
Reply by ●July 10, 20092009-07-10
On Fri, 10 Jul 2009 16:36:22 GMT, nico@puntnl.niks (Nico Coesel) wrote:>larwe <zwsdotcom@gmail.com> wrote: > >>On Jul 10, 11:35=A0am, n...@puntnl.niks (Nico Coesel) wrote: >> >>> Nope. A microcontroller always has memory (ram/rom), a cpu and >>> peripherals. If you've seen one, you've seen them all. Ofcourse there >>> are people that like to toy around and try to get every peripheral >> >>That's absolutely untrue, starting with the difference between double- >>and single-buffered UARTs, buffered vs. non-buffered PWM peripherals, > >Perhaps but -for instance- all UARTs work the same.Until you encounter one with a FIFO. Or need to figure out when data is actually finished sending to disable an RS485 transmitter. Or need to figure out _exactly_ how to kick it to clear a framing error status.
Reply by ●July 10, 20092009-07-10
On Fri, 10 Jul 2009 15:50:19 -0400, George Neuner <gneuner2@comcast.net> wrote:>On Thu, 09 Jul 2009 23:07:18 GMT, nico@puntnl.niks (Nico Coesel) >wrote: > >>The problem with commercial tools is that each MCU has a different >>crappy IDE and a different toolchain. That is why the combination >>Eclipse, GCC en GDB is so powerful. You learn the tools once and can >>apply that knowledge to any target. Besides, Eclipse beats most IDEs >>hands down. > >Eclipse is still far from the best IDEs, but it has potential ... >somebody with a lot more time than me could potentially develop an >Eclispse based code browser as useful as Smalltalks or a debugger as >good as Wind Rivers. > >BTW: GDB sucks and GCC is just a decent compiler - not a really good >one. > >Apart from these points, I agree that some kind of a standard tool >chain is desirable. Or at least a plug and play tool chain with >standardized intermediate formats so you can choose compiler, linker, >debugger, etc. and they all interoperate. > >Georgeor at the very least, be able to juggle the function keys around so the same key always builds, debugs, halts etc.
Reply by ●July 10, 20092009-07-10
On 10 July, 20:50, George Neuner <gneun...@comcast.net> wrote:> On Thu, 09 Jul 2009 23:07:18 GMT, n...@puntnl.niks (Nico Coesel) > wrote: > > >The problem with commercial tools is that each MCU has a different > >crappy IDE and a different toolchain. That is why the combination > >Eclipse, GCC en GDB is so powerful. You learn the tools once and can > >apply that knowledge to any target. Besides, Eclipse beats most IDEs > >hands down. > > Eclipse is still far from the best IDEs, but it has potential ... > somebody with a lot more time than me could potentially develop an > Eclispse based code browser as useful as Smalltalks or a debugger as > good as Wind Rivers. =A0 > > BTW: GDB sucks and GCC is just a decent compiler - not a really good > one. =A0 > > Apart from these points, I agree that some kind of a standard tool > chain is desirable. =A0Or at least a plug and play tool chain with > standardized intermediate formats so you can choose compiler, linker, > debugger, etc. and they all interoperate. > > GeorgeThe XMOS tools use Eclipse (they can also be used from the command line). I've always disliked Eclipse but the XMOS implementation is very good. Leon
