MPLAB PM3 -> extreem duur

ritmeester

Golden Member

Kan iemand mij uitleggen waarom de MPLAB PM3 extreem duur is?

Op dit moment bij microchipdirect voor €800.- en dan moeten er ook nog socket modules bij van gemiddeld €200.- per stuk.

Ik vat dit even niet :-)

Kun je die sockets niet zelf maken ?

[Bericht gewijzigd door ritmeester op 22 juni 2019 18:28:00 (11%)]

I love it when a plan comes together !
Jochem

Golden Member

Nouja er zit natuurlijk een stuk ontwikkeling in, en de hoeveelheden die ervan worden verkocht zijn verhoudingsgewijs niet al te hoog.

Maar verder moet je het als techneut ook niet proberen te begrijpen. Het is een stuk gereedschap en dit kunnen ze er kennelijk voor vragen.

Heb geduld: alle dingen zijn moeilijk voordat ze gemakkelijk worden.

Voor een universele programmer is het niet overdreven duur, ik heb lang geleden een HiLo programmer gehad, ook met losse pods tegen vergelijkbare prijzen.
Kosten zijn er ook omdat de device list continu moet worden aangevuld met nieuwe types.

Ik weet niet hoe deze pods er van binnen uitzien, maar die van HiLo zat nog aardig wat electronica in, niet iets om snel even te maken...
Daarbij kost een goede ZIF voet ook al gauw iets tussen 20 en 100 euro... (of meer)

De Galep 5D is vergelijkbaar qua opbouw en kost 599...2199 dollar (al naar gelang uitvoering), losse pods 300...1300 USD.

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Op 22 juni 2019 19:55:55 schreef Arco:
Kosten zijn er ook omdat de device list continu moet worden aangevuld met nieuwe types.

Een dom ontwerp van je programmeer-algorithme betekent dat je device list continue aangepast moet worden.

Echt... Nadat je daar in 1990-1995 vijf jaar last van gehad hebt moet je beslissen: We maken voortaan een standaard manier waarmee de programmer kan opvragen welke generatie de chip is. (4 bits o.i.d). Vervolgens heb je vanaf generatie 2 dat je op kan vragen hoeveel RAM/ROM/EEPROM het ding heeft en kan je die op een standaard manier programmeren op basis van de gegevens die de chip je zelf geeft.

Voor RAM/ROM neem je een exponentieele codering zodat het lang blijft werken. 1 byte: 0bxxxxxxxy = (1+y/2) * 2 ^ x kB. heeft met 1Mb flash in processoren nog drie bits ongebruikt. Tegen de tijd dat die op zijn, moet je je realiseren dat we ook geen woorden meer hebben voor 10^x van die orde-van-grootte!

Dit alles moet je in generatie 2 van je microcontrollers bedenken, omdat je als bedrijf de "instapdrempel" voor jou processor omlaag wil hebben. En je toch geen winst kan maken op de "programmer- uptodate-houdt-afdeling". Daar gaat geld in die je met de verkoop van de programmers ook al vraag je 800 euro per stuk niet meer terugverdient.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

Je zult altijd device lijsten moeten maken. Al was het maar omdat veel fabrikanten niet doen aan opvraagbare data, of dat er geen logisch verband in zit.
Daarbij zijn er veel verschillende programmeerinterfaces; je zult toch moeten weten welke te gebruiken bij een bepaalde chip.
(of je loopt grote kans om iets in de chip om zeep te helpen als je lukraak gaat proberen)

Sommige dingen zijn ook moeilijk te voorspellen. Bijv. harddisk: die zijn sinds de vroege modellen nu een factor 1.600.000 groter geworden qua capaciteit... ;)
Meeste universele programmermakers zoals Conitec bieden ook nog service om op aanvraag nieuwe (of oude) chips toe te voegen.
Prijsvoorbeeld van een ZIF voet voor een 100 pins QFP van Yamaichi: https://nl.rs-online.com/web/p/prototyping-sockets/5008015/

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

In 1948 zei Von Neumann:

Over een paar jaar is de rek er uit en zullen we computers niet veel sneller meer kunnen maken: De natuurkunde staat gewoon niet toe dat we de boel nog sneller maken. Maarja, zo'n statement kan enorm lullig klinken zeg vijf jaar vanaf nu.

Zo'n 17 jaar later is Moore met een regeltje gekomen wat met kleine aanpassingen gewoon prima toepasbaar is op de periode 1948 - 2018.

En gedurende de hele zeg 1970-heden periode heb je af en toe mensen die Von Neumann napraten, maar dan zonder dat laatse zinnetje. Die moet je negeren, want ze hebben geen gelijk. Daar is al ruim vijftig jaar bewijs van.

Dus dat harddisks zo'n 1000x groter worden is een kwestie van 20 jaar. Een factor miljoen kost 40 jaar een factor 1.6 miljoen ongeveer 42 jaar. De "constante van moore" zoals ik hem maar even noem, zou best iets kunnen afwijken van de praktische, afgeronde waarde van 1000 per 20 jaar. En dan is die 1.6 miljoen niet in 42 jaar tot stand gekomen maar in 37-47 jaar. Maar het zal niet veel schelen.

En dan moet je inzien dat het coderen van de flashgrootte als floating point getal (met in mijn voorstel 7 bits exponent en 1 bit mantissa) ruwweg 240 jaar mee zal gaan. Voor harddisks is die 1 bit mantissa net niet genoeg. Maar met twee bits mantissa zit je met 8 bits totaal nog steeds aan 120 jaar levensduur van zo'n size identifier. Echt vijf minuten nadenken en je kan zoiets toekomstbestendig maken.

Waar vroegere programmeer-acties een 12V nodig hadden die je extern moest aanbieden, wordt die tegenwoordig gewoon door de chip onboard gemaakt. Dit maakt "in circuit programming" en "self programming" makkelijker. Het gevolg is dat het programmeer-probleem degradeert tot: hoe krijg ik de data in de chip en communiceer ik over timing en succes.

Goed. Een gui wil misschien de namen van bitjes in "eflags" registers kunnen aangeven. Dan moet je je gui upgraden als je daar gebruikersvriendelijk mee om wilt gaan. Maar "kan nieuwe chip niet programmeeren" zou al 20 jaar verboden moeten zijn.

Atmel had eerst een "flags" register. Toen er meer dan 8 bits nodig waren een lflags, en hflags. Toen 16 onvoldoende was, kreeg je "eflags" er bij. Hoeveel ze er nu weer bij geprutst hebben weet ik niet. Maar de technische implementatie is dat er een adresspace is, gewoon met adressen. 0-1-2 is lflags, hflags, eflags. Hoe moeilijk is het om dit een flags-ruimte te noemen, zeg 1024 bits te definieren en te zeggen: "Diverse chips houden op met het implementeren van deze bits op varierende adressen. 2-3 zijn typische getallen heden-ten-dage." Met een simplele extra regel: "je kan de chip niet bricken met bit 7 van een onbekend adres" betekent dat een algemene programmer kan testen hoeveel er geimplementeerd zijn.

vijf minuten nadenken en je hebt iets wat toekomst bestendig is.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

We hebben het hier niet over de fabrikanten van chips, maar die van programmers... ;)
(en die zullen moeten leven met/zich aanpassen aan de chipfabrikanten...)

Niet alles verbetert perse als het vernieuwd wordt. Neem een OS als Windows. (maar dat geldt ook voor de meeste andere)
Sinds de eerste versie is de omvang enorm toegenomen. (wat op een paar diskettes paste, zou je nu vele duizenden diskettes voor nodig hebben...)
Tevens zijn pc's duizenden malen sneller geworden. En toch is opstarten van het OS veel trager: oude Windows paar seconden, nu makkelijk een minuut.
(da's met een conventionele HDD, maar ook met een SSD blijft 't trager qua opstart)

Je zou toch verwachten dat een modern OS ook in seconden op zou kunnen starten. Geldt ook voor embedded systems met Linux.
Ergert me mateloos dat 'iets' met Linux aan boord bijna altijd een halve minuut of meer nodig heeft om tot leven te komen. Is totaal niet nodig.

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Op 23 juni 2019 11:58:30 schreef Arco:
We hebben het hier niet over de fabrikanten van chips, maar die van programmers... ;)

Is MPLAB niet van microchip zelf?

Goed knippen in een opstartprocedure moet een snelle opstart mogelijk maken. Mijn 486 had vroeger X draaien na zo'n 2 seconde. (8Mb RAM, 130Mb hd, 33Mhz. Dat zal 1992, 1993 geweest zijn. En nee, dat ging toen ook niet vanzelf. "Daar moet je wel wat voor doen!". En met iedere upgrade weer, dus ik heb het opgegeven en wacht die dertig seconde gewoon).

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/