Fedora je od 10. února dostupná v Sýrii. Sýrie vypadla ze seznamu embargovaných zemí a Fedora Infrastructure Team mohl odblokovat syrské IP adresy.
Ministerstvo zahraničí Spojených států amerických vyvíjí online portál Freedom.gov, který umožní nejenom uživatelům v Evropě přístup k obsahu blokovanému jejich vládami. Portál bude patrně obsahovat VPN funkci maskující uživatelský provoz tak, aby se jevil jako pocházející z USA. Projekt měl být původně představen již na letošní Mnichovské bezpečnostní konferenci, ale jeho spuštění bylo odloženo.
Byla vydána pro lidi zdarma ke stažení kniha The Book of Remind věnovaná sofistikovanému kalendáři a připomínači Remind.
Grafický editor dokumentů LyX, založený na TeXu, byl vydán ve verzi 2.5.0. Oznámení připomíná 30. výročí vzniku projektu. Novinky zahrnují mj. vylepšení referencí nebo použití barev napříč aplikací, od rozhraní editoru po výstupní dokument.
F-Droid bannerem na svých stránkách a také v aplikacích F-Droid a F-Droid Basic upozorňuje na iniciativu Keep Android Open. Od září 2026 bude Android vyžadovat, aby všechny aplikace byly registrovány ověřenými vývojáři, aby mohly být nainstalovány na certifikovaných zařízeních Android. To ohrožuje alternativní obchody s aplikacemi jako F-Droid a možnost instalace aplikací mimo oficiální obchod (sideloading).
Svobodná historická realtimová strategie 0 A.D. (Wikipedie) byla vydána ve verzi 28 (0.28.0). Její kódový název je Boiorix. Představení novinek v poznámkách k vydání. Ke stažení také na Flathubu a Snapcraftu.
Multimediální server a user space API PipeWire (Wikipedie) poskytující PulseAudio, JACK, ALSA a GStreamer rozhraní byl vydán ve verzi 1.6.0 (Bluesky). Přehled novinek na GitLabu.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-1.2 a 20.04 OTA-12.
Byla vydána (Mastodon, 𝕏) nová stabilní verze 2.0 otevřeného operačního systému pro chytré hodinky AsteroidOS (Wikipedie). Přehled novinek v oznámení o vydání a na YouTube.
WoWee je open-source klient pro MMORPG hru World of Warcraft, kompatibilní se základní verzí a rozšířeními The Burning Crusade a Wrath of the Lich King. Klient je napsaný v C++ a využívá vlastní OpenGL renderer, pro provoz vyžaduje modely, grafiku, hudbu, zvuky a další assety z originální kopie hry od Blizzardu. Zdrojový kód je na GitHubu, dostupný pod licencí MIT.
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 0
Tu 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 stop
Funguje 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: