| Details | Message |
|---|
Read-Only Author Christophe Champigny Posted 19-Dec-2001 07:55 GMT Toolset None |  Idea for the next version of µvision Christophe Champigny 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?
|
|
Read-Only Author Mike Kleshov Posted 19-Dec-2001 10:59 GMT Toolset None |  RE: Idea for the next version of µvision Mike Kleshov IMHO, it's not worth including in the toolset. Keil tools are software development tools, specialized programmers suit better for production. Besides, there is quite a variety of ways in wich in-system programming is implemented in different microcontrollers. Probably it's better left to 'third party' tools. There are other things to work on in the toolset, though. The optimizer could be smarter, and there is this annoying thing that *.c files with 'pragma asm' are recompiled at every build. |
|
Read-Only Author Andrew Neil Posted 19-Dec-2001 12:05 GMT Toolset None |  RE: Idea for the next version of µvision Andrew Neil I once heard it said that some alarmingly high percentage of "new features" suggested/requested by Microsoft's "Focus Groups" are already present in the Products!
It is, indeed, already possible to do in-system programming now with the current uVision2 as it stands; eg, see AN159 - my Application Note for the Triscend E5: http://www.keil.com/appnotes/docs/apnt_159.asp
It just requires the chip vendor, or other 3rd party, to provide the necessary supporting interface |
|
Read-Only Author erik malund Posted 19-Dec-2001 13:25 GMT Toolset None |  RE: Idea for the next version of µvision erik malund 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 |
|
Read-Only Author Christian Bienert Posted 19-Dec-2001 13:54 GMT Toolset None |  RE: Idea for the next version of µvision Christian Bienert All right and 4) document all switches like NOSO (no variable sort) and __DATE2__ (old format of __DATE__)
Chris |
|
Read-Only Author Christophe Champigny Posted 20-Dec-2001 07:37 GMT Toolset None |  RE: Idea for the next version of µvision Christophe Champigny 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. |
|
Read-Only Author Andrew Neil Posted 21-Dec-2001 09:30 GMT Toolset None |  RE: Idea for the next version of µvision Andrew Neil 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. |
|
Read-Only Author Andrew Neil Posted 19-Dec-2001 13:43 GMT Toolset None |  RE: Idea for the next version of µvision Andrew Neil A glaring omission from the current version is any ability to save or print the information from the debug windows, disassembler, profiler, etc, etc |
|