Nincs felrakva, akkor próbálkoztam vele mikor kezdtem és kerestem a nekem tetsző nyelvet, de végül a c maradt.
De előkeresem és egy próba erejéig felpakolom, viszont csak holnap vagy vasárnap, most tényleg nem sok időm van kutakodni a cd-k között. Ha nem késő akkor.

Köszi! megfelel persze.

Időközben megoldódott, úgy ahogy írtad nem lehet lekérdezni sajnos.
Viszont előjött egy másik érdekes probléma.... pár éve pascalozok, és ez egy olyan hiba(?) hogy az eszem megáll.

var
str1:string[255];

begin
If Str1='akarmi' then Uart1_write_text('akármi');
If Str1='barmi' then Uart1_write_text('bármi');
end;

Egyszerűen nem engedi lefordítani, pedig mindenhol működik (Delphi 5, Delphi7,TurboPascal, WinPascal) tényleg ennyire gaggyer ez a mikropascal, vagy valami nyelvi sajátosság?

Nem írtál konkrét típust, de általánosságban igaz:
A közvetlen összehasonlítás "if" utasítással nem fog menni (hardver okokra visszavezethetően csak egyszerű típusok közvetlen összehasonlítása működik).

Két megoldás is elképzelhető:
1. Használod a string library "strcmp" nevű függvényét,
2. A stringet tömbként kezeled és karakterenként hivatkozol az elemeire str1[1] str1[2] stb.
Példa:
if (str1[2]='a') and (Str1[3]='b') then Uart1_write_text('akármi');
if (str1[4]='b') or (Str1[4]='c') then Uart1_write_text('bármi');

Amikor mikrovezérlőt programozol, mindig figyelembe kell venni, hogy ez nem egy PC. Mivel a hardver erőforrások ROM, RAM, CPU korlátozottak, emiatt sokszor egyszerűsíteni szükséges. Ráadásul minden fordítónak "saját" nyelvezete van, amit az adott architektúrához alakítanak/igazítanak. Emiatt a hardver korlátai megjelenhetnek a programfejlesztés során.

Érdemes mindig a Language Reference vagy Language Howto részt a dokumentációban átolvasni.

Értem, köszi az infót, ez így akkor oké!
DE! találtam közben egy másik "érdekességet"

tegyük fel hogy egy String típusú változóból szeretnénk átmásolni egy másik string típusú változóba a tartalmat, karakterekként.

Ez nálam úgy nézne ki hogy
var
source,destination:string[50]
index:byte;

Begin
Index:=1;
repeat
Destination:=Source[Index];
Index:=Index+1;
Until Index=Length(Source);

namost, ez sem működik, ott kezd el nyávogni hogy (5.8.0-ás verzió) Source[Index]
a 4.8.0.0-ásnál semmi baj nem volt. Itt vajon mit gányoltak? Ez szerintem azért egy eléggé alap dolog a pascalban...

Itt az hiányzik, hogy a "Destination" nevű változó esetén is meg kell mondani, hova kerüljön az adat. Így jó kell legyen a kód:

Profi vagy Gozi. Honnan szedted az értesüléseid ?

Gyanítom, hogy a pascal nyelv leírásából...

Lehet, de mint írtam, mindenhol máshol működik amit megírtam, csak itt nem, de köszönöm hogy hozzászóltál.

Lehet, hogy van olyan fordító (főleg a nagyobb processzorokra), ami lehetpvé teszi, de még nem találkoztam olyannal, mi nem jelzett volna hibát azokra, amit itt írtál a tömb indexelésre. Turbo Pascal 5.5, 6.0, 7.0, Delphi 1.0, 3.0, 5.0, 6.0; Z80 -ra való HiSoft Pascal, Real Pascal, stb.
A C nyelvjásaiban a tömb neve egyben a tömb 0. elemére mutató pointer is.
Az if (string1 = string2) -nek mennie kellene, lehet, hogy valamilyen utit -ot be kell szerkeszteni hozzá. (A strcmp.h megint C -hez való...)

Bármelyik Pascallal működik ami nálam van. Hibát nem ír sehol. Példának okáért a képeken a windows pascal 1991-92-es kiadás látható.

Helló,
Simulink-ból küldök ki számokat RS232-ön keresztül MikroPascalba. Ott a számmal végzek pár alapműveletet, majd küldöm vissza Simulinkbe. PIC18-as mikrokontrollerem van. Így néz ki a program:



Az a baj vele h random hülyeségeket ír ki minden olyan esetben ha művelet eredményét tartalmazó változót küldök ki UART_Write-tal. Pl. akkor is ha nem változtatom az értékét

Viszont ha x-nek beírok 1 akármilyen értéket(ami nem művelet eredmény) akkor kiadja jól.
Mi lehet a probléma?

Köszi a segítséget.

A leírás szerint az UARTx_Write_Text() eljárást kellene használni, mert az UART1_Write() csak egy bájtok/karaktert küld ki!Bővebben: Link, benne az UART_LIBRARY

Konkrét megoldást a problémádra nem tudok adni, (mert csak azért sem mert nem vagyok biztos mit is küldesz a PIC felé és mit is vársz eredményként) csak néhány észrevétel:
- "number" változó típusa nincs definiálva általad
- "str2int" , "Float2Str" nem standard Mikropascal funkciók
A Mikropascal-nak egész jó szoftveres nyomkövetője van, érdemes használni biztosan rátalálsz a megoldásra.

1. A 'number' az real(elfelejtettem beírni, amúgy ez csak 1 variáns a sok program közül amit probáltam futtatni), de végülis mindegy, mert ha akár 1 byte típusut akarok átküldeni azzal se boldogul.
2. Libstock-ról töltöttem le ezeket a függvényeket,

ha debuggal nézem a változókat akkor mindent helyesen elvégez, ezért nem értem hogy 'élesben' miért nem működik...

Nem az a baj.
Például, így működik jól:



de ebben az esetben már nem 10-et ír ki UART-on

Helló,
Simulink-ból küldök ki számokat RS232-ön keresztül MikroPascalba. Ott a számmal végzek pár alapműveletet, majd küldöm vissza Simulinkbe. PIC18-as mikrokontrollerem van. Így néz ki a program:

A fenti csak 1 a sok probálkozás közül. Probáltam egyszerűbb, kisebb számokkal, úgyse megy.
Az a baj vele h random hülyeségeket ír ki minden olyan esetben ha művelet eredményét tartalmazó változót küldök ki UART_Write-tal. Pl. akkor is ha nem változtatom az értékét


Viszont ha x-nek beírok 1 akármilyen értéket(ami nem művelet eredmény) akkor kiadja jól.
Például ezzel működik:

De így már nem kapom vissza a 15-öt UART-on keresztül

Mi lehet a probléma?

Köszi a segítséget.

Sziasztok!

Van egy kapcsolás, ami 3db ceruzaelemmel működik. Rajta egy 16f690-es pic végzi a dolgát. Hogyan tudom érzékelni (elsősorban kapcsolási rajz szinten) hogy merül az elem? Arra gondolok, hogy hogy ha 3V alá csökken a feszültség kapjon a pic egy jelzést, vagy addig kapjon amíg normál a feszültség.

Köszi, üdv: T.

Kapcsolási rajzot hirtelen nem tudok, de három lehetséges megoldást tudok javasolni:

1. A 16F690-es PIC-ben van komparátor. Azt kell felhasználni úgy, hogy a komparátor neminvertáló bemenetére az elemfeszültség kerül (szükség szerint leosztva), az invertálóra pedig egy fix feszültségreferenciát/zener diódát kötsz. Így az elemfeszültség csökkenésekor akár megszakítást is tud generálni a belső komparátor.
2. Külső hardver felhasználásával is megoldható a dolog, pl: TC54 és társai...
3. Emlékeim szerint a 16f690-es széria WAKE-UP modulja is felhasználható erre a célra: AN879

+ 1 lehetséges megoldás:
Külső alkatrész nélkül is megoldható a feladat: de ehhez olyan PIC-et kell választani, ami támogatja a LVD (Low Voltage Detect) funkciót.

Sajnos nincs elegendő adat ahhoz, hogy a hibát mindent kizárva meg lehessen határozni, ugyanis se a konkrét PIC típus, se a használt fordító verziószáma se ismert. A hardverről nem is beszélve...

Pár tipp elsődlegesen: oszcillátor nem megfelelő beállítása, a soros adat útja során van valami gond, esetleg bekapcsolt/alapértelmezésben bekapcsolt MCU periféria okozhat hasonló gondot (esetleg ha van, akkor akár az usb-soros konverter is).

A következő kód biztosan működik (mikroPascal PRO for PIC v.5.8.0; 18F4550):

Van beépített fix referencia is!

4. lehetőség: ADC-vel VDD referenciával megmérhető a belső referencia (ami 0,6 V-os). Abból, hogy az ADC mennyinek méri vissza lehet számolni, az ADC ugyanis a Vref/VDD arányt adja
eredményül. Ez a módszer megszakításra nem alkalmas, de folyamatos ellenőrzésre annál inkább.

Hű, igazad van. El is felejtettem (16F szériát már ritkán használok), hogy ennél a szériánál is van fix referencia, ráadásul be is állítható a belső komparátorhoz, így gond nélkül megoldható a megszakítás is... Adatlap 8.4 fejezet.

Szia!
Az első 3 megoldással az a baj, hogy sokkal többet fogyasztanak, mint a sleep módban levő kontroller. Egy P-MOSFET és egy N-MOSFET felhasználásával nyugalmi áram nélkül lehet a telepre kapcsolni a mérőkört. A mérőkör bekapcsolása után megvárni a beállási időt, mérni, meghozni a döntést, jelezni, majd újra sleep egy ideig. Időzítő felébreszti a kontrollert és a műsor kezdődik előlről. Ha sokáig futó állapotban van, akkor időnként mér egyet...

Hello



A chr(); argumentuma csak konstans lehet, ha jól tudom, mert a mikrovezérlő nem ismeri az ASCI kódtáblát, tehát a fordítónak fordításkor ismernie kell az argumentumot.
Üdv.

Köszi a válaszokat, ezt kipróbálom.

Prototype: function Chr(code : byte) : char;

Returns: Returns a character associated with the specified character code.

Description: Function returns a character associated with the specified character code. Numbers from 0 to 31 are the standard non-printable ASCII codes.

This is an “inline” routine; the code is generated in the place of the call.

Requires: Nothing.

Example: c := Chr(10); // returns the linefeed character

Ezzel a fuggvennyel biztos nincs baj.
Ez a program mukodik:

Adatok: mikroPascal PRO for PIC v.5.6.0; 18F8520; 10 MHZ osc;
USB-soros konvertert hasznalok

van 1 ilyen programom:


Amint a kommentekbe irtam, mindegy milyen erteket kuldok neki az olvasoregiszterbe, mindig 252-t ad ki a Simulink-ban. Ha valamilyen muveletet akarok csinalni a szamma alakitott karaktersorral, akkor 0-at ad ki. ???

Minden uart adat kiolvasása előtt meg kell vizsgálni az RCSTAn regiszter FERR és OERR bitjeit.
A 16F88x adatlapjából:


Mág annyit hozzátennék, hogy a hibásan vett karaktert ki kell olvasni.

Ez a kód működésképtelen. Minden ciklusban lenullázod az "st" változó értékét... Ráadásul akkor is küldesz adatot, amikor nem is kaptál semmit... Azt sem látom, hogy hol van lekezelve, mikor van vége a kapott adatnak...

Ha stringet küldesz a soros vonalon, az szépen számjegyekre bontva kerül kiküldésre. Ezt neked egyenként le kell kérdezned a vételi pufferből, és ebben az esetben tudnod kell, hol van kezdete vagy vége az adatnak.
Egy példa: át kell küldeni az 0123456 karakterláncot.

Átküldésre kerül a mikrovezérlőbe (tehát ez az adat kerül az uart_rd regiszterbe) a következő, szépen egymás után:
48, 49, 50, 51, 52, 53, 54.

Ezzel még nem vagyunk készen, ugyanis ezt fel kell fűzni egy karakterlánccá, és tudni kell, hol kezdődik, vagy hol fejeződik be az adat. Nem tudom, hogy a simulink adatformátuma mennyire rugalmas, de egy határolóadat mindenféleképp javasolt. Az esetek többségében ez a CR+LF (kocsi vissza+soremelés; 0x0D (13) és 0x0A (10)) érték.