Fórum témák
» Több friss téma |
Köszönöm a segítséget mindenkinek!Sikerült megoldani megszakítás nélkül de újabb problémába ütköztem.Működik az áramkör , úgy hogy eljutottam addig , hogy beszereljem a szivattyúhoz.A szivattyú egy pincébe van , ahol van egy kötő doboz és egy nyomáskapcsoló kapcsolja ki - be a mágneskapcsolót , ami meg a szivattyút kapcsolja be.Úgy oldottam meg a számlálást , hogy a nyomáskapcsolóra rákötöttem egy relét , aminek az érintkezőjére egy 9V-os elem negatívját kötöttem , tehát a relé ezt kapcsolgatja és ezt számolja a kontroller.A probléma az , hogy ha a kötődobozba rakom az áramkört , akkor elszámol egyig és lenulláza magát egyből , ahogy kikapcsol a szivattyú , pedig a nyomógombbal működik a léptetés.Az az észrevételem , hogy ha kihozom egy 5 méterre a kötődoboztól az áramkört egy kábelen keresztül , akkor nem nullázza lemagát.Elképzelhető , hogy ott a kötődobozba így "bezavarna" a 230V kapcsolgatása , hogy lenullázza a picet?Ha ez előfodrulhat akkor mi a megoldás?
Mikrokontrollerek zavarszűrése c. téma.
Zavarszűrés illetve a feszültség ingadozása lehet a probléma.
Sziasztok!
Már volt itt vagy a haladóban említve a PIC16F18857/77 4096 byte-os RAM-al, már nem emlékszem ki említette, de volt szó arról is, hogy a fordítót is át kell majd szervezni a 64 bank miatt. Na, most a doksiban 40-46 oldalon láthatjuk, hogy 64 bank van(0-63). Aztán ugrunk 88. oldalra az indircet addressing-hez és láss csodát a traditional addressing-be is csak 32 bank van és a linear addressing-ba is csak 32. Szóval van 4096 byte RAM-unk, de nem férünk hozzá? Vagy most megint "ügyes" volt a drága Microchip? Vagy én értem félre és a 32-63-ig csak direkt címzéssel érhető el? De nekem lehetetlenül van megoldva ez, 12 bites a RAM címzése és egy bank 128 byte-os akkor azzal csak 32 bankot tud címezni nem vagy ez meg csak az indirekt címzésre vonatkozik?
A BSR 6 bites. Innentol kezdve 64 bank van. De az FSR0L/H-n keresztul ugyis elered, ha muszaj.
Akkor az adatlapban van ellentmondás?
Az első képen az elmondásod szerinti 6 bit a második képen pedig 5 bit. És az FSR-en keresztül linear módban el lehet érni az összes 80 byte-os blokkot?
Jelenleg voltam olyan trehány, hogy az adatlapot meg sem néztem, de szorozni attól még tudok. Ha 128 byte van egy bankban, és összesen 4096 byte a memória, ahhoz csak 32 bank kell, nem 64. Számít az bármit?
Ez oké én is számolgattam
 de a Microchip az első 32 bankból sokat nem használ és csinált 64 bankot, hogy megzavarjon vele engem 
