Fórum témák
» Több friss téma |
Sziasztok, olyanra lennek kíváncsi, hogy egy adott impulzusra (mely kb 2mp és 12v) lehet-e csinalni, hogy masik kimeneten megjelenik ugyan az az impulzus es 10mp utan egy kovetkező lábon egy másik szintén 12v os jel, viszont az nem megy csak 3mp et (vagy amíg egy negyedik labra nem érkezik egy jel ami viszont folyamatos es valtozó) , viszont az első folyamat tart a kovetkező 12v os impulzusig.
Itt egész pontosan autó távindításról lenne szó, hogy a 4. jel ami a fordulatszammérőtől érkezik és az letiltja utána az önindítót. 1 jel a gyújtás es a 10mp amíg a mptor készen áll az indításra, ott akár a check engie lámpa elalvására is lehetne kötni. Ha valaki segítene véghezvinni a projektet azt megköszönném. 
A sima C forrást első körben object-re (.o) fordítja a compiler, és abból a linker gyárt egy futtatható firmware-t (.bin). Kérés esetén lista file gyanánt (.lst) a linker dob assembly dumpot is. A firmware külön programmal átkódolható hex-re (.hex), ami a pickit bemeneti állománya, azt tudod feltölteni a pic-re. Mplab akár egy lépésben csinálja az egészet, ott lehet, hogy pár dolog el van rejtve a szemed elől, de a folyamat ugyan az.
A feladat könnyedén megoldható, itt inkább az autó biztonságos indítása a kérdéses: sebességbe van, kézifék, esetlegesen túl hideg motor, mi történjen, ha elsőre nem indul el, meddig köszörüljön egy próbálkozás alatt és még egy csomó dolog, ami nem jut eszembe.
A hozzászólás módosítva: Jan 15, 2017
Köszönöm a válaszokat!
Idáig csak Arduino-t programoztam, a C alapok mennek, de még PIC-re nem fordítottam programot. Ma összekötöttem az LCD-t a programozóval és felprogramoztam rá a gyári HEX fájlt, az LCD müködik. Csak annyival szerettem volna kiegészíteni, hogy ha a 12-es láb fel van huzva 5V-ra, akkor az eepromot töltse meg FF-el és írja ki, hogy RESETED. Ez a videó alapján megprobálom feltelepíteni majd lefordítani a forráskódot. Ha valamiben elakadod, akkor még írok.
Az object file-okat meg lehet nézni valamivel ( pl. milyen függvények, milyen paraméterekkel vannak benne, vagy ez már itt nem kinyerhető ?! ) ?!
Egy HxD, vagy hasonló bináris fájlnézegetővel valószínűleg megtalálhatók a külső hivatkozások, publikus definícók, szöveges formában. Meg kell próbálni.
A második videó alapján mindent ugy csináltam, ahogyan ott mutatta, de amikor rákattintok a Build-ra egy csomó hibát ír ki.
A hozzászólás módosítva: Jan 15, 2017
Ilyen hosszú szöveget nem illik egy fórumba írni. Mellékletként, vagy a kód gombbal légy szíves!
Elnézést kérek, de egy csomó szöveggel együtt lemaradt a [/code] parancs. A moderátort megkérem, hogy törölje ki a hozzászolásból.
Hp41C: Kiprobálom a CC5X-et. A hozzászólás módosítva: Jan 15, 2017
Feltelepítttem ez a leírás szerint, de fordításkor ezt a hibaüzenet kaptam:
Sziasztok!
Néhány információra lenne szükségem.Azt szeretném,hogy amikor megszakítás jön,akkor belép a rutinba,majd ott kikapcsolja a megszakítást,és kiírja a kijelzőre a 0x45-öt,de csak 0xFD jön másodpercenként a második adattól,mert az első jött adat a 0xFF.Ha a GIE megszakítást nullázom a rutinban,akkor meg semmilyen adat nem jön,pedig előtte az is be volt kapcsolva.
Máskor figyelj jobban oda, mit csinálsz!
A hozzászólás módosítva: Jan 15, 2017
Szuper!És ha csak a 13. vett adatot akarom kiíratni,mert a GPS elég sok adatot küld?
1. A GPS által küldött NMEA0183 sorok elején $ karakter van. Kell egy számláló, amit a $ érkezésekor 12 -ra állítunk. Minden karakter vételekor csökkentjük a számláló értékét, ha 0 lett, a vett karattert elküldjük. Ha megint $ jön, kezdjük előlről.
2. Veszünk két buffert. Minden sikeresen vett karaktert beírunk ebbe a vételi bufferbe és jelezzük a főprogramnak, hogy új karakter jött. Az adási megszakítás megvizsgálja az adási buffert. Ha van benne elköldendő adat, elküldjük, csökkentjük a tárolt karakteret számát. Ha nincs köldendő, letiltjuk az adási megszakítást. A főprogram kiszedi a vételi bufferből a karaktereket, kibogarássza a számára értékes adatokat a vett NMEA táviatból, feldolgozza, az elküldendő adatokat az adási buffer-be írja. Minden karakter beírásakor engedélyezi az adási megszakítást.
Azt próbáltam,hogy a megszakítás előtt várok egy kicsit,majd azután akartam kiíratni a vett jelet,de semmi reakció.
A hozzászólás módosítva: Jan 15, 2017
Fogalmam sincs, mire lenne az jó neked. Egy object file temérdek sok szimbolum hivatkozassal van tele, mert meg nincsenek beleirva a vegleges cimek. Például van egy fuggvenyed, azt becsomagolja indexelve, es ha mashonnet van oda hivatkozas, oda a jump-hoz berakja a szimbolum hivatkozast - es nem a tenyleges cimet. A cimeket a linker pakolja bele, amikor eldonti, milyen sorrendben masolja bele a vegleges allomanyba a fuggvenyeket egymas utan. A sorrend például olyasmire is jo lehet, hogy egy adott program részen belül nagyon sűrűn hívott függvény call far ptr helyett call near ptr-t is kaphasson, mert az gyorsabb, és a függvények adott sorrendje mellett kapni tud olyan helyet is a memóriában, hogy éppen elérhető legyen mindenhonnét. Na olyasmi és hasonlók miatt az object még nem kész program, hanem temérdek sok "bedobozolt" erőforrás. Hogy éppen valamelyik 8 bites pic esetében nincsenek külön call címke típusok, attól az object egy ősrégi megörökölt szerkezet, és a toolchain még ugyan úgy épül fel, maximum az adott sdk-ban átdrótoznak pár használaton kívüli részt.
Ami neked inkább kellhet, dobj a linkerből egy assembly dumpot. Ott már a kész címeken nézhetsz meg mindent. A linker helpje írni fogja, hogyan paraméterezheted fel arra is. Linkerje válogatja.
Köszi Neked és nedudgi kollégának is a segítő sorokat, majd nézegetem
!
Most találtam:
DS51288H a Microchip dokumentum neve. Ez tartalmazza a COFF fájl leírását. (Appendix A) A hozzászólás módosítva: Jan 15, 2017
Szia!
Köszi, de ha jól látom, akkor ez már az 'o' fájlok felhasználását írja le...( ha jól tudom, akkor a linker eredményeként ) ! A hozzászólás módosítva: Jan 15, 2017
Ezt már nem tudhatom, mert nem használok C-t.
Köszi, közben meglett, hogy miért nem működött.
Csak Mplab hiba volt..
Látom, nem sok válaszod érkezett. Én C-ben nem vagyok otthon, de gyanítom, hogy ki kell egészíteni a programodat - legalábbis az én érzékelőm is egy kis csavarral adja vissza a hőfokot, bár az adatlap alapján először én is így kezdtem...
Ami frankón működik, azt a kommentek alapján már meg tudod írni.
Tiszteletem a PIC szakértőknek!
Egy outsider kérdez... Ha valaki szakít időt erre a kérdésre, akkor csak igennel/nemmel válaszoljon a többit nem nagyon fogom érteni. Modellvasutazáshoz szervóvezérlőkhöz (váltóállítás) vannak egyszerű PIC-es kapcsolások a neten. Ehhez a PIC-hez vettem kínából pic programmert. Annyit jelezett felém egy fórumtárs a hobbivasúton, hogyha feltöltöm a hex filét a pic-be akkor figyeljek, hogy az eredeti órajel maradjon benn a pic-ben (Oscal?). A pic író ezt a két kérdést tette fel nekem írás előtt. Mind a kettőre NEM-el válaszoltam. Aztán megírta. A pic-et kipróbáltam működik. Kérdésem: így a pic eredeti órajelét (kalibrációs értékét) használja, jól csináltam az egészet? Vagy csak mázlim volt, hogy működik? Köszönöm előre is a váalszt! Newl A hozzászólás módosítva: Jan 18, 2017
Jól csináltad.
Ha rosszul is csináltad volna, kárt nem okoztál volna vele, újra próbálhatnád akárhányszor.
Új 12F629, 12F676 stb. a programtár legutolsó szavában tárolja a belső oszcillátor kalibrációs adatát és a konfigurációs szóban a band gap kalibrációt (bit 13 és bit 12).
A korrekt eljárás: Csatlakoztatás a programozóhoz. Kiolvasás, az említett két adat felírása, mentése. Program betöltése a programozó memóriájába. A programtár utolsó utasítását át kell írni a kiolvasott értékre. Az utasításnak egy retlw xx utasításnak kell lennie (0x34xx). Ugyanis azok a programok, amelyek felhasználják a kalibrációs adatot, egy call utasítással segítségével veszik elő az értéket és beírják az OSCCAL regiszterbe. Ha nem retlw utasítás programtár utolsó utasítása, a program tovább lép és újra a 0x0000 címre kerül. A konfigurációs szóban az 13. és 12. bit átállítása a kiolvasottra. Programozás. |
Bejelentkezés
Hirdetés |
