Při restauraci německého LC měřiče LCM1 jsem musel nakreslit novu stupnici. Možná se někomu bude také hodit. K dipozici je vektorový formát pro CorelDraw a bitmapa s hustotou 600 x 600 DPI. Bitmapa se dá stáhnout (Uložit odkaz jako...) a vytisknout například v XnView při volbě Měřítko 1:1.
http://mtajovsky.wz.cz/stupnice/lcm1.bmp
http://mtajovsky.wz.cz/stupnice/lcm1.cdr
Stupnice pro LCM1
Moderátor: Moderátoři
Pravda, mohl jsem ji zazipovat. Ale menší bitmapa nejde, když má po tisku být výsledek podobný tisku z vektorového programu. Tak to vychází při exportu do BMP z Corelu. Hrubější bitmapa - 300 DPI už dává granularitu po 0,085 mm, což je příliš, uvážíme-li, že dílky jsou kresleny 0,15 mm. Ne každý má Corel a proto jsem uploudnul i bitmapu.
-
ZdenekHQ
- Významný člen
- Příspěvky: 25519
- Registrován: 21 črc 2006, 00:00
- Bydliště: skoro Brno
- Kontaktovat uživatele:
Ještě OT otázka: Mě zaujal ten HW klíč. Potřeboval bych něco podobnýho, ale s nějakým osmipinovým Atmelem a komunikací přes I2C, v nejhorším přes SPI.
Pro moje oslovení klidně použijte jméno Zdeněk
Správně navržené zapojení je jako recept na dobré jídlo.
Můžete vynechat půlku ingrediencí, nebo přidat jiné,
ale jste si jistí, že vám to bude chutnat[?]
Správně navržené zapojení je jako recept na dobré jídlo.
Můžete vynechat půlku ingrediencí, nebo přidat jiné,
ale jste si jistí, že vám to bude chutnat[?]
Potřebné syst. prostředky jsou:
Flash asi 4 kB, vešlo by se to ATmega48 po zapnutí optimalizace překladače.
EEPROM: podle počtu buněk, na každou buňku 9 byte (1 byte status, 4 byte data, 4 byte heslo)
RAM: teď nevím přesně, největší žrout je šifrování RC4, které potřebuje pracovní buffer 128 byte na rozběh šifr. algoritmu - na pořádných strojích se doporučuje alespoň 512 byte dummy dat zašifrovat, aby se spolehlivě nastavil. To by se asi dalo nějak ještě optimalizovat pro dané použití, kde šifrujeme skutečně jen malé dávky dat.
ATtiny 45 mi vychází jako jediný - má 4 kB flash a 8 nožiček.
Jinak, ten kód pro MCU i knihovna pro PC je public domain, kdo si s tím co udělá je jeho věc.
Komunikace na straně MCU je v modulu serial.c. Pracuje celkem autonomně. Na zbytek kódu je navázána takto:
- při příjmu celé zprávy se nastaví flag
rxcompl = (u08)1;
a hlavní smyčka se na něj dotazuje přes getter serialIsRXComplete(). Pokud je nastaven spustí hlavní smyčka zpracování povelu funkcí processCommand(), která se nalézá v process.c. Přijatá data jsou umístěna v bufferu u08 rxbuff[50];
- vysílání se aktivuje funkcí serialSend(u08 length), přičemž data k vysílání jsou připravena v u08 txbuff[50];
Pokud se jiný komunikační modul (I2C) chytne na výše popsané funkce a buffery, tak může snadno nahradit komunikaci přes UART. To znamená implementovat:
u08 serialIsRXComplete(void);
void serialSend(u08 length);
a pracovat s buffery:
extern volatile u08 rxbuff[50]; // RX data buffer
extern volatile u08 txbuff[50]; // TX data buffer
Samozřejmě je zde otázka jiné inicializace a taky musí komunikační modul pracovat s timerem, aby mohl detekovat a zvládat neukončené zprávy. Viz makra SET_TO a CLR_TO.
Komunikační modul spolupracuje se stranou PC v režimu klient - server v half duplexu. Dokud není odvysílána odpověď na poslední přijatý povel, případně přijatá data jsou zahazována.
forbidden<< zararovaná bitmapa má 112 kB.
Flash asi 4 kB, vešlo by se to ATmega48 po zapnutí optimalizace překladače.
EEPROM: podle počtu buněk, na každou buňku 9 byte (1 byte status, 4 byte data, 4 byte heslo)
RAM: teď nevím přesně, největší žrout je šifrování RC4, které potřebuje pracovní buffer 128 byte na rozběh šifr. algoritmu - na pořádných strojích se doporučuje alespoň 512 byte dummy dat zašifrovat, aby se spolehlivě nastavil. To by se asi dalo nějak ještě optimalizovat pro dané použití, kde šifrujeme skutečně jen malé dávky dat.
ATtiny 45 mi vychází jako jediný - má 4 kB flash a 8 nožiček.
Jinak, ten kód pro MCU i knihovna pro PC je public domain, kdo si s tím co udělá je jeho věc.
Komunikace na straně MCU je v modulu serial.c. Pracuje celkem autonomně. Na zbytek kódu je navázána takto:
- při příjmu celé zprávy se nastaví flag
rxcompl = (u08)1;
a hlavní smyčka se na něj dotazuje přes getter serialIsRXComplete(). Pokud je nastaven spustí hlavní smyčka zpracování povelu funkcí processCommand(), která se nalézá v process.c. Přijatá data jsou umístěna v bufferu u08 rxbuff[50];
- vysílání se aktivuje funkcí serialSend(u08 length), přičemž data k vysílání jsou připravena v u08 txbuff[50];
Pokud se jiný komunikační modul (I2C) chytne na výše popsané funkce a buffery, tak může snadno nahradit komunikaci přes UART. To znamená implementovat:
u08 serialIsRXComplete(void);
void serialSend(u08 length);
a pracovat s buffery:
extern volatile u08 rxbuff[50]; // RX data buffer
extern volatile u08 txbuff[50]; // TX data buffer
Samozřejmě je zde otázka jiné inicializace a taky musí komunikační modul pracovat s timerem, aby mohl detekovat a zvládat neukončené zprávy. Viz makra SET_TO a CLR_TO.
Komunikační modul spolupracuje se stranou PC v režimu klient - server v half duplexu. Dokud není odvysílána odpověď na poslední přijatý povel, případně přijatá data jsou zahazována.
forbidden<< zararovaná bitmapa má 112 kB.
- Přílohy
-
lcm1.rar- (111.25 KiB) Staženo 145 x