Az adatlapban mindenkeppen ellentmondas van. De most mar en is belezavarodtam.
Sajnos a Microchip dokumentacio-keszitoi nem restellnek durva copy&paste modszerekkel dolgozni, mas esetben is talalkoztam ilyennel.
Sajnos ez egy nagyon új típus, így a dokumentációja elég trehány. Sajnos ehhez lassan hozzá kell szoknunk.... (Főleg a copy-paste módszer és a másolat javításának elmaradása okozza a gondot.) De nem csak a dokumentációvan van baj, hanem a megvalósított áramkörrel is. Érdemesebb várni egy két javítási menetet a felhasználás előtt. Továbbá minden típusnál érdemes olvasgatni az Errata -t. Ez az adatlap hiba még nincs benne.
A hozzászólás módosítva: Jún 30, 2016
Az erratát már néztem és meglepődtem, hogy három kisebb hiba van benne, bár az eeprom indirekt olvasásának hiánya lehet valakinek nagy probléma. (Bár ez lehet csak azért van mert eléggé új cucc).
Szóval én azt gondoltam, hogy végre meghallgatott minket az M, de nem ... (Ez lehet nem függ össze)De én úgy gondolom egy olyan cég aki sorra vásárolja fel a többit (a legújabb "szerzeménye" az Atmel) az, hogy követhet el ilyen hibát ami csak a lustaságból ered.
Nagyon egyszerű, a felvásárláshoz tőkeerő kell, nem szakmai gárda
Csak a tárgyszerűség kedvéért: egy felvásárlásnak több oka is lehet. Ma már a 32-bit előzi a 8-at,szóval összességében ez a helyzet :
Bővebben: Link Hogy ezen az 5. helyen mit változtat az Atmel, az majd kiderül. Idézet: „Az erratát már néztem és meglepődtem, hogy három kisebb hiba van benne,” Lessz az még hosszabb... Az adatlap még csak A verziójú.
Az errata frissítések helyett, miért nem az adatlapot frissítik?
Egy kiadott adatlapot már nem olyan egyszerű dolog csak úgy átírni logisztikailag. Azt azért is kell az elején normálisan csinálni, mert utána hivatkozásokkal jönnek a visszajelzések, és összekeverednének a fő doksi számok. Jobb egy áramköri termékről csak egyetlen elsődleges dokumentáció. Amit még el lehetne (lehetett volna) követni, hogy első körben csak preliminary doksit kiadni, és megadni egy dátumot, amikor az befrissül. De a jelek szerint nehezen tanulnak bele a srácok a dolgokba. 30 év még nem volt elég hozzá
A hozzászólás módosítva: Jún 30, 2016
Csalókák tudnak lenni azok a statisztikai blogok, hogyan is számolják az első helyet. Pld legtöbb eladott termék darabszámra? Vagy bruttó bevételre? Vagy nettó nyereségre? Community méretre? Vagy hogyan?
A pic32 az egyetlen 32 bites koncepció, ami belső ramból is tud végrehajtani, és részint azzal tudnak sebességet is növelni, részint fogyasztást is csökkenteni. Egyik másik gyártó terméke sem tud olyat. Nagyon alapvető fejlesztési potenciált foglaltak el mc-ék, és van üzleti egészségük is a tényleges fejlődésre. Tud még változni az a lista. Idézet: „A pic32 az egyetlen 32 bites koncepció, ami belső ramból is tud végrehajtani” Szerintem az összes ARM Cotex-M3 tud RAM-ból futni (hogy ennek van-e gyakorlati haszna, azt ne firtassuk), az IAR Technical Note 11578 például az alábbiakra ad egy-egy mintaprojektet: AT91SAM3U (Cortex-M3) example project IAR Embedded Workbench for ARM 6.10.3.zip LPC2148 (ARM7) example project IAR Embedded Workbench for ARM 6.10.3.zip STM32F2xx (Cortex-M3) example project IAR Embedded Workbench for ARM 6.30.6.zip Bővebben: Link A hozzászólás módosítva: Jún 30, 2016
Hmm, letöltöttem egy stm adatlapot, és megkukucskáltam újra. Nálad a pont, tényleg rajta van a belső ram is az I buszon. Fogalmam sincs, mit néztem el anno
 Egyébként van teljesítménybeli vonatkozása. Ahol külső memória vezérlők vannak (dinamikus ram), ott cache line-ozás megy még azzal a kódrészlettel is, ami esetleg egy interrupt kiszolgáló rutinja. Az sokkal hatékonyabb belső memóriából végrehajtva, ami 0 wait ciklussal olvasható. Persze nem mindegyik alkalmazás gondol cutting edge-nek lenni, de éppenséggel előny, ha arra is jó az adott processzor.
De nem is lenne olyan bonyolult. Az adatlapnak verzió számot kell adni és meg van oldva a probléma. Vagy legalább az adatlapban jelezni kellene valahogy az adott résznél, hogy hibásan van írva és az errata-ban van a javítás. Ez utóbbi tényleg nem okozna nagy logisztikai problémákat.
A hozzászólás módosítva: Jún 30, 2016
De bizony okozna. Tapasztalat, hogy nem jön be a gyakorlatnak az átírásos verzió. A népek nehezen szoknak hozzá agyilag a verziókhoz. Nincs meg bennük a reflex, hogy a doksi mellé a doksi verzióját is megjegyezzék. Egy probléma, ami csak van, mint a halál, meg az adó. Az utólag kiadott update doksi az elfogadhatóbb.
Ugyan, hagyjuk már. Aki agyilag nincs a toppon az nem foglalkozik hibajelentéssel. Ha van egy normális hibajelentő oldal, akkor kizárt a doksi verziószámának nélkül elküldeni a hibát. Küldtem már be hibajelentést játékkal kapcsolatban és ott is kért minden kutyafülét, addig nem lehetett elküldeni a hibajelentést míg meg nem adtam a verziószámot. Így meg csak maguk alatt vágják a fát, mert aki nem olvas errata-t (nagyon sokan nem is tudják hogy van) az folyamatosan küldi be ugyanazokat a hibákat. A felhasználónak is rossz, hogy nem jelzik helyben a hibát. Mert most komolyan, ha akarok használni egy modult akkor előtte át kell nyálaznom az errata-t, hogy van-e benne elírás? Nonszensz.
 Kíváncsi lennék milyen tapasztalatból született ez a kijelentésed. Mert ha logikusan belegondolsz akkor teljesen mindegy, hogy az adatlapot vagy az errata-t frissítik (felhasználó barátság szempontjából nézve nem, de ez most lényegtelen). Mindkét esetben ugyanúgy le kell(ene) töltened mindig a legújabb verziót, hogy ne okozzon váratlan meglepetést a uC. Mellesleg nem szoftverről van szó amit a végtelenségig lehet fejleszteni... A hozzászólás módosítva: Júl 1, 2016
