Hello
A Tx/Rx lábakat jól kötöttem be. A két pic egy kb. 15cm-es huzallal kötöttem össze (külön próbapanelon vannak). NOT parancs jól működik ebben a 2009-es mikropascalban, bár nekem is rémlik, hogy az előző verzióknál nem nagyon működött. Nos van úgy, hogy rendesen működik, nyomogatok egy gombot az adónál, és vesz a vevő. De van úgy, hogy egyszer csak már nem megy. Lehetséges, hogy zavart szed össze az összekötő huzal? Máskülönben mennyire megbízható ez az uart? Szóval elméletileg nem is szabadna vételi hibának lennie?
Üdv.

Úgy értettem ezt a részt, hogy a következő sorban adtál annak a 3 változónak 0-ás értéket. Nem a port értékadásra gondoltam, igazad van, félreérthető voltam.

Akkor lehet, hogy időzítési gondok lesznek. Próbáld meg, hogy mindkettő PIC-re ugyanolyan értékű kvarcot teszel (ha esetleg most különbözőek). Ha jól rémlik, 1B sikeres vételéhez max olyan 10% körüli időzítés-eltérés lehet. (2B-nál már csak 5%, de ez csak megközelítő érték, pontosan most nem ugrik be.)
A Gnd-k össze vannak kötve?

Hello
Most már 100%-osan működik az uart. Igazi szarvashiba volt, mert ugye nem kötöttem össze a GND-ket
De az igazsághoz hozzá tartozik, hogy én előzőleg a manchester-es unittal próbálkoztam, sajnos ennél a mikropascalnál se tudtam működésre bírni, és ezek után próbálkoztam meg azzal, hogy uart-ot használva próbáltam kommunikálni 433MHz-es adó-vevő modulok segítségével. Olvastam, hogy így nem fog menni a dolog, merthogy a vevő a hosszabb ideig tartó H szint vételét előbb-utóbb L szintnek fogja venni, de gondoltam, hogyha elég gyors az adatátvitel, akkor talán nem lesz baj. Nos, az eredmény az, hogy néha működött, néha nem. Ha 2-3 méternél távolabbra vittem az adó részt, akkor egyszer se vett a vevő. Ezek után módosítottam a dolgon. Az adó mielőtt kiküldené az adott bájtotot, elküldi a %10101010 bájtot. így valamelyest javult a dolog, de nem túlzottan.
Ezek után történt, hogy ki akartam próbálni külön csak az uart unitot vezetékkel, de...a többit már tudod.
Szóval szerinted lehetne valahogyan adó-vevő modulok segítségével kommunikálni úgy, hogy az uart-ot használnánk (úgylátszik a mikropascal uart unitja jól működik)?
Üdv.

Üdv!
Ezen az UART-RF illesztésen már gondolkoztam én is régebben. Még csak elméletben van kész a dolog (nincs most RF modulom), de talán úgy működne, hogy a PIC TX lába menne egy AND kapu egyik bemenetére, a másik bemenetre a PWM kimenetet, az AND kapu kimenetére pedig az RF modult. Így meg lenne modulálva az UART, amit már át vinne a modul. Ez a rész eddig biztosan működne.
A visszaalakítás már húzósabbnak tűnik, talán úgy lehetne, hogy az RF modul kimenetét egy pár nanós kondival kisimítani (az értéke PWM frekvencia, kitöltés függő, jól el kell találni), majd egy komparátorral TTL jelet csinálni belőle, ami mehetne az RX lábra.

Ha esetleg kuszán fogalmaztam, szólj és lerajzolom.

Csináltam egy printscreen-t arról a sorról, amiről beszélek.

Pascalról magyarra fordítva ( ) ezt a részt:
Ha fel/le/enter közül valamelyik "1", és ha ki van kapcsolva a világítás, akkor mind3 változó legyen "0".

Vagy direkt csináltad így, hogy az első gombnyomás csak világítást kapcsoljon?

Szia Pako!

Igen, direkt van így. Ha a világítás nem működik az első gombnyomás bekapcsolja, utána működnek a gombok funkciójuknak megfelelően.
A helyzet különben változatlan, azóta sem működik a program, bár nem nagyon volt időm vele foglalkozni. Valószínű, hogy újra írom az egészet. :no:

Hello
Olvastam sok helyen, hogy mások is uart-tal oldják meg az RF adást-vételt és működik is, vagy pedig manchester kódolással az adott bájtból 2 bájtot csinálnak, amit külön-külön küldenek el uart-tal. Próbáltam uart-tal olyan bájtot küldeni RF-en, amiben nincs egymás után 3 egyforma bit, de csak néha-néha vette a vevő. Szóval nem is álltam neki írni olyan függvényt/eljárást, ami 1 bájtból manchester kódolás alapján 2 bájtot csinál.
De azt hiszem, rájöttem, hogy mi a hiba a rendszerben. Elolvastam Topi cikkét most már 100-adszorra, és felfigyeltem arra, hogy a PC soros portján az alapállapot a H szint, majd az adás kezdetekor lemegy L-re, majd jönnek az adatbitek...Nos én ezidáig azt hittem, hogy pic-es közegben az alapállapot az L szint, majd... Ezután szkóppal rálestem az adó próbanyákon a pic uart kimenetére, és ott láttam, hogy ugyanaz a helyzet, mint PC-nél, szóval picnél is az alapállapot a H szint.
Szerintem ez lesz a gond, mivel az adó áramkör tápra kötése után az adó modul rögtön H szintet sugároz, a vevő modul rögtön vesz, de a vevő egy idő után ugye L szintnek veszi a H szintet is.
Szóval arra gondoltam, hogy összeállítok 3 ellenállásból meg egy NPN tranyóból invertert, egy invertert beiktatok az adó próbanyákon a pic kimenete és az adómodul közé; egy invertert pedig a vevő próbanyákon a vevő modul és a pic bemenete közé. Így elméletileg működnie kéne. Majd persze figyelek arra, hogy olyan bájtot küldjek, ahol nem ismétlődik 3x egymás után ugyanaz a bit (és figyelembe veszem, hogy a START BIT most már H szintű lesz). Mi a véleményed?
Üdv.

Ezt nem értem tisztán. Leírnád, mit értesz ez alatt?

Úgy tudom, hogy ezen RF-modulok, amik nagy számban kaphatóak sok helyen, TTL-szintekkel dolgoznak, mind a ki-, mind a bemeneteiken. Mit keresne ott az adó bemenetén egy TTL jelre modulált PWM-jel? :crazya:

Üdv!
Szerintm inkább egy CD4093-al (vagy 7404-el) próbálkozz, mint tranzisztorral. Egy kis programozással az UART-ból is lehet a Manchasterhez hasonló adatsorozatot kiküldeni, de ez szerintem meg sem fogja közelíteni a valódi manchaster kódolást, bár a puding próbája az evés... Ezt amúgy azért gondolom így, mert az UART a bemenő adatbitek közepénél nézi a jelszintet, Manchester kódolásnál pedig a felfutó élek közti időt mérik.

Norberto:

PWM helyett lehetne akár egy egyszerű kis négyszögjel is, pl. egy 555-ösből, a PWM viszont kéznél van a PIC-ben. (50%-os kitöltéssel alkalmas lenne a modulálásra.) Erre azért lenne szükség, mert csak pár msec hosszúságú "H" jelet képesek átvinni az adó modulok, utánna "elmászik" az adófrekvencia. (Gondolom erre gondolt m.joco is). Ezért kell a hosszú "H" szinből ($FF) is négyszögjelet csinálni.

Üdvözletem!

Az UART-al van egy kis problémám.
UART1_Read_Text utasítással várok 9 karaktert, amik a következők lehetnek:
ER_CMD#P0
ER_CMD#P1
ER_CMD#P2
.
.
.
ER_CMD#P9

Az utolsó számot kellene ebből kinyernem. Konkrétan a gondom pedig az, hogy nem sikerül odáig eljutnom a beolvasással. Fogalmam sincs, hogy a "Delimiter", illetve az "Attempts" helyére mit írjak.
UART1_Read_Text(text,'P',255) utasítással ennyit olvas be: 'ER_CMD#', ha a 255-öt módosítom, akkor semmit. A Delimiter-t próbáltam üresen hagyni, illetve szóközt is próbáltam, de úgy sem olvas be semmit.

Van valakinek ötlete, hogyan lehetne ezt megoldani?

Hello
Nos az RF-fel kapcsolatos sikertelenségek után egy időre mérgemben áttértem a PC-PIC összekötésére UART-tal.
Delimiter, vagyis határoló --> ha pc-felől küldesz szöveget a pic-nek, akkor mindeggyik stringnek ezzel a delimiterrel kell végződnie. Pl.:
PC-nél:
'hello' ---> ezt akarod a pic-nek küldeni
delimiter = 'stop'
Akkor a 'hellostop' stringet kell a picnek küldened. Ekkor az UART1_Read_Text(text, 'stop', 255); utasítás a pic-nél a text változóba a 'hello' stringet teszi.
Attempts = ha jól vettem ki a mikropascal súgójából, akkor arra való, hogy megadd, hogy legfeljebb hány beérkezett karakteren belül jelenjen meg a delimiter. Szóval ha 10-re állítod, és a delimiter = 'stop', akkor max 6 karakteres stringet tudsz elküldeni. Ha pedig 255-re állítod, akkor pedig nem veszi figyelembe ezt a számot, addig, amíg nem küldöd a delimitert, addig az input pufferjában maradnak a karakterek. Azt hiszem azért van a delimiter és az Attempts, mert ez a read_text utasítás egy blokkoló utasítás.
Üdv.
Egyébként szerinted infra adatátvitelhez lehet használni az uart-ot?
infra vevő - valamelyik tsop infra vevő
infra adó - astabil 555-el, kimenetén az infra LED-del, Control Voltage lábat kapcsolja a pic.
Vagy itt is kódolni kéne a jelet?

Hali!

A delimitert tudtam, mire való, de az attempts kínai volt. Az ehhez tartozó súgót le fordítottam a webforditas.hu-ne, de attól csak még kínaibb lett.
Mindenesetre most már értem, köszi!
Amúgy a probléma az volt, hogy a delimiter után kellett volna mégegy karaktert beolvasnom. Aztán végül megoldottam a következő módszerrel:

Function Get_UART : byte;
VAR outp : byte;
Begin
_Repeat
__Repeat Until UART1_Data_Ready=1;
__outp:=UART1_Read;
_Until outp = 'P';
_Repeat Until UART1_Data_Ready=1;
_outp:=UART1_Read;
_result:=outp - 48;
end;

Elvileg működnie kell infrával az UART-nak. Az adón a modulálást gondolom az említett 555-ös végezné, a TSOP-on pedig már a szűrt jel jön ki. Próbáld ki, aztán majd kiderül vagy beborul.

(Amúgy én is RF modullal szenvedek most, ER400TRS a típusa, UART-al kommunikál a külvilággal. A manchester kódolást is megoldja saját magának, tud CRC16-ot is. 10 centis nyák antennával át lő 3 falon kb 20 méter távra, ami szerintem egész jó.)

Üdv. Mindenkinek...

MikroPascal Pro változatból megjelent a 3.2 verzió.
Gyógyítás itt

További szép napot

Scanmen

Sziasztok!

Elsőként közölni szeretném, NAGYON JÓ a MicroPascal program! Én a Pascal nyelvhez értek a legjobban, és ha PIC-ről van szó, akkor ez is megoldódik

Kérdésem az lenne, hogy tegyük fel, hogy egy 16F88-as PIC-ben létrehozok egy tömböt így ->



Ebben az esetben a MicroPascal nem tudom miért, kiírja, hogy nincs elég memória a tömb létrehozásához....

Hogy lehet ez, mikor a PIC 365 byte RAM-al rendelkezik, amiből egy ilyen tömb létrehozásakor MAX 91 byte-osat tudok!?!
A következő képpen persze működik:



így 2X96 = 192 byte-os tömböt hoztam létre!!?!
Miért nem működik 0..120-al?!

Köszi
Sziasztok!

Az adatlap 15. oldalán megláthatod a választ. (Az elrendezést, elosztást nézd, ne a bájtok számát közvetlenül.)

Szia!
A tömbök definíció szerűen összefüggő memóriaterületek. Mivel a 16F88 RAM területei bankokba vannak szervezve, ezért nem lehet 96 byte- nál nagyobb összefüggő memória területet lefoglalni. Megoldás lehet a problémára a mutatótömbök használata.
Üdv.

