Sziasztok.

A következö lenne a kérdésem. Ti hogy oldanátok meg piccel, hogy az egyik lábán(rutinszerüen a pwm kimeneti láb)egy relative alacsony ferekvenciásáju(változtathato, 10-100hz), szabályozhato kitöltési tényezöjü jel jelenjen meg, egy másikon pedig az elöbbi láb jelének lefutása pillanatában egy stabil, és mindig állando "impulzushosszu" impulzus jelenjen meg. Én két lehetöségre gondoltam, vagy kivülröl müveleti erösitövel megoldani a dolgot, vagy olyan picet választani amiben van eccp funkcio, bár azzal nekem még sosem volt tapasztalatom.
A másik probléma, meg hogy ilyen alacsony frekvenciához alacsony frekis oszcillátor kell,ami meg ugye " az azonnal jelenjen meg a stabil impulzus" rovására menne... nem?
Köszönöm a válaszokat

Szerintem ez nem olyan bonyolult. A pwm-et előállítod a modullal ahogy akarod, ezt a jelet beviszed a külső megszakítást fogadó lábra, beállítod, hogy lefutó élre adjon megszakítást, megszakításba egy timerrel előállítható a megfelelő jelszélesség egy másik lábon.
Remélem jól értelmeztem a feladatot.

Meglehetőst kicsike frekvenciákat adtál meg. Abban a tartományban akár programozhatod is az impulzusokat egy timer-hez, és akkor nem kell pwm modullal tapasztaltnak lenned sem

Köszönöm, jol értetted Ha jol gondolom akkor a pic int0 lába alkalmas lesz erre a bevezetésre Egyébként pic kimenet és pic bemenet közé nem kell más elem, pl ellenállás, ilyet még nem.csináltam, még sosem kötöttem össze egy ugyanazon pic lábát, az általad leirt modon. Szabad ezt minden külsö elem nélkül?

Ez tetszik, ezt ki fogom probálni, bár elfogadnék ehhez néhány instrukciot, mert ilyesmit még nem csináltam Egyébként egyes picek osctune regisztere mire valo?

Hangolni lehet a beső RC oszcillátort.

Azt tudom, de minek, ha egyszer az osscon reg.ben lehet a frekit beállitani?

Hangolni lehet a beső RC oszcillátort kb. +/- 10 %-kal.

Én sem csináltam még ilyet a gyakorlatban, de hasonlót javasoltak már nekem is. Egy ellenállást nem árthat, de szerintem nem szükséges.

A lényeg egy max órajelre pörgetett gyors pic, és egy beállított timer, hogy legyen gépórád. A programot megírod aszinkron főciklus stílusban, nem terheled a főciklust semmi logikai dologgal, foglalkozol csak az időpillanat előreszámításával, mikor válts jelet, és jelet váltasz. A főciklusnak célszerűen vagy 100x gyorsabbnak kellene lennie, mint az előforduló legmagasabb frekvenciád ciklusideje, de azt jelen esetben nem nehéz elérni, ha csak nem akarsz ugyan arra a pic-re usb-t, ethernetet, vagy bármi keményebben terhes libet is feltolni. Ha mégis, na akkor viszont vagy kell neked a hw pwm, vagy dobj fel egy második pic-et is a panelra.

Jelen esetben kvarcot célszerűbb használnod, és olyankor nem kell a belső rc oszcillátor semmire. Vagy ha elég neked a +/- 10% pontosság, lehet belső rc oszcillátor is, de hangolnod akkor is céltalan, elvégre nincs referenciád külső hőmérsékletből, külső órajelből, meg semmiből. Én sosem szerettem az önmagukért való elméleteket, az rc hangolósdit mindig is hagytam a fenébe.

Szép estét!

Mellékletben egy Flowcode forrásfájl, minden tartozékával, amit csak a program generál. Egy egyszerű kis programocska, 2x16 LCD és egy DS18B20 szenzor.

Ha minden igaz, akkor a "1WireTeszt_18F2580.casm" nevű fájl tartalmazza a teljes C forráskódot. Ebben, feltételes elágazások között, van egy Lookup table "//CRC lookup table for the OO...". A kérdés az, hogy ez a 256 bájtos tábla benne van-e az asm és/vagy hex fájlban (feleslegesen foglalva a helyet). A program nem hivatkozik rá sehol, elvileg nincs benne de az asm és a hex fájl átböngészése már magas nekem.

Előre is köszönöm.

Tényleg ritka gusztustalanul csubakkás egy program. Nem is vágom, hogyan fordul az le..

Van egy trükk szimbólum keresésre, ha már más nem segít. Fogod az egész projectet, kiszeded belőle az exe-ket, hex-eket, doksikat, akármi bináris cuccokat, hogy csak a forráskód maradjon valamilyen mappa szerkezetben, aztán fogsz egy winrar-t, és becsomagolod az egészet rar típusú archívumba "Raktároz" opcióval. Raktározás esetén olyasmit csinál, mint linux alatt a tar, egyetlen szövegfileba összemásol mindent. Úgy nem kell 100 féle állományban kotorászni, csak egyetlen egyben. Utána wordpaddal megnyitod, és rákeresel a nevekre. Ha nincs rá jobb oldali hivatkozás a forrásban, akkor nem csinál vele semmit. Jelen esetben én nem találtam rá hivatkozást.

Ami kicsit zavaró, hogy némelyik fordító környezet előre definiált szimbólum neveket használ implicite, és abban nem vagyok képben, hogy amivel fordítod ezt a cuccot, annak milyen rigolyái vannak. Mi a bánat az a "BoostC Compiler"? Na nem mintha tényleg érdekelne, költői kérdés volt, pusztán csak jelezném neked, hogy ha nem tiszta anyagot szívsz, hanem valami pancsoltat, mert abból a több is olcsóbb, ne csodálkozz rajta, ha mellékhatásként belehü**ülsz

Szeretek egyszerűen élni.

nem csodálkozom rajta, egy magas szintű nyelv követte el: FlowCode.
Módszerek:
1 - A CRC táblázatot első 2 -3 elemét megkeresed a program memóriában. Folytatható több adatra is az egyezés vizsgálat.
2 - Kiértékeled a feltételes fordítás engedélyezését akár fejben, akár egy másik utasítás (sorozat) ugyan ilyen feltétellel vezérelve.
3 - Kikommentezed az egészet és lefordítod. Ha hibajelzés lesz, akkor szüksége van a részletre.
4 - Nem kell trükközni az állományokkal, a .lst állományban elvileg minden a kódba fordított szakasz benne van.

Sziasztok!

16F819-el készítettem egy I2C Slave eszközt, eddig csak kiolvastam belőle, ez a része működik is. Viszont most kellene írnom bele pár bájtot. Sajnos kicsit már bele kavarodtam és nem látom át, hogy mikor mi van az SSPSTAT regiszterben íráskor. Megszakításból kezelem, de olyan mintha nem akkor jönnének az adatok, mint kellene. Adatok beírását kb az EEPROM-hoz hasonlóan végezném, tehát slave address - regiszter kezdőcím - byte1 - byte2. Egyáltalán küldhetek egymás után három adat bájtot? BASIC-et használok, de a beépített rutinokat kerülöm. Van valami jó példátok erre? Nem kell feltétlenül BASIC. Sajnos most csak telefonon van netem, így kicsit nehézkes a keresés.

Köszi!

A list állományt nem néztem meg, de egy intelligens embedded fordító nem optimalizálja ki akkor sem, ha nincs rá jobb oldali hivatkozás, elvégre elektronikai környezetről beszélünk, aminek lehetnek hardverből következő műveletei is, mert az alu nem az egyetlen egység, ami memória hozzáféréseket végezhet.

Telepítenem kellene azt a környezetet, feltolnom a firmware-t arra a hardverre, amire szánták, és ellenőriznem azon, hogy vele meg nélküle ugyan az-e a működése. És tudod mit? Fáj a hócipőm vacakolni vele azért a pár100 byte-ért. Csinálja csak @Bakman, ha már annyira unatkozik, hogy nekiállt bajt csinálni a saját fejére