Idézet: „Mert most komolyan, ha akarok használni egy modult akkor előtte át kell nyálaznom az errata-t, hogy van-e benne elírás? Nonszensz.” Ennél sokkal bonyolultabb a helyzet. Sok felhasználó van és náluk a legkülönfélébb verziójú (silicon revision) kontroller van. Ha egészen pontos szeretnék lenni, akkor előbb ki kell olvasnod a nálad levő kontrollerből a verziót. Annak alapján megnézni az adatlapot és a hozzá tartozó errata -kat. Ekkor be tudod azonosítani, hogy erre a verzióra mely hibák vonatkoznak. Ennek ismeretében tudod eldönteni, hogy a modul megfelel-e a Te feladatodra. Ugyanis egyes hibákat az újabb verzióban kijavítaniak, de az újban lehetnek új hibák... A kérdéses típus nagyon új... Tanulságul idéznék a 16F887A első verziójának errata -jából, főleg arra a kérdésre kereve a választ, hogy használható-e az első széria: Idézet: „3. Module: Core Certain code sequence and placement may cause the corruption of a few bits in the instruction fetch when the part is used above 4 MHz. A corrupted instruction fetch will cause the part to execute an improper instruction and result in unpredictable outputs. Microchip cannot predict which code sequences and placement will cause this failure. If this failure mechanism exists in your system, it should be evident during statistically significant preproduction testing (minimum suggested sample size 100 units) of your particular code sequence and placement. Any code change should be tested in the same manner prior to their implementation. If most parts fail your tests, or if failures are seen at all voltages or at all frequencies, this indicates that the problem experienced does not relate to this failure mechanism. This problem has not been observed at operating frequencies below 4 MHz.” Pedig nem egy új típus...
Na most akkor miről is megy itt a vita? Mert nagyon nem mindegy hogy a chip működési hibáiról van szó, vagy az adatlapban vétett elírásokról. Az "Errata" az előbbihez van, az utóbbit viszont az adatlap reviziójával javítják.
(Cross51 a kivágás/beillesztés miatt keletkezett elírásra panaszkodott.) A hozzászólás módosítva: Júl 1, 2016
Egy kép többet mond, mint 1k szó...
Idézet: „(Cross51 a kivágás/beillesztés miatt keletkezett elírásra panaszkodott.)” Egy trehányul összeszerkeszett (01/29/2016) A verziójú adatlapban talált hibáról van szó. Egy régebbi válaszomban említettem Neki, hogy valószínűleg a CPU részt (BSR és a lapozás) átvették egy másik típusból és nem javították, de ebben a típusban a BSR 6 bites. A hiba még nem szerepel az eddig (06/10/2016) megjelent errataban. PIC16(L)F18857/18877 Family Silicon Errata and Data Sheet Clarification Sajnos közös dokumentumban írnak a chip és a dokumentáció hibáiról. A hozzászólás módosítva: Júl 1, 2016
Arról megy a vita, hogy Microchip-ék miért nem jelzik az adatlapban is - ha már mint kiderült szokták frissíteni azt is -, hogy pl. a Timer1 modul az "x verziójú y típusú PIC-nél hibásan működhet, bővebben lásd az errata-ban". Én csak ennyit kérnék tőlük.
Ezt szerintem nem lenne bonyolult bevinni az adatlapba és így tényleg csak akkor kellene megnyitnod az errata-t ha használni is akarod a nem 100%-os modult és nem minden egyes modulnál megnézni az errata-t, hogy esetleg nincs-e abban is hiba. De mindegy, ez van, ezt kell szeretni.
Bizonyára 5-6 errata után amikor már 3-4 éve nulla frissítés van a kontrolleren is, meg a doksiján is, kiadnak majd mindegyik vezérlőhöz egy "végleges" doksit (beleírják a nevébe, hogy datasheet revision D vagy akármi), és kap is egy újabb számot. De azt akkor sem nyakra-főre minden aprólék javításnál csinálják, maximum ha dokumentációs mérföldkövenként.
Az én kijelentéseim némelyike mögött olyasmik vannak, mint például munkatapasztalat multinál. Láttam már elementáris káoszt, és van érzékem hozzá, hogy feltűnjön, ha valamit nem jó ötlet terhelés próbának alávetni. Olyasmik, hogy "logikusan belegondolni" - hát nem. Azt biztosan fényév távolságban lőtted mellé
Sziasztok!
16F870-elszeretnék átlagot számolni, 10-el osztani.
A meas count tartalmazza a mérések számát, az u_t_sum a mérések összegét ás az u_t_avg az átlagolt feszültség. A meas count és u_t_avg uint8_t, az u_t_avg uint16_t. Ez így korrekt? Egész számot szeretnék kapni.
Kerekítésre nem gondoltál?
Köszi! A követketkező kérdésem is kitaláltad!
|
Bejelentkezés
Hirdetés |
