Hát.... biztos van ennek megfelelő beállítás valahol, de egyelőre nem találom.

Üdv Mindenki!

Eddig csak szemlélője voltam az itt folytatott fórumozásnak. De sajnos szembesültem egy olyan problémával ami már annyira bosszant, hogy itt is rákérdeznék.

Nagyvonalakban:
Adott egy hall szenzor, ami billent egy 4013 d-ff-ot. A ff kimenete egy 16f887-re van kötve, ami impulzusonként változtatja egy szervó pozícióját.

Probléma:
Lehet valami bagatel szarvashibát vétettem de maga flipflop a hall szenzorral szépen működik billeg amerre és amikor kell...ha kimenetre ledet kötök akkor is korrekt...A microconroller jól vezérli a motort ha nem a ffra van kötve hanem például nyomógombbal adom neki a magas jelszinteket akkor tökéletesen megy...Ellenben ha már a 4013 kimenetéről vezérelném akkor lezúzza a kimenetet nulla volt környékére és meg se nyikkan. Alapból a számomra evidens módon kötöttem, egy ellenállás a Q kimenetre és irány a microcontroller bemenete...próbáltam ezek után pull up pull down ellenállatokkal...akkor is semmi...aztán egy tranzisztorral...nah azzal ment...de! egy bizonyos frekvencia felett már nem érzékelte az összes impulzust (nem olyan nagy frekiről lenne szó max 50Hz)...Valamiért gondolom nem volt ideje lemenni nullára és két magas között nem érzékelt alacsony jelet...vagy valami hasonló...

Egy szónak is száz a vége, nem akarnám túlbonyolítani a kérdést. Igazából tranzisztort se akartam berakni, de már lassan optocsatolóban gondolkodom.

Bárki ötletét szeretettel várom mert már marhára bosszant, hogy képtelen vagyok összekötni egy flipflopot egy microcontrollerrel. Remélem jó topicba írtam.

Válaszokat előre is köszönöm!

Szia!
Saját program ketyeg a PIC-ben?
Jó lenne egy kapcsolási rajz.

Saját program. Igazából egy nagyobb vezérlés egy részlete...mondhatni tesztje.

int i=0,time=310,q=0,sz=0;

void VDelay_us(unsigned time_us){
unsigned n_cyc;
n_cyc = Clock_MHz()>>2;
n_cyc *= time_us>>4;
while (n_cyc--) {
asm nop;
asm nop;
}
}
static void turn()
{
porta.f1=1;
vdelay_us(time);
porta.f1=0;
delay_ms(20);
}

void main()
{

ANSEL = 0;
ANSELH = 0;
C1ON_bit = 0;
C2ON_bit = 0;

trisa=0;
trisd=1;
trisc=0;
porta=0;
portd=0;
portc=0;

for(i=0;i<20;i++)
{
turn();
}
delay_ms(100);
do
{
turn();
if(portd.f2==1)
{
portc.f2=1;
time=time+3;
do
{
turn();
}
while(portd.f2==1);
portc.f2=0;
}
if(time>1024) time=1024;
}
while(1);
}

( a képen csak a ff "bekötését" csináltam meg gyorsba csak a miheztartás végett)

helyett:

Bár elvileg ez nem fogja megoldani a problémát, de egy próbát megér.
Szerk.: ha a PORTD0 láb valami más bemenet, akkor:

Röhögni fogsz...megoldotta a problémát

Úgyhogy már csak okulnom kéne, hogy most mivan?

Mert ugye eddig az egész d port bemenetnek volt beállítva...
így meg csak az a láb...szóval az a láb eddig is bemenet volt nem? még nem vagyok nagyon járatos a picben úgyhogy ez azért némi magyarázatra szorul

trisd=1 --> 00000001 binárisan, azaz csak a PORTD 0. bitje volt bemenet, a kimenetet próbáltad meghajtani és az "erősebb kutya élt nemi életet" !
trisd=4 --> 00000100 így már a PORTD 2.bitje lett a bemenet!

Erre csak elegánsan annyit, hogy ÁÁÁÁÁÁ!

A manóba nem tudom miért emlékeztem arra, hogy ha simán csak 1 akkor az egész port bemenet lesz...

Nagyon köszönöm a segítséget...és most megyek ritmikusan verni a fejem a falba

De jó! Köszi.

Az X nem tudja felülírni a configurációs biteket, emiatt kötelező a kódban megadni. Legalábbis az 1.92 és elődeiben nem volt ilyen lehetőség, nem hiszem, hogy belekerült volna a későbbiekben. De ha nem hiszel neki, akkor állíts be mindent ott ahol nézed, gondolom a "PIC memory view - Comfiguration Bits" menüt nézed és generáltasd le "Generate Source Code to Output"majd illeszd be a meglevő helyére a kódban. Ha így sem megy (szerintem nem fog, de ne legyen igazam) akkor más baj lesz ott. PIC-et lecserélted, nem lehet hogy valami megy az RB7-en amit ki kéne kapcsolni? Nem néztem az adatlapot, csak a lábkiosztást.

Így csináltam, így kezdődik, a "pic32_conf_bits.h" file-ban vannak a legenerált config bitek:Csak a fordítás után az általad említett ablakban alaphelyzetben vannak a config bitek.
Kipróbáltam MPIDE fejlesztő környezettel, akkor működik a LED az RB7-hez tartozó lábon is. (Csak váltani kéne, mert az MPIDE-nek más hiányosságai vannal.)

Kipróbáltam PIC18-al PICkit3-al mplab x 1.95-el működik. Sőt, ha meglevő projectet töltök vissza akkor is átállítja fordítás után alaphelyzetből az aktuálisra.Mondjuk ez pont asm, de keresek egy c pogit is. Az X-et még ki tudom zárni ha letöltöm az ujat, de se klónom se pic32-m nincs kéznél. Próbáld ki egy másik PIC-el ha van otthon. Még a kód protect jutott eszembe, de látom azt is kikapcsoltad, úgyhogy innentől más ötletem egyenlőre nincs.
Fordításkor nem dob hibát?

Nem dob hibát fordításkor, a 3-ból 2 LED működik is, csak az RB7-re kötött nem. Azt a lábat valami fogja. Mint már említettem, MPIDE alatt az is megy, ezért valami beállítási hibára gyanakszom.
(A web-en talált minta az RB7-et használja, egy napig piszmogtam a progival, mire végre az az ötletem támadt, használjak másik lábat.)

Ok. Megnézve az adott oldalt, még egy dolog eszembe jutott. Az x alatt a debug gombot használod, vagy fordítás után egyből beégeted és nem megy?

Sziasztok! Tippeket kérnék spi kezeléshez.

Van kettő pic-em külön tápfeszültségeken, amik egymástól függetlenül meg tudnak szűnni - és idővel újra rendbejönni. A két pic között spi buszon kommunikációt akarok létrehozni.

A problémám. Ha a slave pic olyan szerencsétlen pillanatban kel életre (tápfeszültség relatív probléma), amikor a master információt küld el neki, és már csak az utolsó fél byte-ot "látja" az üzenetből (de akár egyetlen bitnyi szinkron elcsúszás is már régen rossz), mi fog akkor történni az egymás után következő byte-ok integritásával? Mondjuk még nSS vonalat is fel tudok használni az spi-hez, és a küldő a vonalat inaktívba húzza az üzenet végén, de valahogy nem találtam olyan infot arról sem, hogy az inaktívba húzott SS kiresetelné a fogadó oldalon a byte töredéket, és alapállapotba állítaná az spi vételi bit számlálóját. Szóval most theorycraftolok. A byte veszteség nem probléma, de ha átcsusszannak a bitek a byte-ok között, az viszont igen. Valami okosság kellene azt tuti biztosra kivédeni.

Szia, Ha TP a kimenete akkor nem kell pull-up, de ha OC-s, akor igen. Mindenesetre érdekes jelenség, mert ha egy LED-et meg tudhajtani, akkor a PIC-et is. Mindenesetre, ezt nézd át. Érdekes lenne egy szkóppal megnézni, hogy mi is lástszik valójában. Körbenézek, ha találok itthon ilyen hipp-hopp -ot akor összedobom kiváncsiságból a kapcsolásod. Üdv: Mike

Bocsi, elnéztem a lapszámokat, már nem aktuális, de már törölni sem tudom.

Ugye, release módban fordítod a programot, s nem debuggernek, hanem programozónak választottad ki a PICkitet?

A slave egy vonalon jelezze a masternek, hogy mikor kész az adatfogadásra. Addig ne tűnjön el, amíg a fogadókészség jelzést meg nem szüntette, s amíg egy adatküldésnyi időt utána ki nem várt.

Mellesleg szólva logikusabb lenne I2C kommunikációt használni. Ott automatikusan adott a visszajelzés (ACK), csak figyelni kell rá.

Próbáltam mindkét módot, így sem, úgy sem megy.

A master, és slave az adatátvitelkor fix kódot küldjön első bájtként. Ha nem ez megy át, akkor nincsenek szinkronban.
Miért éppen SPI? Az SPI akkor jó, ha közös a táp. Ha külön táp van akkor aszinkron adatátvitel kell, az SPI-nél és I2C-nél beragadhat a slave a vételbe. I2C esetén a master észreveszi, SPI esetén csak értelmezett válasz esetén lehet biztos a dolgában.

icsernyi, nedudgi:

Időnként át kellene hajítanom azon a csatornán 100 kbyte-nyi hasznos adatot oda-vissza egészben (összesen 200 kbyte hasznos adat megmozgatása), és az spi nem csak nagyon sokkal gyorsabb az i2c-nél, de ráadásul full duplex.

A salve-re rárakom azt az adatkészség visszajelzést, de hogy ne tűnjön el menet közben a master, azt nem fogom tudni szabályozni, és továbbra is kérdés, hogy a slave hogyan tudja észrevenni, hogy resetelnie kell.

Utolsóként még azt tudom megtenni, hogy megszakítás vezérelten timerrel folyamatosan hajigálni fogok keep alive byte-okat, és ha valami félre sikerül, a master resetbe rántja a slave-et, bár az se kicsit brutális játék csak a kommunikációs szinkron miatt, ugyanis akkor az egyik blokkom fullra elveszett a szinkron megőrzés nevében.

A slave oldal sehogyan sem tudja észrevenni, hogy egy spi kommunikáció beragadt? Direkt kitalálnak egy nSS vonalat is, és éppen arra nem használják, amire jó lenne?

Nagyon megerőszakoltnak tűnik ez a koncepció, ettől függetlenül bizonyára található megoldás a problémára.

A slave-nek szerintem elég annyi, ha kitalálsz valami protokolt (mondjuk az utolsó bájt egy kontrollösszeg). Az egy tranzakcióban vett bájtok számát és a kontrolösszeget szoftveresen ellenőrizni tudod, amikor vége az adásnak. Ha nem stimmel, eldobod, vagy hibaüzenetet küldesz válaszul.

Ha megszakításos adatátvitelt használsz, akkor meg lehet saccolni, mikorra kellene végezni az adatátvitellel. A probléma ott van (szerintem), hogy a szinkront miként fogja létrehozni a két kontroller. Ahhoz a puffert át kell mazsolázniuk, legalábbis a kezdő és végkaraktert, vagy ellenőrzőösszeget ellenőrizni, hogy az átvitelre szánt idő alatt átment-e a kívánt adatmennyiség. Szerintem probléma mindössze a szinkronizálás, ha a két páciens közül az egyik kiszáll a meccsből.
De menjünk vissza a kályhához. Árulj el többet arról a felhasználásról, ahol két mikrokontroller 100kB nagyságrendű adattal pingpongozik. Milyen időközönként kell végrehajtani az ütésváltást?

Oké, még mindig van egy utolsó félelmem. Ha valaha menet közben elveszíteném a bit szinkront, azt nem csak észrevenni kell tudni, de ki is javítani.

Pic 32-eseknél amit találtam, SPIxCON: SPI Control Register, bit 15 ON: SPI Peripheral On bit (1 = SPI Peripheral is enabled, 0 = SPI Peripheral is disabled). Pic 8 bitesen (jelenleg 18f2550) amit találtam, SSPCON1: MSSP CONTROL REGISTER 1 (SPI MODE), bit 5 SSPEN: Master Synchronous Serial Port Enable bit (1 = Enables serial port and configures SCK, SDO, SDI and SS as serial port pins, 0 = Disables serial port and configures these pins as I/O port pins).

Ha azzal a bittel menet közben lekapcsolom az SPI-t, részemről gyanítom (vagy inkább csak remélem), hogy a vételi bit számlálót is lereseteli, de explicite írva sehol sem találtam meg. Teljesen egyértelmű, és azért nem írták, vagy eszébe sem jutott még soha senkinek, hogy ekkora kulimászba is bele lehet tenyerelni?

A dolog egyszerűbb, mint gondolnád. Az SPI adás/vétel a slave oldalon nem jelent beavatkozást a folyamatba, ha sikerült venni az adatot, akkor jó, ha nem, nem. A protokoll slave és master oldalon is feltételezi, hogy a folyamat résztvevői üzemképesek. A master szerepe mindössze annyi, hogy ő szolgáltatja az órajelet. Ha az általa vett adat(blokk) hibás, akkor a slave elvesztette a fonalat. A slave azzal tud operálni, hogy megjött-e a megfelelő számú órajel (adatbit). Ha az adatbitek száma stimmel, akkor jöhet további ellenőrzés, ha nem, akkor a protokoll szerinti átviteli idő után újra meg kell kísérelni a vételt. Ugyanezt kell tennie a masternak is. Ha mindketten kivárják ezt az időt, akkor a második nekifutásra értelmes adatcsere történik.

Nem értem, amit írtál.

SPI-ben elektronikai szinten hol lenne olyan kivárási idő, hogy a slave észrevehesse, hogy nem jött meg az adat? Nem az SPIxBUF-tól fölfelé, hanem attól lefelé. Egy buta állapotgép, ami csak számlálja az órajeleket, amiket az SS kapuzgat, és akkor van meg a byte, amikor a 8-at leszámolta. Ha eltelt az 5. és 6. bit között egy óra, akkor eltelt egy óra, és addig ott várakozik a töredék byte. Én legalábbis semmi infót nem találtam arról, hogy létezne bármiféle auto reset az spi modulban kivárási időre, hogy ha nem jött meg az adat, eldobná azt, ami addig megérkezett. SPIxBUF-tól fölfelé annyit lehet majd látni, hogy a master el sem kezdett küldeni semmit sem. Nem lehet belelátni az állapotgép saját folyamataiba. Arra találtam interruptot, hogy megérkezett egy új adatbyte, de arra nem találtam, hogy elkezdett venni egy új byte-ot, és megérkezett az első bitje.

Protokol szinten már megoldom, de az mind SPIxBUF-tól fölfelé van. Kell valami kezelés attól lefelé is.

Te írod a kontroller programját. Ismered a hardvert, tehát tudod, hogy a master milyen órajellel küldi az adatokat. Az adatmennyiséget, legalábbis maximális mennyiségét ismered, tehát meghatározható, mennyi idő alatt kell beérkezni az adatcsomagnak. Ez az idő az első adatbájt beérkezéskor indul.
Feltételezem, megszakítással kezeled az adatátvitelt. A fő programág tudja figyelni, hogy jött-e adat, és az adatcsomag átvitelére szánt idő letelt-e? Ha az idő letelt, és nem érkezett meg (nem került elküldésre) a teljes csomag, a slave tudja, hogy elvesztette a fonalat. A master, mivel ő vezérli az átvitelt, tehát részéről az adátvitel megtörtént, a vett adat érvényességét tudja ellenőrizni.
Az állapotgép csak a folyamat megértésében segít, menetközben nincs értelme, azt a hardver eltakarja előled.

Üdvözlet!
Egy 320x240-es kijelzővel birkózom. Nagyon elakadtam. Képet szeretnék kirajzolni sd kártyáról. A képet szépen lekonvertáltam 565 -ös formátumba. A pic-kel kirajzolva a kártyáról nem stimmelt a kép. Ezután az egyszerűség kedvéért csináltam egy kissebb képet, ami egy kocka, 17x17 pixeles méretben (képet csatoltam, 565 ös bmp + az ő hex -e). Hex editorral megnézve, az a fura (nekem), hogy két fehér pixel között nem 17, hanem csak 16 fekete(pixelre vonatkozó adat) van, olyan mintha tömörítve lenne .Csináltam egy teli fekete 17x17-es kockát is, ott is kevesebb a HEX -ben a pixelszám a valóshoz képest,tehát a helyzet ugyanaz. Természetesen a kijelzőn pontosan az jelenik meg , amit a hex-ben láttok, tehát egy nagyjából 16x16 -os kocka. Ha ugyanezeket a képeket lekonvertálom a "bitmaptoarray" nevű programmal, az így kapott hex fájl tökéletes, ha ezt beírom C tömbbe a picbe, a kép JÓ. Mit rontok el, miért látok mást hex editorral??

Az a hexaeditor ne nullával kezdi a számolást?