MojeFedora.cz informuje co nového přinese Fedora Workstation 34. Většinu uživatelů praští do očí přepracované GNOME 40, ale další důležité změny se dějí i pod povrchem. Wayland na grafických kartách Nvidia, Pipewire jako hlavní zvukový subsystém, Fedora Toolbox s RHEL, Flatpaky ve Fedoře s inkrementálními aktualizacemi.
Byla vydána verze 4.4 kolekce svobodného softwaru umožňujícího nahrávání, konverzi a streamovaní digitálního zvuku a obrazu FFmpeg (Wikipedie). Kódové označení Rao bylo vybráno na počest profesora K. R. Raa za práci na DCT (diskrétní kosinová transformace).
Český LibreOffice tým aktualizoval příručku LibreOffice Calc na verzi 7.0. Kniha je určena pro uživatele tabulkového procesoru LibreOffice Calc. Pokrývá hlavní oblasti programu Calc, včetně zadávání, úprav a formátování dat, funkcí a vzorců pro výpočty nad daty, statistické analýzy, kontingenčních tabulek a hledání řešení pro potřeby analýz, databázových funkcí pro nastavení, ukládání a filtrování dat, široké škály 2D a 3D grafů,
… více »Jamie Zawinski na apríla vydal XScreenSaver (Wikipedie) ve verzi 6.00. Přehled novinek v příspěvku na blogu a v changelogu. Proběhlo refaktorování kódu. Démon xscreensaver byl rozdělen na tři programy: xscreensaver, xscreensaver-gfx a xscreensaver-auth.
Byla vydána verze 2.3.0 kryptografického softwaru GnuPG (GNU Privacy Guard), tj. svobodné implementace OpenPGP. Jedná se o první veřejnou verzi z vývojové větve 2.3. Stabilní bude až verze 2.4.0. Z novinek lze zdůraznit podporu TPM (Trusted Platform Module) 2.0 aneb soukromé klíče lze chránit pomocí tohoto kryptoprocesoru. Více v příspěvku na blogu.
Úřad pro zastupování státu ve věcech majetkových (ÚZSVM) prodává v aukci 0,42337268 jednotek virtuální měny bitcoin (BTC). Nejnižší podání bylo 544 632,00 Kč. Aukce končí dnes v 15:00.
Firma IBM oznámila vydání překladače jazyka COBOL pro Linux na architektuře x86, verze 1.1. Podporované distribuce jsou RHEL aspoň 7.8 a Ubuntu LTS aspoň 16.04. Jak upozorňuje The Register, je to zřejmě pro běh stávajícího softwaru v „hybridním cloudu“ IBM a migrace mezi Linuxem, AIX a z/OS.
Byla vydána verze 2021.1 integrovaného vývojového prostředí IntelliJ IDEA (Wikipedie). Představení novinek na YouTube. Instalovat lze také ze Snapcraftu.
Microsoft oznámil, že nabízí vlastní distribuci OpenJDK (Open Java Development Kit). Ke stažení je také balíček pro Linux. Po změnách v licencování LTS verzí přímo od Oraclu vzniklo hned několik distribucí OpenJDK.
V únoru Google představil nový hlasový kodek Lyra s datovým tokem 3kbps. Včera na GitHubu zveřejnil příslušné zdrojové kódy. K dispozici jsou pod licencí Apache 2.0.
Proc se nepoohlidnes po nejakem programatoru s vlastni logikou - neco ve stylu PAtmelu za par stovek? Vzdycky me udivuje, kdyz se nekdo snazi casovat komunikaci se zarizenim na portu primo programem z user-space a pak se divi, ze to (vetsinou) nejede...
Vzdycky me udivuje, kdyz se nekdo snazi casovat komunikaci se zarizenim na portu primo programem z user-space a pak se divi, ze to (vetsinou) nejede...Háček je v tom, že avrdude přes paralelní port umí běžně programovat úplně bez problémů. Asi to bude mít nějakou souvislost s tím, že z toho portu odcházejí i hodiny, takže preempce toho programu nezpůsobí selhání funkce programátoru. Sám používám jako "programátor" paralelní port už dost dlouho a téměř bez problémů.
Pokud spojím pin1 přes odpor se zemí, tak už to jakoby jede, ale avrdude: Expected signature for ATtiny2313 is 1E 91 0ATady by se hodilo vypsat i to, co se skutečně přijalo, tj.
Device signature = 0xXXXXXX
Jinak s programátorem "dapa" jsem občas měl problémy hlavně v situaci, kdy jsem se pokoušel pracovat s testovacím MCU, který toho měl docela dost za sebou. Tak jsem zkusil místo toho použít programátor "xil" a od té doby ani jediný problém.
"xil" je taky programátor pro paralelení port, od "dapa" se liší jenom zapojením vývodů. Jak se liší, najdeš v souboru /etc/avrdude.conf
(hledej "xil", "dapa" je kousek vedle). Když změníš zapojení, spouštíš avrdude -c xil ...
(Ta změna zapojení je takhle: MOSI je stále pin2, to se nemění. SCK není připojené na pin 1, ale na pin 3. RESET není připojené na pin 16, ale na pin 4. MISO není připojené na pin 11, ale na pin 13. Všechny změny pinů se týkají paralelního portu, tzn. na straně mikropočítače se nic nemění. Zakreslil jsem změny do původního schématu a přiložil obrázek. Za nic neručím, než to zkusíš, zkontroluj si to podle toho avrdude.conf.)
-i 100
(určuje počet mikrosekund mezi každou změnou bitu) Pokud je nějaký problém ve spojení (špatné kabely apod.), tak tohle by mohlo pomoci (za cenu zpomalení programování)
Podle datasheetu musí být před započetím programování vývod RESET/ v nule, proto může částečně pomoct ten odpor.Ale i tak je to divný. Kdyby to tak bylo, tak to znamená, že LPT port sám není schopen dotlačit pin reset toho MCU do nuly včas. To by znamenalo, že na tom pinu je nějaká dost velká kapacita a to mi přijde divné - kde by se vzala.
Za obvodem max232 když spojím vysílací a přijímací, tak se nic nedějeTzn. piny 9 a 10 toho obvodu MAX232 jsou propojené mezi sebou, ale nejsou připojené k ničemu jinému. Sériový port je připojený k 7 a 8, ostatní piny podle schématu. Když pošleš něco pomocí echo, tak cat nevrátí nic. Napadají mě tři možnosti:
avrdude -c dapa -p t2313 -E reset avrdude -c dapa -p t2313 [příkaz pro programování](Místo dapa může být xil, podle toho, jak to máš zrovna zapojené.) Při tom prvním příkazu se nestane nic, jenom bude nadávat, že má špatnou Device signature. Zajímá mě, co udělá ten druhý příkaz. Spouštět samozřejmě bez toho odporu. A ještě jeden nápad - jak je ten port nakonfigurovaný v BIOSu? Mám takový matný pocit, že když jsem ho neměl v režimu SPP, tak mi to taky blbnulo.
Zjistil jsem, že pokud posílám přes echo na sériové rozhraní nějaká data, tak při připojeném max232n klesne napětí od com konektoru na přibližně -4V na jednom vodiči a na -7V na druhém z původních -6.6V a -10.4V.To je logické. Klidové napětí na sériové lince má být -12V (log.1). Když začneš něco posílat, tak tam občas projde nějaká log. 0 (tj. ideálně +12V), což stejnosměrný měřák vyhodnocuje jako pokles té hodnoy.
A na straně, která vede z max232n do atmela je na jednom vodiči z 0.14V 0.10V a druhý zůstává 3.5V i když nic neposílám."Jeden" a "druhý" vodič je skvělá identifikace. Já mám třeba na jednom vodiči pořád nulu, ale zas tak moc to nevadí, protože je to zem. (Čti: když nevím, co ty vodiče spojují, nemůžu říct, jestli se chovají správně.)
Pokud naprogramován je tak jde z atmela na obou vodičích 5V.To je správně, v klidovém stavu se vysílá/přijímá log.1, tedy +5V
"Jeden" a "druhý" vodič je skvělá identifikace.PIN 9 a 10 z MAX232N.
A může to tak vůbec fungovat?Jo. Takhle zkouším pokaždé, když se mi procesor nechce bavit s počítačem, abych vyloučil chybu ve spojení.
zjistil jsem, že pokud něco atmel posílá, tak 5V bylo na 11pinu maxe a na tom dalším, který vede taky do atmela bylo 0.3V a zároveň se změnilo napětí na pinu14 z -0.8V na 0.2V, takže to jakoby něco posílá, ale končí to bůhví jak.Zjišťovat, co se děje na datové lince sériového portu stejnosměrným voltmetrem, je krajně neefektivní a nicneříkající. Na to je potřeba osciloskop. Proto doporučuju nejdřív rozchodit komunikaci port - max - max - port. Až to půjde, tak to teprve spojit s MCU.
programator:~# stty -F /dev/ttyS0 speed 9600 baud; line = 0; -brkint -imaxbelJe tohle v pořádku?
Co si mám o tom myslet? Vadný sériový port?Jakým způsobem je to vlastně všechno propojené? Myslím jako co je kupované a co je dělané ručně. Jak je propojen port s MAXem, MAX s MCU, LPT s MCU atd. Z toho, že to občas funguje a občas ne, mi přijde, že je to všechno nějak divně popropojované. Možná by stálo za to pro zkoušení samotného portu a MAXe zapnout paritu:
stty -F /dev/ttyS0 parenb parodd inpck ignpar -parmrk
Dokud se nebude vracet to, co z portu vylezlo, tak je stále někde problém.
(Paritu lze následně opět vypnout pomocí stty -D /dev/ttyS0 -parenb -inpck
)
, term1: programator:~/programator/lepsi# cat /dev/ttyS0 term2: while : ; do echo "ll" > /dev/ttyS0; done ��H���H���H���H���H���H���H���H���H������C!��H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H���H��kl ll ll ll ll ll llZjistil jsem že nejdřív musím pustit cat a pak echo, jinak to nefunguje. Takhle to funguje dobře, nicméně přes maxe se to nedostane. Zapojený to mám následovně: konektor CANON 9 napájený takto: http://www.abclinuxu.cz/images/clanky/martinek/1cip-rs232-9pin-2.jpg. Od něj jsou vedený 3 vodiče třívodičovým kabelem přes nulové odpory do nepájivého kontaktního pole. Jeden do země, dva do maxe. K maxovi jsou přidělány elektrolytické kondénzátory 1uF. Všechno je proměřené, všechny kontakty ok.
┌┌ ┌┌ ┌┌ ┌┌
stty -F /dev/ttySx -a.
stty -F /dev/ttyS0 -a speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; parenb parodd cs8 hupcl -cstopb cread clocal -crtscts -ignbrk -brkint ignpar -parmrk inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke
A komunikace s atmelem nejde.Vykašli se na atmel. Dokud ti nepůjde samotný max, tak ti nepůjde ani ten atmel. A když ho náhodou rozchodíš, tak to bude tak nespolehlivé, že to nebude na žádnou užitečnou práci.
Teď jsem to přepojil podle http://www.dhservis.cz/dalsi/prevodnik.htm a už to "funguje" i za maxem se spojenými výstupy.Podle toho, jak se funkce těch obvodů mění se změnou zapojení, se pro jistotu zeptám ještě jednou: jak to napájíš? Nahoře píšeš, že stabilizovaným napětím 5V přes LM78L05. Z čeho bereš vstupní napětí pro ten LM78L05? Jak velké je to vstupní napětí, jak velký proud dá ten zdroj toho napětí? Je na výstupu toho LM78L05 určitě 5V? Funkce toho maxe by se neměla měnit se zapojením - na netu se jich povaluje víc, ale měly by být vzájemně ekvivalentní. Podle toho, že ti to občas jde a občas ne, mi přijde, že to nemá dostatek šťávy.
stty -F /dev/ttyS0 clocal cread -crtscts cs8 -cstopb hup -parenb parodd -brkint -icrnl ignbrk -igncr ignpar imaxbel -inlcr inpck -istrip -iuclc -ixany ixoff -ixon bs0 cr0 ff0 nl0 -ocrnl -ofdel -ofill -olcuc -onlcr -onlret onocr -opost tab0 vt0 -crterase crtkill -ctlecho -echo -echok -echonl -echoprt -icanon -iexten -isig -noflsh -tostop -xcase time 5 min 1viz. http://www.abclinuxu.cz/clanky/hardware/seriova-komunikace-pod-linuxem-i to dokonce vypíše přesně to co mu pošlu a nevypisuje to pořád dokola jako předtím.
Teď mi to jde spolehlivě.I s tím MAXem, předpokládám. Výborně.
Pozorováním jsem došel k závěru, že vše funguje jak má dokud to nepřipojím třeba jen na chvilku na atmela a zpátky.Takže pár pokusů: 1. Vytvoř smyčku s tím MAXem (port - MAX - MAX - port). Atmela připoj jenom k napájení. Komunikuje ještě ta smyčka echo/cat? 2. Naprogramuj Atmel tak, aby ty sériové piny byly vypnuté, tedy byly nastaveny do stavu vysoké impedance. Úplně na to bude stačit program typu:
.org 0 rjmp 0Tu stranu, kde jsou TTL úrovně (spojení pinů 9 a 10 na MAXovi), propoj s RXD (pin 2 na MCU). Funguje to ještě? 3. Piny 9 a 10 na MAX jsou stále spojené, místo s RXD je spoj s TXD (pin 3 na MCU). Funguje to ještě? 4. Piny 9 a 10 na MAX jsou stále spojené, opět je spoj s RXD a napiš program, který aktivuje RXD pin, například:
ldi r16, (1 << RXEN) out UCSRB, r16 stop: rjmp stopFunguje to ještě? Všechny testy mají vyloučit hardwarovou chybu procesoru; pokud je procesor v pořádku, nemělo by ani při jednom z nich hrozit poškození součástek.
echo A > /dev/ttyS0 Bò echo AAA > /dev/ttyS0 BA echo AAA > /dev/ttyS0 BI
Tiskni
Sdílej: