Tényleg nem tudsz olvasni? Akárcsak rolandgw?
Vagy csak addig olvasod, amíg beleköthetsz?
Tedd már meg, hogy végigolvasod és értelmezed mindazt amit eddig leírtam!
Többen is rágjátok ugyanazt a csontot, amit én sem tagadtam eddig sem. Csupán annak adtam hangot legutóbb, hogy a hardverek értelmetlen sokfélesége, inkompatibilitása miatt
csak egy bonyolultabb, hosszabb könyvtári fájl képes viszonylag nagyszámú különböző hardveren is elfutni!
Mivel én is írtam már olyan, többféle PIC18-on is elfutó LCD kezelő programot, ami belső oszcillátor használata esetén 500KHz-s órajeltől 16MHz-s órajelig automatikusan korrigálja az időzítéseket is, így tudom, hogy miről beszélek!

Lehet, hogy engem is megkövezel érte, de elmondom mi a baj. Kiemelve a cikket it. Előre leszögezem, tudom milyen érzékeny vagy, ne vegyél semmit sértésnek, minden tiszteletem az assemblyben elért és készített dolgaidért.
Semmi baj, hogy te foggal körömmel ragaszkodsz az assemblyhez. A baj az, ahogy azon többiekhez állsz akik nem ezt teszik. Ez a baj a cikkel is. Csak le kellet volna írnod mi mindent lehet csinálni assemblyben egy "apró" 8 bitessel, kihagyva az Arduino és magasszintű nyelvek lenézését és akkor nem indult volna el ez az egész.
A másik dolog, hogy hobbistáknak címezted. Kit tartasz hobbistának? Ahogy Bakman is leírta sokan csak örülnek ha valammit programozhatnak és látják a végeredményét, nem feltétlen akarnak belemélyedni az assembly és ezáltal a vezérlő részletes rejtelmeibe. Továbbá nem mindenki tud vagy akar NYÁK-ot gyártani PIC-ekhez. Az Arduino boardon ott vannak a csatlakozók, csak összedugdossa és kész. Igaz PIC-et is összelehet breadboardon. PIC-hez kell egy PICkit. Az Arduinohoz csak egy USB kábel. Vagy az már nem hobbista? Nem védem egyik oldalt sem. Én PIC-el kezdtem. Assemblyt a PIC-en tanultam meg. Ma már nem használom, csak ha kell. Miért? Mert 8 bites már nem volt a kezemben szerintem 5 éve. Ugyanazon az áron több erőforrással lehet kapni jobb vezérlőt. Hiába szajkózod, hogy erőforráspazarlás. Az a baj, hogy te csövön keresztül nézed a világot és szeretnéd azt a saját nézetedhez igazítani. Márr nem a 80-as években vagyunk. Már nem elég egy 2x16 karakteres LCD-re kiíratni egy hőmérsékletszenzor adatait 1-2 nyomógombbal. Az érintős HMI-k és hasonló finomságok korában vagyunk. Igen, van jogosultsága a 8 biteseknek is, és az assemblynek is. Nyilván például egy autó távnyitóba nincs értelme "I9-es PC-t" rakni bár manapság már a távnyitók is távolságot, mozgást, ujjlenyomatot mérnek, kávét főznek. Lassan a WC-t sem tudod lehúzni update nélkül, de ez van. Megszoksz vagy megszöksz.

Idézet:
„Mi a fenéért kell csak a PIC18F szériából kb. 500 fajtának lennie?”

Gazdaságpolitika. Ezt egy pár képekből álló óvszerreklám anekdota tudná leírni. Nem idevaló. Kicsit hosszú lett, de nem kívánok hozzászólni többször.

Kérjük, hogy a témára koncentrálva értekezzetek tovább, semelyik olvasó nem kíváncsi a személyes ellentéteitekre, ezek lerendezésének helye nem a fórum.

Köszönjük.

Jó napot, sziasztok ! Szerintem mindenki abban programoz ami neki szimpatikusabb, nekem 8 bites pic-eknél az assembly jön be jobban. Régen a comodorokra is erőltették a basicet, de az igazán gyors nagy progikat gépi kódban írták rá. Mostanában egy kis cnc-t építgetek arduino grbl vezérlővel, viszont a léptetők helyet "ablaktörlő" motorokat alkalmaztam és pic 16f628-ra irtam szervó vezérlőt assembly-ben. Bővebben: Link

Sziasztok!
Teljes terjedelemben elérhető valamerre ez a könyv? Kerestem de csak a 70. oldalig van meg.
Köszönöm!

A bookline-on van egy antikvár példány.

Most botlottam bele a Jún 5, 2020 -i cikkedbe. 100%-ban egyetértek vele.
Egy gép minden adottságát csak assembly-ben, közvetlen gépi kódban lehet kihasználni. A készen kapott moduloknál már kötve vagy másokhoz. A modulok által ki nem használt lehetőségektől el vagy zárva, vagyis nem teljesen tiéd az az eszköz.
Amikor én programozni kezdtem, a cégnél, ahol dolgoztam, még másik gép sem volt, amin az assebler futott volna. Közvetlen gépi kódban írtam a programot epromba, 3,6 MHz-es 8085-ös processzorra. Nem elírás, MHz és nem GHz! 4kbyte-os epromnál akkor még nem lehetett nagyobb epromot kapni, ebbe kellett elférni. De elfért benne egy liftvezérlés, vagy egy raktári rakodó robot programja. Integrált áramköröket tartalmazó kártyákat tesztelő automatába már 8 db 4 kbyte-os eprom kellett, de a működtető program itt is elfért 4 kByte-ban, a többi a kártyák adatait tartalmazta.
Minden bit számított duplán is. Egyrészt mert kevés volt a memória, másrészt pedig a lassú processzor miatt hosszú programnál a végrehajtási idő annyira megnőtt volna, hogy a lift nem egy szintben állt volna meg az emelettel, vagy a robot a villáját nem a raklap alá tolta volna, hanem a polcba vagy a csomagba. Hiba nem lehetett benne, mert az nagy kárt tudott volna okozni, akár emberéletet is követelhetett volna. Egy olyan szószátyár programmal, mint a mai modulok, megoldhatatlan lett volna. És ki tudja, mennyi hiba van egy ilyen hosszabb programmodulban! Nem véletlen, hogy olyan nagy divat manapság a frissítés!

Sziasztok!

Gondolkoztam már, hogy én is hozzáfűzök pár gondolatot, most jutottam el időben odáig:
Szerintem a maga módján mind a két "tábornak" igaza van. De ahogy olvasom a hozzászólásokat, mindenki elfelejti az egyik legfontosabbat. Mindennek meg van a maga helye. A távirányítós példát használva, simán mehet assemblyben. Legyen tömör, férjen el akár egy pici memóriával rendelkező kontrollerbe is.

Másik oldalról megközelítve, lehetetlen a mai komplexitású eszközöket tisztán assemblyben megírni. Amikor C kódból is több ezer, tízezer sor jön össze, senki ember fia nincs, aki ezt értelmes időn belül (értsd, amíg anterioritási időn belül van) megírja. Assembly-t szétosztani fejlesztők között pedig szerintem megint nincs értelme. Ha csapatban írják a kódot, akkor se fogják az egészet átlátni, ha egyedül, akkor pedig az ember képességeinek határa miatt nem fogja tudni egyben kezelni, nem is beszélve arról, hogy ember legyen a talpán, aki a különböző assembly modulokat integrálja majd. Így odakanyarodtunk, hogy nem lesz biztos a működése, nem biztos hogy azt fogja csinálni ahogy azt elképzeltük. A C és hasonló "magas" nyelvek ezért szerencsésebbek, mert könnyebb őket szétosztani kis modulokra és utána összerakni is egyszerűbb.

Komplexitásból egy gondolat: egyre több beágyazott rendszeren használnak már valamilyen mesterséges intelligenciát. Ha csak a járműipart nézzük és azt, hogy haladunk az önvezető autók felé (nem mondom, hogy túl gyorsan, de haladunk), egyre több és több szenzor információit kell egy időben feldolgozni. Ezekre már nem lehet felírni még bonyolultabb függvényeket se. Egyszerűen olyan nagy számú bemenet van, ami szinte felfoghatatlan mennyiségű kimenetet képes előállítani (És az autós példánál nem csak egy kimenetet szeretnénk előállítani, hanem szintén többet (kormány, fék, gáz, stb.)). Itt megint ott tartunk, hogy neurális hálókat nem fogunk tudni assemblyben létrehozni, magasabb absztrakciós szintre kell emelni.

A hibákhoz és a frissítéshez még annyit fűznék hozzá, hogy régen is voltak hibák, csak akkor még esély sem volt kijavítani. Másfelől egyetértek, hogy csábító lehet annak a tudatában kiadni valamit, hogy majd úgyis kijavítjuk később...

Lezárva, azt érzem, hogy többen ragaszkodtok a régebbi technikákhoz, technológiákhoz, de ismét kiemelném, hogy mindent a maga helyén kell kezelni. Se a régi se az új nem rossz.

Sziasztok!

Ebben neked igazad van. De az én véleményem az, hogy vannak olyan területek, ahol nem szabad túlzásba vinni az elektronikázást.
Ilyen pl. az autóipar. Már lassan bonyolultabb, komolyabb számítógépek lesznek egy autóban, mint egy repülőben. Csakhogy, míg egy repülőben minden rendszerből több van, azaz ha egy meghibásodik a másik átveszi a helyét, ráadásul bőségesen van idő adva a fejlesztésekre, a programokra, a tesztelésekre, addig az autóknál ez nincs így. Belegondolva, hogy a légi-katasztrófák nagyrészt a technika hibájából adódnak annak ellenére, hogy tényleg mindent megtesznek a mérnökök, kissé tartok az autóelektronikától. Mindemellett a mai autók a mi érdekünkre hivatkozva döntenek helyettünk. Pl. a BMW jelzi, hogy szervizintervallum van. De nekem halaszthatatlan dolgom van az ország másik végében, jobb ha kölcsönautóval megyek, mert a hiper-szuper BMW félúton megtagadhatja az utazás folytatását. Megtörtént eset ismeretségi körben. Vagy vagyok olyan rutinos sofőr, hogy gyufásdoboznyi helyre is be tudok állni, de a parkolóasszisztens nem engedi. Autókban már jó pár éve van ráfutásgátló rendszer. Ami esetenként még jó is lehet, ha elbambul az ember. Ám ha előzni készülök és ezért rágyorsítok az előzni kívánt jármű mögött, hogy amint a szembejövő elsuhant, már lendületből előzhessek, és a komputer befékez, epét hányok. Ugyanez a rendszer újabban bekerül már a motorkerékpárokba is. Csakhogy a motoros egy ilyen helyzetben akár fel is bukhat.
Egyetértek veled abban, hogy millió soros assembly programot egyszerűen lehetetlen írni, de olyan eszközökbe, amiken életek múlhatnak, olyan programnyelven összetákolt szoftvert tölteni, aminek a belső működését, esetleges hibáit nem látja át a fejlesztő, nagyfokú felelőtlenség.

Itt még egy gondolatot hozzáfűzök ehhez, ezután lezárom, nem szeretném túlhúzni a dolgot:
Igazad van, sok esetben szükséges hogy megbízható legyen egy-egy rendszer, de ezek már tényleg olyan komplexek, hogy nem lehet ennyire hardver közelien kezelni.

A repülőről a Boeing 737 MAX jutott eszembe, ez a duplázás se jön össze mindig. Amíg ember tervezi, hibázni fog...

Visszatérve a autóipari biztonsághoz: Érdemes rákeresni az ASIL rendszerre. Ha megnézed a különböző kockázatú rendszerek különböző besorolást kapnak. A a legkisebb kockázatú, D a legnagyobb. Ami képes befolyásolni a jármű irányát, sebességét, stb., tehát aktívan beleszól a vezetésbe, azok mind D, esetleg C. Én is az autóiparban dolgozok (nem ezért védem, azért ott is látni cifraságokat), és meg kell mondjam, a D elérése azért nehéz. Ebben rengeteg követelmény van, kockázatelemzéssel és nem utolsó sorban a minőségellenőrzés ahogy haladunk a D felé, egyre durvább. D-nél mindennek is le kell dokumentálva lennie (kis túlzással persze) és a teljes fejlesztésnek D ként kell folynia, nincs az, hogy elkezdjük A-ban, majd a végére rájövünk, hogy milyen jó kis termékünk lett, dobjuk ki D-ben, így több lesz a pénz...

Sziasztok!
Valahogy megmaradtam, a PIC assembler programozásában, nem váltottam át C-re, és az PMLAB-X-re. Az MPLAB 8.92 verzióját, és a PICKIT3-at használom. Most viszont szükségem lenne a PIC18F27K42, nagyobb 128k program memóriájú típusra, de sajnos az MPLAB ezen verziója nem ismeri, nincs ilyen .inc file. A Microchip oldala annyira megváltozott a váltás óta, hogy semmit nem találok, még az MPLAB letöltésket sem, gyanítom, hogy nincs is már...
Azon kivűl hogy áttérek az MPLAB-X-re, szerintetek mit lehet tenni?

Nem sok lehetőség maradt:
Idézet a mplabx-ide-v5.25-release-notes-00.zip -beli Readme for MPASM Assembler.htm -ből:

Mostanában az MPASM helyett a Pic-as nevű képződmény van assembler helyett.

Az egyedülálló út a Microchip szerint a C, az XC8. Az is leginkább a bérelhető optimalizálással.

Szia!
Több okból én is assemblyben fejlesztek, de váltottam, a PIC-ek helyett az ST processzorait használom. Itt is elég rögös az út, de mind a 8 bitesek, mind a 32 bitesek esetében végül is járható. Van a 8 bitesek között is 128kB flashes is, bár valószínűleg nem csak ez a szempont a választásnál.

Azert egy darabig kell kalapalni a billentyuzeten mire megtoltesz 128k-t assembler-ben
(Persze nagy statikus adattablakkal mas a helyzet)

Attól függ, honnan indulsz. Ha valaki már egy ideje fejleszt egy kontrollerre/processzorra, rendelkezhet olyan szubrutin, vagy makrókészlettel, ami sok memóriát igényel. "Magas" szintű nyelven sokkal kevesebb kalapálással, hamarabb el lehet jutni ebbe az állapotba. Mindez csak gazdasági kérdés - mennyi idő van egy feladatra.

Ezert irtam, hogy assembler-ben. Par k program memoria folott (feladattol fuggoen 4k-8k folott) en mar C-t hasznalok, mert a meret mar kevesbe nyom a latban, mint a fejlesztes sebessege. De izlesek es pofonok

Nálam 5.30-as MPLAB X van fent, ebben benne van a MPASMWIN.EXE, nem tudom az újabbakkal mi a helyzet.

Itt mpasmx\mpasmx.exe néven van és támogatja a PIC18F27K42-et. Ezt az egész könyvtárak akár vissza lehet másolni a MPLAB 8.92 alá a MPASM Suite könyvtár tartalmát lecserélve, csak vissza kell nevezni MPASMWIN.EXE-re. Ez alatt vannak a .inc file-ok is, így az is lenne. (Próbáltam működik a fordítás vele 8.92 alól olyan PIC-cel amit a 8.92 támogat.)

De hiába az új fordító, ettől még a 8.92 nem fogja ismerni az új eszközöket, csak a korábbiakat lehet az új fordítóval használni ...

A 8.92 az MPLAB IDE\Devices alatt tárolja az infókat a támogatott eszközökről a *-.dev file-ban. Ilyet lehetne csinálni valami hasonló eszköz lemásolásával és megszerkesztésével, de ez kevés, mert a támogatott eszközök listáját a *.mmc fileokból (masterdb.mmc és 18bridge.mmc) veszi, amik meg binárisak, azokat nem tudod szerkeszteni.

A korábbi MPLAB verziók még mindig letölthetőek a Microchip oldaláról. Minden régebbi verzió elérhető ITT: Downloads Archive

Az aktuálism MPLAB X IDE meg ITT

Sziasztok!

Sürgős segítségre lenne szükségem.
Én eddigi PIC-es pályafutásom során mindenféle kommunikációt, (I2C, SPI, UART, 1 Wire) kizárólag szoftveresen oldottam meg. Most először adódott úgy, hogy a PIC "nem ér rá" foglalkozni az adatok vételével. Arra lenne szükségem, hogy a hardveres UART folyamatosan figyelje, jön-e adat, ha igen, fogadja, váltson ki egy megszakítást, melynek során kiveszem belőle a beérkezett adatot, majd figyelje tovább az adatvonalat. Megpróbáltam önerőből az adatlap alapján megfejteni, de a szinte nulla angol tudásommal ez nagyon sokáig tartana, nekem pedig sajnos erre a projektre borzasztóan kevés időt adtak.
Ha valaki megtenné nekem, hogy leírja mit hogyan kell beállítani, mi az útja-módja az adatok kinyerésének, mindezt assemblyben, nagyon megköszönném.
A PIC típusa 18F14K22
Az órajel PLL-el 64MHz, az UART adatsebessége 115200.
Segítségeteket előre is köszönöm.

Itt Írtam erről.

Ne haragudj, de ezzel nem vagyok előrébb.
Azt sem tudtam eddig kihámozni az adatlapból, hogy hogyan kell inicializálni az uartot.

Küldök egy PÜ-t.

Bár nem PIC-en, de ráfutottam olyan problémára, hogy nem volt elég idô "jókor" feldolgozni a vett soros adatcsomagot (tehát volt idô amikor ráért a uC, de nem akármikor, a soros adat meg ugye akármikor jöhet). Erre én beépítettem egy újabb uC (vagyis egy Arduino Nano) ami csak bufferelt, és amikor a fô uC üzent (egy lábon, H/L) hogy ráér, akkor küldte ki amit addig kapott. Csak egy ötlet, ha van holtidô a porgramodban, és van még egy kis hely a projekt dobozában, lehet így is.

Uart inicializálás:
1. Sebességból osztás számítása:
64000000 / 4 / 115200 = 138.88 Kerekítéssel 139. 64000000 / 4 /139 = 115107,91
Eltérés számolása (115200 - 115117) / 115200 = 8.07E-4 azaz 0.0807 %

2. SPBRG, SPBRGH felprogramozása:
SPBRG = 138
SPBRGH = 0
BAUDCON = 8 ; BRG16
TXSTA = 4 ; BRGH

3 UART engedélyezése:
RXSTA = 0x90 ; SPEN | CREN

Ettől a pillanattól kezdve a UART a PIR1 regiszter RCIF (5) bitjének 1 értékével jelzi, ha vett karaktert.

Köszönöm.
Ezekre rákerestem, és ez így világos.
Remélem sikerül alkalmaznom.

Ezt nekem egyben kell valahogy kezelnem, mert közel 500 byte adat jön kb 30msec alatt.
Az összes feldolgozása kb 5 msec. Utána gyakorlatilag várakozik a PIC. A baj csak az, hogy két adatcsomag között mindössze 200usec a szünet. Tehát miközben az előzőt feldolgozom, javában jön az új.

Ennyi adathoz biztos PIC kell? Nekem soknak tűnik az adat.

A 115200baud az kb 10kByte/sec sebesség. Ez még szerintem simán feldolgozható ha megszakításban körpufferbe rakod a vett adatokat. Mondjuk asm-ben sosem csináltam ilyet, csak C-ben.

Pic32-n úgy csináltam, hogy 2 puffer van, amíg az egyiket töltögeti a megszakításban, addig a másik feldolgozása lehet (nálam kiíródik SDkártyára) Az adat folyamatosan dől a soroson igaz, csak 9600baud. Illetve időnként van GPS óraszinkron lekérdezés másik soroson, harmadik pufferba

Nem nagyon értek a PIC-ekhez, de rákerestem, és az adatlap azt írja, hogy 512 bájt RAM van ebben a csipben: https://www.microchip.com/en-us/product/PIC18F14K22

Ebbe egy puffer fog beférni csak, két puffer már nem.

Csak úgy lehet megoldani, ha vétel közben párhuzamosan dolgozod fel az adatot, és csak annyit tárolsz, amennyit muszáj. Vagy cipőkanalas megoldásokat még el lehet képzelni, hiszen ha a vétel után egyből feldolgozod az adatokat, akkor csak 5ms ideig kell áthidalni a tárolási problémát, ami csak 83 bájt. De így is több lehet összesen, mint 512 a pontos számok fügvényében.

Ráadásul ha kicsit is komplexebb a programod, akkor a változóknak is kell hely a RAM-ban.

Megoldás lehet, ha érkezés közben párhuzamosan fel tudod dolgozni az adatot. És akkor a küldési ciklus végére már jóformán el is lehet dobni a puffert. Vagy akár nem is kell tárolni, ha olyan jellegű a feldolgozás, hogy csak kiszedünk valami információt a blokkból. Ezt nem is ördöngősség megvalósítani, feltéve, hogy nem olyan a dolog logikája, hogy az első bájtokat csak az utolsók tükrében lehet értelmezni. Jópofa feladat, de felesleges bonyolítás.

Ha a párhuzamos feldolgozás akadályba ütközik, vagy csak jövőálló megoldás kell, akkor legalább 1kB de inkább 2kB RAM-mal rendelkező csipre kell upgradelni, hogy elférjen két buffer plusz a munkaváltozók.