Léteznek olyan hardver alapú védelmek, amik nekiesnek átfésülni a teljes memóriát egy beégetett számsorozatért, és ha nem találják meg, akkor azt mondják, hogy nem engedélyezett fordítót használtál a szoftver fordításához, és nem futtatják a programot, blokkolják az alu-t is. Például almáék csináltak olyat a provisioning-mániájukkal. Van egy hardveres provisioning, és utána sok lépcsőben logikailag felépítve szoftveres provisioning is mindenféle sw kulcshoz. Ha fejlesztettél már ios alatt, akkor biztos összetalálkoztál vele. Na például az is ilyesmi a gyakorlatát tekintve. Viszont mindannak mikrovezérlős környezetben természetesen nulla keresnivalója van.

Nem láttam a hex-ben ilyet, de már az asm-ben sem.

Idézet:
„A list állományt nem néztem meg, de egy intelligens embedded fordító nem optimalizálja ki akkor sem, ha nincs rá jobb oldali hivatkozás, elvégre elektronikai környezetről beszélünk, aminek lehetnek hardverből következő műveletei is, mert az alu nem az egyetlen egység, ami memória hozzáféréseket végezhet.”

Nem beszéltem optimaléizálásról, az ide belinkelt forrásrészletben található feltételes fordításról beszéltem. Ugyan a 1-Wire kommunikáció része a CRC számítás, de ahogy látom itt a kódban ez kikapcsolható... Ezenkívül van rövidebb, de lassabb módszer a CRC számításra.

1. //One_Wire(0): //Defines:
2.  
3. /**** Macro Substitutions ****
4. a = Unique Reference
5. b = CRC Check Enable (0-Off / 1-On)
6. c = One Wire Port Register
7. d = One Wire Pin
8. ******************************/
9.  
10. //Global Definitions
11.  
12. #define         ONEWIRE_6_OO_CRC_EN                     0
13. #define         ONEWIRE_6_OO_PORT                       portb
14. #define         ONEWIRE_6_OO_TRIS                               trisb
15. #define         ONEWIRE_6_OO_PIN                                0
16.  
17. //I/O for the OO
18. #define         ONEWIRE_6_Float_OO                      FC_CAL_Bit_In_DDR( ONEWIRE_6_OO_PORT , ONEWIRE_6_OO_TRIS , ONEWIRE_6_OO_PIN )
19. #define         ONEWIRE_6_Clear_OO                              FC_CAL_Bit_Low_DDR( ONEWIRE_6_OO_PORT , ONEWIRE_6_OO_TRIS , ONEWIRE_6_OO_PIN )
20.  
21. #ifndef OO_DEFS
22.  #define OO_DEFS
23.  
24.  // 1. ROM function commands
25.  #define                OO_READROM              0x33
26.  #define                OO_MATCHROM             0x55
27.  #define                OO_SKIPROM              0xCC
28.  #define                OO_SEARCHROM            0xF0
29.  #define                OO_ALARMSEARCH          0xEC
30.  
31.  // 2. Memory Command Functions
32.  #define                OO_WRITEPAD             0x4E
33.  #define                OO_READPAD              0xBE
34.  #define                OO_COPYPAD              0x48
35.  #define                OO_CONVERTT             0x44
36.  #define                OO_RECALLE2                     0xB8
37.  #define                OO_READSUPPLY           0xB4
38.  
39. #endif
40.  
41. //CRC lookup table for the OO - Only include once for all 1-wire components
42. #if OO_CRC_EN == 1
43.   #ifndef OO_CRC_ROM
44.         #define OO_CRC_ROM
45.  
46.         ROMARRAY_S OO_CRC_ROM ROMARRAY_E = {0, 94, 188, 226, 97, 63, 221, 131, 194, 156, 126, 32, 163, 253, 31, 65,
47.                                                                         157, 195, 33, 127, 252, 162, 64, 30, 95, 1, 227, 189, 62, 96, 130, 220,
48.                                                                         35, 125, 159, 193, 66, 28, 254, 160, 225, 191, 93, 3, 128, 222, 60, 98,
49.                                                                         190, 224, 2, 92, 223, 129, 99, 61, 124, 34, 192, 158, 29, 67, 161, 255,
50.                                                                         70, 24, 250, 164, 39, 121, 155, 197, 132, 218, 56, 102, 229, 187, 89, 7,
51.                                                                         219, 133, 103, 57, 186, 228, 6, 88, 25, 71, 165, 251, 120, 38, 196, 154,
52.                                                                         101, 59, 217, 135, 4, 90, 184, 230, 167, 249, 27, 69, 198, 152, 122, 36,
53.                                                                         248, 166, 68, 26, 153, 199, 37, 123, 58, 100, 134, 216, 91, 5, 231, 185,
54.                                                                         140, 210, 48, 110, 237, 179, 81, 15, 78, 16, 242, 172, 47, 113, 147, 205,
55.                                                                         17, 79, 173, 243, 112, 46, 204, 146, 211, 141, 111, 49, 178, 236, 14, 80,
56.                                                                         175, 241, 19, 77, 206, 144, 114, 44, 109, 51, 209, 143, 12, 82, 176, 238,
57.                                                                         50, 108, 142, 208, 83, 13, 239, 177, 240, 174, 76, 18, 145, 207, 45, 115,
58.                                                                         202, 148, 118, 40, 171, 245, 23, 73, 8, 86, 180, 234, 105, 55, 213, 139,
59.                                                                         87, 9, 235, 181, 54, 104, 138, 212, 149, 203, 41, 119, 244, 170, 72, 22,
60.                                                                         233, 183, 85, 11, 136, 214, 52, 106, 43, 117, 151, 201, 74, 20, 246, 168,
61.                                                                         116, 42, 200, 150, 21, 75, 169, 247, 182, 232, 10, 84, 215, 137, 107, 53};
62.   #endif
63.  
64.         // CRC working variable
65.         MX_UINT8                ONEWIRE_6_oo_crc = 0;
66.  
67. #endif

Igen, éppen ez lenne a lényege mert a gyári makró egy kalap szerencsétlenség még önmagához képest is. Csak a OneWire TX és RX makrókat akarom használni, saját táblával a CRC számításhoz úgy, hogy a gyári tábla ne kerüljön bele feleslegesen.

A legeslegelső sorban CRC_EN 0, gondolom azért nem fordítja bele.

Erre gondoltam én is, "csupán" a biztos tudás hiányzik az ellenőrzéshez.

Sziasztok!
Nekem egy olyan kérdésem lenne, hogy:
Szeretnék építeni egy egyszerűbb akkumulátor felügyelőt. Ennek funkciója annyi, hogy ha a 14,8 V-ról leesik a feszültség 12 V-ra, akkor a PIC lekapcsolja a terhelést az akkuról.
Úgy gondoltam ezt megcsinálni, hogy egy feszültségosztóval csinálok egy PIC-el mérhető jelet (5 V max). Ezt rávezetném a PIC komparátorának Cin- lábára. Ehhez kötnék egy PIC-en belüli referenciaértéket.
A probléma: butáskodik a feszültség, ha nincs maxon a poti (szimulációban), akkor úgy működik kb, hogy amíg majdnem teljesen fel nincs tekerve a poti, addig 0,01-2 V van. Szóval valami a feszültségosztós résznél van probléma. ehhez kéne nekem valami segítség.
Mellékeltem a rajzomat (a LED egyenlőre a FET+terhelés) és a kódom.
Köszi előre is

Mert a GP1 port kimenetnek és 0-ra van állítva.

Arra a feladatra elég egy mezei analóg műveleti erősítő, meg egy feszültség referencia, és ki / bekapcsolgatni a relét az opa kimenetéről. Minek oda pic?

Szioasztok
Olyan kérdésem lenne hogy soros portnál a szint illesztés utáni rx tx -et lehet párhuzamosan használni egyszerre 3 picnél? Elküldött adatba külömböztetném meg hogy kinek kültem az adatot. pl <picid><Adatok>

Itt: Bővebben: Link.

Master device a pc pic a slave??

Teljesen mindegy, TX lábakat nem szabad közvetlen összekötni. A linkelt kérdés után van egy válasz, azt is olvasd el.

Hopsz igen ott a válasz.
Akkor 3db szintillesztö mindegyiknek és szintillesztö ellöt közösitek pc felöli rész??
MAX232 használnék.

Itt: Bővebben: Link. A diódás megoldás jónak tűnik. Tesztelni nem teszteltem, ilyenre még nem volt szükségem.