Ruben J=F6nsson escribi=F3: >> On Thu, Nov 6, 2008 at 3:27 AM, Martin K wrote: >>>> Right, so what's the point in this context of a enhanced 16F that's >> slightly >>>> cheaper than a 18F? >>> "slightly cheaper" is the point. >> Microchip agrees with you. ;-) >> > = > Another thing that this is good for is that you might be able to reuse an= old = > design for something else. Whenever I need to do this it seems that I alm= ost = > always need more code space than the original design. If it already has a = > standard 16F, you can just pop in an enhanced 16F which has more code and= ram = > memory. This way you have a proven design and may even be able to use the= old = > test reports for safety and EMC. "Just" change the code. > = I agree with you Ruben, I read the hole thread and the microchip website about the = new enhanced architecture and at first glance I thought the = same than most of you probably: why? isn't it the same or a = mid-step between the 16F standard and the 18F ? and my = answer was "yet, it is but..." And is the what follows the *but* of the sentence what = solves the dilemma... for some new developers may be this = will confused them more (I would start with a 18F if price = is not the main problem), but what about those more than 1 = billion uC that are sold every year? Most of them are 8bit, = this is a well known information (even Mchip CEO admits that = one of their strategies is that one unit can support = economically other one until it is profitable or just = because is strategically important for them). Well, many of those 'big customers' that buy almost 16F = parts could be interested in some enhancement in their 16F. = May be redesigning an old project to fit a 18F part could = cost more than what we see by just comparing = microcontrollers costs... I'm a small developer compared with huge companies, even = thou I have an application running on a 16F876 then I moved = it to a 16F876A (reducing costs very easily) and then to a = 16F886 (reducing some u$s cents again). The application = occupies almost 7.95K words; the fact is that I have added = some new priority features and deleted some old ones (or = commented them in the cost) just because the code didn't = fit. It is important to say that the code is fully written = in assembler with no tables... it is all code. That application is very well tested, it's been in the = market for about 4 years and the best of all is that I trust = on it. Changing to a 18F part, could be easily done but... = but I should test the application for every case and = condition, that could demand me (or to the tester) hours, = days, months. Adding a new feature to a 16F part, would = demand only testing the new feature and the most common code = flow. The enhanced architecture (and only for the reason of = having more program memory and more Mips) seems to be the = solution to my problem. Even if costing some cents more = than the 16F886 , the equation is favorable. Big companies have more strict development processes (using = CMMI for example), migrating a working code from a 16F to a = 18F could impact in many other areas (documenting, project = planning, configuration management, testing, inspections, = and many more). This costs money... tons of it. Adding a = new feature to an existing 16F project will impact less = more... the difference of some cents between the 16F to the = 18F wouldn't matter here, the bigger impact would be the = engineers hours costs (as is the case in my small self = example). And consider if the application is a medical = device or an engine injection controller ... The application I'm talking about takes less than 1K 16F = parts a year but the applications of the big companies = probably will impact in thousands or millions of parts a = year. Then if only a few big customers demand something = like this, may be that by itself will solve the equation. Probably for new applications a 18F or a 16-bit part (dspic, = pic24, pic30) *are* the choice (even more considering that = most development are not mass production ones) A difference = in 1 u$s in a device is not much if we think the time that = takes making a design full-filling constraints like fitting = in a small memory footprint, or dealing with intensive = calculation with a slow core (20MHz for example). Those = constraints could demand more development days, that cost = big bucks that could be saved if using a bigger = microcontroller with a faster core... If we consider a = simple number like a 1K u$s per week per engineer (US, = Europe) , every week the development takes will require that = the marketing area would have to increase the selling by 1K = pieces per engineer/week involved in the development. Going back to the 16-bit architecture, what about the = already existing designs? This new arch could be the answer = to those *big*, *huge* customers, those that are the reason = of why Microchip is growing each year... Those companies probably have hundreds, or thousands of = lines of code in libraries, macros, code-snippets, in = assembler fully written for the 16F parts. -- = ------------------------------ Mauricio Giovagnini (Maunix) www.maunix.com.ar Cordoba, Arg. LinkedIn Profile: http://www.linkedin.com/in/mgiovagnini -- = http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist