Reagálnék pár mondatodra: - Nem teljesen értem, de a tápfeszültség referencia feszültségén mire gondolsz? Ha pl. egy TL431-re, akkor az simán kiszabályozza a tápfeszültség hullámosságát, a kimenetén pedig nagyjából ugyanazt a feszültséget fogod mérni. Akár ráraksz 10K terhelést, akár nem. Ezért referencia, mert fix. Maximum hőmérséklet változásra érzékeny, de a tápfeszültség önmagában sem olyan pontos. Azt kellene nézni, hogy mit mihez képest mérsz. Méred a tápfeszültséget, ami zajos, akkor keresni kellene hozzá egy fix, pontos referencia pontot, és akkor kapsz megfelelő eredményeket. Ha a referencia is lebeg ide-oda, akkor nagy pontatlansággal tudsz mérni. Sok esetben persze ez is elegendő.
- Az ADC konverter referencia feszültsége nem terheli a feszültség osztót. Egy feszültség nem tud terhelni, de nincs is a feszültség osztóval kapcsolatban. Az ADC vesz egy mintát a feszültségosztón levő feszültségből, ezt eltárolja egy kis kapacitásban (innentől nincs kapcsolatban az ADC konvertere a feszültség osztóval), majd összehasonlítja a referencia feszültséggel, és közli az eredményt az uC-lel.
- A bemenetre köthetsz feszültség osztót, mint írtuk, a terhelés rajta minimális (ezért nem szabad a feszültség osztónak Mohm-os tartományban lennie), és fix, tehát kiesik a hiba. A referencia feszültség, pl. Atmega328-nál kb. 40-60mA-rel terhelhető. Csak így tudja kiszabályozni a zajt. Én hajtottam már róla LED-et is. A TL431-nek sem okoz gondot ekkora terhelés. De a feszültség referenciát egyébként sem szoktuk terhelni (és leosztani sem). Vagy ha terheljük, akkor rajta a terhelés fix, és a feszültség is fix lesz rajta.
- a feszültség osztó önmagában nem okoz mérési pontatlanságot, ugyanis az ellenállások értéke fix marad, maximum hőmérséklet változásra változik az értékük. Egyszerűen meg kell mérni pontosan az értéküket, és be kell vinni a programba, hogy tudjuk, mivel kell számolni. Ugyanúgy ha a referencia feszültségünk pl. TL431, arra is érdemes rámérni egy jobbfajta multiméterrel, mert a 2.50V lehet 2.49-2.51V-is, és ezzel kell számolni. Viszont ez a mért 2.49V nem fog már tovább változni, ez fixnek tekinthető. Az 1x-es műveleti erősítőt jól meg kell választani, mert pl. egy LM358 a maga 5mV-os offset feszültségével lehet többet ront, mint ha ott sem lenne. Én nem szoktam ilyet alkalmazni, bőven elég a pontosság.

Én azt írtam le, amit megtanultam és megtapasztaltam. Csak azért reagálok a hozzászólásodra, hogy ne hidd azt, hogy igazt adtam, mert több dologra rá tudok cáfolni és ajánlani, hogy próbáld ki. Nincs erőm és kedvem hogy mindent leírjak. Senki nem köszöni meg vagy gondolkozik el rajta.

Már ne haragudj, hogy bele szólok, mert aztán tényleg nincs hozzá közöm, de végig olvasva az egész beszélgetést, a te stílusodon is lehetne csiszolni rendesen. Mert azt hiszem arroganciából simán hozod az 5-söt.

Egy PIC18F14K50 megdicsőülése

