The reason is an attitude thing: First you treat your smallest customers badly, they are after all insignificant and contribute almost nothing to the bottom line, they are a nuisance. Why would that be? The amount that I was buying was less than a millionth of their annual turnover, I did not protest on the internet or take any direct action against the companies concerned. Today NONE of those companies exist in this country. That product is still made today without their connector (or anybody elses for that matter). In one case it was a large multinational connector manufacturer that messed me around so much that I designed the connector out of the product. Over the years I have been in business, there have been about five companies that have treated me badly. GP "Alas poor PIC16s! I knew them, Horatio: a family of processors of peculiar but useful design. From this, you can deduce what I think will happen: the decision will stand.
#Pbp3 supported devices how to#
So each of MCHP's customers will decide how to proceed and most don't use that much assembler code (if any) and therefore don't care about this. And the evidence (so far) is that that has not happened. Only a huge customer saying "I'm leaving the fold." will do that. That said, I doubt anything said on a forum will modify MCHP's behavior. So I doubt I'll use PIC16s in any future products. I haven't been able to match the low power of the newer PIC16s, but it's close enough. The relative cleanliness of other architectures (both PIC and non-PIC) makes them more attractive. Since my library of assembler code is essentially useless*** going forward (sans a huge translation effort), I now look at the alternatives. The reason to keep using a family is its suitability OR one's knowledge base (or a combination). I no longer consider using PIC16s as a direct result of the loss of MPASMX.
I cannot find a comprehensive way to implement the MPASM "DA" directive that packs two 7-bit ASCII character in one 14-bit instruction word of a mid-range PIC. What I would like from Microchip is for pic-as(v2.20) to directly support all the MPASM directives without evading the issue by suggestion the developer implement the missing directives using assembly macros. And now you want them to spend a similar effort to port a tool chain that "appears" non-essential to Microchip as the assembler for XC8 is already ported? The pic-as(v2.20) tool chain is an archaic assembler except when compared to MPASM. The tools team at Microchip has ported the XC8 tool chain to the 64-bit world. MPLABX seems to support around 3000 controller targets. I wonder how many other PIC tools vendors are going to need to decide to cowboy up or get out of the business? Vendors that built tools on MPASM have been "cutting bait" for a few decades now, guess it's time to "start fishing" or go home. So, not only is Microchip putting a hurting on the PIC users, but also it's Trusted 3rd Party Vendors. I know Charles Leo at MP Labs & he says he is at a loss on how to maintain PBP3 with the new stuff.
#Pbp3 supported devices upgrade#
Mpgmike I seriously hope Microchip rethinks this pic-as crap and invests the resources to upgrade MPASM.
0 kommentar(er)
