Chci se zeptat jestli nekdo nema zkusenosti se systemem SkyScan k montazi EQ5. Mam v planu konstrukci vlastniho Go-to systemu k tehle montazi a nejak nevim odkud zacit, jestli tohle nekdo vlastnite, mam dotaz jestli k tomu vyrobce nedal nejakou dokmentaci nebo tak neco. Ve schema nedoufam, ale spis neco jako popis propojeni.
Predem diq
SkyScan
SkyScan
Oldik napsal: Chci se zeptat jestli nekdo nema zkusenosti se systemem SkyScan k montazi EQ5. SkyScan pro montáž EQ-5 ještě není k dispozici
lepší rada žádná než špatná
milantos(šnek)centrum(puntík) cz
milantos(šnek)centrum(puntík) cz
-
MMys
- Příspěvky: 18320
- Registrován: 02. 01. 2001, 05:03
- Bydliště: Běleč nad Orlicí
- Věk: 52
- Kontaktovat uživatele:
SkyScan
Pro EQ5 jak píše Milan Skyscan zatím není. Nicméně by tam určitě mohl jít přidělat Skyscan jako ugrade Kit pro EQ6 nebo H-EQ5. Obnášelo by to asi jen vyřešit mechanické připojení motorů na šneky EQ5.
Druhou možností je vyrobit vlastní systém, ale je to běh na dlouhou trať (návrh a realizace elektronických obvodů, programování mikrokontrolérů, nějaká ta strojařina). Touto cestou jsem šel já (když SkyScan ještě nebyl), dokumentaci mohu případně poskytnout.
http://hvbo.cz/foto_astronomy_cz/EQ6.htm Komfort sice není takový jako u Skyscanu (menší databáze objektů , menší počet tlačítek pro přímé volby, akže je třeba více používat menu, ustavení jen na jednu hvězdu - což je ale pro astrofoto stejně jediný vhodný způsob) Cena je oproti SkyScanu zhruba poloviční.
Více o tom je i v diskuzi zde: http://www.astro-forum.cz/cgi-bin/yabb/ ... 7;start=16
Několik kusů jsem již postavil. Momentálně je zatím jeden požadavek na stavbu dalšího kusu, ale v jednom kuse se mi to nevyplatí dělat (plošné spoje, nákup součástek) a tak je třeba počkat, až se sejde zase tak 5 zájemců.
Mimochodem, opravdu jsi žena ? To mne docela udivuje, za celý svůj život jsem ještě neviděl ženu, kterou by zajímal návrh a vývoj elektroniky a k tomu navíc ještě astronomie. Pokud si opravdu na toto troufáš a máš na to vědomosti, tak se klaním a smekám
S pozdravem MMys
Druhou možností je vyrobit vlastní systém, ale je to běh na dlouhou trať (návrh a realizace elektronických obvodů, programování mikrokontrolérů, nějaká ta strojařina). Touto cestou jsem šel já (když SkyScan ještě nebyl), dokumentaci mohu případně poskytnout.
http://hvbo.cz/foto_astronomy_cz/EQ6.htm Komfort sice není takový jako u Skyscanu (menší databáze objektů , menší počet tlačítek pro přímé volby, akže je třeba více používat menu, ustavení jen na jednu hvězdu - což je ale pro astrofoto stejně jediný vhodný způsob) Cena je oproti SkyScanu zhruba poloviční.
Více o tom je i v diskuzi zde: http://www.astro-forum.cz/cgi-bin/yabb/ ... 7;start=16
Několik kusů jsem již postavil. Momentálně je zatím jeden požadavek na stavbu dalšího kusu, ale v jednom kuse se mi to nevyplatí dělat (plošné spoje, nákup součástek) a tak je třeba počkat, až se sejde zase tak 5 zájemců.
Mimochodem, opravdu jsi žena ? To mne docela udivuje, za celý svůj život jsem ještě neviděl ženu, kterou by zajímal návrh a vývoj elektroniky a k tomu navíc ještě astronomie. Pokud si opravdu na toto troufáš a máš na to vědomosti, tak se klaním a smekám
S pozdravem MMys
http://hvbo.cz/foto_astronomy_cz, http://hvbo.cz, e-mail: martin(*)myslivec(a)volny(*)cz, Dobson 400mm, N400/1600, Refraktor Borg 77ED, Montáž EQ6, Hvězdárna s montáží vlastní výroby, kamery MII C3-61000, ZWO ASI 1600MM
SkyScan
Použít kit HeQ5 nebo EQ6 bych viděl jako dost mechanický problém- EQ5 má přece jen naprosto odlišně konstruovanou mechaniku a možnost připojení motorů. Navíc kit pro EQ5 je avizován, takže během několika měsíců bude zřejmě k dispozici.
lepší rada žádná než špatná
milantos(šnek)centrum(puntík) cz
milantos(šnek)centrum(puntík) cz
-
MMys
- Příspěvky: 18320
- Registrován: 02. 01. 2001, 05:03
- Bydliště: Běleč nad Orlicí
- Věk: 52
- Kontaktovat uživatele:
SkyScan
Myslel jsem variantu, kdy by se použily pouze motory, převodovku by bylo nutno vyrobit novou, na míru mechanickému řešení EQ5. To je jasné, a i tak je to jednoduší než stavba vlastního systému, který se vzhledem k ceně kitu dnes už asi nevyplatí, pokud to někdo nebere jako hoby.
Pokud je verze SkyScanu pro EQ5 již oznámena (nějak jsem to nezaregistroval) tak je opravdu nejlepší počkat.
Pokud je verze SkyScanu pro EQ5 již oznámena (nějak jsem to nezaregistroval) tak je opravdu nejlepší počkat.
http://hvbo.cz/foto_astronomy_cz, http://hvbo.cz, e-mail: martin(*)myslivec(a)volny(*)cz, Dobson 400mm, N400/1600, Refraktor Borg 77ED, Montáž EQ6, Hvězdárna s montáží vlastní výroby, kamery MII C3-61000, ZWO ASI 1600MM
SkyScan
No mam to zadany jako diplomku ve skole, takze pomalu savim programator na avrka a snazim se shant info, protoze cas utika a mam blbej pocit, ze rok stacit nebude. Ale diky za informace, mas parvdu, SkyScan jest eneni k dispozici, nasla jsem k nemu nejakej web a podruhy jsem si ho precetla dukladne. Mam k dispozici EQ5 nebo 6 i s motorama a rozhejbanou s jednoduchym navigacnim systemem, jen pohyb ve 4 smerech, ale hejbe se to, takze ja mam za ukol udelat jen jinej modul, kde bude rychlejsi pohyb a databaze objektu. Pripada mi dost jednoduchy, jen mikroprocesor a klavesnicku, muj vedouci diplomky bnavrhoval dotykovej displej. Nevim odkud zacit, jestli mi posles dokumentaci k tomu tvymu, budu ti moc vdecny. Nechci nic kopirovat, to by mi svedomi nedovolilo:) ale chci se inspirovat, mrknout jak to delal nekdo jinej a pripadne pochytit nejakou myslenku. Jo fakt jsem zena:) Obcas se vyskytne takova anomalie:D
MMys napsal: Pro EQ5 jak píše Milan Skyscan zatím není. Nicméně by tam určitě mohl jít přidělat Skyscan jako ugrade Kit pro EQ6 nebo H-EQ5. Obnášelo by to asi jen vyřešit mechanické připojení motorů na šneky EQ5.
Druhou možností je vyrobit vlastní systém, ale je to běh na dlouhou trať (návrh a realizace elektronických obvodů, programování mikrokontrolérů, nějaká ta strojařina). Touto cestou jsem šel já (když SkyScan ještě nebyl), dokumentaci mohu případně poskytnout.
http://hvbo.cz/foto_astronomy_cz/EQ6.htm Komfort sice není takový jako u Skyscanu (menší databáze objektů , menší počet tlačítek pro přímé volby, akže je třeba více používat menu, ustavení jen na jednu hvězdu - což je ale pro astrofoto stejně jediný vhodný způsob) Cena je oproti SkyScanu zhruba poloviční.
Více o tom je i v diskuzi zde: http://www.astro-forum.cz/cgi-bin/yabb/ ... 7;start=16
Několik kusů jsem již postavil. Momentálně je zatím jeden požadavek na stavbu dalšího kusu, ale v jednom kuse se mi to nevyplatí dělat (plošné spoje, nákup součástek) a tak je třeba počkat, až se sejde zase tak 5 zájemců.
Mimochodem, opravdu jsi žena ? To mne docela udivuje, za celý svůj život jsem ještě neviděl ženu, kterou by zajímal návrh a vývoj elektroniky a k tomu navíc ještě astronomie. Pokud si opravdu na toto troufáš a máš na to vědomosti, tak se klaním a smekám
S pozdravem MMys
MMys napsal: Pro EQ5 jak píše Milan Skyscan zatím není. Nicméně by tam určitě mohl jít přidělat Skyscan jako ugrade Kit pro EQ6 nebo H-EQ5. Obnášelo by to asi jen vyřešit mechanické připojení motorů na šneky EQ5.
Druhou možností je vyrobit vlastní systém, ale je to běh na dlouhou trať (návrh a realizace elektronických obvodů, programování mikrokontrolérů, nějaká ta strojařina). Touto cestou jsem šel já (když SkyScan ještě nebyl), dokumentaci mohu případně poskytnout.
http://hvbo.cz/foto_astronomy_cz/EQ6.htm Komfort sice není takový jako u Skyscanu (menší databáze objektů , menší počet tlačítek pro přímé volby, akže je třeba více používat menu, ustavení jen na jednu hvězdu - což je ale pro astrofoto stejně jediný vhodný způsob) Cena je oproti SkyScanu zhruba poloviční.
Více o tom je i v diskuzi zde: http://www.astro-forum.cz/cgi-bin/yabb/ ... 7;start=16
Několik kusů jsem již postavil. Momentálně je zatím jeden požadavek na stavbu dalšího kusu, ale v jednom kuse se mi to nevyplatí dělat (plošné spoje, nákup součástek) a tak je třeba počkat, až se sejde zase tak 5 zájemců.
Mimochodem, opravdu jsi žena ? To mne docela udivuje, za celý svůj život jsem ještě neviděl ženu, kterou by zajímal návrh a vývoj elektroniky a k tomu navíc ještě astronomie. Pokud si opravdu na toto troufáš a máš na to vědomosti, tak se klaním a smekám
S pozdravem MMys
Oldik
-
MMys
- Příspěvky: 18320
- Registrován: 02. 01. 2001, 05:03
- Bydliště: Běleč nad Orlicí
- Věk: 52
- Kontaktovat uživatele:
SkyScan
Já to sice nemám postavené na AVR-ku, nýbrž na obvodu C8051F121 (Sillicon Labs, klon x51), ale koncept bude podobný. No, čeká tě pěkný kus práce, dál to můžeme řešit pomocíme e-mailu, ať tím zbytečně nezatěžujeme fórum.
A nebo budeme pokračovat zde, kdyby se to mohlo hodit ještě někomu dalšímu, nebo někdo další přispěje svými zkušenostmi ?
A nebo budeme pokračovat zde, kdyby se to mohlo hodit ještě někomu dalšímu, nebo někdo další přispěje svými zkušenostmi ?
http://hvbo.cz/foto_astronomy_cz, http://hvbo.cz, e-mail: martin(*)myslivec(a)volny(*)cz, Dobson 400mm, N400/1600, Refraktor Borg 77ED, Montáž EQ6, Hvězdárna s montáží vlastní výroby, kamery MII C3-61000, ZWO ASI 1600MM
SkyScan
Oldik:
Jako diplomka je to zajimave tema. U EQ6 SS je tato koncepce: Vnitrni cast montaze obsahuje 2 motory s jemnym krokem, desku plosnych spoju kde je menic napeti na cca 35V pro motory, 2 mikroprocesory PIC + budice motoru (pro kazdy motor jeden procesor). Vnejsi jednotka (ovladac) obsahuje nejaky x51, pameti EPROM (s databazi). Presnou funkci komunikace neznam, ale mam otestovano, ze kdyz zapnu siderickou rychlost posunu osy RA a nasledne odpojim rucni ovladac, pak montaz pokracuje dale v cinnosti, jako by se nic nestalo. Stejne tak pri najizdeni na objekt - muzu zadat objekt, potvrdit a montaz najede bez problemu s odpojenym ovladacem. Vypada to tak, ze ovladac proste vlozi do 'motorove logiky' pocet pulsu RA a DE. Snimani polohy je pomoci odpocitavani pulsu motoru. To ma vyhodu a nevyhodu. Jako vyhodu bych videl jednoduchost koncepce, nevyhoda je v nemoznosti rucniho posunu montaze - veskere posuny jsou motorove, coz klade duraz na rychlost a presnost s ohledem na preskakovani kroku. Ja bych asi volil snimani polohy opticky, aby slo montazi hybat rucne - otazkou je dosazena presnost.
HonzaS
Jako diplomka je to zajimave tema. U EQ6 SS je tato koncepce: Vnitrni cast montaze obsahuje 2 motory s jemnym krokem, desku plosnych spoju kde je menic napeti na cca 35V pro motory, 2 mikroprocesory PIC + budice motoru (pro kazdy motor jeden procesor). Vnejsi jednotka (ovladac) obsahuje nejaky x51, pameti EPROM (s databazi). Presnou funkci komunikace neznam, ale mam otestovano, ze kdyz zapnu siderickou rychlost posunu osy RA a nasledne odpojim rucni ovladac, pak montaz pokracuje dale v cinnosti, jako by se nic nestalo. Stejne tak pri najizdeni na objekt - muzu zadat objekt, potvrdit a montaz najede bez problemu s odpojenym ovladacem. Vypada to tak, ze ovladac proste vlozi do 'motorove logiky' pocet pulsu RA a DE. Snimani polohy je pomoci odpocitavani pulsu motoru. To ma vyhodu a nevyhodu. Jako vyhodu bych videl jednoduchost koncepce, nevyhoda je v nemoznosti rucniho posunu montaze - veskere posuny jsou motorove, coz klade duraz na rychlost a presnost s ohledem na preskakovani kroku. Ja bych asi volil snimani polohy opticky, aby slo montazi hybat rucne - otazkou je dosazena presnost.
HonzaS
ED80, Dobson 16" a další bordel
SkyScan
HonzaS napsal: Oldik:
Ja bych asi volil snimani polohy opticky, aby slo montazi hybat rucne - otazkou je dosazena presnost.
HonzaSTo bych volil, pokud by to mel byt dokonaly system. Pokud to ma co nejrychleji chodit, pocital bych kroky motoru. Kdysi jsem to tak udelal pri motorizaci GS montaze a bylo to velice jednoduche - procesor nepotrebuje vstup od enkoderu, pocita kroky, ktere sam generuje. Takze se to snadno veslo do jednoho AT2051 i s pomalym rozbehem, sirokou skalou rychlosti, moznosti provozu bez ovladace a s rizenim 3 motoru ( uvazoval jsem o el. ostreni, ktere jsem ovsem mechanicky nikdy nerealizoval ). Je fakt, ze to nebylo "prave" go-to - nefungovalo po odaretovani os a max. rychlost byla 40x ( vic nezvladaly pohony z EQ5 ), coz je na prejizdeni malo.
Ja bych asi volil snimani polohy opticky, aby slo montazi hybat rucne - otazkou je dosazena presnost.
HonzaSTo bych volil, pokud by to mel byt dokonaly system. Pokud to ma co nejrychleji chodit, pocital bych kroky motoru. Kdysi jsem to tak udelal pri motorizaci GS montaze a bylo to velice jednoduche - procesor nepotrebuje vstup od enkoderu, pocita kroky, ktere sam generuje. Takze se to snadno veslo do jednoho AT2051 i s pomalym rozbehem, sirokou skalou rychlosti, moznosti provozu bez ovladace a s rizenim 3 motoru ( uvazoval jsem o el. ostreni, ktere jsem ovsem mechanicky nikdy nerealizoval ). Je fakt, ze to nebylo "prave" go-to - nefungovalo po odaretovani os a max. rychlost byla 40x ( vic nezvladaly pohony z EQ5 ), coz je na prejizdeni malo.
e-mail : mpec(at)cce(dot)cz&&
-
MMys
- Příspěvky: 18320
- Registrován: 02. 01. 2001, 05:03
- Bydliště: Běleč nad Orlicí
- Věk: 52
- Kontaktovat uživatele:
SkyScan
Takže já taky popíšu řešení mého systému, pro inspiraci, které není nikdy dost. Jedná se o variantu, kde poloha se získává počítáním kroků motoru, nicméně hardware je připravený i na připojení enkodérů.
Aby bylo nad čím diskutovat, tak tedy nejprve zveřejním schéma: http://hvbo.cz/foto_astronomy_cz/other/eq6_goto_sch.pdf.
Celý systém (oba motory) je řízen jednočipovým mikrokontrolérem C8051F121 (Mixed signal MCU, až 100MIPS, 8kb RAM, 128kB Flash, více na www.silabs.com) Každý z motorů je buzen výkonovým budičem L298 (U3 a U7), základní krokování v bipolárním režimu je realizováno pomocí jeho vstupů IN1 až IN4 (dva pro každou fázi motoru) a mikrokrokování je realizováno pomocí PWM (pulzně šířkové modulace) na vstupech ENA a ENB obvodu L298. Pokud je požadavek na rychlé pohyby použitelné pro motorové najíždění na objekt, musí být převod mezi hřídelí krokového motoru a šnekem malý, typicky v rozmezí 1:1 až 1:5. Z toho vyplývá nutnost použít u motoru synchronní režim, tzv. mikrokrokování, protože jinak bude při siderické rychlosti (sledování otáčení oblohy) krokování příliš hrubé, a montáž se bude pohybovat po skocích. Pokud se naopak použije větší převodový poměr, než zhruba uvádím, nebude možné dosáhnout vyšších rychlostí díky omezené maximální rychlosti krokování motoru. Realizace mikrokrokování je tedy klíčová pro takovýto systém, a pokud nevíš o co jde, doporučuji to nejprve nastudovat. V principu spočívá v tom, že průběh proudu vinutími krokového motoru má sinusový průběh (s fázovým posunem o 90 stupňů ve druhé fázi).
Aby bylo nad čím diskutovat, tak tedy nejprve zveřejním schéma: http://hvbo.cz/foto_astronomy_cz/other/eq6_goto_sch.pdf.
Celý systém (oba motory) je řízen jednočipovým mikrokontrolérem C8051F121 (Mixed signal MCU, až 100MIPS, 8kb RAM, 128kB Flash, více na www.silabs.com) Každý z motorů je buzen výkonovým budičem L298 (U3 a U7), základní krokování v bipolárním režimu je realizováno pomocí jeho vstupů IN1 až IN4 (dva pro každou fázi motoru) a mikrokrokování je realizováno pomocí PWM (pulzně šířkové modulace) na vstupech ENA a ENB obvodu L298. Pokud je požadavek na rychlé pohyby použitelné pro motorové najíždění na objekt, musí být převod mezi hřídelí krokového motoru a šnekem malý, typicky v rozmezí 1:1 až 1:5. Z toho vyplývá nutnost použít u motoru synchronní režim, tzv. mikrokrokování, protože jinak bude při siderické rychlosti (sledování otáčení oblohy) krokování příliš hrubé, a montáž se bude pohybovat po skocích. Pokud se naopak použije větší převodový poměr, než zhruba uvádím, nebude možné dosáhnout vyšších rychlostí díky omezené maximální rychlosti krokování motoru. Realizace mikrokrokování je tedy klíčová pro takovýto systém, a pokud nevíš o co jde, doporučuji to nejprve nastudovat. V principu spočívá v tom, že průběh proudu vinutími krokového motoru má sinusový průběh (s fázovým posunem o 90 stupňů ve druhé fázi).
http://hvbo.cz/foto_astronomy_cz, http://hvbo.cz, e-mail: martin(*)myslivec(a)volny(*)cz, Dobson 400mm, N400/1600, Refraktor Borg 77ED, Montáž EQ6, Hvězdárna s montáží vlastní výroby, kamery MII C3-61000, ZWO ASI 1600MM
-
MMys
- Příspěvky: 18320
- Registrován: 02. 01. 2001, 05:03
- Bydliště: Běleč nad Orlicí
- Věk: 52
- Kontaktovat uživatele:
SkyScan
Pro takovéto řízení krokového motoru musí mít mikrokontrolér nejlépe hardwarové PWM, a to hned dvě, pro každou fázi motoru jedno. Pro kompletní dvouosý systém jsou tedy třeba 4 PWM jednotky na jednom mikrokontroléru (tak to mám já), nebo použít dva mikrokontroléry (pro každý motor jeden se dvěmi PWM, jako ve SkyScanu) AVR-ka s PWM jednotkami na čipu snad existují, stačí jen vhodně vybrat. S těmito kontroléry jsem zatím ale nepracoval, tak nevím konrétní typ. Další možností je použít takový budič motoru, který má PWM-ka v sobě (vím, že to existuje, narazil jsem na to při stavbě, typ si teď nevzpomínám, musel bych to znovu najít) pak je mikrokontrolér nemusí mít. Třetí možností je pak použít nějaký speciální integrovaný obvod pro generování PWM, pozor všakn typy s plněním po sériové sběrnici (SPI, I2C) ty nejsou vhodné, nestíhá se je dostatečně rychle plnit. Je nutný paralelní vstup na jeden takt.
Nepokoušej se PWM realizovat softwarově, je třeba, aby jeho opakovací frekvence byla v ultrazvukové oblasti nad 20kHz, jinak motory ošklivě pískají, a navíc kontrolér musí dělat i hromadu jiných činností, a na to by při softwarovém generování PWM nemusel zbýt čas, PWM-ko musí být totiž stabilní a mít nejvyšší prioritu, jinak je pohyb trhaný.
Nepokoušej se mikrokrokování vynechat nebo nějak obejít, nevede to k použitelným výsledkům při požadavku na velký rozsah rychostí (siderická na volný chod polární osy a alespoň tak 300x siderická na přejezdy k objektům.
Taktéž je třeba vyřešit plynulé rozjíždění na vyšší rychlost, protože skokem z nuly na vyskou rychlost se motor díky setrvačným momentům montáže s dalekohledem buď nerozeběhne, a nebo budou vznikat rázy, ničící soukolí.
Volba motorů - pro dosažení vyšší rychlosti při malém převodovém poměru jsou třeba motory s poměrně velkým momentem. Nejlépe dostupné třeba z produkce firmy Microcon, konkrétně pro EQ5 i EQ6 vyhoví motor SX-17 s momentem 0.4Nm, který je ještě dost malý, a obě montáže utáhne při převodu kolem 1:3 až 1:4 i při 12V napájení (není nutný měnič na vyšší napětí pro motory)
Pokud jsou nyní u montáží původní motory s odporem vinutí v desítkách až stovkách ohmů (obvykle takové plechové kulaté) tak s těmi NELZE dosáhnout ani zdaleka rychlostí vyhovujících pro GO-TO systém, a je třeba je skutečně nahradit motory s nízkou impedancí vinutí.
Dost nutná je i regulace špičkového proudu vinutím v závislosti na aktuální rychlosti krokování. Pro pomalé pohyby je třeba pomocí PWM snížit maximální proud na u motoru povolenou mez, a při zrychlování, kdy přirozeně proud klesá se vzrůstající frekvencí, protože roste impedance vinutí, pak pokles proudu úměrně kompenzovat a udržovat ho přibližně na konstatní úrovni, dokud stačí napětí. Jinak je buď omezena maximální rychlost (dost) a nebo při použití plného napětí se při pomalém pohybu motory (popř. i budiče) silně přehřívají. Dá se to udělat kompromisně i bez toho, ale nebude to ono a nevyužije se maximální rychlost a monet motoru.
Další poznámky:
V mém provedení je celá logika řízení, včetně komunikačního protoklou (Meade LX200) a databáze objektů implementována v hlavním mikrokontroléru (C8051F121 - U5). Komunikace se pak odehrává pomocí dvou sériových rozhraní RS232 (přes konvertory MAX232 - U4), nebo USB (konvertor CP2010 - U6). Jedním kanálem se komunikuje s PC, a druhým s ručním ovladačem (na ten mám jiné schéma - kdyžak pošlu taky, ale to není tak důležité), tam je impementováno pouze menu, a komunikace s hlavní jednotkou je pomocí stejných příkazů protokolu LX200. Dalším vhodným "astronomickým" protokolem může být protokol řídících příkazů ASCOM, nebo nějaký vlastní protokol.
Možné je i jiné řešení, použité asi i ve SkyScanu, kde je většina logiky (menu, astrovýpočty, databáze, komunikace) v ručním ovladači, a mikrokontrolér(y) na desce u motorů vlastně jenom hýbou motory o daný počet kroků a danou rychlostí podle zaslaných povelů z ovladače.
Těžko říci, která varianta je lepší, každá má svoje klady a zápory.
Třetí varianta (kterou si ale nedokážu moc představit) je ta, že všechno (motory, i logiku ovládání a komunikaci) řídí jeden mikrokontrolér, a v ruce se drží pouze panel s tlačítky eventuelně displejem. Je ale třeba vzít v úvahu, že je omezen maximální počet vodičů, který může vést k ovladači tak na 6-8 kvůli ohebnosti kabelu a vhodnému konektoru. Navíc mikrokontrolér, který by to všechno zastal, bude muset být dostatečně vybavený (počet vývodů, periferie, paměť) a rychlý. Pravděpodobně tedy půjde spíše o distribuovaný systém ze dvou komponent. Ani opačné řešení (vše v ovladači do ruky, a pouze 8 drátů k motorům) není moc reálné. Při parametrech požadovaných pro GO-TO systém (hlavně dostatečná rychlost) je výkonová ztráta na budičích motroů taková, že to vyžaduje chladič, sice relativně malý, ale přesto to již nebude do ruky.
http://hvbo.cz/foto_astronomy_cz, http://hvbo.cz, e-mail: martin(*)myslivec(a)volny(*)cz, Dobson 400mm, N400/1600, Refraktor Borg 77ED, Montáž EQ6, Hvězdárna s montáží vlastní výroby, kamery MII C3-61000, ZWO ASI 1600MM
-
MMys
- Příspěvky: 18320
- Registrován: 02. 01. 2001, 05:03
- Bydliště: Běleč nad Orlicí
- Věk: 52
- Kontaktovat uživatele:
SkyScan
Nevím, jak zní Tvoje zadání, jestli máš řešit i takové věci jako omezení pohybu montáže, aby třeba nejela na objekt pod obzorem, což je výpočetně dost komplikovaná záležitost, vyžadující přepočet ekvatoreálních (RA a DE) souřadnic na azimutální (Elevace a Azimut) a kontrolu na zápornou elevaci. Ve vztazích pro přepočet figuruje reálný čas (je třeba tedy tam mít obvod hodin, v mém případě DS1307 - U8 ) a zadané zeměpisné souřadnice. Výpočet vyžaduje operace s reálnými čísly (nejlépe v plovoucí řádové čárce), je tam hodně výpočtů goniometrických funkcí.
Ad. navrhovaný dotykový displej - tohle nepovažuji vůbec za šťastné řešení. Sice by to možná bylo efektní, ale dost nepraktické. Z vlastní zkušenosti vím, jak je nepříjemné se v noci dívat na osvětlený displj, čím větší, tím horší. Obvykle je nutné ho mít prosvětlený červeně, a velmi slabě (ve dne to nesmí být vůbec vidět) jinak to je v noci nepoužitelné, protože po každém pohledu na něj si zlikvdiuješ adaptaci na tmu a v dalekohledu pak nic nevidíš. Navíc v noci se obvykle vše rosí (v zimě i omrzá) a jak by se za takových podmínek choval dotykový displej, to nevím. Některé typy nefungují na dotek v rukavicích -> problém v zimě. V mrazu se většina LCD displejů značně zpomalí, nebo úplně zamrznou. Proto jsou lepší luminiscenční dipleje, červené, a ty dotykové obvykle nejsou.
Ty máš zadáno jako cíl pouze teoretické řešení problému, nebo skutečnou realizaci prototypu ? Pokud je to ta druhá varianta, tak doufám, že máš k dispozici překladač jazyka C pro ty AVR-ka, protože úspěšně vyřešit do jednoho roku takový komplexní systém, byť v nejočesanější verzi, v assembleru, to si nedokážu představit (speciálně části pro práci s databází objektů a případné astronomické výpočty by byly v ASM chuťovka).
V případě zájmu můžu poskytnout i zdrojový kód, nebo jeho části, ale asi ti to k ničemu moc nebude, neboť je to dost striktně vázané ke specifickému hardware konkrétního mikrokontroléru.
Doporučuji začít tvořit tímto stylem:
1) koncpční návrh systému (která komponenta bude mít jakou funkci, zvolit například jedno z uvedených možných řešení)
2) návrh nejnižší úrovně systému týkající se řízení motorů (rutiny pro pohyb daný směrem a danou rychlostí, o zadaný počet kroků, mikrokrokování, řízení proudu, rozjezdy, brždění)
3) tvorba logiky vypočítávání souřadnic polohy montáže z napočítaných pulsů motorů RA a DE, synchronizace polohy s objektem - alepoň na jeden refernční bod, s tím souvisí i databáze pár desítek referenčních hvěz pro kalibraci.
4) volba způsobu komunikace mezi ovladače a řídící jednotkou, a její navázání na rutiny pro řízení motorů a odečet souřadnic, Nyní by systém měl již umět manuální pohyby z ovladače, nastavenou rychlostí (rozumné jsou alespoň tři, malá pro jemné centrování při vysokém zvětšení, střední pro hrubé vycentrování objektu a maximální, s plynulým rozjezdem, pro najíždění na objekt) a ukazovat na displeji aktuální souřadnice.
5) volba struktury databáze objektů, logika menu pro její prohlížení, vyslání povelů pro najetí na objekt, kontrola polohy objektu, určení nejkratší dráhy (aby se montáž místo o 10 stupňů nepřetáčela o 350 stupňů) a spousty dalších drobností...
No, povím Ti, ušila sis na sebe pěknou boudu Hlavně minimalizuj celý problém, a nenech se uvrtat do různých parádiček a vychytávek. Věř, že i samotné funkční jádro ti dá slušně zabrat, a rok je na to tak akorát.
Tenhle příspěvek byl míněný pro případ, že bys to skutečně chtěla stavět tak, aby to k něčemu bylo v praxi. Jelikož jsem samozejmě vysokou školu studoval, a diplomku dělal, tak vím, jak to pak chodí v praxi, takže je možné, že budeš muset nakonec z mnoha věcí ustoupit, u nějak to ošidit, jen aby bylo hotovo, a nebo si to naopak o rok protáhnout a dělat na tom dál, to ale záleží na tom, co chceš Ty.
Přeju hodně úspěchů, a v případě problémů se tady klidně na cokoli zeptej. Víc hlav víc ví.
Ad. navrhovaný dotykový displej - tohle nepovažuji vůbec za šťastné řešení. Sice by to možná bylo efektní, ale dost nepraktické. Z vlastní zkušenosti vím, jak je nepříjemné se v noci dívat na osvětlený displj, čím větší, tím horší. Obvykle je nutné ho mít prosvětlený červeně, a velmi slabě (ve dne to nesmí být vůbec vidět) jinak to je v noci nepoužitelné, protože po každém pohledu na něj si zlikvdiuješ adaptaci na tmu a v dalekohledu pak nic nevidíš. Navíc v noci se obvykle vše rosí (v zimě i omrzá) a jak by se za takových podmínek choval dotykový displej, to nevím. Některé typy nefungují na dotek v rukavicích -> problém v zimě. V mrazu se většina LCD displejů značně zpomalí, nebo úplně zamrznou. Proto jsou lepší luminiscenční dipleje, červené, a ty dotykové obvykle nejsou.
Ty máš zadáno jako cíl pouze teoretické řešení problému, nebo skutečnou realizaci prototypu ? Pokud je to ta druhá varianta, tak doufám, že máš k dispozici překladač jazyka C pro ty AVR-ka, protože úspěšně vyřešit do jednoho roku takový komplexní systém, byť v nejočesanější verzi, v assembleru, to si nedokážu představit (speciálně části pro práci s databází objektů a případné astronomické výpočty by byly v ASM chuťovka).
V případě zájmu můžu poskytnout i zdrojový kód, nebo jeho části, ale asi ti to k ničemu moc nebude, neboť je to dost striktně vázané ke specifickému hardware konkrétního mikrokontroléru.
Doporučuji začít tvořit tímto stylem:
1) koncpční návrh systému (která komponenta bude mít jakou funkci, zvolit například jedno z uvedených možných řešení)
2) návrh nejnižší úrovně systému týkající se řízení motorů (rutiny pro pohyb daný směrem a danou rychlostí, o zadaný počet kroků, mikrokrokování, řízení proudu, rozjezdy, brždění)
3) tvorba logiky vypočítávání souřadnic polohy montáže z napočítaných pulsů motorů RA a DE, synchronizace polohy s objektem - alepoň na jeden refernční bod, s tím souvisí i databáze pár desítek referenčních hvěz pro kalibraci.
4) volba způsobu komunikace mezi ovladače a řídící jednotkou, a její navázání na rutiny pro řízení motorů a odečet souřadnic, Nyní by systém měl již umět manuální pohyby z ovladače, nastavenou rychlostí (rozumné jsou alespoň tři, malá pro jemné centrování při vysokém zvětšení, střední pro hrubé vycentrování objektu a maximální, s plynulým rozjezdem, pro najíždění na objekt) a ukazovat na displeji aktuální souřadnice.
5) volba struktury databáze objektů, logika menu pro její prohlížení, vyslání povelů pro najetí na objekt, kontrola polohy objektu, určení nejkratší dráhy (aby se montáž místo o 10 stupňů nepřetáčela o 350 stupňů) a spousty dalších drobností...
No, povím Ti, ušila sis na sebe pěknou boudu Hlavně minimalizuj celý problém, a nenech se uvrtat do různých parádiček a vychytávek. Věř, že i samotné funkční jádro ti dá slušně zabrat, a rok je na to tak akorát.
Tenhle příspěvek byl míněný pro případ, že bys to skutečně chtěla stavět tak, aby to k něčemu bylo v praxi. Jelikož jsem samozejmě vysokou školu studoval, a diplomku dělal, tak vím, jak to pak chodí v praxi, takže je možné, že budeš muset nakonec z mnoha věcí ustoupit, u nějak to ošidit, jen aby bylo hotovo, a nebo si to naopak o rok protáhnout a dělat na tom dál, to ale záleží na tom, co chceš Ty.
Přeju hodně úspěchů, a v případě problémů se tady klidně na cokoli zeptej. Víc hlav víc ví.
http://hvbo.cz/foto_astronomy_cz, http://hvbo.cz, e-mail: martin(*)myslivec(a)volny(*)cz, Dobson 400mm, N400/1600, Refraktor Borg 77ED, Montáž EQ6, Hvězdárna s montáží vlastní výroby, kamery MII C3-61000, ZWO ASI 1600MM
SkyScan
MMys napsal:
...Další možností je použít takový budič motoru, který má PWM-ka v sobě (vím, že to existuje, narazil jsem na to při stavbě, typ si teď nevzpomínám, musel bych to znovu najít) pak je mikrokontrolér nemusí mít. ...
Napr. Allegro SLA7060(61...62). Umi mikrokrokovani v nekolika stupnich (myslim 16 az 64 mikrokroku na krok) a hlavne PWM.
Info viz http://www.allegromicro.com/sf/97060/
Mam je v supliku, ale zatim jsem je nepouzil
. Puvodne jsem je planoval na rizeni minifrezky/plottru, ale asi skonci v amaterske montazi k MTO-1000 
.
...Další možností je použít takový budič motoru, který má PWM-ka v sobě (vím, že to existuje, narazil jsem na to při stavbě, typ si teď nevzpomínám, musel bych to znovu najít) pak je mikrokontrolér nemusí mít. ...
Napr. Allegro SLA7060(61...62). Umi mikrokrokovani v nekolika stupnich (myslim 16 az 64 mikrokroku na krok) a hlavne PWM.
Info viz http://www.allegromicro.com/sf/97060/
Mam je v supliku, ale zatim jsem je nepouzil
. Puvodne jsem je planoval na rizeni minifrezky/plottru, ale asi skonci v amaterske montazi k MTO-1000 .SkyScan
Uff, tak to je vycerpavajici, dekuju za odpoved:) Prekopcim si to a budu se tim pokud mozno ridit. Mam to dovest do funkcni podoby, no pokud mozno funkcni, prekladac na avrka mam, jmenuje se to Ponyprog, jeste jsem s tim nedelala, prave k tomu bastlim jednoduchej programatorek, asembler jsem videla jen zdalky, kdyz jsem se ho museli ucit, ale od toho ruce pryc:) S ti dipslejem to je fakt, to jsem si neuvedomila, jen mi to navrh vedouci, kterej o tom moc nevi a ja mu na to skocila. Jinak ta 8051 me napadla, delala jsem na ni neco ve skole, mame tam programatory, takze by tim odpadlo jedno bastleni,ale avrka jsou prece jen trochu lidstejsi, teda aspon me prijde snadneji programovatelny. Jinak v tom starym modulu je nejaka 2051, ktera zajistuje to jednuduchy ovladani, jak jsem psala, takze dalsi faze bude preprogramovat ji na vetsi rychlost-to si porucili na hvezdarne, coz bude asi problem, pac zrejme nepujde upravovat zdrojak, vetsinou to vyrobci nejak zamknou:(
Omezeni pohybu montaze, to asi necham byt, kdyz to spoctu kolem a kolem, mam na to tak devet mesicu a to po me fakt nemuzou chtit. To mikrokrokovani zkusim najit a nastudovat.
Kdyz o tom tak premejslim, tak bude asi nejlepsi klavesnicka s jednoradkovym displejem, nebo tak neco.
No zatim moc dekuju za vycerpavajici popis, nevim jak ted budu na netu, odjizdime s hvezdarnou na takovy skoro dvoutydenni neco jako soustredeni:) Tak az se vratime, asi na tom zacnu intenzivne makat a otravovat Te. Teda spis az zacatkem zari(po zkouskach :-/)
Tak zatim moc dekuju, ze sis udelal cas a co nejdriv se ozvu
MMys napsal: Nevím, jak zní Tvoje zadání, jestli máš řešit i takové věci jako omezení pohybu montáže, aby třeba nejela na objekt pod obzorem, což je výpočetně dost komplikovaná záležitost, vyžadující přepočet ekvatoreálních (RA a DE) souřadnic na azimutální (Elevace a Azimut) a kontrolu na zápornou elevaci. Ve vztazích pro přepočet figuruje reálný čas (je třeba tedy tam mít obvod hodin, v mém případě DS1307 - U8 ) a zadané zeměpisné souřadnice. Výpočet vyžaduje operace s reálnými čísly (nejlépe v plovoucí řádové čárce), je tam hodně výpočtů goniometrických funkcí.
Ad. navrhovaný dotykový displej - tohle nepovažuji vůbec za šťastné řešení. Sice by to možná bylo efektní, ale dost nepraktické. Z vlastní zkušenosti vím, jak je nepříjemné se v noci dívat na osvětlený displj, čím větší, tím horší. Obvykle je nutné ho mít prosvětlený červeně, a velmi slabě (ve dne to nesmí být vůbec vidět) jinak to je v noci nepoužitelné, protože po každém pohledu na něj si zlikvdiuješ adaptaci na tmu a v dalekohledu pak nic nevidíš. Navíc v noci se obvykle vše rosí (v zimě i omrzá) a jak by se za takových podmínek choval dotykový displej, to nevím. Některé typy nefungují na dotek v rukavicích -> problém v zimě. V mrazu se většina LCD displejů značně zpomalí, nebo úplně zamrznou. Proto jsou lepší luminiscenční dipleje, červené, a ty dotykové obvykle nejsou.
Ty máš zadáno jako cíl pouze teoretické řešení problému, nebo skutečnou realizaci prototypu ? Pokud je to ta druhá varianta, tak doufám, že máš k dispozici překladač jazyka C pro ty AVR-ka, protože úspěšně vyřešit do jednoho roku takový komplexní systém, byť v nejočesanější verzi, v assembleru, to si nedokážu představit (speciálně části pro práci s databází objektů a případné astronomické výpočty by byly v ASM chuťovka).
V případě zájmu můžu poskytnout i zdrojový kód, nebo jeho části, ale asi ti to k ničemu moc nebude, neboť je to dost striktně vázané ke specifickému hardware konkrétního mikrokontroléru.
Doporučuji začít tvořit tímto stylem:
1) koncpční návrh systému (která komponenta bude mít jakou funkci, zvolit například jedno z uvedených možných řešení)
2) návrh nejnižší úrovně systému týkající se řízení motorů (rutiny pro pohyb daný směrem a danou rychlostí, o zadaný počet kroků, mikrokrokování, řízení proudu, rozjezdy, brždění)
3) tvorba logiky vypočítávání souřadnic polohy montáže z napočítaných pulsů motorů RA a DE, synchronizace polohy s objektem - alepoň na jeden refernční bod, s tím souvisí i databáze pár desítek referenčních hvěz pro kalibraci.
4) volba způsobu komunikace mezi ovladače a řídící jednotkou, a její navázání na rutiny pro řízení motorů a odečet souřadnic, Nyní by systém měl již umět manuální pohyby z ovladače, nastavenou rychlostí (rozumné jsou alespoň tři, malá pro jemné centrování při vysokém zvětšení, střední pro hrubé vycentrování objektu a maximální, s plynulým rozjezdem, pro najíždění na objekt) a ukazovat na displeji aktuální souřadnice.
5) volba struktury databáze objektů, logika menu pro její prohlížení, vyslání povelů pro najetí na objekt, kontrola polohy objektu, určení nejkratší dráhy (aby se montáž místo o 10 stupňů nepřetáčela o 350 stupňů) a spousty dalších drobností...
No, povím Ti, ušila sis na sebe pěknou boudu Hlavně minimalizuj celý problém, a nenech se uvrtat do různých parádiček a vychytávek. Věř, že i samotné funkční jádro ti dá slušně zabrat, a rok je na to tak akorát.
Tenhle příspěvek byl míněný pro případ, že bys to skutečně chtěla stavět tak, aby to k něčemu bylo v praxi. Jelikož jsem samozejmě vysokou školu studoval, a diplomku dělal, tak vím, jak to pak chodí v praxi, takže je možné, že budeš muset nakonec z mnoha věcí ustoupit, u nějak to ošidit, jen aby bylo hotovo, a nebo si to naopak o rok protáhnout a dělat na tom dál, to ale záleží na tom, co chceš Ty.
Přeju hodně úspěchů, a v případě problémů se tady klidně na cokoli zeptej. Víc hlav víc ví.
Omezeni pohybu montaze, to asi necham byt, kdyz to spoctu kolem a kolem, mam na to tak devet mesicu a to po me fakt nemuzou chtit. To mikrokrokovani zkusim najit a nastudovat.
Kdyz o tom tak premejslim, tak bude asi nejlepsi klavesnicka s jednoradkovym displejem, nebo tak neco.
No zatim moc dekuju za vycerpavajici popis, nevim jak ted budu na netu, odjizdime s hvezdarnou na takovy skoro dvoutydenni neco jako soustredeni:) Tak az se vratime, asi na tom zacnu intenzivne makat a otravovat Te. Teda spis az zacatkem zari(po zkouskach :-/)
Tak zatim moc dekuju, ze sis udelal cas a co nejdriv se ozvu
MMys napsal: Nevím, jak zní Tvoje zadání, jestli máš řešit i takové věci jako omezení pohybu montáže, aby třeba nejela na objekt pod obzorem, což je výpočetně dost komplikovaná záležitost, vyžadující přepočet ekvatoreálních (RA a DE) souřadnic na azimutální (Elevace a Azimut) a kontrolu na zápornou elevaci. Ve vztazích pro přepočet figuruje reálný čas (je třeba tedy tam mít obvod hodin, v mém případě DS1307 - U8 ) a zadané zeměpisné souřadnice. Výpočet vyžaduje operace s reálnými čísly (nejlépe v plovoucí řádové čárce), je tam hodně výpočtů goniometrických funkcí.
Ad. navrhovaný dotykový displej - tohle nepovažuji vůbec za šťastné řešení. Sice by to možná bylo efektní, ale dost nepraktické. Z vlastní zkušenosti vím, jak je nepříjemné se v noci dívat na osvětlený displj, čím větší, tím horší. Obvykle je nutné ho mít prosvětlený červeně, a velmi slabě (ve dne to nesmí být vůbec vidět) jinak to je v noci nepoužitelné, protože po každém pohledu na něj si zlikvdiuješ adaptaci na tmu a v dalekohledu pak nic nevidíš. Navíc v noci se obvykle vše rosí (v zimě i omrzá) a jak by se za takových podmínek choval dotykový displej, to nevím. Některé typy nefungují na dotek v rukavicích -> problém v zimě. V mrazu se většina LCD displejů značně zpomalí, nebo úplně zamrznou. Proto jsou lepší luminiscenční dipleje, červené, a ty dotykové obvykle nejsou.
Ty máš zadáno jako cíl pouze teoretické řešení problému, nebo skutečnou realizaci prototypu ? Pokud je to ta druhá varianta, tak doufám, že máš k dispozici překladač jazyka C pro ty AVR-ka, protože úspěšně vyřešit do jednoho roku takový komplexní systém, byť v nejočesanější verzi, v assembleru, to si nedokážu představit (speciálně části pro práci s databází objektů a případné astronomické výpočty by byly v ASM chuťovka).
V případě zájmu můžu poskytnout i zdrojový kód, nebo jeho části, ale asi ti to k ničemu moc nebude, neboť je to dost striktně vázané ke specifickému hardware konkrétního mikrokontroléru.
Doporučuji začít tvořit tímto stylem:
1) koncpční návrh systému (která komponenta bude mít jakou funkci, zvolit například jedno z uvedených možných řešení)
2) návrh nejnižší úrovně systému týkající se řízení motorů (rutiny pro pohyb daný směrem a danou rychlostí, o zadaný počet kroků, mikrokrokování, řízení proudu, rozjezdy, brždění)
3) tvorba logiky vypočítávání souřadnic polohy montáže z napočítaných pulsů motorů RA a DE, synchronizace polohy s objektem - alepoň na jeden refernční bod, s tím souvisí i databáze pár desítek referenčních hvěz pro kalibraci.
4) volba způsobu komunikace mezi ovladače a řídící jednotkou, a její navázání na rutiny pro řízení motorů a odečet souřadnic, Nyní by systém měl již umět manuální pohyby z ovladače, nastavenou rychlostí (rozumné jsou alespoň tři, malá pro jemné centrování při vysokém zvětšení, střední pro hrubé vycentrování objektu a maximální, s plynulým rozjezdem, pro najíždění na objekt) a ukazovat na displeji aktuální souřadnice.
5) volba struktury databáze objektů, logika menu pro její prohlížení, vyslání povelů pro najetí na objekt, kontrola polohy objektu, určení nejkratší dráhy (aby se montáž místo o 10 stupňů nepřetáčela o 350 stupňů) a spousty dalších drobností...
No, povím Ti, ušila sis na sebe pěknou boudu Hlavně minimalizuj celý problém, a nenech se uvrtat do různých parádiček a vychytávek. Věř, že i samotné funkční jádro ti dá slušně zabrat, a rok je na to tak akorát.
Tenhle příspěvek byl míněný pro případ, že bys to skutečně chtěla stavět tak, aby to k něčemu bylo v praxi. Jelikož jsem samozejmě vysokou školu studoval, a diplomku dělal, tak vím, jak to pak chodí v praxi, takže je možné, že budeš muset nakonec z mnoha věcí ustoupit, u nějak to ošidit, jen aby bylo hotovo, a nebo si to naopak o rok protáhnout a dělat na tom dál, to ale záleží na tom, co chceš Ty.
Přeju hodně úspěchů, a v případě problémů se tady klidně na cokoli zeptej. Víc hlav víc ví.
Oldik
SkyScan
Oldik napsal: ....Mam to dovest do funkcni podoby, no pokud mozno funkcni, prekladac na avrka mam, jmenuje se to Ponyprog, jeste jsem s tim nedelala, prave k tomu bastlim jednoduchej programatorek, asembler jsem videla jen zdalky, kdyz jsem se ho museli ucit, ale od toho ruce pryc...
Oldik:
Dle tve posledni odpovedi soudim, ze se s architekturou mikroprocesoru a zpusobem psani programu teprve seznamujes. Jen bych chtel upresnit, ze Ponyprog je pouze nastroj k zapsani, ci nacteni obsahu nekterych typu mikroprocesoru a pameti EEPROM, v zadnem pripade se nejedna o kompilator ani assembler. Proto dovol, abych shrnul nektere vybrane typy mikroprocesoru, dostupna vyvojova prostredi, ktera jsou k videni ve zdejsich krajich.
Jako nejnizsi kategorie mikroprocesoru povazuji PIC od Microchipu, jejich architektura je 8bitu RISC, maji pomerne malo pameti RAM i FLASH, psani zdrojovych kodu obvykle probiha v assembleru, ceckovy prekladac primo od Microchipu je pomerne zabugovany. Ladeni programu na zakladnim debuggeru (ja mu rikam 'Lentilka'), ktery jsem parkrat pouzil je dost nic-moc, tvari se jako realtime, ma hrozne pomale odezvy, nekdy nereaguje vubec.
Picky jsou velmi dobre pro aplikace typu: snimac polohy, generator PWM, aj. jednoduche aplikace. S modelem 10F200 (v 6 vyvodovem pouzdre!!) mam teplomer s digitalnim prenosem. Nektere typy flash lze programovat Ponyprogem. Mezi nectnosti patri prepinani bank registru, pevna hloubka stacku - u nejnizsich modelu pouze 2 adresy. Mezi klady cena, spotreba, elektricka odolnost, HW konstrukce I/O, prakticky nesmrtelna spolehlivost obvodu vzhledem k vnitrnimu WDT, kterym je nezavisly RC.
Dalsi kategorii 'malych' jednocipu je zakladni rada x51, x52. Je to prakticky nejoblibenejsi 'skolni' vybaveni. Prakticky uz ve svem okoli neznam firmu, ktera by s x51 mela komercni aplikaci (ted nemam namysli klony x51, ktere poskytuji mnoho periferii, J-TAG, vyssi vykon aj., ktere napr. pouziva Martin). Ja jsem s x51 prisel do styku samozrejme ve skole. Architektura je 8bitu, CISC. Vetsina z nich nema J-TAG. Omezena RAM, ROM (FLASH) do 64k, pak je nutne strankovat. Prakticky zadne periferie (prakticky jen timer, usart, preruseni a to jeste dost omezene). Nicmene i pres spatne vlastnosti zakladni rady x51/x52 je tato architektura pomerne oblibena. Procesory jsou pomerne levne. Coz je vykoupeno velmi vysokou spotrebou a nizkym pracovnim vykonum (vzhledem k jejich frekvenci). Jak prekladace jazyka C, tak i assembleru jsou kvalitni. Osobne mam otestovan FSI a Keil - samozrejme se jedna o placene produkty. Demoverze jsou do 4kb, resp. 2kb vysledneho kodu, coz je nic moc. Simulator je samozrejme softwarovy, HW emulator je nutne zakoupit.
AVR-kovy kit jsem doma mel uz kdysi davno, byl na nem AT90S2343 (nebo tak nejak), na prvni pohled vylepsena architektura - vice registru, periferii, pameti, linearni pristup do cele pameti, rychlost. V dobe, kdy jsem o teto platforme uvazoval byly dost nedostupne. Testoval jsem 'default' prostredi od Atmelu, byl to assembler (kompilator C je samozrejme placeny). Zda se, ze to funguje. Ladeni programu probiha pomoci simulatoru. Nektere nove 'velke' modely maji J-Tag, snad je AVRStudio podporuje. Aplikaci zadnou nemam, vadila mi opet pomerne vysoka spotreba i kdyz o neco vyssi, ne u x51.
zde bych asi udelal tlustou caru - pro mikroprocesory nize je vhodne pouziti C kompilatoru, jinak hrozi nizka casova efektivita prace (vlastni zkusenost).
--------------------------------------------------------------
Dalsi kategorii 'stredni tridy' bych povazoval klony x51, ktere vyrabi napr. CYPRESS, PHILIPS XA, DALLAS. Maji jiz vice periferii, jine jadro, ktere je zpravidla mnohonasobne vykonejsi, nez zakladni x51. Nektere typy jsou celkem drahe, coz u kusovky je jedno. Architektura prakticky vychazi z x51. Vetsina z nich ma J-Tag (interface pro realtime debugging primo v aplikaci - neni nutny HW emulator), k nemu je ale nutny software, ktery to podporuje (Keil). O teto kategorii by mohl napsat Martin, nebot se jimy zabyva.
Pro klony x51 lze pouzit SDCC (free verze kompilatoru a linkeru) http://sdcc.sourceforge.net/
Nasleduje dalsi kategorie 'stredni tridy' - rada MSP430 od Texase. Je to 16-bitova RISC architektura s naprosto plochym modelem pameti. Jedna se o pomerne novou architekturu. Kompilatory lze pouzit GCC Crosscompiler pod linuxem vcetne realtime J-Tag debuggeru GDB (testoval jsem, GDB je plne funkcni, nicmeme nektere me kolegy vubec nenadchnul). Jelikoz je to ma 'mainstreamova' platforma, tak mam dva kompilatory: IAR a Rowley, ktery vychazi lepe hlavne cenove, posledni verze uz prakticky bez chyby. Oba kompilatory lze poridit v plne 'demo'-verzi na 30 dni. Realtime debugging primo v aplikaci je presne tak, jak si predstavuji. Kompiler podporuje jak 32, tak 64 bitouvou matematiku plovouci, celou, tak int, coz jej predurcuje pro matematicke vypocty (GCC Crosscompiler taktez). http://www.rowley.co.uk/
Tento mikrokontroler je urcen zejmena pro mixed-aplications (ma spoustu periferii), vykazuje taktez neuveritelne nizkou spotrebu.
Jako posledni bych uvedl, ze v posledni dobe dochazi k velkemu boomu mikroprocesoru s modifikovanym jadrem ARM. Ktere jsou plne 32-bitove. Lze poridit rovnez kompilator a debudder od Rowley, nebo rovnou nativne pouzit GCC Crosscompiler. Bohuzel jedinne, co vim, je ze funguje GCC a to ze mi lezi kit ve skrini, nebot pro to nemam uplatneni. - Melodicky zvonek si s ARMem asi stavet nebudu . Nejnizsi modely maji kolem 16kb RAM a 128kb Flash, vykon kolem 60-75 MIPS ve 32 bitech a mnoho periferii (Philips LPC2104), cena je pro zajimavost kolem 200,-, samostatny kit poslou prakticky zadarmo - plati se pouze letecka doprava. Vyssi modely maji radic pameti SDRAM primo na sobe, externi adresovy prostor je vsak omezen na 16M x 32bitu - coz musi stacit. Jako aplikaci jsem doma testoval (samozrejme s integrovanou externi ROM a RAM) zarizeni pro indentifikaci osob pomoci otisku prstu od Atmelu. Zarizeni v realnem case vyhodnocovalo odporovou sit palce + pritlak a z toho 3D relief. Ten pak porovnaval s ulozenymi daty. Abych nezapomel, cele to bezelo na embeded linuxu, administrace probihala skrze webove rozhrani (sitova karta), kde pri prejeti prstem se zobrazila 3D mapa pomoci obrazku, nasledne to vypsalo shodu, ci neshodu. Zde je link na hracku: http://www.atmel.com/dyn/resources/prod ... oc5391.pdf
Zcela zamerne jsem vynechal jednocipy od Motoroly (HC11, HC6809 aj.) se kterymi jsem sice setkal, ale nemel jsem k nim zadne prostredi, takze jsem si s nimy nemohl hrat, vyjma 68HC340 na ktery chodi GCC a GDB, jehoz architekturu prakticky neznam.
--------------------------------------------------------------
Nakonec bych jeste vzpomenul assembler Z80 a 8080A - najdou se naprosto silene konstrukce v amaterskem radiu se zrovna tak silenym (hroznym) assemblerem.
PS: jsem odkojen asm 6502/6510/68000 (Atari/C64/A500), takze to nekteri jiste chapete.
HonzaS
Oldik:
Dle tve posledni odpovedi soudim, ze se s architekturou mikroprocesoru a zpusobem psani programu teprve seznamujes. Jen bych chtel upresnit, ze Ponyprog je pouze nastroj k zapsani, ci nacteni obsahu nekterych typu mikroprocesoru a pameti EEPROM, v zadnem pripade se nejedna o kompilator ani assembler. Proto dovol, abych shrnul nektere vybrane typy mikroprocesoru, dostupna vyvojova prostredi, ktera jsou k videni ve zdejsich krajich.
Jako nejnizsi kategorie mikroprocesoru povazuji PIC od Microchipu, jejich architektura je 8bitu RISC, maji pomerne malo pameti RAM i FLASH, psani zdrojovych kodu obvykle probiha v assembleru, ceckovy prekladac primo od Microchipu je pomerne zabugovany. Ladeni programu na zakladnim debuggeru (ja mu rikam 'Lentilka'), ktery jsem parkrat pouzil je dost nic-moc, tvari se jako realtime, ma hrozne pomale odezvy, nekdy nereaguje vubec.
Picky jsou velmi dobre pro aplikace typu: snimac polohy, generator PWM, aj. jednoduche aplikace. S modelem 10F200 (v 6 vyvodovem pouzdre!!) mam teplomer s digitalnim prenosem. Nektere typy flash lze programovat Ponyprogem. Mezi nectnosti patri prepinani bank registru, pevna hloubka stacku - u nejnizsich modelu pouze 2 adresy. Mezi klady cena, spotreba, elektricka odolnost, HW konstrukce I/O, prakticky nesmrtelna spolehlivost obvodu vzhledem k vnitrnimu WDT, kterym je nezavisly RC.
Dalsi kategorii 'malych' jednocipu je zakladni rada x51, x52. Je to prakticky nejoblibenejsi 'skolni' vybaveni. Prakticky uz ve svem okoli neznam firmu, ktera by s x51 mela komercni aplikaci (ted nemam namysli klony x51, ktere poskytuji mnoho periferii, J-TAG, vyssi vykon aj., ktere napr. pouziva Martin). Ja jsem s x51 prisel do styku samozrejme ve skole. Architektura je 8bitu, CISC. Vetsina z nich nema J-TAG. Omezena RAM, ROM (FLASH) do 64k, pak je nutne strankovat. Prakticky zadne periferie (prakticky jen timer, usart, preruseni a to jeste dost omezene). Nicmene i pres spatne vlastnosti zakladni rady x51/x52 je tato architektura pomerne oblibena. Procesory jsou pomerne levne. Coz je vykoupeno velmi vysokou spotrebou a nizkym pracovnim vykonum (vzhledem k jejich frekvenci). Jak prekladace jazyka C, tak i assembleru jsou kvalitni. Osobne mam otestovan FSI a Keil - samozrejme se jedna o placene produkty. Demoverze jsou do 4kb, resp. 2kb vysledneho kodu, coz je nic moc. Simulator je samozrejme softwarovy, HW emulator je nutne zakoupit.
AVR-kovy kit jsem doma mel uz kdysi davno, byl na nem AT90S2343 (nebo tak nejak), na prvni pohled vylepsena architektura - vice registru, periferii, pameti, linearni pristup do cele pameti, rychlost. V dobe, kdy jsem o teto platforme uvazoval byly dost nedostupne. Testoval jsem 'default' prostredi od Atmelu, byl to assembler (kompilator C je samozrejme placeny). Zda se, ze to funguje. Ladeni programu probiha pomoci simulatoru. Nektere nove 'velke' modely maji J-Tag, snad je AVRStudio podporuje. Aplikaci zadnou nemam, vadila mi opet pomerne vysoka spotreba i kdyz o neco vyssi, ne u x51.
zde bych asi udelal tlustou caru - pro mikroprocesory nize je vhodne pouziti C kompilatoru, jinak hrozi nizka casova efektivita prace (vlastni zkusenost).
--------------------------------------------------------------
Dalsi kategorii 'stredni tridy' bych povazoval klony x51, ktere vyrabi napr. CYPRESS, PHILIPS XA, DALLAS. Maji jiz vice periferii, jine jadro, ktere je zpravidla mnohonasobne vykonejsi, nez zakladni x51. Nektere typy jsou celkem drahe, coz u kusovky je jedno. Architektura prakticky vychazi z x51. Vetsina z nich ma J-Tag (interface pro realtime debugging primo v aplikaci - neni nutny HW emulator), k nemu je ale nutny software, ktery to podporuje (Keil). O teto kategorii by mohl napsat Martin, nebot se jimy zabyva.
Pro klony x51 lze pouzit SDCC (free verze kompilatoru a linkeru) http://sdcc.sourceforge.net/
Nasleduje dalsi kategorie 'stredni tridy' - rada MSP430 od Texase. Je to 16-bitova RISC architektura s naprosto plochym modelem pameti. Jedna se o pomerne novou architekturu. Kompilatory lze pouzit GCC Crosscompiler pod linuxem vcetne realtime J-Tag debuggeru GDB (testoval jsem, GDB je plne funkcni, nicmeme nektere me kolegy vubec nenadchnul). Jelikoz je to ma 'mainstreamova' platforma, tak mam dva kompilatory: IAR a Rowley, ktery vychazi lepe hlavne cenove, posledni verze uz prakticky bez chyby. Oba kompilatory lze poridit v plne 'demo'-verzi na 30 dni. Realtime debugging primo v aplikaci je presne tak, jak si predstavuji. Kompiler podporuje jak 32, tak 64 bitouvou matematiku plovouci, celou, tak int, coz jej predurcuje pro matematicke vypocty (GCC Crosscompiler taktez). http://www.rowley.co.uk/
Tento mikrokontroler je urcen zejmena pro mixed-aplications (ma spoustu periferii), vykazuje taktez neuveritelne nizkou spotrebu.
Jako posledni bych uvedl, ze v posledni dobe dochazi k velkemu boomu mikroprocesoru s modifikovanym jadrem ARM. Ktere jsou plne 32-bitove. Lze poridit rovnez kompilator a debudder od Rowley, nebo rovnou nativne pouzit GCC Crosscompiler. Bohuzel jedinne, co vim, je ze funguje GCC a to ze mi lezi kit ve skrini, nebot pro to nemam uplatneni. - Melodicky zvonek si s ARMem asi stavet nebudu . Nejnizsi modely maji kolem 16kb RAM a 128kb Flash, vykon kolem 60-75 MIPS ve 32 bitech a mnoho periferii (Philips LPC2104), cena je pro zajimavost kolem 200,-, samostatny kit poslou prakticky zadarmo - plati se pouze letecka doprava. Vyssi modely maji radic pameti SDRAM primo na sobe, externi adresovy prostor je vsak omezen na 16M x 32bitu - coz musi stacit. Jako aplikaci jsem doma testoval (samozrejme s integrovanou externi ROM a RAM) zarizeni pro indentifikaci osob pomoci otisku prstu od Atmelu. Zarizeni v realnem case vyhodnocovalo odporovou sit palce + pritlak a z toho 3D relief. Ten pak porovnaval s ulozenymi daty. Abych nezapomel, cele to bezelo na embeded linuxu, administrace probihala skrze webove rozhrani (sitova karta), kde pri prejeti prstem se zobrazila 3D mapa pomoci obrazku, nasledne to vypsalo shodu, ci neshodu. Zde je link na hracku: http://www.atmel.com/dyn/resources/prod ... oc5391.pdf
Zcela zamerne jsem vynechal jednocipy od Motoroly (HC11, HC6809 aj.) se kterymi jsem sice setkal, ale nemel jsem k nim zadne prostredi, takze jsem si s nimy nemohl hrat, vyjma 68HC340 na ktery chodi GCC a GDB, jehoz architekturu prakticky neznam.
--------------------------------------------------------------
Nakonec bych jeste vzpomenul assembler Z80 a 8080A - najdou se naprosto silene konstrukce v amaterskem radiu se zrovna tak silenym (hroznym) assemblerem.
PS: jsem odkojen asm 6502/6510/68000 (Atari/C64/A500), takze to nekteri jiste chapete.
HonzaS
ED80, Dobson 16" a další bordel