- A Corsair égisze alá kerül a Fanatec
- Megérkezett a Corsair új M.2-es SSD-je, és mindennek mondható, csak lassúnak nem
- Módosít a memória sebességének jelzésén a Microsoft
- Elveszítette az egyik legnagyobb kínai partnerét az Intel és a Qualcomm
- Átlátszó OLED kijelzőket építenek az ablakok helyére a koreai metróban
- Fejhallgató erősítő és DAC topik
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Milyen videókártyát?
- Sony MILC fényképezőgépcsalád
- Canon MILC: EOS R és M topik
- HiFi műszaki szemmel - sztereó hangrendszerek
- Hobby elektronika
- TCL LCD és LED TV-k
- 5.1, 7.1 és gamer fejhallgatók
- Azonnali informatikai kérdések órája
Hirdetés
-
Enduro változatot kapott a Mobvoi TicWatch Pro 5
ma WearOS 3.5 rendszerrel és kettős FSTN és AMOLED kijelzővel érkezik az új modell.
-
Már nem hisz a nagy európai EV-forradalomban a Ford
it Meggondolta magát a Ford, a helyzetre való tekintettel 2030 után is kínálhat Európában hibrid és benzines autókat.
-
Módosít a memória sebességének jelzésén a Microsoft
ph A Mhz megy, a MT/s paraméter pedig jön, amitől kevesebb félreértést várhatnak a gyártók.
-
PROHARDVER!
Ez itt, az elektronikával hobbiból foglakozók fórumtémája.
Lentebb összegyűjtötttem néhány elektronikával kapcsolatos, hasznos linket.
Új hozzászólás Aktív témák
-
And
veterán
válasz lmaresz #49132 üzenetére
Ha néhány - vagy akár csak egyetlen darab - ledet felcserélsz a 'normálisan működő' és a 'hibás' csoportok között, és a jelenség ugyanaz marad, akkor a hibát nyilván nem a ledek okozzák, hanem a beküldött adattal van valami gond. Mindenesetre eléggé gyanús, hogy a jelenség egy csoportban, a felső sorokban jelentkezik, talán az adat is abban a fizikai sorrendben van rajtuk léptetve? Az időzítések 150 ns-os tűrése is elég szoros az adatlap szerint.
-
And
veterán
válasz lmaresz #49139 üzenetére
Mivel a vezérlőjel betáplálási helyének megváltoztatása 'eltolja' a hibás működés kezdeti helyét, ez egyértelműen vezérlési gond, maguk a ledek hibátlanok. Innentől csak az a kérdés, hogy miért pont 96 ledig jó: mi történik a 97. példánynál avagy a 7. sorban, főleg akkor, ha a szoftver ciklusokban küldi az adatot (oszlopok / sorok), és minden ciklus illetve oszlop-sor átváltás elvileg egyforma.
-
Batman2
őstag
válasz lmaresz #49991 üzenetére
Vannak megfelelő előtét ellenállások az egyes színek előtt?
Mert ha pl. egyforma értékű ellenállásokat tettél be az összes szín elé, akkor ne csodálkozz a feszültségesés külöbségen, mert amekkora érték pl. elég egy kék kristálynak az több mint sok a piros kristálynak, ami nagyon nagy áramot fog felvenni éa akkor is sokkal nagyobb feszültségesést fog okozni a tápban, ha nem haladja meg a táp korlátait,mert a táp stabilitása egészen biztosan nem 1-2százalék eltérést, hanem vagy legalább 10-et enged meg!
Tehát az egyik megoldási lehetőség, hogy minden egyes színnek biztosítod az azonos áramfelvételt, azonos feszültség mellett, a másik lehetőséged pedig, hogy a vezérlő egységet külön stabilizált tápról hajtod, vagy pedig külön szüréssel, puffereléssel próbálod meg stabilizálni a vezérlő egység részére a feszültséget, esetleg valami kis feszültségesésű stabilizátor ic használatával pl. 78Lxx sorozatból, vagy más sorozatból.
Üdv.Batman2 - Viva la Mercedes W123-200D 1979
-
And
veterán
válasz lmaresz #50011 üzenetére
Ja, most már rémlik ez a 96. ledtől elkezdődő probléma, ami mindenféle ledkonfigurációnál a 96.-ra jött ki. Már elég régen volt, ezek szerint azóta sem oldódott meg.
"Esetleg megoldás lehet rá, hogy több párhuzamosítást csinálok [..]"
Az 1,5 mm^2-es vezeték métere kb. 11mΩ ellenállású, nem tudom, milyen hosszan van vezetve. Továbbra is kérdés, hogy a táp nem megfelelő stabilitása okozza-e a feszültségesést (a táp sorkapcsinál is mérhető-e nagyobb áramú terhelésnél), vagy a vezetékezés, és hogy utóbbi számít-e. Sajnos a led egyoldalas (csak olyat találtam) adatlapja homályban hagyja a vezérlőjelek szükséges szintjét, nem túl alapos a doksi. Viszont a GND / 0V-os ágat ilyen nagyságú áramoknál valóban illene nem besorosított, hanem csillagpontos vagy nyák esetén 'telefóliás' kivitelre készíteni, hogy az egyes ledeknél a GND-feszültség ne másszon el (a táptól távolodva egyre jobban) a referenciaponthoz képest.[ Szerkesztve ]
-
Batman2
őstag
válasz lmaresz #50009 üzenetére
Az csak azt jelenti, hogy egy áramkör van előttük, ami vezérli a mátrixot, nyilván nem magától megy, de attól még a LEDeknek kell velemi előtét, ha nincs, akkor mert az IC pl pwm-mel szabályozza az áramot, akkor viszont akár természetes is lehet ez a különbség.
Ha abban nem tudsz, vagy nem lehet, vagy nem akarsz, bele nyúlni, akkor marad a külön táp.Azt még megteheted érdekesség képpen, hogy a három alapszínre vezérled a mátrixot és mindegyiknél egyenként leméred az áramfelvételt, illetve méred a táp fesz. esését a LEDmátrix pnelján és a tápegység panelján is, akkor azt is meg tudod látni, a táptól a mátrixig mekkora a fesz. esés.
Üdv.
[ Szerkesztve ]
Batman2 - Viva la Mercedes W123-200D 1979
-
And
veterán
válasz lmaresz #56261 üzenetére
Akkor is ezt csinálja, ha nem ellenőrzöd a busy flag-et, hanem helyette késleltetést használsz (vagyis a writeLCD hívásánál a CheckBusy-t 0-ra állítod)?
Mod: amíg nem tudsz rá bármilyen karaktert kiküldeni, hogy bizonyosodsz meg arról, hogy az inicializálás rendben megtörtént, és a kapott parancsot végrehajtja? Mondjuk bekapcsolod a villogó kurzort és elviszed valahová a kijelzőn?[ Szerkesztve ]
-
And
veterán
válasz lmaresz #56273 üzenetére
Következő teszt: mi történik, ha egy sikeres parancsot / inicializálást követően csak egyetlen karaktert küldesz rá? Mintha parancsot küldenél, egy darab byte-ot, de adatként (RS = 1). Bármelyik latin ASCII-karakter megteszi, például az "A", kódja: 65 (ezen karakterek valószínűleg ugyanúgy néznek ki eltérő verziójú CGROM-ok esetén is).
-
And
veterán
válasz lmaresz #56277 üzenetére
Na, most ha kihagyod a harmadik writeLCD-t (0x41,1,0), és úgy a kurzor a 2. sor 1. karakterénél villog, akkor az olyan, mintha a vezérlő ugyan kiírná azt a bizonyos 0x41 karaktert, de annak a helyén a CGROM-ban nem lenne semmi. Vagyis minden egykarakteres normál adatírásra eggyel ugyan jobbra tolódik a kurzor, de azon a pozíción, ahonnan továbblépett, üres karakter jelenik meg. Ezt még érdemes lenne kipróbálni.
Úgy tűnik, alapvető hiba nincs semmivel, hiszen a parancsot a DDRAM írásától csak az RS-jel állapota különbözteti meg, és előbbi működik. Az időzítésekkel sem lehet túl nagy gond. Ami még érdekesnek / furcsának tűnik, az a BF-check kódrészletben a "TRISD = 1; ", mivel az csak a PortD.0 lábat konfigurálja inputnak, a PortD többi lába output marad, miközben a Busy-flag az RD7 lábon érkezne meg. A teljes PortD bemenetté állításához ugye "TRISD = 0xff " kellene, de ez az egész úgysem számít, ha BF check helyett késleltetést kérsz a writeLCD-ben. -
And
veterán
válasz lmaresz #56281 üzenetére
A BF check amúgy sokszor hanyagolt dolog, mert úgy egy pin-t (az R/W-t) a kontroller felől meg lehet spórolni: a BF helyett sima késleltetést alkalmazva nincs szükség a modul olvasására, az LCD R/W-bemenete fixen 0V/GND-re köthető. 4-bites adatátviteli móddal újabb 4 pin spórolható, úgy 11 helyett már csak 6 darab I/O kell a teljes vezérléshez.
"Ahogy mondtad, kikommenteltem a sort és most a 2. sor 1. karakterén villog a kurzor."
Ha úgy tűnik, hogy egy n-elemű string kiküldésekor a kurzor éppen n pozícióval megy jobbra a kiindulási helyéhez képest, és közben nem jelenik meg semmi (a kontraszt nyilván rendben van, egyébként a kurzor sem látszódna), az minimum érdekes. Akkor kipróbálnám egy teljesen más típusú HD44780-kompatibilis modullal, vagy bevetném azt a trükköt, hogy a CGRAM-ba, mondjuk a 0. pozícióba beleírnék egy akármilyen karaktermintát - ha jól emlékszem, az eredeti HD vezérlő esetén a 0..7 című karakterek képe módosítható - és megpróbálnám azt a karaktert kiküldeni a kijelzőre. Ha az megjelenik, akkor valami gond van a fix tartalommal, de én ilyennel még nem találkoztam, úgyhogy simán lehet más probléma is, de több ötletem nincs.. -
And
veterán
válasz lmaresz #56299 üzenetére
Azt a lehetőséget még megvizsgálnám, hogy véletlenül nem a read-modify-write probléma-e a jelenség gyökere. Bővebb infó az RMW-ről: [link]. Ilyen jelenséget nem csak a portlábakkal direkt párhuzamosan kötött, hanem akár a jóval kisebb szórt kapacitások is okozhatnak. Különösen igaz ez akkor, ha magas az órajel frekvenciája, pl. HS-oszcillátort használsz 10 MHz nagyságrendű kvarccal, de kisebb órajelen is előfordulhat (kialakulása az órajelen felül a kapacitás függvénye). Én már futottam bele ilyen írási problémába korábban: a kóddal látszólag minden rendben volt, mégsem azt tette, amit elvártam tőle. Minimális késleltetés (akár egy NOP) beszúrása eltüntette ezt. Ami a te esetedben e lehetőség mellett szól, az az, hogy több olyan port írási műveletet látni, amelyek kis időkülönbséggel történnek ugyanazon a 8-bites porton, ami pedig ellene, hogy a jelenség esetleges. Mindenesetre próbálkozhatsz azzal hogy az ilyen jellegű írások közé rövid, µs nagyságrendű késleltetéseket teszel, hasonlóan az E-jel pulzus megoldásához, bár ott nyilván más, a minimális impulzushossz biztosítása volt a célod vele. Ugyanilyen késleltetések beiktatása célszerű lehet az adatirány váltások (TRISx) után is, ha a BF-check marad. Mivel a teljes port - nálad: PortA - egyidejű írása az LCD-vezérlőhöz szükséges minimális időzítések miatt nem járható, azzal is próbálkozhatsz, hogy külön portcsoportokra teszed az RS, RW és E-jeleket. Legalább ideiglenesen, mert amúgy ez nem túl életszerű megoldás.
Új hozzászólás Aktív témák
- Fejhallgató erősítő és DAC topik
- Politika
- Autós topik látogatók beszélgetős, offolós topikja
- Külpolitika
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Dragon Age: Origins
- Háztartási gépek
- Milyen videókártyát?
- Sony MILC fényképezőgépcsalád
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest