Kihasználja. Meg is nézheted a szorzó rutinokat a C18 src/tradicional/math könyvtárában. Az fxm kezdetűek azok.

Üdv!
Azt szeretném kérdezni , hogy egy folyamat leprogramozására (c-ben) milyen megoldások vannak?Arra gondolok , hogy például egy óránál menü funkció , meg ébresztés funkció.Van jobb megoldás az if elágazások tömkelegénél?

Kösz a választ.

Switch-case. Bővebben: Link Ha jól értem erre gondoltál.

if, switch, véges állapotgép (ez utóbbi nem C utasítás, hanem programozási technika)

Sziasztok! PIC24H-nál, megszakítás kezeléskor, miket érdemes elmenteni? SR, W0 (és még amiket használok gondolom W1,2,3) Program számláló? szoftver verem?

A (megszakítási rutinban) használt regisztereket. Az állapotregiszter és a programszámláló automatikusan eltárolódik a verembe. Az árnyékregiszterek használatánál meg figyelembe kell venni hogy az árnyéktár csak 1-es mélységű, tehát ha a megszakított programban használva vannak, akkor a megszakító rutinban ne legyenek (vagy fordítva)! Ha mégis, akkor azokat is menteni kell a normál regiszterek után.

Köszönöm!

Sziasztok!
Még régebben írtam egy programot 16f628a típusú PIC-re, amiről kiderült, hogy tartalmaz egy bugot amit fel kéne derítenem. MPLABX-et használok XC8 fordítóval linux és windows alatt egyaránt. Sajnos az áramkörhöz nem férek már hozzá, így az mplab szimulátorát szeretném használni debuggoláshoz. A probléma az, hogy futtatja a programot, a változókat tudom is figyelni, PC értékét is mutatja de az éppen végrehajtott sort nem látom és breakpointok is brokenek bárhová is rakom őket. Hogyan lehetne ezt megoldani?
Előre is köszönöm a válaszokat!

Linux alatt működik, csak windows alatt nem.

Szia,

Bevallom őszintén, nem olvastam el a teljes történetet, mert a legeleje valahol 6 lappal ezelőtt volt, és hát jó hosszan kínlódsz vele. A tutit megmondani nem az én dolgom, épp csak felhívnám szíves figyelmedet pár apróságra.

Ha sebességet kell elérni, a normális hardver a fontos első lépésben, és annak a hatékony kihasználása második lépésben.

Első lépésben 4550-et választani lehetségesen nem volt a legbölcsebb döntés. Azon a pic-en - amennyire az adatlapot felkotorni tudtam - szerencsére van különálló adó és vevő buffer, de csak 1 byte mélységű. Ha nem tudsz az érkező adatra figyelni 70 usec idő alatt, akkor a buffered túlcsordul (8 bit / 115200 bit => 69.44 micro sec per byte). Mindezt adó és vevő oldalon is kezelni azt jelenti, hogy kb 70 usec időnként kell lefutnia egy interrupt alsó oldalt kezelő rutinodnak mind vétel mind adás számára, hogy azon a sebességen időkiesés nélkül kezelni tudják az adatátvitelt. Vételi oldalon az interruptod tud futni akkor, amikor érkezett új byte, és az biztosan akkor fog csak futni, amikor van mit csinálnia, de az adat kiküldést timer interruptra kell majd raknod, mert nem biztos, hogy a kimeneti buffered akkor fog kiürülni, amikor van következő kiküldendő adat is. Ha majd tényleg belejössz, eljátszadozhatsz azzal, hogy a timer interruptot bekapcsolni a felső fél kezelési területről, ha byte került a kimeneti bufferbe, valamint átkikapcsolni a timerből uart transmitter interruptra, ha elég sok byte van benne, mert akkor az uart interrupt is biztosan fog következő byte-ot találni, mire az előzőt kiküldte, és annak kell majd újra visszakapcsolnia a timer interruptot, ha éppen nem talált már semmit, valamint a timer interruptnak lekapcsolnia önmagát, ha újfent semmit sem talált (a felső fél majd úgyis visszakapcsolja az első bufferbe helyezett byte után). Meg lehet vele spórólni valamennyi cpu időt összességében Mellette a felső oldalon az alkalmazás logikának annyi cpu idő maradhat, amennyi marad. Hogy mi mindent akarsz belegyömöszölni egy 8 bites pic-be, azt nem tudom, de tökéletes flow control mellett is én túlterheltnek érzem. Az interrupt alsó fél mellett a felső féllel (ami az érkezett byte-okat álltja majd össze feladat csomagokká) már pollozni kell a helyi bufferedet, arra is cpu idő megy el, és még mellette az alkalmazás logikára, amit gondolom idővel fejleszteni is szándékozol. Nincs fejlesztési tartalékod azon a cpu-n. Hogy nyersen tudni fogsz 115200-ig turbózni adatátvitelt, az nem jelenti azt, hogy az akkor is tudni fog működni, amikor a teljes alkalmazást is belegyömöszölöd a pic-be. Ami tippet a következő alkalomra adnék (valahol olyasmit láttam, hogy valami már le van gyártva, ergó már kőbe vésted az elhamarkodott döntést), hogy mostanra 32 bites pic-et is fele áron kapsz, mint a 4550-est (forrás chipcad jelenlegi szabad készlet árlista), és azokban nem a semmiért van felbővítve az adó / vevő buffer 8 byte mélységűre, meg normálisabb cpu teljesítményed is van, mint a 4550-esen.

Második lépésben a "flow control" fogalmára hívnám fel szíves figyelmedet. Amennyire az első bejegyzéseket láttam, az adatátviteli protokoll arra épül, hogy miután leküldtél egy csomagnyi adatot, azt a pic feldolgozza, és addig a pc vár. Ha a pic visszaküldte a feldolgozás eredményét, a pc akkor fogja küldeni a következő feladat csomagot (és addig meg a pic vár). Most nem tétel, mit jelent a "feldolgozás" és a "munkacsomag", azt kezeljük fekete dobozként, "valami". Maga a folyamat a gyenge. Ha legfelső szinten teljesítményt szeretnél látni a pic oldalán, nullára kell csökkentened a pic oldalán az üresben várakozási időt. Nincsen olyan, hogy vársz, amíg a pc küldi a következő csomagot. Helyette a pic oldalán is előre bufferelned kell egy következő csomagot. Ha a pc elküldte az elsőt, annak a pic nekiállhat, de míg fut az alkalmazás logikád, a háttérben a pc-nek már küldenie kell a második feladat csomagot is, és azt pic oldalon le kell bufferelned (arra valók az interrupt rutinok). Amikor a pic alkalmazás a helyi (virtuális) kimeneti bufferbe lerakta az első feladat feldolgozási eredményeit (amit "háttérben" az interrupt alsó fél fog kidobálni a pc felé), addigra már ott kell lennie a következő feladatnak a helyi memóriában, hogy várakozás nélkül nekikezdhessen. Ha nem így csinálod, időkiesésekkel számolhatsz, ami a végső statisztikában a teljes sávszélességedet csökkenti majd. Alkalmasint siralmasan alacsonyra.

Ha úgyis csak hobby, gondolom lesz rá elég időd összeismerkedni az interrupt-ok működésével, a flow control és a párhuzamos folyamatok fogalmával (abban a pic-ben önálló elektronikai eszköz az uart és a cpu, valójában párhuzamos információ kezelésed van), az aszinkron adatkezelés fogalmával, számolgatni kicsit, hogy összesen mire tud elég lenni a 4550-es memóriája (az a 2048 byte bizony nem sok, és abba kell mindent belegyömöszölnöd), és hogy a cpu időből mennyi megy el interruptokra (ezt ki kellene majd mérni), és mennyi marad az alkalmazásra, és mindezekhez hozzácsiszolni a pc alkalmazásodat is. Apropó a pc oldalán is lehet sok szálasan építeni alkalmazást, nem kell annak egyetlen főciklus mentén várakozásban pörögnie, vagy oda se figyelnie a soros portra, tud a pc program egyszerre is csinálni sok mindent, hála a sokmagos processzoroknak.

Ja igen, a "Csharp" szokásosabb jelölése "C#", de az öregebb szleng néhol csak "dot c"-ként ismeri (a "c#" a ".net" c-je, ejtsd "dot net").

Remélem nem lett túl hosszú

Szerintem az a sebesség talán már elég lesz amit a végére ki tudtam préselni belőle.
Amúgy 18F442 nem 4550.
Utoljára 5-6kb/s-el kocorgott az adatátvitel, 64byte-ot bufferelve, de ezt még fel tudom vinni duplájára vagy is annak közelébe.
Úgy gondolom az már elég lesz, de ha még sem, akkor továbbgondolom a dolgot és nem UART hanem USB kommunikációt fogok alkalmazni nyilván másik (18F4550) pic-kel, de mivel ez egy kis tanuló és hobbi projekt nem hiszem, hogy lényeges lenne ennyire kiélezni a dolgot.
Meglátom, hogy a memória írási folyamat mennyire lassítja be majd a kész hardvert, ott még lehetnek gondok amúgy, de csak tudok majd kicsit rajta hegyezgetni, ha kell.
Ha memóriában is otthon vagy akkor itt tudsz segíteni mert elakadtam: Bővebben: Link

ui: a választás pedig arra esik általában ami a fiókban van, és megfelel a célnak. (lábszám, funkciók...stb)
18F442, 452 van a fiókba, kiveszem és nem kerül semmibe.

32mx795 20 mhz mag frekivel, az mc usb libjével, pc oldalon generic usb driverrel c# alatt oda-vissza teszteltem a sebességet mindenféle flowcontrollal vacakolás nélkül is egy alkalmazásban, és 60 kbyte/sec simán volt meg. Ennyit tudok tesztekről írni. Egy 8 bites pic-el lassabb lesz, de a soros portnál biztosan gyorsabb. MEgnézem a memória problémádat is a másikon.

Sziasztok! Gondom akadt egy INT1 megszakítással. A főszerepben PIC24H, és nem akar belépni a megszakításba, semmi képpen. Egy másik környezetben INT0 val hibátlanul működik a dolog, viszont INT1 áthelyezhető periféria, ez is be van állítva mégsem jó valami. Csatolom a fontosabb részeket: Mi lehet a hiba?

Elfelejtettem írni, hogy PK3-mal debuggolás indítása után 1 mp mulva megáll a futás. Gyanítom, hogy ott lehet a hiba, amikor belép megszakításba. Mintha ott eltévedne, vagy nem lenne RETFIE, pedig van.

Stimulussal teszteltem MPLAB sim alatt, INT0 külső lefutó élre a megszakítási vektorához ugrik, INT1 pedig resetre Ez mitől lehet?

Üdv!
Esetleg ez lemaradt a program elejéről:

Minden megszakításvektor alapból a Reset-re mutat, ha nem adsz meg mást.
Egyébként miért nem a verembe mented a regisztereket? Azért (is) van. Ha fix mentési helyet használsz, akkor egymásba ágyazott megszakítások esetén gubanc lesz. Az állapotregisztert meg nem kell menteni, mert az automatikusan megtörténik.

Természetesen jelen esetben a W1 és W2 regiszter mentése is felesleges (mivel a rutinban nem módosulnak), csak a példa miatt kerültek bele.

Szia! Hihetetlen hogy mennyire figyelmetlen tudok lenni. Az INT0 meg volt adva .global-lal, viszont az INT1 lemaradt... Köszönöm a kiigazítást mentést illetően is! Üdv: Balázs

Szívesen!
Én is mindig a figyelmetlenségem miatt szívok. (Legtöbbet a helyi címkékre történő helytelen irányú ugrásokkal.)

Sziasztok!

ESP8266 modullal próbálok UART-on kommunikálni egy pic18f14k22-es mikrokontrollerrel. USB-Soros átalakító és a modul között tökéletesen megy a párbeszéd, a pic-el viszont durci van. Szkópban látszik a probléma oka de nem találom, hogy hol van elcseszve a program.
Helyes küldés USB-Soros átalakítóval (ESP8266 válaszol):
a
Helytelen pic-el (nincs válasz):
b
Azt látom, hogy egy magas bit becsúszik a két 8bites karakter közé, de miért?
Ezt a programot használom a mikrokontrollerben:
c
És így:

Már órák óta szenvedek vele, minden segítséget előre is köszönök!

Szia!

Akaszd rá a PIC TX lábára az USB-Soros átalakítót és akkor terminál programban láthatod, hogy mit küld ki a PIC, vagy az RX lábra akkor pedig az ESP8266 válaszait láthatod.

Az ábrákból nem derül ki, mit is küldtél és minek is kellene látnunk a lefolyását. Az uart kapcsolat a keretek között tetszőleges idsejű inaktív szinetet elvisel.
A programodban az UART_Write_Text eljárás legalább egy karakter elküldési idejét váratozással tölti, de lehet, hogy kettőét is. A UART_Data_Ready csak megnézi, hogy van-e már vett karakter, de nem olvassa ki. Ha még egy érkezik, ráfutási hiba keletkezik. Ha volt vett karakter, akkor 1 másodpec, ha nem volt akkor csak 1/2 másodpercig várakozik a program, Ez alatt az idő alatt több karakter is érkezhet, ami megintcsak ráfutási hibához vezethet. Nem fogod megúszni a megszakításos, bufferelt uart kezelést.
Ha a modul 3.3V -os, a pic 5V -os tápról jár, akkor a vételi vezetékre szintillesztőt kell beépíteni.

A STOP bit után nem indul azonnal a második karakter küldése. Ez nem hiba.

Sziasztok.
Nagyon kezdő vagyok a témában. Kérdésem lenne, hogy *.c *.h *.lkr fájlokból hogyan és mivel lehet egyszerűen hex-et generálni?

A megfelelő C fordítóval.

Köszi. Esetleg valami leírást nem tudnál hozzá linkelni?
MPLAB amim van, hátha ez meg tudná oldani a feladatot.

Látom én mindkettőt szkópon is, és Pickit3 debug módban is. Képekkel is illusztráltam.

Ha csak az alap MpLab van letöltve, akkor még le kell tölteni egy C fordítót is: XC8, Microchip C18, stb.
Bele kellene nézni a .c állományba, hátha voltak olyan gondosak és beleírták a fordító nevét...

A programban benne van mit küldök: "T\r", és természetesen ugyan ezt terminál programban is.


Nem is kell neki, azt debuggerben és szkópon látom, nem ez a lényeg.

Ez a program csak azért van, hogy szkópon lássam a kimenetet/bemenetet, nem a feldolgozás miatt.

Nem. 3.3V-ról labortápról működik mindkettő, a mikrokontroller működőképes ebben a feszültségtartományban is.

De akkor a terminál programban miért nincs ott a STOP bit? Mert csak így válaszol a modul.