Mégis hány kimenetre lenne szükség?
PIC18F2550: 18 18F4550: 29 kimeneti lába mehetne az ULN -ekre. Szerintem ez kevés. Ráadásul a 18 - 29 vezérlés közös árama mind a kontrollert tartalmazó panelen menne kereszül. 100mA /kimenettel számolva ~ 3A áram is összejöhet.

Ennél sokkal több kimenetre kellene méretezni, ha lehet modulárisra.
SPI:
Ha az ULN -eket 8 vagy 16 bitesével 1 vagy 2 74HC595 / CD4094 vezérelné, akkor 8 / 16 vezérlésenként egy modul keletkezne. Ezeket a modulokat lehetne láncba fűzni. Ha a felület SPI és mondjuk 64 modult használsz fel (64*16 bit = 1024 kimenet már elég nagy pályaudvar) és mondjuk 100kHz -vel lépteted ki a biteket, akkor az összes kimenet frissítése 10.24 ms alatt megtörténne. Ehhez nem kell csak két kimenet (SCK és SO), azaz egy 14 lábú 16F1455 is meg tudja csinálni. A modulok külön tápbecsatlakozással rendelkeznek maximálisan 1.6A árammal. Egyszerűbben is gyártható a panel... Ezzel a megoldással nem tudod visszaolvasni a kivitt adatokat. A USB - SPI konverter programja függ az alkalmazott modulok számától.
I2C:
16 bites I2C portbővítő (MCP23017) -ből csak 8 db tehető fel egy buszra, így buszonként 128 bit vezérelhető és olvasható vissza. Több buszt kellene kialakítani, de a kontrollerekben csak 1 illesztő van. A többit programból kell megoldani. De I2C slave -ként használható kontroller is (pl. 16 bitre egy 16F883), ekkor nincs a gyári megkötés a cím felső 4 bitjére, azaz elvben 128 kontroller is köthető lenne egy I2C buszra, ami 2048 visszaolvasható kimenetet eredményezne. A busz működéséhez két nyitott kollektoros vezeték kellene, ami zavarérzékenyebb, mint az SPI megoldása. Ezenkívül a vezetékeken kétirányú átvitelt kell biztosítani, ami megnehezíti az optikai leválasztást.
RS485:
A kontrollereket alkalmazó I2C -s meholdással kb azonos költségű megoldás. Az RS485 - TTL konverzió után a jel mehet a modulok kontrollreére, 16 bites modulhoz jó a 16F883. Az adatok visszaolvashatók. Az optikai leválasztást a modulok TTL szintű uart jeleninél célszerű megcsinálni.

En kihagynam a 4094-eket, egybol a lancolt kimenet ra a TPIC-ekre.
Esetleg egy buszmeghajto (ha jol emlekszem, a 245-os) jo lenne a kozos jelekre (pl. CLK, OE, CS, stb), mert ennyi IC mar fogyaszthat boven 10 mA nagysagrendu aramot is.
MIndenkeppen javaslom a tobbi vezerlolab tovabbvitelet is, mert igaz, hogy a shifteles ideje gyors, de akkor is fals felvillanasok vannak. Ha hasznalod a 'hatter' tarat a shifteles ideje alatt es csak ha kesz, akkor irod at a LATCH regiszterbe, akkor ez teljesen kikuszobolheto.

pgabor: ez igaz, viszont a kikuldes igen gyors (ezek a regiszterek a 10MHz-et siman viszik, de legyen csak 100kHz, mint a fenti peldaban, ez az emberi szem fotopias idobeli felbontokepessege hataran jar, szoval pont a 'szempillantas' idejebe esik
Es ha hasznalja a TPIC tobbi vezerloregiszteret, akkor ebbol semmit nem lat a felhasznalo.

Sziasztok,
A következő lenne a kérdésem, a cikkek között található JDM mennyire aktuális még? Érdemes e megépíteni? Egyenlőre csak tanulgatom a dolgokat, nincs konkrét célom még, és egy 16F887-essel gondoltam kezdeni a kísérletezgetést.

Szerintem olvasd el a lap tetején található sárga mezőt...

Hát elég sok verzió született, már végképp nem tudom mit csináljak, valami próbát pedig meg kellene építenem, ahhoz meg vásárolnom
Ma voltam egyeztetni költségvetésileg, hát eléggé szűkösen kell megoldani. Ebből adódóan akkor az RS485 és I2C kiesik.

Konkrétan lenne szükség körülbelül ~150 db kimenet lenne (izzók) és bemenetként kb. 60 db nyomógomb.
Ez az SPI megoldás még nagyon homályos nekem, de ha jól gondolom, sokkal több elektronikai egység kellene, mintha az ULN-eket a buszvezetéken sorosan kötném.

Ha erre a 150 kimenetre egyszerre küldeném ki a bitsorozatot (nem célorientáltan), akkor kb. milyen veszteségre számítsak? Ilyen kimeneti mennyiségnél is működne ez a LATCH-enable dolog?
Ha jól gondolom, akkor az ULN-ekkel így nem lenne megoldható a nyomógombok "észlelése", mivel egyoldalú lenne az adatátvitel. De mondjuk lehetne a nyomógombokra külön áramkör?

Szia!

Pont erről mesélek. Nézd meg a VFD óra vezérlését...
Az UNL -ek nem tárolnak. A 74HC595, TPIC6C595 tárol és a léptető regiszter egy kimeneti regiszteren keresztül vezérli a kimeneteit - a beléptetés nem látszik a kimeneten.

Maradnék a kaszkádosításnál, mint 20 kiválasztó jelet vigyek át a külön címzéshez.
Ha a gombokat 74HC166 párhuzamos beírású léptető regiszterekből kialakított lánc bemeneteire kötöd, akkor a 60 gomb állapotának beolvasása sem gond, egy vezetékkel kell több: 74HC166 SHIFT/LOAD. A két csoport egyéb vezérlőjelei lehetnek közösek. Ez a megoldás több gomb állapotát olvassa be, de a program csak a kiépítettek adatát továbbítja.
Kimenetek: 150 ~ 20*8: 20 db TPIC6C595 vagy 20 db (74HC595 + UNL),
Bemenetek: 60 ~ 8*8: 8 db 74HC166
Meghajtás: 1 db 74HC244.
Vezérlő: 1 db 16F1455 vagy 16F1459 vagy 18F2550
Még a tápfeszültséget, az áramfogyasztást is mérheted a beépített A/D átalakítóval.

sziasztok!

Hogy tudom az UART -nál kimérni oszcilloszkoppal, hogy a Baudrate pl. 9600 Kbaud?
1/9600k kb. 104.2e-9

Ha küldök egy 0x55 -t üzenetként, akkor egy bit ideje ez a 104.2e-9?

Oszd el/szorozd meg azokat az értékeket 1000-el és akkor jó lesz.

Van nekem kb 25-30db TPIC6c695-osom, beforrasztva (mar) hulladekpanelre. Biztosan mukodtek, mert ebbol volt a szines ledes csikvilagitasom. A ledeket mar kiszedtem belole.
Postakoltsegert viheted.

Tehát:
Baudrate: 9600k
1/9600k = 104.2e-9

A jelem 2 információt hordozhat: 0 v. 1 azaz 1 bit információt viszek át
Akkor 1s alatt 9600 000 bitet tudok átvinni. Ami: 9600 Kbit/s


Ha 0x55 = 0b01010101 küldök,
akkor ezt a byte -t 104.2e-9s alatt viszi át?
és egy bitet 104.2e-9s / 8 = kb. 13e-9s

Ez a gondolatmenet eddig stimmel?

Az nem stimmel, hogy a sebesség nem 9600kbit/s, hanem 9600bit/s. És ne keverd, a biteket a bájtokkal, egy bit átvitelének az ideje az 1/9600, vagyis 104.2e-6 másodperc. Egy bájt átvitele tízszer ennyi ideig tart, mivel van start és stop bit is.

Baudrate: 9600
1/9600 = 104.2e-6

A jelem 2 információt hordozhat: 0 v. 1 azaz 1 bit információt viszek át
Akkor 1s alatt 9600 bitet tudok átvinni. Ami: 9600 bit/s


Ha 0x55 = 0b01010101 küldök,
akkor ezt a byte -t + start és stop bitet 104.2e-5s alatt viszi át
és egy bitet 104.2e-6s alatt.

Köszönöm

Lenne még egy kérdésem a UART -l kapcsolatban.
A uC -m támogatja a hardware flow control -t. Ha engedélyezem a Transmitter clear-to-send opciót, akkor elvileg a uc automatikusan vezérli az adatátvitelt?
Vagyis nekem szoftveresen nem kell egyebet tennem, csak ezt engedélyeznem?

Köszönöm!!! Valószínűleg élni fogok az ajánlattal, majd privátban megkereslek!

Elnézést, hogy ennyi alapvető dolgot kérdezek, de örülök, hogy ennyire segítőkészek vagytok.

Ha kimenetként tehát TPIC6C595-öt alkalmazok, ráengedhetem közvetlenül a 24V-ot és az izzókat?
Utánaolvasgatok majd jobban a dolgoknak, és megpróbálok majd egy blokkvázlatot készíteni az elemekről, hogy jól képzelem-e el a szisztémát. Mert ennek az áramköri kapcsolásától meg eléggé messze áll a tudásom.

Igen, mivel nyelokent van definialva. Tehat az izzo egyik vegere direktbe kapcsolod a 24V-ot (remelem, egyenfeszrol beszelunk), a masik vege megy az IC-be kozvetlenul.
Az ic-t magat 5V-al taplalod meg a Vcc bemeneten. A TPIC IC-k foldjeit csillagpontosan kozositenem - ugyanoda megy a 24V-os tap foldje is - mert ott komolyabb aramok mehetnek.
A digitalis foldeket osszefognam es a vegen ugyanabba a csillagpontba vezetnem.
Termeszetesen idejon az USB vezetek es a 2550-es foldje is.
Ezeket a vezetekeket vagy vezetosavokat jo vastagra erdemes kesziteni. A +tap feloli vegek nem tulsagosan igenyesek. Szurni es stabilizalni a digitalis tapokat erdemes.
En a helyedben kihagynam az USB tapjat a bulibol es kapna kulso, stabilizalt 5V-os tapellatast a PIC2550 es a TPIC IC-k is.

Ebben az esetben azonban figyelni kell, hogy az USB-re rá van-e csatlakoztatva az eszköz. A gyári demókban viszont általában ki van kommentelve (nem aktív) ez az opció:

Hoppa, koszi, igazad van. A sajat csapdamba estem. Szoval kaphat a 2550-es taplalast a PC-rol, a tobbi TPIC pedig 5V-ot mashonnan, csak a foldek legyenek kozositve a megfelelo csillagpontban.

Sziasztok!
Mehet a PIC a saját tápjáról is, a USE_USB_BUS_SENSE_IO -t be kell állítani, ki kell építeni egy digitális bemenetet, ami az USB +5V táp jelét figyeli, ennek a bemenetnek a nevét is meg kell adni a USB firmware -nek. A táp figyelésénél ügyelni kell arra is, hoy előállhat az az eset is, hogy az USB tápja megvan, de a saját táp nincs meg. A figyelést úgy old meg, hogy az USB +5V tápját egy ellenállással a föld felé terheled (alacsony szintet ad, ha nincs meg az USB +5V) és egy nagy értékű (100k) ellenálláson keresztül vezesd a bemeneti lábra (magas szint, ha megvan az USB +5V). A nagy értékű ellenállás megakadályozza, hogy a bemenet beépített védődiódáin keresztül kapjon feszültséget az 5V -os saját táp és maga a PIC. Ha a fentieket beállítottad, akkor engedélyezi csak a firmware az USB illesztőt, ha érzékeli az USB tápot.

Valaki tud esetleg hardware flow control -l kapcsolatban segíteni?

A uC -m támogatja a hardware flow control -t. Ha ezt engedélyezem akkor a hardware elvégzi ezt a flow control vezérlést? Nekem szoftver részről ezzel kell valamit csináljak? Csak beírom send buffer -be az adatom
és a többiről a hardware gondoskodik? Flow controlhoz szükséges a clear-te-send és request-to-send opció is? Csak simán clear-to-send -l működhet a kommunikáció?

Nem tudunk rá válaszolni, ha nem árulod el, hogy konkrétan milyen mikrovezérlőről van szó, hogyan engedélyezed az adatfolyam vezérlést, és milyen módban (simplex/duplex?), és hogyan szeretnéd használni azt.

Ezektől függően lehet a válasz igen, vagy nem.

Sziasztok,
A közeljövőben (első szabadabb hétvégémen) tervezem megépíteni a Szilva féle PICKit2 klón-t.
Az lenne a kérdésem hogy kinek mi a tapasztalata vele, ha van?
Illetve ha nem beszéltek le róla, akkor a firmware-t hol tudnám beprogramoztatni? valaki vállal e ilyet? (Budapesten)
Előre is köszönöm

Szia!

Vélemények a PICkit2 klón építése topikban. Ha most állsz neki és még nem készítettél panelt, inkább a Watt féle vagy a furatszerelt verziót ajánlanám. Több, mint kétszeres a kezelhető kontroller típusok száma.

Köszönöm, azt hiszem ennek megfelelően fogok választani akkor.

Sziasztok!

Köszönöm szépen, megépítem az alapkapcsolást és a napokban majd ismét fogok jelentkezni, mert biztosan lesz még krédésem!

Köszönöm az eddigieket.

Sziasztok!
Van ötletetek hogy erre a progira a 16f1512 mért csak magasat ad ki a portokra mért nem villogtatja a ledet ?


Köszi

Szia!
Van! banksel ANSELB clrf ANSELB

Nem nem ez lesz az nem értem mért nem működik

Watchdog le van tiltva?

Nem jó az se letiltottam de az se
De ennyit mit ki ír az mplab:
Message[303] D:\DOCUMENTS AND SETTINGS\RENDSZERGAZDI\MPLABXPROJECTS\FUTOFENY.X\16F1513.ASM 2 : Program word too large. Truncated to core size. (FFFC)
Message[302] D:\DOCUMENTS AND SETTINGS\RENDSZERGAZDI\MPLABXPROJECTS\FUTOFENY.X\16F1513.ASM 8 : Register in operand not in bank 0. Ensure that bank bits are correct.
Message[302] D:\DOCUMENTS AND SETTINGS\RENDSZERGAZDI\MPLABXPROJECTS\FUTOFENY.X\16F1513.ASM 13 : Register in operand not in bank 0. Ensure that bank bits are correct.
Message[302] D:\DOCUMENTS AND SETTINGS\RENDSZERGAZDI\MPLABXPROJECTS\FUTOFENY.X\16F1513.ASM 16 : Register in operand not in bank 0. Ensure that bank bits are correct.
Message[302] D:\DOCUMENTS AND SETTINGS\RENDSZERGAZDI\MPLABXPROJECTS\FUTOFENY.X\16F1513.ASM 18 : Register in operand not in bank 0. Ensure that bank bits are correct.
Message[302] D:\DOCUMENTS AND SETTINGS\RENDSZERGAZDI\MPLABXPROJECTS\FUTOFENY.X\16F1513.ASM 22 : Register in operand not in bank 0. Ensure that bank bits are correct.
Message[303] D:\DOCUMENTS AND SETTINGS\RENDSZERGAZDI\MPLABXPROJECTS\FUTOFENY.X\16F1513.ASM 27 : Program word too large. Truncated to core size. (FFFC)

Nem értem mire utal de lehet ez a baj.