Today, many microcontroller use in-system programming, or other system. So, why µVision could not include one in the next generation? I think it can be very usefull, no?
Why go for all kinds of new features, that is what killed many excellent products, they became so complex that only the chosen few could use them. Ther are many little areas of improvement. 1) better optimization (the size has grown with a new release). 2) make inline assembly work without the stupid .src twopass. 3) make the variables stay in the same place when renamed or one is added. I am sure there are more little things that can be improved without feature creep, I know that is not as flashy as a new feature, but it is worth ten times more to the user. Happy hollidays, Erik
All right and 4) document all switches like NOSO (no variable sort) and __DATE2__ (old format of __DATE__) Chris
I'm not agree with you. If Keil want to keep their customers, they must follow their wishes. If you don't want to use the new feature, that's your opinion. But that's not always the opinion of other people. I'm sure, that many people who use Keil Software since a long time appreciate some new features if they can easily improve any product developpement. Example: for me in a R&D service, I don't want to have many different programmer for each device. If they have in system programming interface. I prefer to use it. yes, I know, that's my own interrest but maybe few people think like me.
I think Erik has a good point but, of course, all generalisations are dangerous! ;-) But, in fact, this case does illustrate Erik's point: the more features you add, the harder it is to find the one you actually want! As I mentioned earlier, uVision does already have the necessary facilities to support in-system programming - it just requires someone (eg, the chip vendor) to provide the necessary support drivers.