Elindul, ha szerencséd van és épp nincs semmi a közelben, ami felhúzná az MCLR potenciálját 8-9V fölé.

Arra.

Szia!

Ilyen alapon a PIC10F200T-I/OT 87 Ft + Áfa) helyett használjak PIC18F23K20-I/SS (330 Ft + Áfa), mert egyszerűbb, kényelmesebb a programozása? A 10F200 is megoldja a problémát. Minkettőben van belső oszcilátor is. Ha 5V -os típust választottam volna, az ár arány még rosszabb lenne...

Nem, ellenkezőleg, én is inkább a legkisebbe próbálom mindig belepréselni, abban van kihívás. Én csak arra válaszoltam, hogy az ugrótáblázat kezelés 18F-en másként oldható meg, mint a 16F és kisebbeken, és hogy ebből a szempontból nem hátrányosabb a 18F. C-ben meg tökmindegy, a fordító megoldja, nekem csak meg kell adnom a tömböt.

Hat igen, egy ilyet probaljon meg valaki 18F-el csinalni

(Igen, az a kis fekete valami a kozepen a 10F202)

Kicsit félresiklott a vita,mert nem az a lényeg, hogy mit miért gyártanak, vagy mit mivel gazdaságos megoldani (az iparban!), csupán arról volt szó, hogy a PIC18 vagy PIC24 esetleg könnyebben tanulható egy kezdőnek, kevesebb vele az értelmetlen szívás a lapozással meg a konzisztens gyári C fordító hiányával.

Külön bosszantó ugyanis, amit a szoftverfejlesztők művelnek: Tegnap pl. a Hi Tech fordítóval szenvedtem egy sort, s véletlenül sem sikerült lefordítani egy korábbi változatához írt programot, mert a regiszterek neveit teljesen értelmetlenül átnevezgették a gyári header állományokban. Emiatt a közeljövőben nem fogok bele olyan projektbe, ami a HiTech-re alapozna.

igen, errol mar volt szo korabban / mostanaban. Azt hiszem nem tett nekik jot, hogy a Microchip felvasarolta oket... Amugy nem neztem meg, de vajon C18 regiszter elnevezeseit / konvencioit probaljak raeroltetni?

Igen félresiklott...

A válaszom erre irányult:

Idézet:
„Balagemann, ha rám hallgatsz, akkor a 16-os sorozat helyett a 18-ast választod. Árban nincs nagy különbség de a tudása, szolgáltatása, programozása sokkal jobb. Kezdve azzal,hogy van benne oszcillator, tehat elvileg egy db ellenállással mar elindul.”

Az indok nem jó! Hogyan is lehetne egy 6 lábú kontrollert használni, ha nem lenne belső oszcillátora (1 táp, 1 föld, 2 quartz: ez már 4 láb - akkor csak 2 marad... Ha még a MCLR is dedikált láb lenne, egy maradna - UNIIO még szóbajöhetne ...)

Tudom, hogy 18F programozása kényelmesebb...

Kezdőknek azt ajánlanám inkább, hogy egy családot ismerjen meg - mindegy melyiket - lehetőleg alaposan... Egyszerre több család megtanulása nehézkes, mert nem egyformán működnek sem a hardware sem az utasítások (decf, incf, rrf , rlf stb - utasítások statuszbit állításai). Elég sok idő telt el, amig kezdőként kinőttem a 2K page határt. Pont azoknak írtam meg a cikket, akik eljutottak idáig. Sok-sok 16F futtat néhány 10 .. néhány 100 soros programot...

@potyo: Én is szeretem a kihívásokat - egyetértek, hogy ki lehet hozni a maximumot egy kis kontrollerből is.

Nem tudom, én a PIC12/16-os verziót néztem, s ilyenekbe botlottam: OPTION helyett OPTION_reg, GODONE helyett GO_DONE. Mire ezeken túljutottam, jött 10 másik hiba, s akkor sürgősen abbahagytam.

Ezzel maximálisan egyetértek.

Ehhez hasonlók vannak assembly include állományokban is - főleg a konfigurációs biteknél, de akad máshol is.

16F628(A): T0IE, T0IF - 16F88: TMR0IE, TMR0IF
16F628(A): _MCLRE_OFF - 16F88: _MCLR_OFF
16F628(A), 16F88 _BODEN_ON - 16F690: _BOR_ON

Mindig az adatlaphoz próbálják meg igazítani - néha nem sikerül: ld. "Readme for MPASM Assembler.htm" "Repairs and Enhancements Made Since v5.30" bekezdését. Megmosolyogtató dolgokat lehet olvasni:

Sziasztok!
Kb. egy év után megint érdeklődök a 18F-es szériánál lévő "Táblaművelet" iránt (TBLRD*).
Már nagyjábból minden világos, csak magának az adatnak a letárolása nem.
Ebben a hozzászólásban a

részre lennék pontosabban kíváncsi... mert nem teljesen látom át, az MPLAB Disassembly ablakát se.

A csatolt képen lévő kódban csak úgy beírkáltam értékeket, és nem értem hogy minek vannak ott azok a NOP-ok, meg miért csak 1010-ig tart a kód, amikor 18byte adatot foglaltam le?
Szerk.: ja és egy sorban nem fér el sok adat, szóval mondjuk ha 250 byteot akarok beírni, akkor hogy kell több sorban leírni? Minden sor elé rakok egy "DB"-t, és utána mehetnek a byte-ok?

Valójában 1000-tól 1011-ig tart a kód, mert a következő cím, amit kiírna ott balról, az az 1012. Így viszont pontosan 18 bájt van.

Ami engem jobban zavar, hogy hová lett a 0xFC? Gyanús, hogy nemjó ablakot nézel, mert ezek ugye nem utasítások, viszont a Disassembly listing megpróbálja annak értelmezni. Ezért inkább a View->Program Memory ablakban keresd az adataidat.

Illetve nekem úgy rémlik, hogy a programmemóriában DT-vel kellene az adatokat elhelyezni, nem DB-vel. De lehet, hogy tévedek, mindenesetre egy próbát megér, ha valami úgy tűnik, hogy nem stimmel.

Kicsit utánanéztem az MPLAB helpjében, és a DT-t a 12/16F-es PIC-eknél szokták használni (a képen is látható, ez a RETLW-s módszer..)
Ír a DB-ről is, de persze azt úgy hogy ne értse meg egykönnyen az ember, de megpróbálom értelmezni.
(Lehet hogy ezt a DB-s részt a disassembly nem tudja máshogy megjeleníteni?!...)

Megvan!
Csak sikerült rájönni.
A DB-nél azért írta ki a NOP-okat, mivel a 2. oszlopban az utasítást írja ki hexa kódban (vagyis a címét..), illetve az operandus értékét "csapja hozzá".
A kép elárul mindent.

Sajnos csak egy pár számmal működik, aztán gondol egyet és valami mégse jó.
Ez nekem magas.

Vagyis csak akkor van baj, ha több, mint 30byte-ot szeretnék beírni.

Hali!
Fontos, hogy az adatok ne lépjenek át laphatárt!
azaz az összes adat 0x00 és 0xff területen legyen, vagy
0x100 és 0x1ff területen. Ha laphatárt átlépi az adat, akkor nem lesz jó a beolvasás.

Ezt azthiszem írja az MPLAB helpje, de köszi hogy írtad!
Viszont! Ha egy többsoros kódrészletet másolok és beillesztek, akkor meghülyül, de ha csak egy sort, akkor meg jó. Eddig ez a legmegmagyarázhatatlanabb dolog, amit tapasztaltam az MPLAB-ban. Így jár az, aki mindent tudni akar.

Szia!

MpLab + 18F assembly adatmegadásnál ügyelni:
- minden sorban kizárólag páros számú byte -ot megadni - ha páratlan számút adsz meg, kiegészül egy 0x00 -van (nop) ...
- a sorban ne legyen láthatatlan karakter (TAB lehet)... A több soros beillesztésnél lehet, hogy ez a hiba.

Akkor már érthető miért bolondult meg, nem tetszett neki a delphis sortörés...

Az Enter kódja egymás után a 13, 10 kódok (decimálisban), és én a delphis programban csak a 13-at írattam ki, de most hogy a 10-et is beszúrom, elfogadja az MPLAB.

Szia!

Akkor volt promlémám, amikor egy web lapról unikódos szöveget másoltam be...

Ebből az ENTER csak a 13. A 10 a CL (soremelés, kocsivissza)

Pontosítok:

13 - kocsi vissza (CR, Carriage Return) Bővebben: Link
10 - soremelés (LF, Line Feed) Bővebben: Link

Az MS-DOS és ennek nyomán a Windows a CR+LF karakterkombinációt használja a sorvége jelzésére. Máshol ez nem így van. Pl. Unix/Linux esetében csak 10-es kód áll a sorok végén (ami ott NL, azaz Newline karakter). Macintosh gépek használóitólkapott fájlokban pedig csak 13-as kódot találunk a sorok végén.

Enter kód szerintem nincs, csak Enter billentyű!

Amugy a Macintosh-ra sem igaz mostmar ez a CR dolog. Ugyanis a MacOs X mar BSD (Unix) alapu, igy mar ott is az LF a sorvegjel. Amugy a Macintosh elott az Apple mar alkalmazta a CR-t mint sorveg jelet az Apple I-tol kezdve, ami ugye vegig vonult a II-es sorozat es utana a III-as es a Lisa modellekben is. A valasztas logikusnak is tunt, mivel egy irogepen is a 'kocsi vissza' jelenti az uj sort. Csakhat mivel a Unix teret hoditott (ugye az okos telefonjainkban is Unix fut), az abban alkalmazott LF jobban elfogadott manapsag.

Amugy ezek miatt eleg nagy kavarodasok szoktak lenni. Pl mail szervereken rendszeresen latni meglehetosen fura sorveg jelzeseket, es azokat csak eleg bonyolult modon lehet kiszedni. Pl a level jon egy Windows kutyubol, az ugye belerak CR+LF-et, es utana egy Linux-os MTA racsap LF-eket. ugyanezt lattam mar forditva is. Es akkor dontse el az ember 1 vagy ket sorelvalasztasnak kell ott lennie (ami neha nem mindegy, mivel a fejlec es a level torzse ket vagy tobb sorelvalasztas valasztja el egymastol -- vegulis egy ures sor).

Jaj, köszi! Fordítva írtam!

Hát, ez filozófia. Enter billentyű ASCII kódja a 13...

Így a legegyszerűbb leírni. Mármint hogy "Enter kód".

Idézet:
„Hát, ez filozófia.”

Az bizony! Mert amit Enter gomnak gondol a mezei halandó, az valójában a Return key, az Enter gomb pedig a numerikus billentyűzet adatbeviteli gombja (jobb alsó sarok).

Volt már szerencsém(?) olyan alkalmazáshoz, ami funkcionálisan különbséget tett közöttük, tehát nem volt mindegy, hogy melyiket nyomtam.

És még ilyen vonatkozásban abszolút igazad is van!

Ehhez a filozofalgatashoz meg azt is hozza tehetnenk, hogy ugye van a TAB billentyu, ami egy "--->|" jel, ugyanazon a billentyun egy "|<---" jel is lathato. Joggal feltetelezhetjuk, hogy ez a back-TAB. Namost a TAB karaktert megtalaltam az ASCII tablaban, de a back-TAB-ot sehogy sem...