Vagy voltak régen azok a dip tokos relék 3v-os tekercsel, azzal is lehetne kapcsolni az osztót egy pillanatra.

Hát igen, mondjuk gondoltam kijelzem hogy "battery low, cserélni kéne".

De közben rátaláltam egy olyan fantasztikumra, amit DC/DC step-up konverternek hívnak és azon gondolkodom, mi lenne, ha ceruzaelemről menne a dolog.

És akkor elvileg a HE-s cikk szerint annak van olyanja (max856-ról beszélek), hogy szól az egyik lábán, ha kisebb a feszültség, mint kellene. Zseniális.

Alakul a kép!

Bár, mint az előbb írtam ciw-nek írt válaszomban, lehet, hogy más irányba indulok, de ezt a FETes dolgot akkor is mindenképpen tudni szerettem volna, mert érdekelt és ki is fogom próbálni!

Köszönöm!

Igen, ez sem egy hülye ötlet...

Ilyen megoldast ajanlottam a kolleganak. Azert jo igy elhelyezni, mert egyreszt csokkenti a kikapcsolaskor keletkezo ivet, a masik pedig, amikor az egocseres villanyreszelo kollega csereli a magneskapcsolot ugyis csak eldobna ezt a vackot, "mert minek ez a sz.r oda" . Utana mehetsz legelni mi okozza a zavart. Ugyanez a modszer hasznalatos a TRIAC aramkoroknel, ahol a dV/dT csokkentesere hasznalatos. Magyarul snubber.
De ennek a temanak keressunk valami mas topikot, mert a modulator uraktol kapunk. Igaz van benne PIC, ha az vezerli a relet.

Át kéne nevezni a topicot...

Jogos, elnézést, abbafejezem a FET-jeimet, csak a PIC AD-láb miatt indítottam itt.

Helló!
A nyáktervezés alapjaival igazad van, nem rég óta vagyok a szakmában és SOOOOKAT kell még tanulnom!
El tudod küldeni a te áramköröd kapcsrajzát, hogy megpillanthassam? Mondjuk képként? Ha nem szeretnéd publikálni küldheted ide is: panzer576@citromail.hu
Vagy esetleg van erről valami leírás, mármint a nyáktervezés alapjai vagy ilyesmi, mert régóta keresek ilyet, de sajnos sehol sem találok!
Köszi:
Panzer
[OFF]

Tudtok nekem mutatni egy működő 24 bit bináris -> 8 bit decimális átalakító rutint assembly-ben? Vagy meg tudjátok mondani hogy ebben mely regiszterekbe kell bemásolnom az átalakítandó 24 bites számot?

Ugy erted 24 bites pakolt BCD-bol 8 bites binarisba?

Az nem minden esetben fog neked elferni (999 -et nehez 8 biten tarolni...), igy javaslom 16 bitesre alakitsd, es mikor megvan ellenorizd, hogy belefer-e 8 bitbe. Ha igen akkor jo, ha nem akkor hibakezeles...

Packed BCD to 16 bit binary conversion

Arra az esetre ha ugy ertetted, hogy 24 bites binarisbol szeretnel 8 szamjegyes pakolt BCD-t eloallitani:

Binary to BCD unpacked, 24 bit to 4 digits

Nem, elírtam bocsi! Úgy értem hogy 24 bites binárisból 8 digitet kapjak meg 8 bájtban, BCD-ben.

Szenvedek ezekkel az átalakító rutinokkal. Eredetileg volt nekem egy csak most átültettem egy másik programba a szubrutint és itt nem akar működni. Próbálok rájönni hogy miért nem, egyenlőre még nem jöttem rá. Van benne néhány ehhez hasonló sor:

Itt mi történik? A TEMP nevű regisztert forgatja balra, de mi az F és az A? Ott 0-át vagy 1-et szoktam látni, nem betűket. De sejtem hogy az F azt jeleni hogy a balra forgatás eredményét magába a TEMP regiszterbe írja vissza és nem a W-be, ugye? Na és mi az az A-betű?

Na most adom fel. Ma egész nap ezzel szenvedek de nem jövök rá hogy mi a hiba:

Ez a 24 bit bináris -> 8 digit BCD átalakító szubrutin eddig működött a PIC-es panelmérő I és II áramköreimben. Most a panelmérő III fejlesztésekor valamiért nem megy. Bankváltás vagy lapszél problémája lehet esetleg de amennyire tudtam ezeket letesztelgettem és nem találtam hibát. Szóval nem tudom... Áttettem a szubrutint a program egy jóval távolabbi részére és ott sem megy és Watch ablakban azt is végignézegettem hogy ténylegesen változnak-e a regisztertartalmak. Nem tűnt fel semmi hiba pedig biztos hogy van mert a szubrutinból értelmetlen értékekkel tér vissza. A digit1-digit8 regiszterekben decimálisan rendre tizenvalahányas értékek vannak, pedig ugye maximum 9 lehetne merthogy decimálissá alakít elvileg.
(A program végén a "kicsomagolást" én írtam már hozzá, de eddig az is működött.)

Lehet írok magamnak egy saját kivonós konvertálást, ami kivonogat a számból tízmilliót, aztán milliókat, százezreket, tízezreket stb...
Csak hát mégiscsak egyszerűbb lenne ebbe életet lehelni ha már eddig működött.

Hmm, lehet esetleg hogy az a baj, hogy a TEMP regiszterek nem ott kezdődnek a memóriában ahol kellene lenniük? (Nálam 0x100-tól vannak.)

Igen, áttettem a 0x000-ra és így működik. Mit kellene benne átírni hogy menjen a 0x100 címről?

Szia!
Ebbe a csabdába nem most lépsz bele először...
E sor "24. btfssFSR2L,2,A" helyett kell az utolsó rekesz utáni címére komparálni.

Egyébként, ha a TEMP címe binárisan 00 -ra végződdik, jól működik módosítás nélkül.

Az A betű azt jelenti, hogy az ACCESS memóriaterületen értelmezendő a TEMP címe, vagyis ha a TEMP alsó bájtja 0x7F vagy kisebb, akkor az a nullás memóriabank alsó felére mutat, ha viszont nagyobb mint 0x7F, akkor az SFR zónára mutat. Tehát nálad hiába volt a TEMP változód a 0x100 címen, akkor is az RLCF TEMP, F, A azt mutatta, hogy RLCF 0x00, F, A, ami gyakorlatilag a 0x000 címen levő változót forgatta egy hellyel balra. Neked ezesetben be kell állítanod a BSR regisztert úgy, hogy az egyes memóriabankra mutasson, és RLCF TEMP, F, BANKED utasítást kell használnod, hogy az utasításban szereplő egybájtos címhez hozzávegye a BSR-ben található beállítást és így együtt mutasson a memóriaterületre. Vagy lehet, hogy BANKED helyett elég csak egy B betű is. Szimulátorban próbálgasd és meglátod, hogy működik a dolog.

Igen rémlett, vissza is olvastam. De akkor sem derült ki hogy hogyan lehet áttenni máshová a TEMP-eket.

Melyik az utolsó rekesz? A TEMP+7 címe azaz a 0x007, tehát a 0x008-ra kellene komparálni? Hogyan?

Ejnye... Ha b'xxxxxx00' a TEMP címe és a fenti sor vizsgálata jókor lép ki, akkor TEMP3+1 címének elérésekor kell kilépni a hurokból. Azaz a 32 bitnek megfelelően 4 byte -ot kell csak korrigálni...
Potyo bankolási észrevételét is vedd figyelembe.

Hát én ezt most nem értem. De nem baj, átraktam a 0x000 címre és örülök hogy most jó.

Inkább Mosfet mint tranyó...

Szia!
Mit nem értesz?
- A komment is sugalja:

Az átalakítandó szám a TEMP+7:TEMP+6:TEMP+5 rekeszekben van, a 32 bites BCD eredmény pedig a TEMP+3:TEMP+2:TEMP+1:TEMP rekeszekbe kerül. Minden léptetés után a BCD értéket korrigálni kell, ez csak a TEMP+3:TEMP+2:TEMP+1:TEMP rekeszeket érint. Ha a TEMP címe b'xxxxxx00', akkor a btfss FSR2L,2,ACCESS a b'xxxxx100' cím elérésekor lép ki, azaz ha a TEMP címe + 4 értéket éri el.
Ha nekem kell elmagyaráznom Neked a programod működését, miért nem teszed szabaddá a forrását? Ha még az írója sem érti???

Na ezt már értem, köszi!

Nem én írtam ezt a szubrutint hanem Te. Legalábbis anno te mutattad nekem. Ezt az egyet és a 32 bites osztásrutint lőttem csak a netről, a többit írtam én. Azokat értem is.

Sajnos nem az enyém a babér ezekért a rutinokért, de amikor átírtam 16F -ről 18F -re, kibővítettem 48 bitre, kénytelen voltam végigkövetni.

Írt már valaki PIC -el ModBus ra programot?
Én most ebben gondolkodom, és annyi lenne a dilemmám, hogy a ModBus protokollt felépítő 11 bites karaktereket elő tudom -e állítani a PIC UART moduljával.
Mivel a leírások alapján nem látok különbséget, így gyanítom, hogy igen. Viszont a neten bogarászva sehol nem találtam erre utaló forrást.
(A ModBus karakterében ugyanúgy használják a Start - Stop - Paritás biteket mint az RS232 -ben)

Ezek 9-bites karakterek. A Start és a Stop nem része az adatnak, azokat nem szokás számolni. Emlékeim szerint mindegyik PIC UART tud 9-bites adatot küldeni-fogadni. Viszont a modernebb PIC-ekben levők (pl. PIC32 széria tuti) HW-ből előállítják/ellenőrzik a paritásbitet, azzal sokkal kényelmesebben programozható ez.

Ez mitol lenne 11 bites? szabvany 8 bites adatatvitel. Egy byte (8 bit ) atvitele tortenik az altalaban hasznalt sorosatvitelnel. Persze a szabvany szerint 5, 6, 7 es 8 bites atvitel lehetseges. Az uzenet persze meg tartalmazza a start/stop boteket, valamint ha hasznalatos a rendszeren, a paritasbitet is. Termeszetesen a PIC USART hasznalhato erre a feladatra, viszont a frame csomagokat neked kell lezongorazni a PIC SW irasakor (Addr, Func, Data, CRC). Persze meg ugye csinalni kell egy RS485 illeszto HW-t is, hogy a szabvany Modbus-hoz tudjal csatlakozni. CCS C-ben van ra mintapelda is.

Köszi a válaszokat!
Lehet félreérthetően fogalmaztam, de 8 bites adatról van szó természetesen, csak a "maradék" 3 bit miatt neveztem a fizikai szinten 11 bitesnek.
Tudom, hogy a Start-Stop-Par sem számolódik bele a CRC be, és hogy a protokoll Addr, Func, Data, CRC frame SW -t nekem kell megírnom (RTU mode). A CRC programot már meg is írtam assemblyben, ez rendben működik a teszt byte -okkal. Az RS 485 illesztéshez MAX 485 öt vagy SN 75176 gondoltam.
Akkor ez egy sima PIC USART -al előaállítható karakter, ás a Start bitje Low, a Stop bitje High, mint az RS 232 nél?
Ha jól értem a ModBus működését már csak arra kell figyelni, hogy akkor kapok új framet, ha a vonalon min. 3,5 karakternyi hallgatás után (9600 nál ez 4 msec) a saját címemmel a mester megszólít?

Lehetoleg a szabvany elnevezest hasznaljuk, mert a masik csak nez mi az a 11 bites adatatvitel. Persze, hiszen a Modbuszosok sem talatak fel a melegvizet, csak alkalmaztak a regi RS232C szabvanyt, es hozza a RS485 vonalillesztest. A Frame termeszetesen egy kotott keretrendszer, aminek az eloirasait illik betartani, mert maskepp nem tudsz kommunikalni a tobbi keszulekkel.

Köszi, sokat segítettél bizonytalanságomban
Egyébként igazad van a 8 - 11 bites dologgal kapcsolatosan.