M128 czy podoła - enkodery inkrementalny i inne peryferia

[fobos319]

Witam.

Podczas projektowania robocika 4 kołowego z 4 silnikami(pololu lub HL149) chciałem założyć na oś 4 tarcze z myszy kulkowej i układ opto (dioda IR +fototranzystor podwójny)+komparatory LM358D

Planuje kontrolować przebytą drogę jak i kierunek obrotu kół(coś ala kontrola trakcji),

8 wyjść z komparatorów planuje podłączyć pod 8 przerwań zewnętrznych AT128 .

I teraz nasuwa się pytanie a właściwie pytania :

1- int1 ma wyższy priorytet niż inne nie będzie konfliktu jak enkodery wywołają przerwanie na innych pinach przerwań ??(przerwanie będzie inkrementowało zmienna(droga) i sprawdzało ustawiało flagę kierunku

2-czy atmega przy 16MHz (Vcc-3,3V) wyrobi się z m.in. : karta sd (mapa terenu) lcd z s65

(proste menu) , akcelerometr,

3-generowanie PWM 2 kanały

4-kontrola nap aku (adc)

5-uart (btm222)

6-kilka pinów sterowanie oświetleniem

7-określanie najbardziej optymalnej drogi (algorytmu jeszcze nie określiłem)

8-timer1 32,768kHz

I to na razie tyle chyba że jeszcze mi się coś przypomni a sam liczę, myślę i już sam nie wiem może zredukować enkodery do 2 sztuk tzn. 4 wyjść tylko z tylnych kół ??

Pomóżcie

Schemat myślę że nie jest potrzebny ale mogę umieścić.

Pozdrawiam i dziękuje za pomoc

[MirekCz]

Wszystko zależy od ilości impulsów na sekundę z enkodera. Przy kilkuset impulsach (czyli razem np. 1000 przerwań zewnętrznych) i rozsądnym kodzie przerwania (np 500 cykli zegara) zajmie to tobie 500,000 cykli czyli 0,5 z 16,0mln cykli czyli ok. 3% czasu CPU.

Gorzej jak będziesz chciał dużo większej liczby przerwań (szybko poruszający się robot), bo wtedy obsługa enkoderów będzie zajmować większą ilość czasu CPU i wtedy przyda się sprzętowe rozwiązanie.

Co do reszty punktów to w większości masz do tego specjalny hardware (PWM,ADC,UART), którego samo oprogramowanie to zaledwie kilkadziesiąt cykli CPU, a dalej wszystko odbywa się sprzętowo..

Najgorzej wygląda sprawa z obsługą karty SD i określeniem optymalnej drogi. Jak będziesz to robił raz na ileś sekund to nie problem żeby algorytm był skomplikowany i zabierał np. 1sec. Niestety jak miałoby to działać bardzo szybko to będzie problem i warto rozejrzeć się za procesorem z dużo większą ilością pamięci (np. są army z programowalnym >=256kB flash i >=64kB RAM). W takim wypadku dostęp do obu pamięci jest zdecydowanie szybszy i wygodniejszy niż karty SD itd.

[fobos319]

O sprzętowych peryferiach to wiem i je uwzględniłem , ale jednak to zabiera ileś czasu procesora, silniki prawdopodobnie będą pololu Hp100-1 z obustronną osią tylko nigdzie nie mogę odnaleźć dokładnej liczby obrotów na osi przy zasilani 6V bo obroty na przekładni są zaokrąglone.

A jeśli chodzi o army to nie powiem kusi mnie ale nie wiem czy ogarnę taki potężny procek gdzie jestem początkujący w C :/

Też myślałem nad inną pamięcią dosyć pojemną gdyż planuje zapisywać dużo danych aby potem z dowolnego miejsca mógł określić optymalną drogę , tak myślę aby zredukować enkodery z 4 do 2 tlko na tylnych kołach ale nie będę miał dokładnych danych przy poślizgu skręcie ,

A jakie Army mają wejścia na enkoder inkrementalny ?? lub jaki byś doradził ??

A ma to być mały robocik 15cm x 15cm 4 koła , 6 sharpów + inne czujniki ,BT i inne do rozwijania zdolności i wiedzy w domu :/

Chyba faktycznie pomyśle nad przeniesieniem się na army :/

[MirekCz]

Ja używam STM32. Wybór jest duży, także dev.kitów na początek. Jak dobrze pamiętam są wersje ze sprzętową obsługą enkoderów, ale nie wiem ile możesz ich mieć.

ARMy mają wiele zalet i jak dobrze wybierzesz to możliwości są olbrzymie w porównaniu z ATMEGA128. Programowanie nie jest wcale dużo trudniejsze (chociaż jest więcej funkcji, więc trochę z początku się do czegoś dokopać). Ja miałem trochę problemów z instalacją i konfiguracją kompilatora, ale potem poszło już gładko.

Generalnie to co chcesz zrobić nie jest najprostszą rzeczą. Z jednej strony z ATMEGA128 łatwiejszy masz start, ale z drugiej strony gorsze peryferia i wolniejszy procesor może bardzo utrudnić Tobie życie w dalszych fazach projektu, gdzie tak radykalna zmiana mikrokontrolera będzie trudna.

[fobos319]

Czyli w grę wchodzi tylko przesiadka na ARMa i opanowanie C.

Trochę strach ale co tam

STM32 dużo o nich słychać zaraz zacznę szukać modeli .

Czy mogę liczyć na pomoc w uwzględnieniu tego na co patrzeć bo to chwilowo dla mnie obca architektura i nie wiem dokładnie na co patrzeć .

[Grabki]

Chyba warto, żebyś się tym zainteresował: http://forum.atnel.pl/topic1625.html

[MirekCz]

Ja mam doświadczenie z stm32f103 i jak dla Ciebie powinny spokojnie wystarczyć.

Możesz też spojrzeć na stm32f100, chociaż one już będą raczej za słabe, ale są bardzo podobne do stm32f103, a devkit discovery mam w sprzedaży za 50zł - zawiera on w sobie zarówno programator jak i debugger, czyli idealnie nadaje się do nauki i pierwszyh kroków. Jak opanujesz stm32f100 to przesiadka na stm32f103 to formalność.

[fobos319]

Dziękuje

Zaraz przejże DS STM32 103 i zobaczymy co to ma i czy poradzę sobie z nim

Mam nadzieje ze w razie problemów będę mógł liczyć na Twoją i innych pomoc ?? bo to dla mnie coś nowego

Aha a coś wspominałeś rozwiązaniu sprzętowym możesz trochę jaśniej bo ja kombinowałem na przerzutnikach licznikach i nic sensownego mi nie wyszło :/

A co myślisz o :

STM32F103RCT6 -

Rdzeń: 32-bitowy CORTEX-M3

Liczba pinów I/O: 51

Pamięć Flash: 256 KB

Pamięć RAM: 32KB

Maksymalna częstotliwość taktowania rdzenia: 72MHz

Liczba Timerów: 8

ADC (16 wejść)

DAC

DMA

Ilość kanałów PWM: 16

Komunikacja: 3 x USART, 2 x UART, 3 x SPI, 2 x I2C, USB, CAN, SDIO

Napięcie zasilania:2V to 3,6V

Zakres temperatury pracy:-40°C do +85°C

Obudowa: LQFP-64

Czy ten mniejszy :

STM32F103RBT6

Rdzeń: 32-bitowy CORTEX-M3

Liczba pinów I/O: 51

Pamięć Flash: 128 KB

Pamięć RAM: 20KB

Maksymalna częstotliwość taktowania rdzenia: 72MHz

Liczba Timerów: 8

ADC (16 wejść)

DAC

DMA

Ilość kanałów PWM: 16

Komunikacja: 3 x USART, 2 x UART, 2 x SPI, 2 x I2C, USB, CAN, SDIO

Napięcie zasilania:2V to 3,6V

Zakres temperatury pracy:-40°C do +85°C

Obudowa: LQFP-64