Valószínűleg azért, mert az a 368 byte nem egybefüggő memóriaterület, hanem négy bank, sorrendben 96, 80, 96, 96 byte területtel. A fordítód nem kezeli a bankváltást egy tömbön belül, ezért korlátozott a lefoglalható terület.

Sziasztok! Látjátok, erre nem is gondoltam! Azt hittem, hogy az egsész szabad memóriát tudom kezelni, és kész... Mi az a mutatótömbök?! Hol találok hozzá leírást?!

Köszi a válaszokat! Sziasztok!

Sziasztok!

Az lenne a kérdésem, hogy a MicroPascal-ban bele van gyógyítva egy Manchester kódolásos programrész, amit az ábra szerint Wirelless továbbításra kiválóan működik!

Nah, most szerintetek, hogy lehetne megoldani, hogy egy IR adatátvivő legyen belőle úgy, hogy az IR LED 30kHz-en küldje a jeleket egy TSOP1730-as vevőnek!?!

Köszi! Sziasztok!

Sziasztok!

MikroPascal támogatja az ICD2 -őt, esetleg lehet debuggolni, stb.? Az meprogrammert nézegetem de nem látja az usb-s icd2 programozómat.

Üdv mindenkinek.
Pic16f877a.val szeretnék négyszöggenerátort épiteni 1khz--25khz-ig minden megodást szivesen veszek.

Szervusz gthomas !

Sajnos a Mikropascal nem támogatja sem az ICD2-őt sem más Microchip programozót . Sajnos MPLAB alá sincs "plug in" - ja .

Üdv!
Qka

Sziasztok!
Én, az MPLAB-ot használom. assemblerben programozok, és gyakran szükság lenne bonyolutabbb eljárásokra, amit nehéz assemblerben megoldani. Nem ismerem a Micropascal-t, de jól gondolom hogy egy kis eljárást megírok Micropascal-ba, lefordítás után ezt be tudom szerkeszteni az MPLAB-al? paraméter átadás RAM-ban lévő változókon keresztül..Ha ez nem így működik akkor nem is görcsölök vele. Tudom a C lenne a teljes értékű megoldás, de nem nagyon kívánom ....

üdv
brs

Ne görcsölj vele... Barátkozz meg a C nyelvvel és/vagy nézz körül a "gyári" függvények között is.

Ettől a választól féltem......
De valószínüleg igazad van!!

Szia!

Én így próbáltam kiküszöbölni a 2 kword-ös demo limitet (ugyanis a program ASM-be átfordítja korlátozás nélkül, csak a HEX file-nál van korlátozás), de a MicroPascal által beszélt tájszólást az MPLAB nem érti meg. Nyilván különbözőre tervezték a két assembly nyelvezetet, hogy ne lehessen így trükközni.

Ha ragaszkodsz a nyelvhez, akkor egy kicsit más dialektust beszélő pascal fordító is van PIChez, ez közvetlenül MPLAB által emészthető assemblyra fordít.

Hali!

Éppen az analóg bemeneteket olvasgattam, mikor felvetődött a kérdés, hogy van ahol (mint pl. nekem a kapcsolóóra, ahol elemről is táplálom az RTC-t.), szóval ki kellene jelezni az elem állapotát. Hogyan lehetséges ez? Analóg bemenetre kötöttem egy potit,fesz osztó, a display ezt írta: 394. A tápfeszt ingattam egy kicsit 4-6V, de az érték stabilan 394 ami szerintem ok, mivel relatíven minden a régi. Na most akkor hogyan lehet a tápot, aksit, elem állapotát mérni, ahhoz, hogy kijelezd, "most már cseréld ki".

Kell egy referencia, mert ha a tápot használod referenciának is, akkor mindig ugyanannyinak fogod mérni. Pl. zener dioda is jó, tl431, 4-5 sima dióda sorbakötve is elég lehet, ha a hőmérséklet nem változik sokat. De léteznek feszültségreferencia ic-k is pontosabb méréshez, sőt olyan pic is, amiben belül van referenciaforrás. Illetve olyan rtc is létezik, ami méri az elem állapotát. Szóval széles a választék