Help gomb nyomkodasa ad nemi magyarazatot erre:



Azaz a sarga nem lett meg letesztelve altaluk, elmeletileg mukodik...

Biztosan nem volt kéznél a megfelelő típusú PIC!

Helló watt és trudnai.
Köszönöm a válaszokat, én is sejtettem, hogy részben támogatott, de mi az hogy részben?
"elméletileg működik"
Elméletileg én vagyok a szőke herceg, de gyakorlatilag.....

Azért köszönöm a váloszaitokat

Azt jelenti, hogy nem volt még az előző verzióban, most került bele és még nincs részletesen kitesztelve, lehetnek benne hibák. Tehát ha használod, akkor nem biztos, hogy tökéletesen működik. Ha valami ilyen hibát találsz, akkor azt lehet jelenteni Microchipéknek, és akkor javítják.

Hello potyo.

Köszönöm a kiegészítést.

Ez a dinamikus memóriafoglalás azért elég merész dolog kontrollereken. Ehhez kell memóriakezelő, ami egy pc-n van, de egy kontrolleren nincs (legalábbis meg lehet lenni nélküle).

Ha össze akarod hasonlítani az "alma" kifejezést, akkor tedd azt is bele egy változóba, ami a programmemóriában van (rom const unsigned char alma[]="alma").

Összehasonlítás pedig:

unsigned char *p=kartomb, flag=1;
rom unsigned char *q=alma;
do
{
if ((*p)^(*q))
{
flag=0;
break;
}
while ((*p++)&(*q++));
Ha a ciklus után flag értéke 1, akkor a két tömb azonos. Ha flag értéke nulla, akkor eltérnek.

Köszönöm szépen a segítséget potyo!

Én mikrobasicben írtam.
Az Oshonsoft csak tesztre van. Hex file beolvas, és úgy.
Tegnap megcsináltam, amit szilva írt. Jó lett. Köszönöm!
Persze az interruptokat csak lassítva(normal mode) láttam. Ultimate sebességen nem láttam.
40Mhz-en megy majd úgyis.

Ami meg ott van kód, az a mikrobasic helpjéből van nagyrészt.

Így már érthető! Csak fura volt, hogy Oshonsoft-ot használsz és a BASIC kód meg teljesen eltérő volt ahhoz képest....

Előbb jött a mikrobasic, és utána az Oshonos Debugger. De tetszik.
Még 1 baj volt.
A lábak a Debuggerben ugráltak. De "rákötöttem" 8 Ledet a portb-re, meg a jelgenerátorokat, és most szépen látni mindent.
PORTB.6-ot rá lehet állítani, hogy fel, meg le ágra is működjön? Gondolom a fel után kellene állítani INTCON2-t. De inkább ráteszem a PORTB.7-re, és ott nézem.

Szia, ha nem túl nagy titok és már ennyit beszéltél róla, megtudhatnánk többet erről a szűrőről?
Mihez is készült, használsz külön külső AD/DA-t...
Elég, ha a konkurensek termékeit megemlíted, utána olvasok. Köszi.

Nem titok, nem hasznalok AD-t, digitalis jelekrol van szo, nevezetesen a radio tavvezerlesu modellekkel kapcsolatos a dolog. Ezeknel az un analog radios rendszerekben - ami kisse furcsan hangzik, hogy megis digitais jelekrol beszelek kozben - szoval ezeknel nagyon egyszeru es olcso modon oldottak meg a tavvezerlo funkciojat. Gyakorlatilag egy nagyon lassu PWM jelet kell elkepzelni aminek a periodus ideje lenyegeben majdnem mindegy, azonban a duty cycle (munka fazis?) ami a lenyeg, annak a szelessege hatarozza meg a szero motorok poziciojat.

A gond abbol adodik, hogy a radioban semmilyen logika nincs, az butan veszi az eterbol amit hall, es kiadja a szervo fele barmi is legyen az. Rengetegszer van olyan, hogy egy repulogep radio zavarok miatt zuhan le - par evvel ezelott volt is egy ket emebereletet kovetelo halalos baleset Magyarorszagon, az is ebbol adodott. Szoval a kutyu beepul a radio es a szervo koze es kiszuri a hibas jeleket, kijavitja ha azokat rossznak veli es ha teljesen hasznalhatatlan akkor biztonsagos pozicioba helyezi a motort illetve vezerlo feluleteket.

Autokhoz is es barmi mashoz is lehet hasznalni amugy, ami erre a rendszerre epul. Autoknal egyszeru a helyzet, ott ha valami nem stimmel akkor be lehet fekezni a jarmuvet, nagy problema abbol nem szarmazhat. Repuloknek viszont adott esetben a motor leallitasa egyenlo a biztos zuhanassal... es hat ennek a kutyunek meg pont az lenne a lenyege, hogy ezt elkeruljuk ugye. Eppen ezert ez a leallitosdi a legeslegutolso megoldas kell legyen, a koztes idoben pedig szurni kell es ezaltal ki kell kulszobolni minden zavaro tenyezot ami a repulogep mozgasat karosan befolyasolna. A dolgot persze neheziti, hogy ekozben gyakorlatilag kesleltetesrol szo sem lehet - nyilvan lesz valamekkora, de annak olyan minimalisnak kell lennie ami meg a versenyzoket sem riasztja el a hasznalattol (hisz akkor nincs vedelem, ujra barmikor bekovetkezhet egy baleset).

Amugy a konkurens termekek szinte kivetel nelkul autokra lettek tervezve, es csak azzal torodnek, hogy azt megallitsak ha baj van. Volt amelyik AVR-es, volt ami PIC-es (mid-range-es, valami 12F most nem emlekszem pontosan, de 8 labu volt). Volt egy azt nem sikerult szetszednem meg mert kiontottek mugyantaval - de a lenyeg mind egy csatis, mind nagyobb kontrollert hasznal es ahogy mar emlitettem egyik sem szur olyan jol mint ez, szoval egyenlore elegedett vagyok ezzel

Üdv!
Amit te leírtál az a PPM rendszer. Pulse Position Modulation. Repülősönkél már azóta a PCM rendszer a megszokott. Ez egy bonyolult digitálisan kódolt rendszer.
Tehát szerintem ne a PPM jel analizálásából indulj ki ha failsafet akarsz építeni repülőre.

Igen a PPM az az ahogy az egyes PWM jeleket elkodoljak csatornankent - ezt a radio altalaban egy shift regiszter segitsegevel aztan vissza is kodolja ismet PWM-e. A PCM pedig az amit digitalis radiokent szoktak meg emlegetni, az is csak egy kodolas, ha analog szervok vannak azt ugyanugy dekodoljak PWM-nek.

Ahhoz, hogy a PPM vagy PCM jelekhez hozzaferjek radiot kellene bontani, azt sajnos nem akarom - ill mivel ez egy termek ezert nem is varhatom el senkitol, hogy megtegye. Es akkor ugye ki kellene iktatni a radioban levo shift regisztert vagy PCM dekodolo MCU-t es azzal butykoreszni, hat az nem eri meg - mondjuk PCM mar viszonylag vedett, ott legalabb CRC-vel vedik a jelsorozatokat, de amugy nem bonyolult, csak minden gyartonak eltero a kodolasa, es sokszor meg gyarton belul termekek kozott is vannak valtozasok. Legtobbjeben amugy fail safe azokban sincs, csak legfeljebb joval kevesebb az eselye hogy hibas jelet adjon a szervora. Ha pedig digitalis a szervod akkor azoknak lehet beallitani biztonsagi allast, de azoknak mar nem a megszokott PWM jelet kell kuldeni.

De amugy a termek mar par honapja keszen van, csak egy modositast kellett utolag csinalni a firmware-ben mert ujabb Futaba radiok mar nem shift regisztereket hasznalnak, hanem mikrokat es ez bezavart - na ennek a modositasan vagyok tul aminek annyira orultem

Már régóta foglalkozok PIC-ekkel, de ez a probléma most kifogott rajtam.

A program véleményem szerint hibásan fut ale a PIC-en. PIC12F629-el próbálkozom, de hasonló hiba van a 16F676-on is.

Szóval a jelenség a következő:
ha ezt a programot lefuttatom, az az eredmény, hogy a GPIO4-es láb magas szintre kerül.

Tapasztalatok:
-a legfurcsább az, hogy ha nem megyek vissza Bank 0-ba, akkor jóval bonyolutabb programok is helyesen működnek. De miért? :S
-ha egyszerre módosítom a három bitet, akkor helyes eredményt kapok
-általában, de nem mindíg, ha lenulllázok egy bitet, akkor az előtte állítottat 1-re állítja (nem néztem, hogy a bit értéke is egy-e vagy csak lábat emeli fel, de hamarosan megnézem.)

Valaki el tudná mondani, hogy miért van ez? (Felteszem, hogy a PIC-ek jók, Potyo féle USB-s ICD2-t használok, mint égető)

Egyszeru a magyarazat, ezt hivjak RMW-nek, azaz Read-Modify-Write -hibanak. A jelenseg a kovetkezo:

Elso bcf torli a GPIO,2 bitet, csakhogy utasitas vegen meg nem arantalt, hogy az allapot be is kovetkezik. Majd jon a kovetkezo bcf...

BCF lepesei:
1. Read - azaz kiolvassa a teljes GPIO-t
2. Modify - azaz modositja azt a bitet
3. Write - azaz vissza irja az egesz GPIO-t

Mi is tortenik? Elso BCF meg be sem allitotta 0-ba a bitet, maris kiolvassuk a GPIO-t, igy meg az az elotti magas allapot olvasodik ki... aztan azt szepen vissza is irjuk a GPIO-ba...

Hat ilyen egyszeru... 18F-ekben mar van un, Latch regiszter (pl. LATB) es ha azokat billegteti az emer akkor ilyen meglepetes nincs.

Vedekeses?
1. Idozites az utasitasok koze (pl. nop vagy goto $+1)
2. un arnyek regiszterek hasznalata, azaz letrehozok egy "GPIO_arnyek" nevut, aztan:

bcf GPIO_arnyek,2
bcf GPIO_arnyek,4
movf GPIO_arnyek,w
movwf GPIO

Remelem segitett
Tamas

Köszönöm, erre nem mostanában jöttem volna rá.

Már csak az a kérdés maradt bennem, hogy ha 1-es Bank-ban maradok, akkor miért működik helyesen a program?

Mondjuk a Bank-okat sem értem teljes egészében, ha valaki el tudná magyarázni, hogy miben korlátoz engem, hogy melyik Bank-ban vagyok, vagy egy linket tudna adni, ahol részletesen le van írva, akkor boldogságom beteljesülne.

Sajnos hiába tűzdelem tele nop-okkal a programot, akkor sem akar jó lenni. Gondolom 60 nop-nak elégnek kéne lennie :S
Persze megfelel az árnyék regiszter használata, de zavar, hogy simán nem jó. Na meg hogy ha 1-es Bank-ban vagyok, akkor jó. :S

A bankok létezésének oka a következő: egy programszóban hét bit található a memóriaterület címzésére, tehát összesen 2^7=128 bájt memóriát lehet címezni egy utasításban. Ha több memóriát akarunk a kontrollerbe, akkor valahonnan még venni kell címzőbiteket. A címző bitek pedig a STATUS, RP0 és STATUS, RP1 bitek, amik megnégyszerezik ilymódon a használható memóriaterületet annak árán, hogy állítgatni kell a bankválasztó biteket.

Abban korlátoz, hogyha pl. a piros zoknikat a felső fiókban tárolod, akkor az alsó fiókban hiába keresed, nem fogod elérni ott a piros zoknikat. Tehát négy egymástól független memóriaterületet használatát teszik lehetővé a bankválasztó bitek. Namost vannak olyan területek, amik mégis elérhetők több bankból, ez már a chip gyakorlati megvalósításától függ. Adatlapban megtalálható, hogy mit honnan lehet elérni, mint ahogy az is benne van, hogy miért vannak a bankok.

Csak azon csodálkozom, hogyha régóta foglalkozol picekkel, akkor ezeket hogy nem tudod?

Azért, mert nem érted, hogy mi a probléma. A probléma forrása az, hogy amikor te módosítasz egy bitet a porton, akkor az a folyamat játszódik le, hogy a processzor beolvassa a lábak állapotát (azt, ami fizikailag van a lábakon, ami nem okvetlenül jelenti azt, amit te ráírtál) a saját regiszterébe, módosítja az adott bitet, majd visszaírja az egész portot. Namost egy kicsit erős, de szemléletes példával élve: ha a hármas lábra te kiírsz 1-et, de a hármas láb rövidre van zárva a gnd felé, akkor azon a lábon fizikailag sosem jelenik meg az egyes. Amikor a kettes lábat akarod változtatni, akkor beolvasva az egész portot, azt olvasod be a hármas lábról, hogy ott nulla van, majd az utasítás végrehajtásának végén nullát is írsz a hármas lábra vissza.

A NOP használata csak bizonyos esetekben jelent megoldást, akkor ha a lábon nagy a kapacitív terhelés, és egy oszcillátorciklus alatt nem tudja a kimeneti mosfet a kapacitív terhelést feltölteni. Viszont ha más miatt nem tud a láb felmenni, akkor az árnyékregiszter a korrekt megoldás.

Na persze az is érdekes, hogy 60drb NOP sem elég, valami nem stimmel ott az áramkörrel sem...

Bocsanat ez a bankolasosdi teljesen elkerulte a figyelmem - ez egy masik problema lesz akkor, de amit elozoleg irtam azt se hagyd figyelmen kivul.

Szoval a PIC nem kepes az egesz memoriat megcimezni, kisse talan furmanyosan van megoldva, maskepp is lehetett volna stb, de igy van. 629-nak ha megnezed az adatlapjat ket bankja van. Az elsot kivalasztva (bank 0) 0-7F, a masodikat (bank 1) kivalasztva pedig 80-FF -ig lehet cimezni. Ha megnezed a memoria terkepet, latszik, hogy a bank 0-n van a GPIO, mig a bank 1-en a TRSIO.

Namost az inicializalaskor helyesen 0-s banknal kinullazod a GPIO-t es utana 1-es bankba kapcsolva a TRISIO-val atkapcsolod outputra, ez eddig jo. Ha most ezekutan bank1-ben maradva a movlw 0xFF + movwf GPIO-t vegrehajtod, akkor valojaban a TRISIO-ba teszel FF-et, azaz vissza kapcsolod a portokat inputra. Ha be van kapcsolva a belso felhuzo ellenallas, akkor kb 20k-nak megfelelo ellenallassal a Vdd-t tudod merni a portlabakon - azaz magasnak "latod" a portot. Kitorlod a TRISIO egyik bitjet, erre az ugye atkapcsol outputra, es mivel az ki volt nullazva ezert az 0-s szintet fog neked mukodni - azaz latszolag jol mukodik a port, mintha vegig out lenne...

Szoval ha jol ertem, akkor a kodod most valahogy igy nez ki:
(inicializalas maradt a regi)

?

Teljesen jogos... Kerdes persze meg az is, hogy mindegyik GPIO firkalas utan vannak-e ezek a NOP-ok? De ettol fuggetlenul egy kapcs.rajz-ot nem artana mellekelni hogy tobbet lehessen mondani.

Vagy összekevered a Bank0-t az 1-essel, vagy a TRISIO regiszterrel váltogatod a portlábak irányát(ugyanazon a címen vannak, csak más bankban)! Mikor bemenet nem folyik rajta áram, mikor kimenet akkor folyhat(áramkörtől függően).

Hogy állítod be a bankokat?
Mit kapcsolnak a lábak?
Hogy állítod be a TRISIO-t?

Közben jelezték, hogy ott a forrás. Hát én abban nem sok hibát látok, főleg egyszerűségénél fogva! Elég érdekes a jelenség, hirtelen nincs ötletem...
Ha a bcf-ek helyett kiviszel 0-t egyszerre a portra(movwf-el), akkor kikapcsol?

Még egy kérdés: "_MCLRE_ON" van a konfigban. Van felhúzó ellenállás a lábon?

Sziasztok!

Bocs, ha már volt, de még csak az 1800. hsz-nél tartok a fórum olvasásában viszont nagyon érdekelne a kérdés:

Szóval, itt a HE-n levő Topi áltál készített cikk alapján megépítettem az első típusú JDM égetőt ill a tesztáramkört. A különbség, hogy mivel nem találtam itthon pnp tranzisztort, a külső tápot nem dugtam rá a cuccra. Megmértem, a 3-as lábamon 11,4 volt körüli érték van.

A furcsaságok, amiket nem értek:
- Alapból a COM port 3-as lába áll -11 V-on, ill ICProgban bekapcsolom a Hardware Checknél az MCLR-t, akkor +11V. Viszont ha rádugom az égetőt, akkor 6,6 V kkörnyékére leesik azonnal a fesz. Próbáltam megtalálni mi okozza ezt, kivettem a Topi rajzán látható R3 ellenállást, hogy ne zavarhasson az a kör, de ugyanígy maradt. A kapcsolást többször átnéztem, nem látok zárlatot. Mi okozhatja ezt?
- A következő furcsaság, hogy ennek ellenére a 16F877 PIC-be szépen beégette a .hex-et, működik is a LED-es futófény. (Írás közben MCLR lábon 6,2V van) Ez normális?
- 3. érdekes dolog: Amikor áramkörön belül égettem, akkor csak úgy hajlandó égetni, hogyha nem azt a tápot használom az égetés idejére, amivel az áramkört hajtom, hanem azt lehúzom és az égetőből jövő 5V-ot használom. Itt talán valami olyasmi lehet, hogy elindul a proci, mire égetne, de ezt sem értem miért.

Egyébként már tudom, hogy jobb lenne egy Oshon féle égető, meg művelődtem a fórum olvasása közben, de ezeket a kérdéseket nem bírom megválaszolni két napja és nem akarok továbblépni amíg nem értem meg ezeket.

Kösz mindenkinek!

Nah haladjunk visszafele.


Igen, mivel az ICD2 ezzel indítja el a programot.


Igen, ebben az esetben kikapcsol.


Igen.

Trudnai!
Hasonlóképpen néz ki a program. Csak van (volt) 60 db semmittevő utasításom mindnehol.
És igen, minden bizonynal a TRISIO regisztert írogatam, ami egész jó megoldásnak tűnik.

Ha TRISIO-t állítgatom:
ha inputra állítom azért jó, mert ottvna a felhúzóellenállás,
ha outputra, akkor meg azért, mert alapértelmezésben földre van húzva a port.


Egyszerű: nem volt rá szükség. Tudtam, hogyha X regisztert akarom múdosítani, akkor melyik Bank-ban kell hogy legyek.

Idézet:
„ha a hármas lábra te kiírsz 1-et, de a hármas láb rövidre van zárva a gnd felé, akkor azon a lábon fizikailag sosem jelenik meg az egyes.”

Nah igen, ez a probléma forrása, ugyanis ha nem jelenik meg fizikailag az egyes, akkor RMW hibásan fogja állítani a portot.
Az "áramköröm" annyi, hogy a PIC-re direktben rá van kötve egy (közös anódú) RGB led. A PIC meg az ICD2 programozóra, ami táplálja árammel, elindítja a programot.
Szóval kénytelen leszek majd tranzisztort használni.

Ez van, köszönöm a segítséget!

Nálad ez mit jelent(direktben?)? Ellenállást azért tettél elé nem?

Nálam a direktben rákötött LED azt jelenti, hogy ellenállás sincsen.
Hát istenem, kell a fényerő.

Amúgy nagyon tanulságos: ha úgy indítom el a programot, hogy nincsen a PIC-re rákötve a LED, és csak a végén rakom rá, akkor helyes a program végeredménye!!!