Felnyitottam egy Altera USB Blaster klónt (az Altera CPLD-k , hogy meglessem, mi van benne. A kicsi kínai dobozkában a kicsi kínai panelon meglepetésemre csak egy Microchip PIC18F14K50.
csücsül egy félmaroknyi ellenállás társaságában. Ennek ellenére működik, legalábbis egy Altera MAX II kategóriájú CLPD-t sikerült felprogramoznom vele.

Az ötlet nyilván erről a japán oldalról származik, ahol PIC18F2550-nel építettek JTAG eszközt az Altera CPLD és FPGA eszözök programozásához. A kapcsolást és a firmware-t később PIC18F14K50-re is adaptálták (lásd a 2.回路図 pontot az említett honlapon). Szép munka, bár a PIC18F14K50 esetében a sok ellenállást megspórolhatták volna, ha nem 5V-ról, hanem 3,3 V-ról járatják a mikrovezérlőt! Erről bővebben: Link

Megjelent a PIC32MM0064GPL036 család adatlapja és programozási specifikációja.

Idézet:
„A kicsi kínai dobozkában a kicsi kínai panelon...”

...kicsi kínai mikrovezérlő.

Ez ilyen egy hete van kint vagy régebb óta? Mert gondolom nem egy darab lesz az 32MM szériából és ha jól láttam akkor lesz 32MK is és nem találtam az M honlapján a 32-esek között egyiket se,.

Érdekes történet ez:
A 2014 -ben kiadott PIC32MX_MZ_ProgramSpec_60001145P.pdf megemlíti a 32MM és 32MK családot is, de a 2015 -ben megjelent PIC32MX_MZ_ProgramSpec_60001145Q.pdf meg sem említi. Most 2016 -ben külön specifikációja lett.

Csak azért érdekelne, mert ez a 20 lábas kiszerelés felkeltette az érdeklődésemet kicsit nekem olyan az érzés(de ez persze szubjektív) mintha már eljött az idő, hogy hagyjuk a 8 bitet és irány feljebb és még az egyszerűbb projektekhez is 16/32 bites mikrovezérlő legyen használva. Bár én régóta ezt csinálom sok mindent meg kell még tanulnom, de akkora szabadságot ad már a 16 bit a 255 számtartomány helyett a 65535 és a 32 bitről ne is beszéljünk, bár mondjuk én se 16 se 32 bitesre nem tudok assembly kódot írni csak 8 bitre.

Ez a trend, akár 8 lábra is van.

Kicsit jobb esélyekkel nem kínai, taiwani.

A jelek szerint lefelé cserélnék a régi atmel hangyákat az iot piacon. Stabilan megy 2.4v-ról is, és durván leharmadolták a fogyasztását az elődeihez képest.

Szerintem ezzel vagyunk egy páran, de nem azért, mert nem tudnánk megtanulni, inkább azért, mert nem érdemes. A C nem vesz el annyit a sebességből, mint amit a fejlesztés hatékonyságához ad. A sebesség pedig relatív, mert a C-ben írt kód gyorsabb egy 32MX-Z-n, mint egy 8 bitesen. Érdemes váltani, más világ. Ettől függetlenül a 8 biteseket sem száműztem még. Mindent a megfelelő helyre kell használni...

Szerintem az ellenállások jól jönnek védelemnek. Igaz elég lenne 5-el kevesebb, ha 3,3V-os lenne a táp. Nem gáz így...

Sokszor én is ezt látom. Nem rég éreztem megint hiányát pl. a hardveres osztónak. Bár sikerült megoldani (6 számjegyű szám osztása), de azért elketyeg egy jó pár darabig, míg ha nézek egy PIC24F-et, az 18 utasítás alatt meg van. Na meg a 7 szintes INT sem rossz dolog, a 2 szinteshez képest.
De a másik véglet, mikor megveszi Gipsz Jakab az Arduinot, meg Raspberry-t, és olyan feladatot csinál vele, amit egy 12F is meg tud. Nyilván a hello world, meg gyakorlásnak oké, de sokszor látni jutobon olyat, hogy szigszalag-arduino (32bites) párossal akarják megoldani azt, amit egy bármilyen 8 bites uC is meg tudna csinálni, komolyabb fejtörés nélkül.
Szóval igen, mindent a maga helyén kell kezelni. És szerintem a 8 bitesnek is abszolút van létjogosultsága, persze nem spektrumanalízist kell vele számolni.. (bár azt is akartam már vele, csak matekból időközben elég rosszul állok ).

Én személy szerint nem az érdemessége miatt nem tanultam az assembly-t tovább. Már 8 biten is csak akkor veszem ellő, ha gyorsan kell valamit csinálni és semmi felesleg nem lehet benne. Én nem szeretem, ha nem "néz ki" jól a program. És mondjuk egy VS c#, c++ után visszaülni még a C-hez is nehéz folyamatosan azt éreztem, hogy meg van kötve a kezem.
Ezért tértem át 32 bitre mert, (ez is szubjektív)annyira átlátható strukturált programot lehet összerakni... Ezzel csak egy baj van, hogy a PIC-ről c++ dokumentáció majd a 0-val egyenlő.

zentom:
Meg ha a megszakítások szóba jöttek mikor én gondoltam, hogy kipróbálom a 16 bitet először nagyon fura volt a (több)vektoros megszakítás 32 biten meg "amit szeretnék" direkt című vagy vektoros megszakítás. De ezt lehet napokig lehetne írni, hogy miben jobb, mert mindig lehetne találni valamit amiben jobb(lehet, hogy lehet találni olyat is amiben rosszabb bár nem hiszem).

A 8 biteseket egyetlen helyről még biztosan nem száműzném - és nem is lesznek száműzve soha talán - az extrem low fogyasztást követelő helyekről, ahol semmi multimédia-gyanús vagy egyéb adatot nem kell használni, nem kell flash méret, sem ram, sem extra perifériák, sem cpu sebesség, épp csak valami gagyi logikát otthagynak valahol egy gombelemmel, és el kell ketyegnie arról a kb 5 mAh-ról egy egész évig. Példa: figyelni valami riasztás eseményt, kijelezni kvarc-lapon pontos időt, feljegyezni valami szenzor szélső értékeit (3-4 óránként egyszer bekapcsolni egy tized másodpercnyi időre, és azon túl csak sleep-elni), ilyen helyekre a 32 bites tök felesleges, mert azok még 32 khz frekivel működve is nagyon sok uA-t esznek a nA-ek helyett, és nem juthat annyi. Oda kellenek a 12-esek, amik direkt zéró fogyasztásra születtek, meg kell az asm a perfect kódvégrehajtási hatékonysághoz mindent elbírni zéró közeli órajellel, de csak oda kellenek biztosan.

Aztán ott vannak az 5v-os régi elektronikák, amiket még azért nem cseréltek le, mert a régi olcsóbb, és a fogyasztás nem követelmény. Még oda is elmennek kicsi teljesítményben a 8 bitesek, vagy van a pic30-as család 16 bitesen 5v-osban. De oda az asm már nem különösebben kell, C-ben sokkal kényelmesebb.

A többi helyre szerintem védhetetlen a 8 és 16 bitesek jelenléte, és csak idő kérdése, hogy kiszoruljanak. A népek végül úgyis a kényelmet választják majd, és ahhoz erőforrást kell pocsékolni. Pocsékolni pedig csak abból lehet, amiből van bőven. Még a C is ki fog szerintem szorulni onnét. Lesz majd javascript. Hiába hápogunk ellene, az idő le fogja gyömöszölni a torkunkon, akár akarjuk, akár nem /szopós malac emoji

Az elktro tanárom mindig mondja, hogy az elektro technikusok/mérnökök lusták sose szeretnek többet csinálni mint amit kell.

Ez jópofa mondás és lehet, hogy van is benne valami, de valójában minden ész érv arra vezet, hogy csak annyit, amennyire szükség van. Kivétel ez alól a hobbi, amikor csak a magad szórakoztatására villogtatsz egy LED-et 32MZ-vel.

Minden szép és jó a 16, 32, (64, 128) bites kontrollerekkel.... De az az érzésem kezd előjönni, ami már a PC világban már jó ideje megvan: A felfontosabb alkatrész életét, működőképességét bízzuk a legmegbízhatatlanabbakra. PC esetében a CPU hűtését a forgó alkatrészt tartalmazó vetilátorra, a CPU tápfeszültségét elektrolit kondenzátorokra. PIC eletében a Vcap kondenzátor a leggyengébb láncszem.

Meg a felhasználó, aki elfelejti bekötni... (Velem is megesett már!)

Jó hát az io-tól eltérő magfeszültség tényleg egy kicsit ciki, de ha megy tovább a történet a szuper kicsi fogyasztás irányába, igazából egy nagyobb tokba már kondenzátort is beleépíthetnek akkorát, amennyi egy normálisabb charge pump-al már elegendő a stabil működéshez. A pdip tokokon belül jelenleg jó a fele térfogat teljesen kihasználatlan - a tényleges chip négyzetes alakú, azért terjedtek al a tq tokok, és népszerűsödtek a tsop-ok is, mert úgy hatékonyabb a helykihasználás. Ha a jövőben tenni akarnak vele valamit, igazából tudnak tenni vele bőven eleget. De ha egy tippet adjak a legvalószínűbb kimenetelre, valószínűleg rájátszanak egy kicsit a történetre, hogy sokkal több pic menjen tönkre, és juszt is legyömöszölik a piac torkán még azt is.

Én úgy látom jönnek ki a speciális, alkalmazásokhoz idomított 8 bitesek. Pl. 16F1619: 16 bites PID számítás 32 bites eredménnyel, 24 bites számláló, nullátmenet figyelés, fázisszög mérő, 100mA-es kimenetek, mindez 20 lábon PPS-sel.

Az eltérő I/O és mag feszültség nem a teljesítmény csökkentés miatt lenne fontos? Nem tudom egy 200MHz pörgő MZ-nek mekkora a fogyasztása, de szerintem ezzel próbálják csökkenteni.

Hp41C:
Ami érdekes a VCAP kondival, hogy valamelyik PIC-nél kikapcsolhatjuk a belső szabit és mehet külsőről is, bár ugye azt is kell valahonnan "szedni" és a külső szabihoz is kell kondi(kicsit ilyen ördögi kör).

Nem engedett már módosítani rendesen, de azt akartam még írni: Viszont a PIC32MZ2048EFG100 aminek szép hosszú az erratája ott ezt megoldották(erre vonatkozik a kép).

Egy CMOS technológiájú eszköz disszipációja k * f * (U ^ 2), egyszóval a tápfeszültségtől négyzetesen függ. Ha a mag (a legtöbb "kaput" tartalmazó egység) feszültsége csak 1.8V, a disszipációja 30% -a annak, mintha 3.3V -ról járna. A tápfeszültség csökkentésének másik oka a szilicium dioxid átütési szilárdsága : 8 ×10^6 V/cm = 8 ×10^5 V/mm = 800 V/um = 0.8V/nm

Ezt az átütési szilárdságos dolgot nem értem teljesen. Szóval azért csökkentik a tápot mert a 0.8 1nm-en elég sok és, hogy véletlenül se kerüljön az "egyik helyről a másikra" a töltés és ne csináljon olyat amilyet nem kéne?

Ha az I/O a mag feszültségén megy (V_DD és V_CAP/V_DDCORE összekötve, VREG tiltva), akkor nincs szükség a belső DC/DC konverterre és pufferkondira, vagy másodlagos tápra.

Nem tudom pontosan hol is járunk, de már rég a um alatt. A fenti érték egy ideális eset értéke. Ha tovább csökkentik a csíkszélességet, ez a korlát is fokozottabban jelentkezik.

Jól mondják a többiek. Egy TCP/IP stack-et szép munka megírni asm-ben, bár a pic32 HW-ben támogatja, de nem teljesen.

Próbáld ki a 32 biteset, nagyon más, hasonló mintha PC-re fejlesztenél. Hosszú évekig 8 biteztem, de egy projektnél ragaszkodtak a PIC32-höz. Azóta is ha lehet ezzel fejlesztek és nem értem miért nem próbáltam ki hamarabb.