Ezt hogyan kellene érteni? Az autóra amikor ráindítasz, olyan brutál áramot leszív hirtelen, hogy ihaj. Azt csak nagyon modern akkuknál lehet megállapítani pusztán a feszültség alapján, hogy vélhetően van-e benne akkora töltés, ami elég lesz. Egy normál savas akkunál, ami mondjuk pár éves, ember legyen a talpán bármit is megjósolni az üresjárási feszültsége alapján. És akkor még nem is filoztunk azon, hogy még meleg volt-e a motor, vagy már hideg, mert elég rendesen eltérő áram kell neki mondjuk a téli hideg éjszakákon. Pörgeted némelyik kocsinál az indító motort 10 másodpercig is, míg eszi a 100 ampert. És ott van az a kérdés is, milyen műszaki állapotban vannak azok az indító elektronikák / mechanikák, mert tudnak azok is kopottak lenni, stb. Mindent összevetve, ha azon filozol, amire gondoltam, lehet, hogy egy kicsit nagy fába vágtad a fejszédet.

Ja persze, azt hittem képben vagy a projektek, 29F800-at használtam elsőnek most 29LV640 a kiszemelt memória. Tsop48-as tokozásban.

Igen, tudom hogy C ben nincs bites változó. A példa kódot is értem, köszönöm is.
Ugyanakkor még mindig nem világos hogy például az alábbi kódban hogyan kezelem az IF ágat. A zavart az okozza, hogy szimulátorban én teljesen vad értéket láttam visszatérési értékként.

char fv_1 (void)
{
...
...
return AAAbits.yyyy;
}


int fv_2 (void)
{
fv_1 ();
if (fv_1) {......}
}

Öööö ez nor flash. Ha nor flash kell, miért nem elég egy spi buszos? Ha lassú magot használnál, amúgy sem lesz olyan nagyon gyors az adat kezelése. Bőven lassabb lesz az usb-d. Pláne ahogy ezt a típust elnézem, még olcsónak sem mondanám. Esetleg ezt a listát ha megnézed: mc flash 64 mbit még 8 lábú is akad közte, és bár nem nor flash, de azért sokat téveszteni ezekre sem jellemző, ha nem hulladék irstabil tápot adsz neki.

Az első sorban ráhívtál a függvényre, és sehova nem raktad el a visszatérési értéket.

A második sorban nem a függvényre hívtál rá, hanem a függvény címét adtad át logikai ellenőrzésre. Esetleg próbáld így: if (fv_1()) {......}

Példa PIC24-re, persze párhuzamos port van PIC18-as sorozatban is.

Ez nem ilyen egyszerű.
A fix címlábak kellenek mert a SEGA Motorola 68K-s MCU közvetlen olvassa a memóriából az adatot.
Csak a 16Bit-es memória jó aminek fix a címbusza és fix az adatbusza.

Egy gyorstalpaló TTL - CMOS család áttekintés rádférne...
Egyébként 8 egységből álló D tároló sor, 3 állapotú kimenettel.
Alkalmazási példa: A kontroller 8 lábán byte -osan adod ki a címet. A címet alkotó 3 byte -ot három darab ilyen IC -be írod be. Sőt egymás ulán is kötheted őket: az első bemenete a kontrollerre, a hásodik bemenete az első kimenetére, a harmadik bemenete a második kimenetére kapcsolódik. Egy közös beírő órajellel vezérli őket a kontroller. A harmadikhoz tartozó adatot kiteszed egy 8 bites portra, kiadsz egy órajelet (felfutó élre tárolnak), kiteszed a másodikhoz tartozó adatot, kiadsz egy órajelet, kiteszed az elsőhöz tartozó adatot, kiadsz egy órajelet. A harmadik órajel kiadása után mindhárom IC kimenetén a kívánt adat jelenik meg. A művelet alatt a kimenetüket engedélyezni kell, de ez nem számít, mivel a memória csak az írás vagy olvasás vezérlőjel aktív állaota alatt követeli meg a cím állandóságát.

Szia pajti2!

Köszi a választ. Megnézem.

Szia icserny!

Köszi a választ, megnézem az általad javasoltakat.

Ugyan így csinálom, a shift regiszterrel a címzést, csak annyival másabb, hogy nem egyszerre adom ki a 8bit-et, hanem csak 3 lábon, illetve a 2vezérlőbittel tudom állítani a 3 állapotot.
Sajnos nincs elég láb a 8bit egyszerre való vezérléséhez.
De most már értem mire való.
Szerinted ez mennyivel lenne gyorsabb mint a shift regiszteres megoldás?
Persze azon kívül, hogy a shift regiszternél bitenként kell kiadnom az adatot itt meg byte-onként.
Bár gondolom, ha van elég láb a PIC-en akkor ezekre úgy sem lenne szükség, és a közvetlen vezérlésnél meg nincs gyorsabb.
Alternatívának viszont jó lehet.
Köszi.

A jelek szerint csak azért nézek furcsán a cím shift regiszteres tárolására, mert tényleg gőzöm sincs, hogyan épülne fel az egész, de szerintem a motorola 68k-k jellemzően párhuzamosan címeznek mindent, nincsen rajtuk támogatás shift regiszter vezérlésére. Ahhoz egy külön vezérlő kell nekik.

Szia!
Kb 2-5 percenként kapcsoltasd be egy külön relével a reflektorokat. Kb 0,2 másodperc múlva mérj bele az akufeszbe. A mérés után a refit már ki is kapcsohatod. Az izzók a felkapcsolás pillanatában megrántják annyira az akkut, hogy tudj mérni. Persze ez még csak viszonyítási alap. Sokat kell kisérletezni, hogy megtudd, hol a határérték. Ráadásul hosszútávon a lámpák ezt nem tolerálják.

Húúúú, akkor hamar átfutom még egyszer.
PIC-el töltöm fel a memóriát adattal:
PIC cím küldése -> 3db shifreg. -> memória
PC Adat küldés -> PIC adat fogadása -> PIC adat küldés (16bit) -> memória
Ez a PIC-es oldal, de olyankor mikor feltöltöm az adatot, akkor 68K nincs jelen mert ez egy kártya, ha jelen lenne beleoszol a kommunikációba.
Csatolok egy képet.

Amikor 68K jelen van akkor PIC mindent lekapcsol, így nem szól közbe sem a címbuszba sem az adatbuszba.
De a memóriát 68K csak akkor tudja olvasni, ha az őáltala gyárilag meghatározott módon történik az adatcsere.
Tehát fix cím és fix adatbuszok.

Oké, így már világosabb.

A pic < - > memória kommunikációra én is Hp41C véleményét osztom. Ahogyan vezérled a shitft regisztereket is, meg a 16 bitnyi memóriát is, az az egyik lehetőség, de annak a hátránya, hogy találnod kell egy nagyon sok lábas pic-et, amihez kész usb projected is van, és az lesz a valóban nehéz része. Kész usb projectet egyébként nagyon sok pichez találsz, de hogy akad-e közöttük, amelyiknek elég sok lába van, azt nem tudom.

_Ha_ nem találsz olyat, akkor a latch regiszter dióhéjban annyi, hogy halom sok külső áramkörrel egészíted ki a pic-ed lábszámait, és összesen 10 pic lábról egy javarészt akárhány tagnyi párhuzamos buszt vezérelni tudsz. +10 lába ugyanis bármelyik kiforrott usb-s pic-nek lesz. Pld pic18f4550 usb projectekkel tele az egész net, akár ennyire szájbarágós projectekkel. Nagyon mellé lőni vele simán csak képtelenség.

Hasonló _ha_ esetre lehetőség, hogy ha túl soknak találod a kezelendő vezetékszámot, nem egyszerű logikai áramköröket használsz fel, hanem pic-eket fürtözöl mondjuk i2c buszon. Úgy soros buszra van minden felfűzve, de az nem éppen olcsó (minden tag egy külön pic), mindegyiket külön programozni is kell, és az i2c egy ocsmány dolog szokott lenni. Jobb, ha csak 1 eszközt kell programozni, és minden más buta kis logikai kiszolgáló.

Sziasztok!

Tudna valaki segíteni?
MPlab X ide v3.20-ast használok. Hol lehet beállítani, hogy programmódosításnál hagyja békén az eeprom memóriát? Nem szeretnék több mint 100 adatot újra beírni.

Na igen, pont ezektől tartok.
Ezért kértem a segítségeteket, hogy jó PIC-et válasszak.
USB-vel még nem foglalkoztam eddig, csak egyszer akkor is csak a bootloader-t próbáltam és azt is csak 18F4550-en.
Szóval nagyon jól meg kell vizsgálnom mindent, nehogy na fába vágjam a fejszémet.

PIC32MZ -ben az "External Memory via EBI" memóriua retületem írhatod / olvashatod a külső áramkört. A 100 és 124 lábúakon 20, a 144 lábúakon 24 címbitet használhatsz. Ha jó látom, fel van készítve a NOR-FLASH -ra. Minimum PICKit3 kell a feljesztéséhez. Sajno s az Errata elég hosszú...

Ha külső tárolóval oldod meg a címzést elég lehet a 18F4xK50 és 4 db 74HC574. Páronként vezéreld: Cím 23..16 és Cím 15..8 tárolójának beírását egy port lábbal is megvalósíthatod. A felfutó él a magasabb helyiértékű, a lefutó él az alacsonyabb helyiértékű 8 bitet tárolja - mondjuk a D port vezetékeiről. Ugyanígy állíthatod elő a 16 bites adatvanalat is a memória számára, szintén a D portot használva. Hasonlóan lehetne beolvasni is az adatot, két byte-ot multiplexerrel a PORTD -n keresztül. Kellene még 8 bit cím (PORTB) és néhány vezérlő jel (PORTA). A kommunikációra megmarada a PORTC (usb, uart, led -ek).

Ha port kivezetésekkel közvetlenül címzed a memóriát, a 18F86J94 .. 18F97J99 lehet a megoldás. Jó sok lábuk van és USB -vel renelkeznek.

Az utóbbiakat lehet külső memóriával is járatni. A nagy kapacitás igény miatt lapokra kell osztani a teljes memóriáti és csak egy lapnyit illeszteni. A lapokat más portbittel vezérelni.

A 18F4x50 nem megoldás, 3.3V -ról nem megy a FS USB kommunikáció.

Van még egy tényező, amit figyelmen kívül hagytál. A fejlesztési kényelem.

Nem csak az lesz kérdés, hogy biztosan találj példa projectet, hanem az is, hogy ha ilyen nagyon sok lábas cuccokat tucat szám forrasztasz fel, hányszor fogod megégetni valamelyik ujjadat a forrasztópákával

Abból a szempontból az lesz fontos, hogy tisztán lásd a reális költségvetést. Mindig mindenki úgy kezd neki, hogy összelejmolt cuccokból építkezni, de azt csak a nagyon gyakorlottak tudják tényleg megcsinálni. Ha kell belőle összesen pár darab, és csak funny cucc a haveroknak, nem emiatt mész csődbe akkor sem, ha nem a spártai vérmocsok-megerőszakolós stílusban raksz össze mindent, hanem rászánsz valamennyi pénzt fejlesztési kényelemre, és előregyártott boardokat használsz.

Sziasztok!
Van valakinek tapasztalata pic18f26k80 szériás pic ADC életre keltésével kapcsolatban?
Minden configurációt kipróbáltam , de még a lábat se tudom beállítani analóg bemenetre.
Köszönettel Wincso
beállitásaim
ADCON0 = 1
ADCON1 = 0
ADCON2 = %10100001
ANCON0 = 1
ANCON1 = 0
ADCON0.1 = 1
WaitUs 20
while ADCON0.1 = 1
wend
fenyero= ADRESL
Endif

A kártya Flash ROM-ját a működő SEGA konzolba dugva is tudod írni, úgy nem kell mindig ki-be rakosgatni, ha új játékot akarsz. Törlés és újraírás előtt csak resetbe húzod a 68000-est, (vagy a Halt lábát rántod le földre) akkor a kimenetei nagyimpedanciásra váltanak és szabadon hozzáférhetsz a PIC-kel az adat-, cím- és vezérlőbuszhoz. (Nem tudom hogy milyen vezetékek vannak kivezetve a kártya portra.) Persze azért jó tudni hogy más részegységek ilyenkor szintén inaktívvá válnak-e, és nem pofázhatnak bele a kommunikációba. Így a Flash helyett SRAM-ot is használhatsz, aminek írása gyorsabb, viszont az elveszti a tartalmát kikapcsoláskor. Az írás után csak lekapcsolódik a PIC a buszról, Reset láb felenged és már indulhat is a móka.

Azt csak oéldának mondtam, , de van nagyobb lábszámú 8 bites is.

Nézzük a másik oldalról.
Tegyük fel nem akarsz a CDC-hez drivert írni, így elég a HID által elérhető 64kB/s sebesség.
A leggyorsabb 8 bites MCU manapság 16 MIPS.
Ez azt jelenti, hogy egy bájt feldolgozására 250 utasítás ciklusod van. Nem tudom, mit kell csinálnia a programnak a byteokkal, de gyanítom még az ingyenes XC8 is tud olyan kódot fordítani amibe ez belefér.
Ergo elég kellene hogy legyen egy 8 bites is.
Megnéztem az árát meglepő módon nem drágábbak egy 4550-nél.
Még a legnagyobb is (P18F97J97) is kb ugyanannyiba kerül.

Mindezektől függetlenül játszhatsz a 16 vagy 32 bites procikkal is, C-ben nem észvesztő az eltérés (és árban sem). Rajtad áll.

Szerk.: A memóriakezelés részét nem tudom mennyire időigényes, de ha párhuzamosan kell küldeni gondolom még az is belefér.

Ha így használom error: too few arguments to function hibajelzést kapok.

Csak emlékeztetőül a kérdés az alábbi volt:
Hogyan kell feldolgozni a visszatérési értékként kapott bitet?

char fv_1 (void)
{
...
...
return AAAbits.yyyy;
}


int fv_2 (void)
{
fv_1 ();
if (fv_1) {......}
}

Szia!

A feszt mértem már , az szinte mindig 12V , tehát az nem jó ebből a szempontból. Az Amper-t kell mérni.

Szia!

Azon filózok , hogy ha bekapcsolom az autóban a rádiót , akkor az kapcsoljon le akkor , ha már éppen annyi energia van az akkumlátorba , hogy elindul az autó. ( Tehát ne tudjam addig hallgatni a rádiót álló helyzetben , hogy indításképtelen legyen a kocsi.)

Erre gondoltam mérni a feszt , de az mint kiderült , szinte mindig 12 , helyette Ampert kell mérni.

Szerintem nem jo az ampermeres. Te az akku allapotat akarod tulajdonkeppen monitorozni, amit terhelovillaval tudnak egyedul normalis modon merni, inditasi aram szempontjabol.
Terheles hatasara az akku feszultsege leesik. A terheles az inditomotornal kb egy nagysagrenddel nagyobb, mintha az osszes lampat bekapcsolod, ergo sokkal nagyobbat esik az akkufesz. Szerintem a kerdesed nem oldhato meg hetkoznapi eszkozokkel.

pl. miutan az autod elsore elindult, orulsz, am ha hosszabban kell inditozni (kicsit csiposebb reggel), mar elegtelen lehet az akku. En nem eleznem ki ennyire az akkuhasznalatot, nagyon nem tesz jot neki.

A helyedben beepitenek egy kulon akkut, aztan otthon toltenem, ha kell.

Mint én is, és @bbalazs_ is leírtuk, az igazi baj, hogy nincs mihez viszonyítani. Még ha hipermodern akkud is van, ami tökéletesen egyezik egy mikrovoltig kimérhető karakterisztikával, és ki tudod számolni, mennyi töltés van az akkuban, még azzal sem mész semmire, mert nem tudod biztosan meghatározni, mennyi töltésre lesz szükség az autó elindításához, ami mechanikai műszaki állapotoknak is alá van rendelve.

Esetleg ha az én válaszomat olvasnád el, és nem az általad feltett kérdést akarnád válaszként értelmezni - ami valóban nem válaszolja meg önmagát - akkor egy kicsit előrébb lennél

Hp41C: 74HC574-ből miért kell 4?
Abból csak 3 kellene a 24Bit címzéshez, nem?
Amúgy egyre szimpatikusabb amit írsz és ez a 74HC574.

pajti2: Egy kis új begy pörkölés belefér, ha sok lába van
Van egy csomó PIC-em a fiókba és most ez a 8MBit-es a fiókból lett összeollózva, de ez a mostani 64MBit-es verzió, nem tudom fiókból össze pakolni.
Bele kell nyúlnom a zsebembe, de azért csak ésszel szeretném, mert mint mondottam profitot nem fog hajtani.. Inkább csak kőkemény hobbi és szórakozás gyanánt gondoltam és persze mert ezzel a 64MBit-es verzióval lefedném a teljes SEGA játék palettát, és a fejleszthető demó full méretét is.

Zsora: Igen, a reset lábbal tudom szabályozni, ha akarom, de felesleges.
Arra az időre még a játék fel lesz töltve kihúzzuk a konzolból.
És persze praktikusabb is kihúzva, mert a kazettát, csak könnyebb a PC-éhez vinni mint a PC-ét a SEGA géphez..
Kényelmesebb
Amúgy persze megoldható lenne, és ötletnek sem rossz, de úgy fest a megírt és tesztelt 8MBit-es változat jó és stabil működését és elveit nem vetném el.
És persze, nem kell mindig beírással kezdeni a mókát, ha flash memóriát használunk.
Érv és ellenérv mindegyiknél van, de talán most a flash előnyben van..

usane: Ne tegyük fel, mert ez biztos
Nem akarok CDC-hez drivert írni...
Gyakorlatilag a programnak semmi mást nem kell csinálnia, mint a megkapott byte-okat beírja a flash memóriába.
Ehhez ki kell adni mindent 1-es beírásnál a megfelelő szekvenciákat (sajnos ez minden ciklusnál ismételni kell) és ez után a címzést majd az adatot, persze a vezérlőlábak is.
Nem nagy feladat, de még is hosszú időt igényel.

Teljesen igazad van, a saját megoldásomat másoltam vissza tévedésből.
Ugyanakkor a javasolt megoldással

if (fv_1()) {......}

Írja ki az
error: too few arguments to function
hibaüzenetet. Szóval valami biztosan nem jó meg, nem tudom mi lehet.



És megnéztem szimulátorban valóban ha így használom
if (fv_1) {......}
az fv_1 címe kerül az If argumentumába.