knihovna pro 74HC595 s PWM ??

Ahoj,

nemáte prosím funkční knihovnu v C pro AVR a 74HC595 s využitím PWM??

+Zajímá mě, kolik pinů na to budu potřebovat…
(standardně jsou využity tři…, nevím, jak se pracuje s 595 a PWM…)

Současně mě zajímá, jakej je rozdíl při využití SPI vs na běžné piny??
Je SPI kvůli rychlosti PWM v tomto případě nutné??

Díky

Za chvíli se bude shánět knihovna i na rozsvícení LEDky :laughing:

Ale k věci :

Využití PWM znamená co ? Buď chceš kmitat jedním pinem, pak musíš cyklicky odesílat data do 595-ky (nebo do jejich řetězu) nebo chceš kmitat všema pinama najednou.

V první variantě Ti stačí 3 piny pro data, hodiny a zápis, ve druhém potřebuješ k tomu ještě G, kterým posíláš PWM signál.
SPI port použiješ hlavně v případě, že pošleš byte z mcu (zápisem hodnoty do jednoho registru = jednou instrukcí) a pak se program může věnovat další činnosti a po ukončení přenosu můžeš nechat vyvolat přerušení, ve kterém třeba pošleš další byte (pokud posíláš řetěz dat) nebo pošleš signál pro zápis (na konci řetězu dat). V případě použití standartních pinů se SPI přenosu musí MCU víc věnovat. Buď prostě funkcí generuješ signály (pak se MCU přenosu věnuje po celý čas přenosu) nebo můžeš přenos “rozfázovat” a použít k tomu časovač. V případě použití časovače se MCU o přenost stará jen v okamžiku náběžné a sestupné hrany hodin - ale vzhledem k tomu, že i na takhle jednoduchou věc, jako je SPI přenos sháníš knihovnu, tak bych řekl, že s tím časovačem to bude na Tebe moc…

Použítí PWM signálu pomocí G vstupu 74595-ky. Má to své výhody :

  1. nemusíš kolem dokola posílat ven data
  2. můžeš generovat PWM pomocí HW

Ale i nevýhody :

  1. Nemůžeš měnit jenom jeden pin, ale vždy všechny
  2. Na výstupech z 74595-ek se nestřídá 0<->1, ale log. hodnota pinu<->stav vysoké impedance

Jinak mi můžeš věřit, že než dlouhé dny prohledávat Internet, bude pro Tebe daleko rychlejší a přínosnější sednout si k datasheetu 74595-ky, projít si signály a pak si přenos naprogramovat. Neměl bys s tím strávit víc, než půl hodiny.

Projdi si v klidu datasheet k 74595-ce a hlavně tady upřesni, jak jsi to myslel s tím PWMkem.

Pokud se Ti signály s datasheetu nepodaří vyčíst, dej vědět, do detailu Ti tu popíšu (já nebo někdo jiný), jak má přenos vypadat. Pak už si to podle toho naprogramuješ.

Díky moc za odpověď!

Zatím maluju plošný spoj pro speciální ukazatel se 120 LED…a říkám si, že to rovnou namaluju tak, abych případně mohl využívat PWM…

Líbil by se mi nějaká obecná knihovna, ve které by se dal nastavit jas každé LEDky zvlášť =>tohle je ten první způsob, o kterém jsi mluvil…

Jenže při řetězci 120 LED to bude docela fičák + knihovnu budu muset napsat nějak chytře.
=>při 255 úrovních jasu 30,6kHz

Zapojím teda asi klasicky tři dráty…
=>mnou použitá atmega32 nebude mít téměř žádné jiné úkoly, Metodou jedna jde vlastně nahradit i metoda 2 :wink:

Pokud nemáš nějaký pádný důvod k řízení jasu každé LEDky zvlášť, pak bych se do toho nepouštěl. Datově to problém není - 120 LEDek je 15 bytů (= 15x 74595 v řetězu), což při rychlosti, kterou můžeš data do 74595-ek posílat není problém. Znamená to ale v každém tiku cítače (ne cyklu, ale tiku = při každé změně hodnoty) porovnávat 120 hodnot a na základě toho zapínat/vypínat příslušný bit v posílaných datech. V tomhle případě by pro Tebe bylo ideální řídit jas kompletu pomocí G pinu 74595-ek. Data pošleš jednou a pomocí HW generátoru PWM řídíš jas celého displeje, nebo co to stavíš.

Tady nějak nerozumím těm 30,6kHz…
255 úrovní jasu je zbytečné, ale pokud to nebudeš přepínat ručně, tak to nevadí. Pokud nebudeš LEDky multiplexovat, tak nemusíš mít ani moc vysoký kmitočet. Když vezmu v úvahu, že Timer při Fmcu=8MHz a prescaleru čítače 64 přeteče 488x za sekundu, máš “zobrazovací kmitočet” 488 Hz. Pokud použiješ HW PWM na G, pak jas měníš zápisem jedné hodnoty do registru (OCRxy). Pokud použiješ prescaler jenom 8, pak dostáváš “zobrazovací kmitočet” 3906 Hz. A procesor se drbe za ušima, protože na PWMko programově nemusí sahnout …

Pokud bys řídil každou LEDku zvlášť, je třeba se poněkud přizpůsobit :
Dejme tomu, že “zobrazovací kmitočet” displeje dáme 200Hz, 100 úrovní jasu (PWM 200Hz, 100 stupňů) => 200x100=20 000 Hz => 20 kHz 8MHz/20kHz=>8000kHz/20kHz=400 => máš 400 jednotaktových (!!!) instrukcí na to, abys přepočítal 120 LEDek, odeslal je na SPI a udělal ještě to ostatní, co potřebuješ udělat. Tohle si myslím, že je nereálné i pro assembler. Se “zobrazovacím kmitočtem” (PWM) 100Hz už to bude asi šlo zvládnout, ale máš 800 instrukcí k dispozici. Řešení by bylo použít krystal a nataktovat mcu na 16 MHz.

Samozřejmě záleží na Tobě, pro jaké řešení se rozhodneš.

Zamyslil bych se spíš na jinou věcí. A to je odběr toho celého. Pokud nemáš nějaký důvod, aby svítily všechny LEDky najednou (třeba, že budou sloužit jako osvětlení), pak bych se zamyslel spíš nad tím, rozdělit je do skupin (třeba 4x30 LED) a multiplexovat je. Tím se dostaneš na maximální proud 0,6A. To sice taky není úplně málo, ale je to lepší, než 120 LEDek najednou. Při 20mA/LEDku je to totiž 2,4A. To už je celkem slušnej proud. Řídit jas každé LEDky také lze - i když interně se 120-ti porovnáním nevyhneš. Má to samozřejmě i nevýhodu v tom, že když použiješ multiplex 1:4, tak snížíš maximální jas každé LEDky.

Pokud nebudeš LEDky napájet z 12V (což bych nedoporučoval - protopíš zbytečně moc výkonu na omezovacích odporech). Napájel bych to celé buď 5V nebo 3,6V. Ale ne 7805-kou (při 12V napájení protopíš 7/12 výkonu na stabilizátoru) - použij nějaký pulzní stabilizátor. Například pro 3A stabilizaci z 12V na 5V nebudeš potřebovat ani chladič, což by se 7805-kou nebylo možné, protože by na ní bylo 3x7=21W …

Třeba tenhle umí výstupní napětí 0,8-24V, 3A :
tme.eu/cz/details/a8498sljt/ … rosystems/

Při použití muiltiplexu by Ti stačil i tenhle (1,5A) :
tme.eu/cz/details/mc34063adr … conductor/

Můžeš to pak napájet prakticky čím chceš (do max. vstupního napětí stabilizátorů, což je 40V pro MC34063 a 50V pro Allegro) a nemusíš se bát, že se Ti stabilizátor upeče.

Jen poznámka k řízení jasu. Proud a tudíž i střída musí chodit logaritmicky, jinak jsou ty změny při vyšším jasu už neznatelné.

Tomuhle moc nerozumím…

Když to vezmu úplně od začátku, moje úvaha je taková:

  • každá LEDka se musí obnovovat minimálně 70 krát za sekundu, aby nebylo vidět, že bliká =>70Hz

  • PWM o 100 stupních =>70*100Hz

  • 120 LED - taktovací frekvence procesoru 70100120Hz

Výsledná frekvence 840kHz (nějaký pro mě neznáný čas zaberou operace MCU)

…nicméně s použitím krystalu 14,7456MHz by asi neměl být problém, ne?

Neorientuju se v časech provádění operací, rád se poučím.

Jinak, předpokládám, že pokud nepoužiju SPI, je asi zbytečný využít posuvné registry v rychlém provedení AHC ??

S napájením počítám, mám zelené supersvítivé LED 3mm, s 1k odporem žere jedna LEDka okolo 3mA …takže to bude docela v klidu :wink:

Asi to budu napájet rovnou z +5V zdroje, na desku jsem namaloval 5x 1000uF elektrolyt :smiley:

Přenos 15 byte přes SPI 7000x za 1s by snad problém nebyl. Generovaní těch 120 softwarových PWM budeš muset dobře zoptimalizovat v asm. Při 16MHz taktu procesoru budeš mít 19cyklů na jednu PWM. Otázka je jestli procesor stihne dělat ještě něco jinýho, třeba komunikaci přes usart abys tam ty hodnoty jasu nějak dostal.
Každopádně na tohle hnihovnu nenajdeš :slight_smile:

Existuje nějaké všeobecné pravidlo, v jakých střídách se pohybovat??

Aby Tvoje oko vnímalo změnu jasu jako lineárně musí se ve skutečnosti měnit jas logaritmicky. Jas ledky v určitých mezích linárně kopíruje proud. Takže když budeš nastavovat střídu takto: 0,1,2,4,8,16,32,64,128 bude to oko vnímat jako 8 stejných stupňů. Mužeš ještě nastavovat poloviční diference, to je tak akorát.

Díky moc!