MKVToolNix, tj. sada nástrojů pro práci s formátem (medialnym kontajnerom) Matroska, byl vydán ve verzi 95.0. Podpora přehrávání formátu Matroska míří do Firefoxu [Bug 1422891, Technický popis]. Přehrávání lze již testovat ve Firefoxu Nightly.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 211. sraz, který proběhne v pátek 19. září od 18:00 ve Studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1. Na srazu proběhne přednáška Jiřího Eischmanna o nové verzi prostředí GNOME 49. Nemáte-li možnost se zúčastnit osobně, přednáškový blok bude opět streamován živě na server VHSky.cz a následně i zpřístupněn záznam.
Microsoft se vyhnul pokutě od Evropské komise za zneužívání svého dominantního postavení na trhu v souvislosti s aplikací Teams. S komisí se dohodl na závazcích, které slíbil splnit. Unijní exekutivě se nelíbilo, že firma svazuje svůj nástroj pro chatování a videohovory Teams se sadou kancelářských programů Office. Microsoft nyní slíbil jasné oddělení aplikace od kancelářských nástrojů, jako jsou Word, Excel a Outlook. Na Microsoft si
… více »Samba (Wikipedie), svobodná implementace SMB a Active Directory, byla vydána ve verzi 4.23.0. Počínaje verzí Samba 4.23 jsou unixová rozšíření SMB3 ve výchozím nastavení povolena. Přidána byla podpora SMB3 přes QUIC. Nová utilita smb_prometheus_endpoint exportuje metriky ve formátu Prometheus.
Správcovský tým repozitáře F-Droid pro Android sdílí doporučení, jak řešit žádosti o odstranění nelegálního obsahu. Základem je mít nastavené formální procesy, vyhrazenou e-mailovou adresu a být transparentní. Zdůrazňují také důležitost volby jurisdikce (F-Droid je v Nizozemsku).
Byly publikovány informace o další zranitelnosti v procesorech. Nejnovější zranitelnost byla pojmenována VMScape (CVE-2025-40300, GitHub) a v upstream Linuxech je již opravena. Jedná se o variantu Spectre. KVM host může číst data z uživatelského prostoru hypervizoru, např. QEMU.
V červenci loňského roku organizace Apache Software Foundation (ASF) oznámila, že se částečně přestane dopouštět kulturní apropriace a změní své logo. Dnes bylo nové logo představeno. "Indiánské pírko" bylo nahrazeno dubovým listem a text Apache Software Foundation zkratkou ASF. Slovo Apache se bude "zatím" dál používat. Oficiální název organizace zůstává Apache Software Foundation, stejně jako názvy projektů, například Apache HTTP Server.
Byla vydána (𝕏) srpnová aktualizace aneb nová verze 1.104 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.104 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Spotify spustilo přehrávání v bezztrátové kvalitě. V předplatném Spotify Premium.
Spoluzakladatel a předseda správní rady americké softwarové společnosti Oracle Larry Ellison vystřídal spoluzakladatele automobilky Tesla a dalších firem Elona Muska na postu nejbohatšího člověka světa. Hodnota Ellisonova majetku díky dnešnímu prudkému posílení ceny akcií Oraclu odpoledne vykazovala nárůst o více než 100 miliard dolarů a dosáhla 393 miliard USD (zhruba 8,2 bilionu Kč). Hodnota Muskova majetku činila zhruba 385 miliard dolarů.
Tak jsem jednou potřeboval přibližně změřit frekvenci krystalového oscilátoru a jelikož žádný přístroj k tomuto účelu uzpůsobený nevlastním, rozhodl jsem se udělat malé udělátko s pomocí běžného AVR ze šuplíku. Nějakým zobrazováním jsem se netrápil, data prostě házím pěkně na sériový port a čtu z počítače. Vzhledem k tomu, že frekvence, kterou jsem měřil několikrát převyšovala maximální pracovní frekvenci AVR-ka, bylo nutné předřadit ještě děličku frekvence.
K zbastlení jsem použil profláklý ATtiny2313. Napsat firmware bylo poměrně triviální, neboť tento jednočipu má již v sobě hardwarovou čítačku impulzů. Chceme-li měřit frekvenci, je samořejmě nutné vědět, za jaký časový úsek impulzy počítáme. K tomu použijeme druhý čítač, který bere svůj takt ze systémového oscilátoru (v našem případě 20MHz krystal). Každou sekundu spočítame počet impulzů a dostaneme tak frekvenci. (Pro rýpaly, samozřejmě přesnost měření závisí na přesnosti použitého krystalu. Jelikož ale bylo cílem zjistit jen, zda-li měřený krystalový oscilátor funguje a nikoliv žádné přesné měření, tato přesnost nám bohatě stačí.)
Bohužel oscilátor, který jsem potřeboval ověřit, měl frekvenci 48MHz, ATtiny2313 však dokáže měřit frekvenci maximálně do poloviny pracovní frekvence - a to ještě při 50%/50% střídě. Čili reálně vychází tak 7-8MHz maximální frekvence, kterou jsme schopni rozumně změřit. Bylo tedy jasné, že potřebujeme frekvenci rozdělit. Bohužel jsem v šuplíku žádný dělič frekvence nenašel. Naštěstí se v něm ale povalovaly obvody 74F74 a 74LS74, což jsou klopné obvody typu D, z nichž už takovou děličku (=čítač) sestrojit lze. Měl jsem štestí, neboť obvod 74F74 zvládne až cca 125MHz a 74LS74 až asi 30MHz. Tím se dostáváme k maximální frekvenci něco přes 100MHZ (první obvod rozdělí frekvenci dvakrát na ~25MHz a druhý na cca 6.3MHz, kterou už AVR hravě zvládne.) Firmware jsem vylepšil tak, že je možné jedním vstupním pinem rozhodnout, zda-li AVR dostane již rozdělenou frekvenci (v poměru 1:16) a případně ji sám tímto poměrem vynásobí a zobrazí skutečnou frekvenci.
Výsledek měření je vypsán na UART (součásti zapojení není převodník na RS232, doporučuji tento článek) rychlostí 57600 (8N1).
Projekt je možné stáhnout zde. Aktualizace: opravená verze tady.
Tiskni
Sdílej:
uart_print_freq()
pravděpodobně občas zablbne, pokud program poběží dost dlouho. Může se totiž stát, že hodnota freq se změní mezi vyhnodnocením podmínky a přiřazením do temp.
(Dobrá, asi se to nestane, protože vypsání proběhne jenom po změně status a je rychlejší, než jedna vteřina.)
- status by měla být deklarována jako volatile
. Když není, tak u gcc-3.4 to projde - nevím proč, ta proměnná by pro ten překladač neměla měnit hodnotu a optimalizace by její testování měla odstranit.
U gcc-4.3 už to ale neprojde, když je proměnná nulová, program skočí na instrukci rjmp -2
, což je nekonečná smyčka.
Ještě nějaké detaily:
- SIGNAL() je deprecated, místo něj se má použít ISR()
...
- status by měla být deklarována jako volatile
. Když není, tak u gcc-3.4 to projde - nevím proč, ta proměnná by pro ten překladač neměla měnit hodnotu a optimalizace by její testování měla odstranit.
OK, tyhle věci opraveny, díky.
volatile
proměnnou větší než 8 bitů, tak tam vidí po sobě jdoucí instrukce načítání z paměti:
lds r24, 0x0060 lds r25, 0x0061 lds r26, 0x0062 lds r27, 0x0063Přitom když je ta proměnná volatile, tak to znamená, že se obsah té paměti během vykonávání těch instrukcí může změnit a do registrů se pak načte naprosto nesmyslná hodnota - napůl stará, napůl nová. Podle mě by to mělo být takhle:
in r23, SREG cli lds r24, 0x0060 lds r25, 0x0061 lds r26, 0x0062 out SREG, r23 lds r27, 0x0063obecně nebo
cli lds r24, 0x0060 lds r25, 0x0061 lds r26, 0x0062 sei lds r27, 0x0063v případě, že vím, že přerušení bylo předtím povoleno.
register uint32 tmp; ... cli(); tmp = freq; sei(); uart_print_freq(tmp); ...Akorát je docela opruz tohle psát u každého přístupu k té proměnné a vygenerovaný kód není úplně optimální. Přitom by určitě bylo jednodušší, kdyby gcc pro AVR vypínal/zapínal přerušení automaticky (i když to zas narážíme na otázku, jestli by byl schopen to dělat efektivně)
Akorát je docela opruz tohle psát u každého přístupu k té proměnné...Mno, v tom případě přeci není problém připravit drobné makro, ne? Něco jako:
#define get_volatile(x,y) cli();x=y;sei()
To by vnaselo do jazyka zmatek a zhorsilo prenositelnost kodu.Přenositelnost kódu by to asi zhoršilo, jenom nevím, kam by mělo smysl přenášet kód z AVR (pokud to má dělat něco užitečného, polovina kódu je specifická pro architekturu a jinde se nepřeloží)
Jde hlavně o princip.To jsem si všiml
Ale představ si, že za rok vyrobí trochu jiný model a ty budeš chtít program přenést na něj a zrovna tohle tam bude trošku jinak...Nový model se objevuje každou chvíli a všechny mají stejný vnitřek - jádro AVR. A stále nevidím žádný problém - kdyby se náhodou objevil model, kde by tohle bylo jinak (což si teda opravdu představit nedokážu, jak by se v jednočipu musel změnit přístup k paměti, aby to mohlo být jinak), tak by se prostě ten přepínač při překladu programu pro ten nový model zakázal.
avr-gcc --neprerusitelne-volatile
), tzn. po překladu by se to buď používalo v celém výsledku, nebo nepoužívalo v celém výsledku.
A teď si představ jaký bordel v tom bude a nakonec to skončí tak, že jeden kus kódu budeš muset ručně projít a upravit.Proč? Jediné, co se hlídá, je zablokování přerušení na dobu přístupu k proměnné. Jestli to zajišťoval překladač nebo makro je jedno, protože podstatné je, že ten přístup je ochráněn. Víc nepotřebuju. (Ano, je tu záležitost, že se zapnutým přepínačem by ten kód byl chráněn dvakrát. Nicméně mám důvěru v autory toho překladače, že jsou schopni vytvořit takové optimalizace, které odhalí dvě stejné instrukce za sebou a tu jednu vyhodí.) Co chci říct, že kdyby byla vůle, tak by to pravděpodobně šlo vyřešit nějak automaticky i s možnými problémy okolo.
http://www.abclinuxu.cz/blog/vejsplechty/2008/8/www.etf.cuni.cz/~tomasek/avr_freq_0.1.tgz
a pravděpodobně by mělo být www.etf.cuni.cz/~tomasek/avr_freq_0.1.tgz
.