RoboDoupě.cz

Ahoj,

v posledním amáru jsem si přečetl článek od Lukáše Liebzeita, který pojednává o vykreslování obrázku z SD karty na barevný LCD displej. Pravda trochu skok, když se v prvním a druhém díle probíralo blikání ledkou, ale neva.

Lukáš v článku řeší, jak dlouho trvá arduinu (mega) vykreslit bitmapu (*.bmp) z SD karty na barevný displej 320*240*3.
V článku se mimo jiné pozastavuje, jak to, že když si udělal větší buffer, tak se čtení příliš nezrychlilo.

Tak jsem se chtěl zeptat, jestli víš, proč k tomu došlo? nebo je to pro tebe opravdu záhada, jak píšeš v článku.
Protože pokud by tě to opravdu zajímalo (a možná i ostatní), tak bych ti mohl dát nějaké hinty, co se dá udělat jinak a lépe.

Pro nás, co Amáro předplacené nemáme, to může být jako docela zajímavá tipovačka
Nevíme, co přesně se s rychlostí řeší a jaká ta rychlost vlastně absolutně je. Jestli jde jen o čtení z SD, tak bych si jednak tipnul, že jde o SPI (SD bus nebo UHS mode na osmibiťáku, co běží na 16MHz, asi těžko...). No a pak bych si tipnul, že buď je prostě komunikace v principu pomalá na tak hodně dat (320*240*3 = 230400 bitů čistého), což by při špatném nastavení SPI klidně vzalo několik vteřin i kdyby se s těma datama dál vůbec nic nedělalo, anebo to je prostě špatně naprogramované (když slyším Arduino, tak to je dost vysoká šance...). Nejspíš se i plýtvá zdroji, zejména strojovým časem a pamětí, ale i kdyby ne, tak ono 8kB SRAM, co má ATmega2560, není na zpracování skoro 30kB obrázku zrovna moc, když v těch 8 kilech jsou všechna data programu i zásobník, Tak aby to šlo co nejrychleji, je potřeba se tím dost zabývat.

DavidO píše: ↑07 říj 2023, 20:58 Pro nás, co Amáro předplacené nemáme, to může být jako docela zajímavá tipovačka

Pro těch pár co nemají amáro předplacené mohu doporučit knihovnu Nemá cenu zdržovat většinu, která jej čte pravidelně.
Spíš, že je to Lukášův článek a tak se mi nechce mu kazit autorskou radost, on to určitě uvede.

To co jsi popsal je v pořádku, ale Lukáš asi úplně přesně nezná ten vtip, že kdyby byl člověk stvořen k používání počítače, tak má šestnáct prstů.
Tedy Lukáš si načítá data z karty a pracuje s bufferem o velikosti 240 bajtů a souborem s offsetem 175 bajtů a tak podobně. Takže ho i tak pomalé čtení vyjde ještě dráž na tom, že se mu načítají data z několika sektorů.

Tak jsem se zájmem čekal, jestli se autor toho článku veřejně vyjádří k Fuldovým připomínkám a bohužel nevyjádřil. Což mě (opět bohužel) nepřekvapilo.

Ze židle mě ale zvedl i příšerný článek stejného autora zde na Robodoupěti o Robotu sledujícím čáru. Konstrukce byla zamýšlena pro kroužek robotiky. Na jednu stranu mě děsí, že vychovávat nové odborníky by měl někdo, kdo evidentně postrádá elementární znalosti. Na druhou stranu je super, že se lidé ochotní tyto kroužky vést, stále najdou. Taky jsem to několikrát zvažoval, ale vždy jsem došel k závěru, že bych na to neměl nervy A taky bych asi měl tendence klást značný důraz právě na ty základy, což by děcka nudilo. Jenže bez toho to prostě nejde. Měl jsem taky připravenou stavebnici jednoduchého Line Followeru (vešel jsem se do pětikila).

Nechci autora dehonestovat. Naopak bych ho rád podpořil. Sepsal jsem (zatím 15) bodů jak autorovo vozítko opravit a vylepšit a možná i uspořit náklady. Bude-li zájem mohu postnout. Veřejně či soukromě, dle libosti. Nebo můžu zpracovat i článek. Zde ukázka toho nejzásadnějšího:

1) Asi nejlevnější "pouzdro" do DPS na Arduino Nano je obyčejná patice DIL32. Přebytečné piny lze odříznout, nebo zaslepit (kapkou lepidla). Ještě lepší jsou dutinkové lišty jednořadé, či dvouřadé (ty částečně vytvoří i nepájivé pole).

2) Hrubou chybou je absence jakéhokoliv odrušení komutátorových motorků, které se nacházejí v blízkosti citlivé elektroniky (zde procesoru).
Alespoň já na fotkách nic nevidím. Tohle děcka učit nemůžete! Přitom ještě v dobách, kdy na Robodoupěti vycházely kvalitní články (ze kterých jsem sám mockrát čerpal), to pěkně popsal Ing. Černý.

3) Ladit pomocí podložek přesnou výšku čidel nad dráhou je zbytečné. Já dávám čidla cca 5-8 mm nad dráhu a připojuji je na analogové vstupy procesoru. Firmware pak obsahuje kalibrační rutinu pro nastavení rozhodovací úrovně světlo/tma a tato rozhodovací hodnota se uloží do vnitřní EEPROM Arduina.

A další a další a další...

Držím autorovi palce. Ale tyhle základy se prostě doučit musí.

Budu rád, když se mi ohledně publikace na RoboDoupěti ozvete na dex zavináč robodoupe tečka cz