4-5. oldal

6. műanyagház: No

Ezt kifejtenéd bővebben? Nem érint a dolog, inkább csak kíváncsi vagyok, miért.

A te linkeden. Tekerd lejjebb azt a lapot

Az NXP minősített mikrovezérlőket ad, felhasználhatod veszélyes üzemi környezetben is. A Microchip nem.

Üdvözlet mindenkinek!

Problémába ütköztem és a segítségetek szeretném kérni. Jelenleg egy rádiót építek. Egy régi autórádióból kiemelt tuner modult, hangszínszabályzót és végfokot tartalmaz jelenleg. Ezek I²C-n kommunikálnak a PIC16F887-el. A programot assembly-ben írtam, a kód szerencsére tökéletesen működik, ám a 8192 utasításnyi memória elfogyott. Ezért elhatároztam, hogy PIC18F4520-ast fogok használni. Amennyire utánanéztem, úgy ítéltem meg gond nélkül kellene futtatnia a 887-re írt programot.
Eddig ezeket csináltam meg 4520-nál:

1. átírtam a konfig biteket az adatlap alapján
2. ahol írni kell a portra ott lat-ot használtam (887: BSF PORTB1 --> 4520: BSF LATB,1)
3. kiszedtem a fölösleges LCALL, LGOTO illetve PLCATH,3 és 4 bit beállításokat
4. adatlap alapján átírtam az EEPROM írási és olvasási szubrutint
5. magas és alacsony prioritású megszakítási helyek definiálva a programban (mondjuk nem használom egyiket sem)
6. sima HS konfig bit beállítás mellett 16MHz quartz-nál, PLL szorzó kikapcsolva is brutális gyors a PIC (lehet az időzítési szubrutinokat sem kezeli rendesen...)
7. a konfig biteknél letiltottam a bővített utasítás készletet (PIC16F "örökség" mód)

Igazából a kérdésem az lenne, hogy a 4520-asnak tudnia kellene maradéktalanul futtatni a programot vagy elfelejtek valamit (még szóba jöhet a PIC16F18877 is, de az csak akkor, ha ez nem képes rá)
Mutatok képet, így néz ki jelenleg

Nem:
RAM: ACCESS bank és a lapozott (BANKED) memória elérés, nincs a STATUS regiszterben IRP, RP1, RP0 bit, helyettük az FSR2..0 12 bites és a BSR regiszterrel lehet a bankot kiválasztani.
Táblázat olvasás, kiszámított ugrás (PCL írása).
Egyes utasítások más jelzőbiteket is : decf, incf, rlcf, rrcf, rlncf, rrncf
Kivezetése analóg / digitális módjának beállítása, A/D és komparátor beállítások.
Megszakítás kezelés több regiszterben.

Ez sem képes rá:
RAM: Nincs a STATUS regiszterben IRP, RP1, RP0 bit, helyettük az FSR1..0 több, mint 8 bites és a BSR regiszterrel lehet a bankot kiválasztani.
Kivezetése analóg / digitális módjának beállítása, A/D és komparátor beállítások.
Megszakítás kezelés több regiszterben.

Ha asm-ben elfogyott a 8k utasítás hely, akkor pontosan abba a problémába szaladtál bele, amiért valaki kitalálta a 32 mini boardot. Ha a környezet 3.3V (a pic is azon futott), és nem használtad az eepromot a pic16-oson, akkor legalább a hardver környezetet nem kell újraépítened. Mert egyéb iránt az vár rád. Kellemetlen tud lenni utólag, ha nem gondoltál jó előre a fejlesztési erőforrás tartalékra.

Köszönöm a válaszod, akkor úgy néz ki marad a 887-es.

Köszönöm a válaszod, eleinte elég volt, csak, ahogy telt az idő jöttek az ötletek miket kellene beletenni és hipp-hopp elfogyott a szabad hely. Egyébként működik a dolog így is, szerencsére nem sok mindent kell kihagynom. A rendszerem 5V-os. Ez a miniboard nem is rossz dolog, kár, hogy nem tudok PIC32-őt programozni, de utána nézek a dolognak.

Hi Mesterek!
Önjáró ki robotot akarok építeni. Tárgy érzékelésnek ultrahangos szenzort akarok használni.
Viszont elvesztem a kínálatban. Szerintetek melyik a jobb választás a robothoz.. Azaz melyik mire való, s melyik lenne nekem megfelelőbb? PIC-el szeretném lekezelni. Segítséget előre is köszönöm.

Azok ott annyira olcsók, hogy akár vegyél egyet mindegyikből, és próbáld ki mindet

Ha most kezdenél a 32-vel, annyi a titok, hogy előbb a 32mx-el ismerkedj, használj régi mplab-ot, c32 fordítót, és a legacy mla-kat. Nézd meg azokkal, hogyan jön össze egy project. Csak utána próbáld ki a 32mz-t, xc fordítót, harmony-t. És ha végül lesz egy olyan meglátásod, hogy egyenlőre még adnál a 32mz családnak egy kicsi időt fejlődni, és addig maradnál az mx családnál, csak hogy tudd, nem leszel egyedül azzal a meglátásoddal.

Az US-016 Sensor analóg kimenetű, a HC-SR04 Sensor pedig egy változó szélességű digitális jelet ad. Te tudod, hogy számodra melyiket kellemesebb fogadni. A másik három vízálló kivitelű érzékelőt használ (gondolom, erre itt nincs szükség).

Köszi a tippeket, de még nem tudom mikor állok neki, egyelőre ezt a projectet akarom befejezni. (Egyébként az időzítési problémát sikerült megoldani)

Nem vitatom, hogy igazad van, csak kíváncsi vagyok, miért először a régi fejlesztő környezet, régi fordító? Mondjuk nálam ez nem jön össze, bár kezdőnek tekintem magam, csak mióta nyögdíjas vagyok, nem bosszantom magam a PiciPuha rendszereivel. Linuxra meg MPLAB-X van. Így is lehet használni az MX-hez a legacy libraryket.

Az x környezettel sokkal több fejfájás jött be, mint amit egy windows 7 "olcsón beszerzése" jelenteni tud. Persze én a világért meg nem tiltanám senkinek, hogy mazochista akarjon lenni, de aki mégsem akar az lenni, annak felírtam egy javaslatot.

Egy napon majd kiforrott lesz az x is, de ahogy a híreket figyelem, még nem az jön le, hogy végre felhasználóbarát lett az x. Részemről az első komoly próbát akkor fogom tenni vele, amikor open source lesz a harmony.

A régi fordítókból volt linuxos változat is, igaz, a parancssori használatuk nem leányálom.

Értem! Ti a window$-al szo***tok magatokat, én meg az X-el.

Mod: Kérjük, a trágárságot a jövőben kerüld.

Köszi, de én csak hobbizgatok, megvagyok az X-el. Nem riadok vissza egy kis parancssori munkától, de ha van GUI, inkább azt használom. MX170-el és 250-el játszogatok.

Egy darabig zavart, hogy a szerkesztés közbeni szemantikai ellenőrzése hibás, kielégítetlen hivatkozásokat jelez, holott nem azok. De megszoktam, a fordításkor ezek természetesen rendben vannak.

A másik, amire még nem tudtam rájönni, hogy mit csinálok rosszul, talán csak egy hibás, vagy elmaradt beállítás. Ha a main-be az osztályaim "h" file-ját includolom, kielégítetlen lesz a hivatkozás. Ha a "cpp"-t, akkor jó. Tettem már régebben ide föl mintát, de az feltételezem, hogy hibátlan volt, mert semmi reakció nem volt rá.

Köszönöm a segítséget .

Elakadtam, a segítségeteket kérném az alábbi problémában:
A dsPIC33EPxxGS50x programozási leírásában (ugyan a B verzió még utasítás címeket hasznát és érthetőbb volt) szerepelnek a memória térképek. A dsPIC33EP64GS506 memória térképén (2-9 ábra) single partition módban és utasítás címeket használva 0xAF80 -ig a user, 0xB000 -ig a konfigurációs regiszterek vannak. Dual partition módban csak 0x5780 -ig van a user memória és 0x5800 -ig a vannak a konfigurációs regiszterek.
Lapozzunk a 7.3 fejezethez. A dual partition módot az alábbiakat végrehajtva állíthatjuk be:

Eddig stimmel. A lépések leírásánál 7.4 (Programming in Dual Partition Mode) az 5. pontban nem tudom, hogy jön ki a 0x0AB94.

A teljes program és konfigurációs memória 0x5800 címig tartana dual partition módban. A másik ugyan ekkora rész a törlés után címfolytonosan érhető el. Az "alsó" (majdani aktív) partíció esetében az FSIGN konfigurációs regiszter a 0x5794 címen van. Úgy gondolom, a "felső" (majdani inaktív) partícióban egy partíció méretének megfelelően eltolva (címben feljebb tolva) kellene lennie. 0x5794 + 0x5800 nekem mindig 0xAF94 lesz, akár hogy számolom. Hogyan jött ki a 7.4 pontban, az 5. lépésnél szereplő 0xAB94?

Hogy még érdekesebb legyen a probléma, a dsPIC33EP64GS708-33EP128GS808 programozási leírásában nemes egyszerűséggel ugyan ez a cím olvasható a 7.4 bekezdés 5. pontjában függetlenül attól, hogy mekkora is a programtár? (dsPIC33EP64GSxx vagy dsPIC33EP128GSxx).
Továbbá, a dsPIC33CK leírásában a 6.4 (Programming in Dual Partition Mode) már nem szerepel cím.

Milyen címet kellene ezeken beprogramozni?

Az a fránya 0xAB94 még működik is a dsPIC33EP64GS502 esetében.

Eljött a nap, amikor az MPLABX-el AVR-eket lehet programozni: Bővebben: Link

Én az M helyében fordítva csináltam volna, az Atmel Studio-ba pakoltam volna az X-et...

Párszor már rákerestem az Atmel Studiora, de mindig azt láttam, hogy csak a PiciPuha oprendszerére létezik. Ilyet én már 9-10 éve nem használok, és biztosan nem vagyok egyedül.
Így aztán marad az X.

Én soha nem használtam vindózt, és 2001-től 2010-ig fejlesztettem AVR-re. Nem kell hozzá semmiféle stúdió meg mplabx. Ingyenes avr-gcc (minden optimalizációs szinttel), ingyenes jEdit, unix tool-ok (pl. make) meg egy egyszerű házikészítésű programozó. Még X (értsd: X Window System) sem feltétlenül kell, ha megelégszik az ember a Midnight Commander beépített editorával vagy a nano-val a jEdit helyett.

Bevallom, nem nagyon hiányzott. Arduino lapokkal játszottam, arduino IDE teljesen elég volt.

Ha már felvásárolták, illik fejlesztői környezetet is adni. Számomra logikus, hogy a több platformosat viszik tovább.

Ha úgy vesszuk, akkor ez előrelépés, mert eddig grafikus IDE nem volt Linux-ra AVR-hez. Csak nem tudom, hogy az MPLAB-X mennyire jó választás, mert azt még a megrögzött MC pártiak is szidják rendesen. De nincs összehasonlítási alapom, mert sem az AVR studiot sem az mplab-x-et nem ismerem. De az biztos, hogy AVR-re eddig is lehetett fejleszteni Linux-on, ehhez nem kellett sem avr studio, sem mplabx.

Persze java fut mindenhol de a JVM megeszi a gépet egy nagyobb projektnél - egy megoldás van ami ram slot van a gépbe abba ramot raksz
(+ ha van elég a *.conf file-t át kell írni hogy sok ramot használjon onnan kényelmesebb már)

Én 8GB-val nem bírok vele az elkövetkezendő hetekben újítok pont-e miatt.

Míg a VS el van magával és sokkal fejlesztő barátabb mind a netbeans (szerintem).

Rengeteg funkció ami az X-ben van nem a kis fejlesztésekhez lett kitalálva és nem feltétlen C-hez.
És hát ha sok soruce van sok 1000 sorból áll a kód akkor már nem olyan egyszerű egy text editorral dolgozni.