Koszi ! Nezegetem.

Ok, interrupt. De nekem az kell, hogy fut a kijelzes fuggveny, eler a "delay"-ig, na itt ki kellene adott idore ugrani mast csinalni, aztan ugyan ide vissza ugrani "n" ido utan es folytatni a kijelzest.

Olvasni való:

A C programozási nyelv.pdf .hu 250 oldal.
B. W. Kernighan - D. M. Ritchie
Bővebben: Link

1.7.Függvények

Itt pontosan milyen megoldasra gondolsz ? Fuggvenyekrol van sejtesem.
Ha arra gondolsz, hogy fv. hivassal ugorjak ki az adott kodbol, aztan amikor az lefut visszater a program a hivashoz: NEM jo megoldas, mert akkor az lcd driverbe be kell irjak olyan kodokat ami nem oda tartozik, raadasul kulon fileba is van.

Ja, Te kész megoldást akarsz?

Sajnos a Sült galamb már elfogyott!


A "delay"-t lecseréled Fügvény hívásra!

Mindegy, hagyjuk. Most mondom, hogy nem jo ugy. A sult galambos szovegedet meg osztogasd masoknak.

Miért?
Nincsen meg az LCD kezelő forráskódja?

A függvények tetszőleges sorrendben szerepelhetnek, és egy vagy két forrásállományban egyaránt
állhatnak. Természetesen, ha a forrás két állományban található, bonyolultabb a fordítás és a töltés,
mintha minden egyetlen állományban van, de ez az operáció s rendszer kérdése és nem a nyelvjellegzetessége.

Vagy csak nem tudod megoldani?

Van kész megoldás, lentebb már belinkeltem. A dolog lényege egy olyan mechanizmus, amely lehetővé teszi, hogy egy késleltetés leteltére vagy egy szemafor bebillenésére váró függvény visszatérési pontját erőforrás takarékosan meg lehessen jegyezni, s a felfüggesztés helyétől egyszerűen folytatni lehessen.

A C nyelvben a switch() utasítás kínál ilyen visszatérési lehetőséget. Alternatív lehetőséget kínál a C nyelv kiterjesztéseként a GCC a címkemutatókkal. Tudományosan itt írnak róla.

És persze ezen felül lehet még használni valami RTOS-t is, ha az erőforrások megengedik.

Szia!

Az, hogy kiugorjal es visszaterj ugyanoda, az tenyleg csak egy fuggvenyhivas, semmi tobb.
De, amire te gondolsz (olvasvan a tobbi hozzaszolasodat), az a multitask-os programozas, amihez egy kernel nem art. Akar kooperativ, akar preemptiv. Ez viszont nem programozasi nyelv kerdese. A lenyeg, hogy egyszerre tobb processzed van, de termeszetesen egyszerre csak egy fut, mert csak egy processzorod van. Hogy eppen melyik processz fut, azt a kernel donti el. Amig pl. egy process valamire var (altalaban valami HW esemenyre, egy jelzesre, uzenetre egy masik processztol, vagy egyszeruen egy bizonyos ido elteltere), addig a kernel egy masik 'ready' processznek adja at a vezerlest, azaz az a process fog futni. Aztan, amikor bekovetkezik a vart esemeny, akkor a varakozo processz ismet megkapja a vezerlest, es feldolgozza a vart informaciot. Nagyon leegyszerusitve nagyjabol errol van szo. Egy kooperativ kerlnel az viszonylag egyszeru, es megis nagyon kenyelmesse teszi a munkat.

Ok, segítek.
Kijelző mondjuk 4x20 karakteres = 80 karakter.
Másodpercenként 25x kellene frissíteni, tehát 200 karaktert kellene kiírni másodpercenként.
Csinálsz egy 1/200s-os Timer Interrupt-ot, és minden egyes megszakításként az unsigned char DisplayRAM[80] tömb egy (következő) karakterét kiküldöd a kijelzőre.
Ezek után soha többé nem kell a kijelzővel foglalkoznod, csak a DisplayRAM tömbbe kell írnod, majd amikor jön az idő, az interrupt úgy is megcsinálja amit kell.
Én mindig így csinálom, autonóm modulokat próbálok írni a legkevesebb hardver-szerű interakcióval, persze az init és egyéb szükséges dolgok után.

Total igazad van, ez a legjobb megoldas ezeknel a kijelzoknel. Ezt meg multitask-os kornyezetben is igy csinalja az ember. Csak a szamokat kell kicsit atgondolni, mert 80x25 az 2000 es nem 200. De nincs jelentosege, mert ha 2ms-onknent frissit egy karaktert, akkor 160ms atatt fogja a teljes kijelzot frissiteni, ami meg mindig messze az olvashatosag folotti sebesseg (6.25 kep/sec). A 2ms interrupt meg nem sokat oszt/szoroz, ha csak annyi a dolga, hogy egy byte-ot kitegyen a kijelzore.

Őszintén szólva nem olvastam el rendesen amit írt, csak felületesen. Képernyő-ről volt szó, gondoltam karakteres, én meg példának a saját HD44780-am vettem ami esetemben 4 sor x 20 karakter.
További tuningja lehet a programnak, hogy ha a tömb nagyobb mint ami kell (pl 80), akkor a DisplayRAM[x] pontjától kezdve kvázi görgethető a kijelző tartalom.

Ezek az LCD kijelzők nemhogy a 25 fps-t, de még a 10-et is alig bírják. Alacsonyabb hőmérsékleten ráadásul jó, ha 1-2 fps-sel tudsz dolgozni. Másrészről ha van státusz visszaolvasás (ezt gyakran kispórolják az emberek), akkor akár egy menetben is ki lehet tolni az egész képernyő tartalmát, a tapasztalatok szerint egész gyorsan (1 ciklus max. pár us, 80 karakter esetén ez pár tized ms lehet maximum).

Sose bankodj emiatt, en is siman elkuldtem, hogy 10ms/interrupt az 80ms teljes kijelzo frissites... Pedig 800, hiszen 80 karakter * 10ms = 800ms. Aztan modositottam a hsz-t 2ms/interruptra.

Én is kispóroltam. Nem volt kedvem állítgatni a portot kimenetről bemenetre.

Osszessegeben kevesebb CPU idobe telik, ha fix. par ms-onkent kiveiszel egy-egy byte-ot, mintha a busy bitet figyelned. Es tenyelg nem kell tul surun frissiteni, par kep/sec boven eleg. 37+4 us / karakter lehet irni, ha 270kHz az orajele a HD44780-nak. Nem is olyan keves ido. Csak nem telik 40us-ba egy interrupt entry-leave.. Az 8MHz-en 320 orajel.

Bár nem igazán ARM, csak hozzá hasonló, a rokonság miatt ide passzol a téma: Renesas RX63N 32 bites MCU + HEW IDE + KPIT GCC fordító és a J-link JTAG emulátor összeházasítása.

A hardver egy GR-Sakura kártya (ingyen kaptam, annyit megér). Ezt hivatalosan az Arduino függvényekre és az mbed webes fordítójára hajazó módon kellene programozni (zártforrású firmware és függvénykönyvtárakkal, amit nem igazán csípek).

A kártyában egy 100 lábú, RX63N típuscsatádba tartozó mikrovezérlő ketyeg, amelyet többek között a HEW IDE és a Renesas fordítója (128 kilobájtig ingyenes), vagy a teljesen ingyenes KPIT GNU fordító segítségével is lehet programozni, fütyülve az Arduino kompatibilis könyvtárakra és az mbed stílusú (flash drive) programletöltésre. A programletöltés mehet bootloaderrel (USB vagy UART), illetve használhatunk valamilyen JTAG emulátort (Renesas E1, E20, vagy Segger J-link, egyik drágább, mint a másik...).

Én most J-link-kel próbálkoztam (AliExpressnél 10 USD), amihez a Segger egy adapter kábelt ajánl (lévén a J-link 20 pólusú, ami nem illeszkedik az RX kártyákon található 14 pólusú csatlakozóhoz (ami ráadásul nem kompatibilis a 14 pólusú ARM JTAG csatlakozókkal sem). Természetesen ezt a kábelt is aranyáron kínálják, ezért házilagos kivitellel próbálkoztam. Az információt azonban több helyről kellett összekotorni, s a csatlakozó pólusok összepároztatása nem nagy gond (a Sakura kártyába sima tüskesort ültettem, így female-female típusú átkötő huzalokkal egyszerű összedugdosni.

Az első próba azonban sikertelen volt, mert az elsőnek megtalált bekötési rajz elhallgatta, hoyg egy EMLE jelet is szolgáltatni kell a JTAG engedélyezéséhez (a Sakura kártya egy 7k körüli ellenállással földre húzza, így garantáltan meg sem mukkan a JTAG egység).

Némi keresgélés után sikerült megtalálni azt az információt, hogy ezt a lábat magasra szintre kell húzni. Most nemes egyszerűséggel rákötöttem a 3.3 V-os VDD-re. Így már működik a J-Link Commanderrel is és a HEW IDE-ből is (lekérdezés, programozás, debugolás). A HEW-ben azonban nem lehet bekapcsolni azt az opciót, hogy a J-Link adja a tápfeszültséget, ezért külső tápellátást kell adni a Sakura kártyának. Az általam használt bekötés rajzát mellékelem, hátha másnak is kell.

Figyelem! A gyári firmware felülírásával elvész a Sakura kártya "flash drive" módú programozási képessége (a Renesasrulz.com fórumon található japán nyelvű útmutató a helyreállításához), ezért csak az fogjon hozzá a felülírásához, aki tudja, hogy mit csinál!

Ujrafogalmazok. 4 bites modban HD44780. E(N) lab h/l szintvaltasa kozott nehany ms el kell teljen, itt van egy delay(). Na ezt kellene kivaltani. A jelenlegi delay() fuggvenybol kellene ugrani es vissza. Egy megoldas lehet az, hogy delay()-bol (helyett) hivok egy masik fuggvenyt, ha tudom annak futasi idejet, de ez nekem nem tetszo megoldas. Icserny valasza egy lehetseges megoldas. RTOS kizarva. Gondoltam goto -ra, es egyeb C ugrasokra is.

a) megoldás: timer interrupt, ami minden timer tickre egy-egy lépést megcsinál
b) megoldás: timer interrupt növel egy számlálót, abból lehet tudni, hogy eljött a következő lépés ideje; a főprogram csinál valamit (mondjuk végtelen ciklusban), és minden ciklusnál megnézi, hogy a számláló értéke megegyezik-e az utolsó lépés idejével; amikor nem, akkor meghívja a következő lépést (és a végén elmenti a számláló értékét, hogy tudjon mihez viszonyítani).
c) megoldás: ha változó időket akarsz várni (pl. van, amikor egy timernyi időt, van, amikor 15-öt), akkor lehet azt csinálni, hogy a várakozás elején feltöltesz egy számlálót, amit a timer interruptból csökkentesz, amíg nullára nem ér; a főprogramból pedig azt nézed, hogy nulla-e már a számláló.

Ez a goto-sdi, ez valami rossz assemblysta-beidegződés...

Vagy akkor csináld meg státuszgéppel (switch-case) szerkezet, de mintha erre már utaltak volna lejebb.

Kedves Fórumtagok,
STM32F407-re fejlesztenék, viszont hallottam egy komoly problémát amire nem nagyon találok megoldást a neten így hozzátok fordulok, hátha tudtok valami okosat mondani.
Egy ismerősöm fejlesztett egy STM32F1XX-es típusú mikrovezérlővel. Elkézsítette a HW-t, beépítette, működött is normálisan. Viszont mivel fejlesztésről volt szó időközben szerette volna a kódot módosítani, így átlépett boot módba, hogy átprogramozza az MCU-t.
Ekkor amit beállított normál üzemmódban a mikrovezérlő indulása után Ki/bemenetnek, ezt boot módban nem volt hajlandó követni, és amit soha nem szabadott volna bekapcsolni, azt a beavatkozót is bekapcsolta (hogy konyha nyelven fogalmazzuk meg a probléma gyokerét).
Még hardver fejlesztése előtt állunk, ismert a probléma, tehát ha tudnánk, hogy boot módban az IO lábak alapértelmezetten mit vesznek fel az is megoldás lenne.
A választ/ötleteket előre is nagyon szépen köszönöm.


"Okos ember más hibáiból tanul. "

Szia!
Nem ismerem a konkrét megvalósítást, de nem tudom elképzelni, hogy egy jól megírt ( márpedig egy gyári bootloader gondolom ilyen a sok teszt miatt! ) loader kimenetnek állítson bármilyen lábat, mielőtt elindulna a program ! Inkább az lehetett a probléma, hogy bemenetnek állítja és ez a szint bizonyos eszközöket be tud kapcsolni ( pl. egy tranzisztoron/FET-en keresztül ! )! Vagy rossz volt a rátöltött szoftver ( számrendszer ?! ) ?!

Kicsit OFF, de nem árt tudni, hogy ez sajnos nem mindig van így. Legalábbis az NXP chip-ek gyári bootloader-e messze nem hibátlan. Az adatlapban közölt flow control mechanizmus nem mûködik bennük. Vagy pl. az eddigi chip-ek 115.2 kbps sebességig mentek, az LPC1788-ban csak 57.6kbps a max. kommunikációs sebesség. És ez csak az errata-ból derül ki, meg a gyakorlatból. Szóval attól, hogy valami gyári, az még koránt sem hibátlan.

Erre azért nem gondoltam... Mégis használják ?!

Mégis? Persze. Kénytelen vagy. Csak tudomásul kell venni, hogy ezen a chip-en ennyi a max. speed. Ebben igazából az a szomorú, hogy nem javítják ki. Pedig ez pusztán software kérdés lenne. Egyre újabb chip-ek jönnek ki, de a hibát nem javítják ki, az adatlap az új chip-eknél is írja a flow controlt, de a bootload-er továbbra sem tudja. Sôt, már a sebessége is csak fele az eddigieknek... Ez van. Az is ismert, hogy vannak bizonyos HW hibák, és azokat sem javítják ki. Már az LPC2378-nál tudták, hogy az Ethernet modul hibás, és ugyanaz a hiba benne van a 1788-ban is, pedig a kettô között eltelt pár év. Mit tudsz csinálni? Semmit. Sw workaround. Még mindíg jobb, mint sok más. Bár most ez az STM32F4xx nagyon birizgálja a fantáziámat

Köszönöm a válaszokat, jó látni, hogy ilyen hamar érkeznek a válaszok.

Sajnos pontos specifikációt nem tudok, hogy az illetőnek mi volt a gondja, de ahogy tudom hw fejlesztő az illető és maga is meglepődött rajta, ezért is hívta fel a figyelmet rá, hogy nézzek utána.

Eddig a 8 bites PIC-ek világába éltem, ahol a reset utáni regiszterek beállása le van normálisan dokumentálva:
pl. PIC18F4550-eseknél:
http://ww1.microchip.com/downloads/en/devicedoc/39632e.pdf
4.6 Reset State of Registers

Azért kérdem mert lehet csak én nem találom a doksiban.

Ismét dúrom az adatlapokat és a reset utáni állapotok egyértelműen fel vannak sorolva:
STM32F417_DM00035129.pdf
Az 46. oldaltól kezdődő 7-es táblázatban. De egyelőre BOOT-ot utáni pinout-ot nem találok.

A pic-ek dokumentáltságáról és úgy általában a mikrochip dokumentációk használhatóságáról inkább ne is beszéljünk... De az is igaz, hogy ennek az STM32F407 jószágnak kicsit bonyolultabb az I/O kezelése (több is a lába), mint egy 8 bites PIC-nek. Több dokumentumból kell összevadászni az infót. Jómagam eddig nem dolgoztam ilyen chip-pel, ezert nem is tudok konkrét válaszokat adni neked, de elsô olvasatra úgy tûnik, hogy azért reset utan a legtöbb láb bemenetre áll be. A bootloader sw-e (bár konkrétan nem írja), nem állít kimenetnek semmit, amíg ki nem találta, hogy melyik interface-en keresztül akarják birizgálni. Tehát, ha pl. te az USART1-en keresztül akarod programozni, akkor amíg meg nem kapta az USART1-en az elsô 0x7f szinkron byte-ot, addig még az USART1 Tx lábat sem programozza kimenetnek. De azt viszont írja az adatlap, hogy a többi bemenet, amin szintén lehet programozni a chip-et nem lebeghet, fix szinten kell legyen. Ez azért lehet fontos, mert reset után a legtöbb lábon NEM kapcsolja be a belsô felhúzó/lehúzó ellenállást, azaz neked kell külsûleg garantálnod, hogy pl. az USART3 Rx láb nem mocorog, amíg a bootloader az interface detektálási fázisban van.

van egy STM32F407-essel épített Discovery panelem, meg egy Logikai jelanalizátorom
Leszek olyan beteg, hogy mindjárt végig nézem a lábakat