Miért nem próbálod ki a szimulátorban az időzítéseket?

Veszel egy 8 bites változót és beleteszel 1-et, majd kiviszed az egyik portra, amin a LED-ek vannak. Aztán ezt a számot időközönként szorozgatod 2-vel és kiviszed a kimenetre egymás után a kapott értékeket. A LED-ek futni fognak. Van még néhány más megoldás, de ha ezt megoldod, akkor a többire már rá fogsz jönni. Egyébként félve kérdezem meg, hogy fenn van az MPLAB és valami C fordító? Van égető áramköröd is? Tudod, hogy kell illeszteni a LED-eket? (Ha ezekre nem a válasz, akkor nem itt a helyed egyelőre, hanem a kezdők topicban. Ha igen, akkor üdv a klubban!)

Persze néztem ezt is, ezzel csak az a gond, hogy mivel én a 16f726-ot használom, ezért a b7 b6 port egyben a debughoz szükséges dat és clk lábak is, az általad említett mintaprogram meg az egész b portot állítgatja ki-bemenet között amitől persze a debug fejre áll, ráadásul saját maga által írt időzítésekkel szórakozik miközben a ccs-ben meg vannak ezek az időzítések valósítva, tehát tök fölösleges kódokkal zavarja tele a lényeges részeket, ráadásul mivel 4 hőmérőt használ, ezért a hőmérők id-ját és kérdezgeti meg használja ami megint felesleges az esetemben, míg amit a ccs-hez adnak eleve az nem szüttyög az előbb említett dolgokkal, csak az időzítéssel csúszhat el valami.

Ki fog válaszolni a dallas helyett? Ha jól értettem akkor lehúzom 0-ra a lábat, várok 500us-t felhúzom 1-re a lábat, várok 240usés ha lehúzza a lábat valami 0-ra, akkor az a dallas ic (vagy más slave eszköz), innen lehet tudni, hogy van a lábon valaki. Persze lehet hogy tévedek, akkor majd kijavítasz remélem.
Ezek után küldök parancsokat úgy hogy ha a bit egy akkor 60us-ig fent tartom a jelet, ha 0 akkor 60us-ig lent.
Ez utóbbi része még nem egészen tiszta, erre jó lenne valami magyar nyelvű összefoglaló.
Az viszont biztos, hogy erre bizonyos parancsokra a dallas válaszol, és ezt a választ szimulátorban nem fogom látni.
Az kiderül, hogy a kód észreveszi, hogy ott van az ic, hiszen az egész folyamat csak akkor indul el ha a feltétel tejesül, és jön is valami a dallastól, csak ott lehet valami gond az olvasással amire a szimulátor megint nem jó, vagy ha igen akkor nem tudom hogyan. (kéne valami jelsorozat egy működő dallastól, és azt odaadni a szimulátornak bemenetnek.)
Egyszer láttam egy linket egy magyar nyelvű one wire leírásra de a link már nem működött, ha esetleg tudod hol van szívesen átböngészném.

Ja és ez a mintaprogram megint csak saját kútfőből próbálja kezelni az lcd-t (ami ha valakinek nincs megírva persze jól jöhet), megint csak tovább zavarva a kódot, miközben a cc-ben ez is meg van valósítva és át is alakítottam az én portjaimnak megfelelően, és megy is az lcd kezelés.

Választ valóban nem kap a szimulátor, de ettől azért egy kicsit kreatívabbnak kellene lenni. Azt kell megnézni, hogy a kontrollered jókor húzza-e le, és jókor engedi-e el a lábat!

Valahogy meg lehet a szimulátornak adni, hogy melyik időpillanatban milyen jel jön be, ezért kéne egy működő dallastól az adat.
Igazából a szimulátorral csak az első kommunikációt tudnám megnézni, ami viszont fölösleges, mert az megy.
if(touch_present()) {
touch_write_byte(0xCC);
touch_write_byte (0x44);
output_high(TOUCH_PIN);
delay_ms(2000);

touch_present();
touch_write_byte(0xCC);
touch_write_byte (0xBE);
buffer[0] = touch_read_byte();
buffer[1] = touch_read_byte();

printf ("\r\nTemperature: %c%3.1f C", (buffer[1])?'-':' ', (float)buffer[0]/2);
delay_ms (1000);
}
látszik, hogy ha nem válaszolna a dallas akkor nem írna semmit az lcd-re. A printf előtt állítottam meg a kódot, és néztem a buffer tartalmát. A 0xBE-re 2 byte-ot válaszol a ds1820, azt olvassa i a buffer 1-2-be.

Nézd meg azt az asm-et, amit betettem tegnap vagy tegnapelőtt. Abban be vannak lőve az időzítések, DS1820 és DS1821 teljesen jól kommunikált a programmal. Az a kód 4MHz-es órajellel működik.

Üdv mindenkinek!
Szeretnék segítséget kérni a winpic hez, mert volt egy rendszerösszeomlás és azóta nem tudom feléleszteni az égetőmet :'(. Az égető negy gyári, egy tuning JDM, eddig 100% osan működött, van rajta max232 is, külső tápról megy. A progi viszont most nem ismeri fel, gondolkodás nélkül hibát ír. ERROR -> El hardware no responde.
A hardver beállításoknál próbáltam állítgatni de sehogy se jó. Tud esetleg valaki egy jó beállítást hozzá? Egy kép sokat segítene. A port beállításai most ilyenek:
Csak a winpic et telepítettem, a kompatibilitást win 2000 re állítottam. Vírusírtó kilőve (hátha fogja a portot). Semmi más nem csatlakozik a soros portra. A kép szerint van valami 12C addr, az mi, és honnan tudom mire kell állítani (ha így nem jó).
A segítséget előre is köszönöm.

Az inverz beálítások körül kell keresgélned, de pontos rajz nélkül nem tudunk segíteni...

Üdv!
Meglett a hiba, az alaplapom soros csatija ki volt rohadva. Most működik rendesen.

Ma megszenvedtem a pic programozás közben. Jó szokásomhoz híven magamat szivattam. 16F877 ről van szó, csinosítgatom a kódot, TRISE -t eddig 3 db bit beállítással kezeltem, mondom magmnak legyen inkább egy utasítás, be is írtam hogy legyen 0b11111111, nem számít hogy csak 3 láb van. Gondoltam én, de a microchip-esek nem felhasználták galád módon a trise maradék bitjet ?! Megkavarta a portd kimenetként működését, mire erre rájöttem... Azután a másik: Ez a Hi-Tech C fordító nem figyelmeztet hogyha átlépjük egy deklarált tömb méretét, és oda írunk ahol már nem is az a tömb van. Érdekes volt kideríteni hogy mi a fenéért íródik át egy változó, aminek nem kéne. A 3. az már csak egy bónusz: Ha nem csak 1 analóg bemenetet használunk, akkor csatorna váltás után várni kell egy kicsit mire átkapcsol az analóg multiplexer, különben még az előző csatorna analóg értéket olvassa csatorna váltás után is. Hát ennyi, remélem van akinek segítettem elkerülni némi hajhullást.

1. Ez nem szivatás, mert az adatlapban szerepel minden leírva. Futólag mindig meg kell nézni az ilyesmit.

2. Ez nem Hi-Tech jelenség, hanem a C nyelv olyan, hogy nem végez indexellenőrzést futásidőben. Ha rossz indexet adsz be, kiszámolja az ahhoz tartozó memóriacímet, és te meg csinálj vele, amit akarsz. Többek között ebből ered a sebességbeli fölénye a Pascal-hoz, basichez, stb. képest.

3. Azt hiszem ezt hívják Aquisition time-nak, vagy valami ilyesminek. Szintén meg van adva az adatlapban, hogy mennyi a minimális idő, amit várni kell csatornaváltás után. Az A/D konverterről szóló részt nézd át.

1. "magamat szivatom" tehát magamnak csináltam gondot, mikor átirtam a már működö verziót. Először megnéztem nyilván, csak mikor egyszerűsíteni akartam akkor rontottam el.

2. pc-n azért szokott szólni futás közben, ha túlcímzed, ezért nem is gondoltam rá. Persze mondjuk szegény pic hogy sikítson, míg winnél ugye feldob egy ablakot aztán kész.

Ez a hátránya a koca programozóknak, énis hetente ránézek, ha van egy kis időm, és ilyen alap dolgokkal, el lehet molyolni, pedig már nemegyszer futottam bele, csakhát elfelejti az ember mire legközelebb leül.


Amúgy haladok már, dcc központ még mindíg. Mostmár működik a gombok pergésmentesítése, potik digitalizálása, hang kiadás, dcc jel generálás, és még az időt is méri. Továbbá rs232 -n konzolon is lehet parancsokat küldeni neki. Bővebben: Link

Az alap PC-s C fordító sem szól. Lehet, hogy a C++, C# és ilyesmik szólnak, de az alap C filozófiájával ellentmond az index ellenőrzése.

Ahogy potyo is irja, a C-ben nincs semmilyen forditasi vagy futasi idoben torteno ellenorzes. C++-ban vannak olyan standard template-ek amikkel lehet tomboket kezelni es ott van minden ami szem-szajnak ingere, de az mind futasi ido hatranyara megy - mikor van egy 2GHz-es dual core-os CPU-d 2MB cache memoriaval akkor ezek a dolgok elenyeszoek...

Amugy alap Pascalban sincsenek ilyenek, a Turbo Pascalba raktak bele ki-be kapcsolhato ellenorzeseket - anno jomagam debugba bekapcsoltam es veglegesben kikapcsoltam az ilyesmit. Amugy ha bombabiztos rendszer kell akkor tanuld meg az Ada-t, bar ugy tudom PIC-re nem letezik Ada fordito. Na az mindenre figyelmeztet, a legkisebb hulyeseg miatt is, ezert nem "szeretik" a programozok Azonban pl Az Airbus is ilyet hasznal, es ha jol tudom szoftver hiba miatt meg egyik sem zuhant le

Üdv!

Pénteken végeztem a projectemmel, teszteltem a programot hardveresen is és teljesen jól működik. Már csak a dokumentáció van hátra. Nagyon szépen köszönöm mindenkinek a segítséget!! :hawaii:
A PIC ezést otthon fojtatom, megtetszett a dolog, és már ki is gondoltam mit fogok összehozni ! Szóval még egyszer Köszönöm!!

Sziasztok,

Vennem kellene egy pár darab IC-t. Itthon Debrecenbe majdnem 5eft-os árat mondtak darabjára. AD558-as IC-ről van szó. Az lenne a kérdésem, hogy Pesten tudtok ajánlani olyan boltot, ahol egész olcsón lehet venni elektronikai alkatrészeket? Zalaegerszegen megkérdezem hétfőn az Elektrolight-ba, hogy mennyi, de Pesten lenne szerintem a legolcsóbb.

Üdv:
Krisztián

Na én kikészültem.
Egyész nap szívtam itt ezzel a hőmérővel, végül találtam egy nagyon kasa kódot, ami pont azt csinálja amit akarok.
ds1822-höz van, de a 2 chip testvér, és az időzítés a leírás szerint jó.

#define ONE_WIRE_PIN PIN_B2

#define DS1822_SP_TLSB 0
#define DS1822_SP_TMSB 1
#define DS1822_SP_HLIM 2
#define DS1822_SP_LLIM 3
#define DS1822_SP_CFG 4
#define DS1822_SP_RES0 5
#define DS1822_SP_RES1 6
#define DS1822_SP_RES2 7
#define DS1822_SP_CRC 8

// ds1822 rom registers
#define DS1822_ROM_DEVTYPE 0
#define DS1822_ROM_SERIAL1 1
#define DS1822_ROM_SERIAL2 2
#define DS1822_ROM_SERIAL3 3
#define DS1822_ROM_SERIAL4 4
#define DS1822_ROM_SERIAL5 5
#define DS1822_ROM_SERIAL6 6
#define DS1822_ROM_CRC 7

// ds1822 command set
#define DS1822_CMD_READROM 0x33
#define DS1822_CMD_SKIPROM 0xCC
#define DS1822_CMD_CONVERTTEMP 0x44
#define DS1822_CMD_WRITESCRATCHPAD 0x4E
#define DS1822_CMD_READSCRATCHPAD 0xBE
#define DS1822_CMD_COPYSCRATCHPAD 0x48


// note that not all applications need to disable interrupts when
// performing onewire transactions. but, if unmasked interrupts
// cause onewire timing violations, returned data will be suspect
// or there may be other, hard-to-reproduce problems.

void onewire_disable_interrupts(int disable) {
if (disable)
disable_interrupts(GLOBAL);
else
enable_interrupts(GLOBAL);
}


short int onewire_init_with_error_check() {
onewire_disable_interrupts(TRUE);
output_low(ONE_WIRE_PIN);
delay_us( 500 ); // pull 1-wire low for reset pulse
output_float(ONE_WIRE_PIN); // float 1-wire high
delay_us( 5 ); // allow pin to stabilize
if (!input(ONE_WIRE_PIN)) {
onewire_disable_interrupts(FALSE);
return ( FALSE ); // error (1-wire leads shorted)
}
delay_us( 80 ); // wait for presence pulse, allowing for device variation
if (input(ONE_WIRE_PIN)) {
onewire_disable_interrupts(FALSE);
return ( FALSE ); // error (no 1-wire devices present)
}
delay_us( 420 ); // wait-out remaining initialisation window.
output_float(ONE_WIRE_PIN);
//printf(debug_putc,"<>ok >onewire_init\n\r");
onewire_disable_interrupts(FALSE);
return ( TRUE ); // device(s) present and initialised.
}

az short int onewire_init_with_error_check()
a delay_us(5) után hibára fut, próbáltam ugyan ezt 25-el is, eredmény ugyan ez.
Ic-k jók, ráforrasztottam őket a sima hőmérőre, és ott jók.
Ez egy nagyon kasán megírt rutin gyűjtemény része, de mivel már itt elakad nincs mit csinálni tovább.
Az egyes láb a gnd-n van a 3-as az 5v-on a 2-es egyszer a b2-n és egyszer eg 4.7k-val az 5v-on.
Kimértem, minden oké, mégsem megy.
Öteletek? Én már kifogytam.

Látod, ezért nem (sem) szeretjük a C-t mikrovezérlős környezetben. Ki a fene tudja, hogy pontosan mit csinál az a kód a háttérben? Esetleg megnézheted a fordító által generált assemblyt, vagy a végleges progi disassemblált változatát, hogy kiderüljön, tényleg az történik-e, amire számítasz.

Például az órajelfreki rendesen definiálva van a fordítónak, hogy az időzítéseket jól fordítsa?

Itt volt valahol lejjebb becsatolva az asm, amivel a DS1820 és DS1821 is jól működik. Az időzítések elég kritikusak ám ebben a kommunikációban, főleg az olvasáskor, amikor a master elengedi a buszt és ránéz, hogy a slave 0-ban tartja-e vagy 1-be ment közben.

Sziasztok!

Építettem egy kapcsolást PIC16F628 - al. Azt kéne csinálnia hogy a PIC egyik kimenete villogtat 30 db LED - et. NOs a programot már megírtam. Hogyan kössem a ledeket rá a kimenetre? Mert a 1K ellenállás után BC337 kötve nem működik. A tranyónak földet kéne kapcsolnia a ledekre. Relével nem akarom mert több kimenetet akarok használni és túl hangos lenne ha 4 relé kapcsolgatna állandóan. Hogyan kössem a fogyasztókat a kimenetre?

Szia!

"a PIC egyik kimenete villogtat 30 db LED-et" Ez számomra nem értelmezhető! 30 db kimenetet használsz vagy MUX üzemmódban szeretnéd működtetni ( ezt tudnod kell, mert enélkül a programot sem tudod jól megírni hardver és szoftver szorosan összetartozik! ) ?
A PIC kimenetére 1 kohm-on keresztül tranzisztor bázisa --> ennek NPN tranzisztornál működnie kell, a GND-t tudja kapcsolni!

A 4 db reléből én a MUX eljárásra szavazok, de Te tudod miről van szó...

Kérdezz pontosabban, illetve rajzold le mi a problémád!

Steve

Egész pontosan arról van szó hogy egy fényreklámot csinálok. OPEN felirat fog villogni (meg még mást is csinál). Szóval úgy gondoltam hogy 1 db betű kb 25 - 30 magasfényű piros LED - ből fog állni. Így 1 betű lessz 1 kimenet a PIC - en. Nos az áramkör egy 9V 1.8A -es tápegységről megy. A pic egy egyenirányító kockán és egy stab IC - n keresztül kapja a feszkót. A BC337 -es tranyók GND - t kapcsolgatnak ahogy a betűk villognak. A LED -ek a pozitívot pedig közvetlenül a tápegység pozitívjáról kapják. Nos a betűnkénti 30 LED - et majd úgy kötöm hogy jó legyen a 9V neki. Erre szeretnék egy jó megoldást. A relé jobb lenne mert ott csak az érintkezőktől függ milyen áramot bírnak kapcsolni viszont hangosak. A tranyók meg halkak.

Az az érdekes, hogy a ccs az output_float(port)-al emel fel elméletileg egy adott port-ot, de csak a próba kedvéért beraktam a b3-ra egy ilyet amin egy led van és nagy lótúrót csinált, nem világított, míg az outport_bit(PIN_B3) meg ment, de ha ezután kiadsz egy output_bit(PIN_B2)-őt az meg kikapcsolja a 3-ason a ledet!
Jó hogy nem szeretjük a c-t a mikrovezérlő környezetben, de azért alapvető funkcióknak legalább működnie kéne. Lehet hogy rossz a ccs verzióm? De ennyire? És ezt senki nem vete még észre?

Gratulálok és örülök, hogy sikerült! További jó PIC-ezést!

1. Milyen LED-ek? (nyitófesz, működési áram)
2. Táp milyen? Stabil 9V?
3. Ha nem, akkor terhelés nélkül mekkora a fesz?
4. Mekkora a fesz, ha terheled 1,8A-el?
Enélkül nem tudunk semmit mondani.

Nos a LED - ek nyitófeszültsége: 1,8 V
20 mA -nél adják ki maximum fényerejüket.
A táp egy sima adapter Üresjárási fesz: 9,2 V
Valószínüleg stabilizált.
Leterhelési kisérletet elvégzem de elég jól bírhatja mert még nem volt alkalmam érezni hogy langyosodott volna egyáltalán. De azért leterhelem.

Sziasztok,

Erre valaki?

Köszi:
Krisztián

Nos a gond hogy ha a tápegységet simán megterhelem izzóval (9V 500mA) akkor az izzó normálisan világít. Viszont ha a BC337 - en keresztül kapja meg a GND - t (PIC vezérli) akkor alig pislákol az izzó. És ekkor az izzó áramfelvétele 100mA körüli. Ez a fő gondom.

El kell olvasni, mit csinálnak pontosan ezek a függvények, sőt, érdemes egy egyszerű programot megírni és megnézni a generált assembly kódot is.

Azt bizonyára tudod, hogy CCS C-ben vannak olyan direktívák (pl. #use fast_io), amikkel a portok kezeléséhez fordított kódot tudod befolyásolni. Például, hogy minden portbit-hez nyúláskor beállítsa-e az adott portbit adatirányát és ilyesmik. Ezeken is nagyon sok múlhat ám egy ilyen kritikus kommunikáció leprogramozásában.