Ha már más hardver, akkor inkább RS485 driver. A kérdező RS232-ről beszélt...

Rendben köszönöm szepen az otleteket.

Köszi a tanácsot, meg is csinálta a reportot. (mellékeltem).
Ez alapján jól rakosgatja a RAM függvényeket, igaz?

Jól láthatóan ott van egy több, mint 6k-s ".RAMFUNC$" a "kseg1 Data-Memory"-ban. Tuti biztosra veheted, hogy az a funkció memóriából fut.

Ha mégis lassú, akkor utána kellene nézni, hogy a systemperformance() normálisan van-e beállítva. Tényleg azon az órajelen fut-e, mint amit beállítasz neki, mert az a függvény csak a bemeneti paraméter alapján állítja be a wait state-eket, nem végez külön méréseket ellenőrizgetni.

Egy másik lehetőség pedig, hogy nem amiatt a funkció miatt lassul a programod. Van ott még valami más is, amit figyelmen kívül hagytál.

A legviccesebb baki elkerülése végett én elsőként az oszcillátor beállítást ellenőrizném le kétszer is, hogy nem fele sebességen pörög-e, mint gondolom, vagy ilyesmi.

Hogyan lehet arra rákeresni, hogy melyik 5V-os pic-nek van a legtöbb belső ramja? Jó tudom, átlag 2k ramosak, de akad kivétel? Advanced microchip part selector failed - nincs voltage range szűrés.

Lehet licitálást rendezni. Pl. dsPIC30F6010A 8kB RAM Ki tud többet?

Régen volt ilyen szűrésük...
Amúgy 18F..K80/K22 így első tippre, majdnem 4KB van bennük, ennél nagyobb 8-bitesben nem létezik, a 16/32-bitesek meg emlékeim szerint egyáltalán nem tudnak 5V-ról menni. Tuti biztos kell az az 5V oda? Ha a RAM mérete necces, akkor inkább raknék egy 3.3V-osra szintillesztőt, minthogy 4KB-ba be kelljen szuszakolni.

... ezek szerint rosszul tudtam, 16-bitesben van 5V-os is

8 bit, a bal szélen a Change product group füllel lehet megnézni a 16 és 32 biteseket...

Megy 5V-ról a PIC24FxxKAxx és KM sorozat is, de azoknál most 2 kB RAM a plafon.

Tipp: a Nuvoton Cortex-M0 mikrovezérlői is mennek 5V-tal és van sok köztük, amiben 16 kB RAM van.

Köszönöm a megerősítést. Az oszcillátor 100%, hogy jó, mivel kiszámoltam a beállított 80MHz-es órajelhez egy timert, ami villogtat egy életjel LED-et 500ms-onként. Azon biztosan látnám, hogy ha fele órajellel megy.
Ha valóban RAM-ból fut, és mégsem gyorsabb akkor lehet, hogy jelen esetben nem dob rajt olyan sokat a RAM-ból futás. Egy rövid, de sokszor lefutó ciklus van ebben a függvényben, így gondolom be tudja cash-elni rendesen.
Arról is sikeren meggyőződtem, hogy ez a függvény lassítja be. Innen nincs további függvényhívás, és ha kikommentezem ezt a függvényt, akkor látszik, hogy ez fogta vissza.
Mindenesetre köszönöm még egyszer, hogy segítettél meggyőződni arról, hogy tényleg RAM-ból futtatja. Így más módon kell kicsit gyorsítani...

Cache line-ok alapból bekapcsolva szoktak lenni, de 30 mhz-ig wait state nélkül is futni tud flashből is, így a ram sem gyorsít rajta. Ha pedig kicsike az a ciklus, akkor tényleg meglehet, hogy belefér egészben a cache-be. A ramból futás egyébként nem csak sebesség végett tud fontos lenni. Felezi az áram fogyasztást is. Mondjuk az most vagy fontos, vagy nem.

Pic tippeket köszönöm mindenkinek.

icserny:
Simán megnyerted a licitet. Csak pislogok rá, hogy 16 bites pic-ek között is van 5 V-os Cortexeket inkább nem piszkálnám. Egy több pic-es áramkörön filozok, és keverni picet meg armot, nekem bizony nem hiányzik a több féle fejlesztői környezet. Kész rémálom tud az lenni. Ha nagyon bajban leszek, maximum külső spi ram, de megspórólnám a +1 külső tokot, ha lehet.

PIC18F8722 - Külső memóriabusz 20 bit cím 16 bit adat : 2Mbyte lehet akár RAM is...

Ez hasznos dolog, de nem felel meg az eredeti kérdés feltételének (belső RAM).

.. Azért volt off.

Sziasztok! Egy PIC gurunak a segítségét szeretném kérni! Az alábbi kódot használom egy jó ideje 2x16soros LCD-hez, ami működött is tökéletesen, mindaddíg míg nem váltottam 18F...-es PIC-re.



A display_first_row hívása egy 16F877A-s PICen tökéletes eredményt produkál, a text_table-ból kírja a karaktereket.
Ám ha 18F458-on használom, akkor: minden karakter dduupplláánn jelenik meg.

Többféle dolgot kipróbáltam, pl. az időzítést nyújtani, de eredményre csak az utolsó előtti sor, az incf count,f duplázása vezetett eredményre. Kérdésem, hogy ez így normális?

Ha valaki látja a hibát, kérlek osszátok meg velem!

Előre is köszi!
Üdv
The_Saint

A 18F-eknél két bájt fér el egy címen és a címek párosak lehetnek csak és kettesével ugrálnak. Próbáld leszimulálni az MPLAB-ban...
A programmemória elérésre vannak speciális utasítások, amik sokkal kényelmesebbek. Nézd meg az adatlapban a táblakezelő parancsokat.

Szia!
Ahogy watt is írta a táblázatnál lesz a probléma.

helyett

paranccsal működhet, de a count ilyenkor nem haladhatja meg a 127-et, és garantálni kell, hogy a táblázat a programmemóriában ne szeljen át 256 bájtos blokkhatárt.
Ennél jobb és szebb megoldás a 18F sorozat új utasításait kihasználni, mint pl. tblrd* tblrd*+, ezeknek olvass utána az adatlapban.
Nem kapcsolódik a problémához, de a goto helyett közeli ugrásokra a bra használandó.

Üdv!

watt és mateakos, köszi a segítséget, probléma megoldva. Naívan azt gondoltam, hogy nem kell olyan alaposan végignyálazzam a leírást

További szép napot!
The_Saint

Sziasztok!

Linux alatt (is) szeretnék PIC-eket programozni, tudnátok segíteni, hogy hogyan kezdjek hozzá? Van valami bevált c18 fordítótok, mert én hiába turkálok neten nem találok semmi használhatót.

Üdv, adamhollos!

MPLAB X, XC8/16/32 fut Linuxon. Régebbi modellekre valószínűleg az SDCC-vel is tudsz fordítani, bár azt elég régen néztem utoljára.

Igen, mblab x-et néztem de nem tudtam vele mire menni, ammúgy 18f25k80-at szeretnék programozni

Szia.
MPLAB X és C18 működik linux-on, én azokat használom. Annyi a különbség a windows-os C18-hoz képest, hogy az include-oknál a fájlnévben figyelni kell a kis és nagybetűkre, meg természetesen a / a mappa elválasztó, a \ nem működik.
Az új MPLAB X verziók külön JRE-vel jönnek, úgyhogy a Java-val se lesz gond.

Akkor itt és most megragadnám az alkalmat (mivel még veterán HE-sek kódjában is látok \-t), hogy felvilágosítsak mindenkit: a C-t úgy találták ki, hogy /-t használunk elválasztásra. Windowson is! Majd a C fordító megoldja, ha az alatta futó platform mást használ.

Köszönöm összejött

Üdvözletem,
Szeretném felhívni a kedves PIC-ezők figyelmét egy érdekességre: Egy hete elkezdtem tanulni az XC8-as programozási nyelvet, gondoltam ideje kinőni a CCS-ből (azzal kezdtem körülbelül 2 éve), azt hittem, hogy tömörebb kódot lehet vele írni, elvégre is a Microchip terméke... Szóval gondoltam egyet és elkezdtem átírni a programjaimat CCS-ről XC8-ra, egyelőre csak a kisebbeket, elsőnek egy HD44780 LCD drivert, és itt jött a meglepetés, egy az egyben átírtam a régi kódomat és meglepődve tapasztaltam, hogy a CCS kódja a PIC Romjának 28%-át eszi meg, addig az XC8 34%-ot. Megjegyzem, hogy az XC8 telepítésénél volt egy lehetőség, hogy 60 napig használhatom a PRO verziót, ezt ki is használom, ezek után bele sem gondolom, hogy mi lesz/lenne ingyenes verziónál.
Már láttam a fórumban, hogy sokan szidják az XC8-at, de azt nem gondoltam volna hogy ilyen drámai a helyzet...
Ezt csak egy érdekességnek szántam.

Ha a Project properties-ben beállítasz valamilyen optimalizációt, akkor hogy alakul a dolog? Az O1-es optimalizáció a free verzióban is benne van még.

... A négyszeresére nő... Vagy 995$

Csak nem
Nekem olyan kb 2-szer gyorsabb és 25%-kal kisebb lett a programom, bár az PIC32 volt.

Az XC8 fordító free módjáról volt szó 16F -eken...