HTML

Műszer

Hobby és amatőr elektronika, műszerépítés a XXI. században

Címkék

Friss topikok

  • Nite: @fromi: Ha egy bejegyzéssel kapcsolatos kérdésed van, akkor jobb odaírni kommentbe, mert esetleg m... (2010.11.26. 15:17) FAQ

Licenc

Creative Commons Licenc

Microchip C18 kódok szerkesztése Visual Studio-ban

Nite 2010.01.21. 10:46

 Nagyon kedves dolog a Microchip részéről, hogy a saját PIC-einek programozásához ingyenes fejlesztőeszközt biztosít, ráadásul primitív szoftveres emulátorral, ami segít az egyszerűbb kódokat debugolni. Sajnos az MPLab IDE nem a fejlesztők álma, kód szerkesztési képességei körülbelül a notepaddal vetekednek. Ezzel szemben ott van a Visual Studio, amiből fellelhető nem egy ingyenes verzió is, és az intuitív felhasználói felület koronázatlan királyai (na jó, legalábbis az apple után másodikok) készítették. Nagy kár, hogy a VS-t nehezen lehet rábírni PIC gépi kód fordítására, ráadásul a Microchip C18 a VS-től eltérő tájszólásban beszéli a C-t, így a források szerkesztése sem triviális.

 A Microchip fórumán fellelhető egy VS Wizard, ami az MPLab projekteket hivatott átkonvertálni VS-hez, de nekem valamiért nem működik, és mivel nem értem mit csinál meg sem tudom javítani. Ennél egyszerűbb útnak ígérkezett egy saját megoldást készíteni, amit itt most mindenki okulására meg is osztanék.

A problémát érdemes két részre osztani, egyik a forráskód szerkesztése, másik a fordítás. A kód szerkesztéséhez a VS-t fogjuk használni, és amikor elégedettek vagyunk vele, ráuszítjuk az MCC18 fordítót hogy a Hex fájlt előállítsa. Persze a cucc le fog fordulni a VS alatt is, szépen x86 procira, úgyhogy azzal semmit se fogunk kezdeni azon kívül hogy örülünk hogy nincs hiba a kódban. Ha valaki debugolni szeretne vagy ICE-t használni, akkor meg elvileg a kód visszatölthető az MPLab-ba, és hadd szóljon.

Szóval első lépés, hogy a tájszólásbeli különbségeket kicsit lecsökkentsük. Ehhez a near, rom, far, auto, long típusokat felül kell definiálni, a legtöbbet ráadásul semmivel, mivel hasonló fícsör nincs a VS-ben:
#ifndef __18CXX

#define near
#define rom
#define far
#define auto

#define long int
#define __18F2455

#endif
  Ezt egy mscext.h fájlba belementjük, majd az összes c fájlunkhoz beinclude-oljuk. Látszik, hogy ez az egész csak akkor lesz érvényes, ha a __18CXX nem definiált, vagyis ha MCC18 fordítóval fordítjuk, az ezt átugorja.

A következő lépés kicsit fájdalmasabb, sajnos a VS nem kezeli a bináris számok megadására használt 0b01010101 formátumot, így ezeket mindet át kell írnunk hexára vagy decimálisra. Kísérleteztem pár megoldással, de nem sokra jutottam, úgyhogy akinek van erre ötlete, az ne habozzon megírni.

Hasonlóan nem tud mit kezdeni a VS az _asm, _endasm szófordulatokkal, ezeket érdemes a fentihez hasonló blokkba rejteni:
#ifdef __18CXX
    _asm
        CALL high_vector_branch, 1
    _endasm
#endif

 Ezekkel sem fog a VS szórakozni, csak az MCC18.

Figyelni kell még arra is, hogy az include pathokat a VS máshogy kezeli, mint az MCC, általában ha jól belőjük őket a VS-nek, az MCC panaszkodni fog. Ezt majd az MCC fordításnál egy új include könyvtár hozzáadásával orvosoljuk, most állítsuk be úgy, hogy a VS-nek jó legyen.

A sikeres fordításhoz két dolgot be kell még állítani a VS-ben a Project Properties ablakban: A "C/C++" General fülön az Additional Include Directories-hez írjuk be a "C:\MCC18\h" útvonalat, vagy ahova tettük az MCC-t. Ezután az Advanced fülön a Disable Specific Warnings-hoz írjunk 4068-at, hogy a sok ismeretlen pragma miatt ne sírjon.

 Ha minden igaz, mostmár a kódunk lefordul, egyedül linker hibákat fogunk kilóra látni, mert a PIC-hez használt <p18f2455.h> (vagy más) minden változót extern-nek deklarál, persze neki könnyű mert saját lib-je van. Mi inkább csapjunk hozzá a project-hez egy új fájlt, mondjuk mscext.c néven, amiben létrehozzuk a memória területet az extern változóknak:
#include "mscext.h"

#include <p18f2455.h>
#include <i2c.h>

#ifndef __18CXX

volatile near unsigned char TMR0H;
volatile near unsigned char TMR0L;
volatile near unsigned char TMR1H;
volatile near unsigned char TMR1L;

...
...

volatile near union _RCONbits RCONbits;

unsigned char EEAckPolling( PARAM_SCLASS unsigned char control ){ return 0;}
unsigned char WriteI2C( unsigned char data_out ){return 0;}
void IdleI2C( void ) {}


#endif

 Itt még annyiba futhatunk bele, hogy az MCC header fájljaiban nem minden unionnak / structnak van neve, így abból a típusból nem tudnánk példányt létrehozni (ld. union _RCONbits). Itt kicsit hozzá kell nyúlni a .h fájlhoz, de ez a változtatás nem fogja zavarni az MCC-t:
extern volatile near union _RCONbits {
struct {
unsigned NOT_BOR:1;
unsigned NOT_POR:1;
unsigned NOT_PD:1;
unsigned NOT_TO:1;
unsigned NOT_RI:1;
unsigned :1;
unsigned SBOREN:1;
unsigned NOT_IPEN:1;
};
struct {
unsigned BOR:1;
unsigned POR:1;
unsigned PD:1;
unsigned TO:1;
unsigned RI:1;
unsigned :2;
unsigned IPEN:1;
};
} RCONbits;

 Vagyis adjunk nevet az unionnak.

 Ezután az MPLab kódunk ha minden igaz, lefordul ... intel procira :)

 Hogy Hex fájlunk is legyen a végén, az MCC18 fordítást rábízzuk egy batch fájlra:
rem @echo off

set pic=18f2455
set mccpath=C:\MCC18\bin
set projpath=%~dp0
set projname=test
set sourcepath=%projpath%%projname%
set outpath=%projpath%out
set lkrpath=%mccpath%\LKR\%pic%_g.lkr

del %outpath%\*.* /Q

FOR /R "%sourcepath%" %%i IN (*.c) DO %mccpath%\mcc18 -p=%pic% -I=c:\MCC18\h -I=%sourcepath%\usb -I=%sourcepath% %%i -fo=%outpath%\%%~ni.o -fe=%outpath%\%%~ni.err -D__DEBUG -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-

%mccpath%\mplink /p%pic% /l%mccpath%\..\lib %outpath%\*.o /o %outpath%\%projname%.out /m %outpath%\%projname%.map /u_CRUNTIME /u_DEBUG /z__MPLAB_BUILD=1 /z__MPLAB_DEBUG=1

  És ezt mentsük el picbuild.bat néven, a solution könyvtárába. Értelemszerűen a pic és projname változókat írjuk át. Ezt lefuttatva az out könyvtárban létrejön a Hex, amit letölthetünk a PIC-re.

 A FOR-os sorban a -I=%sourcepath%\usb egy projekt alatti könyvtárat jelöl, ez azért kellett, hogy az include-ok működjenek rendesen - konkrétan a ".."-tal volt baja sok helyen. Ezt vedd ki vagy írd át egy saját alkönyvtáradra.

  Akinek nincs kedve külön futtatni a bat-ot, az a VS-ben a Project Properties ablakban a Build Events / Post-Build Event fülön a Command Line mezőbe írja be a "$(SolutionDir)\picbuild.bat" sort. Így az Output ablakban minden fordítás után megjelenik a picbuild kimenete is.

 Ezzel készen is lennénk, használhatjuk a VS-t az MPLab helyett kódolásra. Éljenek a lusta programozók és az IntelliSense!
 

Címkék: visual studio mcc18

Szólj hozzá!

A bejegyzés trackback címe:

https://muszer.blog.hu/api/trackback/id/tr921689641

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.
süti beállítások módosítása