Byly publikovány fotografie a všechny videozáznamy z Python konference PyCon US 2025 proběhlé v květnu.
Společnost xAI a sociální síť X amerického miliardáře Elona Muska zažalovaly firmy Apple a OpenAI. Viní je z nezákonné konspirace s cílem potlačit konkurenci v oblasti umělé inteligence (AI).
Byla vydána nová verze 9.16 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Americká vláda se po převzetí zhruba desetiprocentního podílu ve výrobci čipů Intel chystá na další investice do vybraných firem. Na sociální síti Truth Social to napsal prezident Donald Trump. Jeho ekonomický poradce Kevin Hassett v rozhovoru v televizi CNBC řekl, že nemusí jít pouze o firmy z technologického sektoru, ale i z jiných odvětví.
V Amsterdamu probíhá Open Source Summit Europe. Organizace Linux Foundation představuje novinky. Pod svá křídla převzala open source dokumentovou databázi DocumentDB.
Přesně před 34 lety, 25. srpna 1991, oznámil Linus Benedict Torvalds v diskusní skupině comp.os.minix, že vyvíjí (svobodný) operační systém (jako koníček, nebude tak velký a profesionální jako GNU) pro klony 386 (486), že začal v dubnu a během několika měsíců by mohl mít něco použitelného.
86Box, tj. emulátor retro počítačů založených na x86, byl vydán ve verzi 5.0. S integrovaným správcem VM. Na GitHubu jsou vedle zdrojových kódů ke stažení také připravené balíčky ve formátu AppImage.
Vláda Spojených států získala desetiprocentní podíl v americkém výrobci čipů Intel. Oznámili to podle agentur americký prezident Donald Trump a ministr obchodu Howard Lutnick. Společnost Intel uvedla, že výměnou za desetiprocentní podíl obdrží státní dotace v hodnotě 8,9 miliardy dolarů (zhruba 186 miliard Kč). Částka podle Intelu zahrnuje dříve přislíbené subvence 5,7 miliardy dolarů z programu CHIPS na podporu výroby čipů v USA,
… více »Organizace Apache Software Foundation (ASF) vydala verzi 27 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Knihovna FFmpeg byla vydána ve verzi 8.0 „Huffman“. Přibyla mj. podpora hardwarově akcelerovaného kódování s využitím API Vulcan, viz seznam změn.
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: