Jaki mikrokontroler wybrać do...?

To do AVR'a trzeba dodać ADC albo zainteresować się czymś z rodziny STM32.

Stm 32 - pewnie 32 bit (oki) , cenowo jeśli będzie to w granicy 30zł to spokojnie , byle by nie 50 czy 100

Ceny są różne - sam sobie sprawdź od którego modelu masz ADC 16 bit. Bo są 12, 16 i 24 bitowe...
Sam trochę poszukaj też.

oki,
W takim razie poczytam na temat stm32 i w razie wątpliwości zapytam tutaj.
Dzięki.

elmłot napisał:

Sygnał jest w okolicy 100Hz . Urządzenie zamienia sygnał zadany na ruch zgodny z nim (jak na wykresie góra dół) . [...]Wówczas osiągnąć można by 17 a nawet 18 bit - takie pseudo 17 czy 18.

Proponuję zastanowić się nad odpowiedzią na takie pytania:
Jaki ruch (w metrach) wykonuje układ wykonawczy ?
Jaka dokładność pozycjonowania (w metrach) jest wymagana aby uzyskać te 17 czy 18 bitów ?
Jaka prędkość musi osiągać układ wykonawczy aby nadążyć za zmianami sygnału o częstotliwości 100Hz ?
Jakie przyspieszenia musi osiągać układ wykonawczy ?
Jaka moc będzie konieczna aby uzyskać wymagane przyspieszenie ?

W milimetrach .

Prędkość = około 100 Hz to 10 milisekund a droga 20-30 mm co da nam 30mm/10ms= 3m/s
spokojnie można uzyskać prędkość 20- 30 m/s
ale wówczas moc jest niezbędna , natomiast przy prędkości rzędu 3m/s waty wystarczają.

Ten temat - mechaniczny - jest już rozwiązany chodzi tylko o dość precyzyjne sterowanie.
Algorytmy ponadto mają pomóc w optymalnym dostosowaniu sterowania mając na uwadze bezwładność elementów wprawianych w ruch o masie rzędu 50g, co również pozwoli na optymalne wykorzystanie energii potrzebnej do wykonania ruchu - sprawność energetyczna. Zasilenie cewki może zostać wyłączone przed uzyskaniem zadanego punktu gdyż siła bezwładności i tak spowoduje że układ rozpędzony dotrze tam gdzie ma dotrzeć.

elmłot napisał:

droga 20-30 mm [...]
Ten temat - mechaniczny - jest już rozwiązany chodzi tylko o dość precyzyjne sterowanie.

Pominąłeś kluczowe pytanie.
Rozdzielczość pozycjonowania 17 bitów dla 30mm wymaga uzyskania dokładności rzędu 0.3 um. Czy zdajesz sobie sprawę z tego co chcesz osiągnąć ?

Pojemnościowy czujnik jest w stanie uzyskać rozdzielczość "nm"
co nie oznacza że AŻ taka musi być , lecz mając na uwadze że będzie pewne przekłamanie (i cyfrowe i analogowe) przyjmuje że minimum 16 bit MUSI być, a programowo można pokusić się o pseudo 18 bit.
Doskonale zdaje sobie sprawę , temat wałkuje jakiś czas i jest to robota zegarmistrzowska.

Moderowany przez LordBlick:

Niemerytoryczne uwagi wykasowałem.
Prośba do odpowiadających - tematyką zapytania jest dobór mikrokontrolera, a nie zapewnienie warunków dokładności.

Porównywanie rozmiarów kodu wynikowego windowsowego pliku wykonywalnego, kodu źródłowego tegoż pliku i zajętości pamięci kodu w mikrokontrolerze moim zdaniem zupełnie mija się z celem. Różne biblioteki (lub ich brak), różne środowiska, różne architektury, implementacja z uwzględnieniem możliwości i peryferiów STM32 i pewnie jeszcze kilka rzeczy można wymienić. Nawet dla prostego programu i zakładając jakiś stopień podobieństwa funkcjonalnego to w praktyce niewykonalne. Zajętość kodu na STM32 należy ocenić z punktu widzenia pisania aplikacji od zera na ten układ.

I sam fakt napisania kodu wprost w języku asemblerowym nie implikuje, że kod będzie mniejszy, współczesne kompilatory zwykle generują znacznie lepszy (wydajniejszy i/lub mniejszy) kod wynikowy, niż człowiek jest w stanie napisać w sensownym czasie.

Napisałem dla zobrazowania jak to obecnie wygląda - wielkość programu w delphi.
Chyba lepiej to tak przedstawić niż wcześniejsze moje określenie :

"Pamięć mogąca pomieścić kilka wersji algorytmu sterującego pracą - myślę że to nie zajmie dużo miejsca - może można porównać do programu sterującego np pralką automatyczną"

Porozmawiam ze znajomym i dowiem się ile to może ważyć w jego wersji.

elmłot napisał:

Napisałem dla zobrazowania jak to obecnie wygląda - wielkość programu w delphi.

Mam wrażenie, że bez znajomości podstaw programowania mikrokontrolerów wiele jałowych postów przed Toba... Oryginalne Delphi raczej nie występuje w aplikacji na mikrokontrolery. Mozesz próbować sił z FreePascal + Lazarus dla ARM.
Zdecyduj się na konkretną architekturę i dopiero zastanawiaj się nad doprecyzowaniem wyboru. Jeśli ma to być aplikacja DSP to możesz ożyć akurat promowanego EK-LM4F120XL - Stellaris® LM4F120 LaunchPad Evaluation Board z procesorem opartym na rdzeniu CortexM4F(zawiera kooprocesor) i mającym 256Kb pamięci na program oraz 32 KB RAM lub STM32F4Discovery.
Tym niemniej, jeśli nie masz pojęcia o mikrokontrolerach, lepiej zacząć od bardzo prostych projektów typu miganie LED, obsługa LCD, celem zapoznania się z funkcjonowaniem i obycia z odmiennymi narzędziami programowania.

Dobra , dajmy spokój z wielkością pamięci . Ja nie będę programował ani uczył się programować kontrolerów . W delphi napisałem programik który niejako symuluje , obrazuje to co chce uzyskać. Przełożeniem na język niskiego poziomu zajmie się znajomy i już dajmy temu spokój. Chciałem tylko zobrazować jakiego rzędu wielkości może zajmować program. Już ustaliłem w rozmowie telefonicznej że 32kB jest wskazane na wszelki wypadek.
Jako że jest to prototypowe urządzenie gdzie jest zastosowany uC a ja zaś mam blade pojęcie o nich to dlatego przedstawiłem co mniej więcej robić ma uC i jest to banalna sprawa . Jedynie zegarmistrzowska precyzja wymusza zastosowanie przetworników A/C na poziomie 16bit lub więcej a to nie w każdej architekturze uC jest .
Natomiast bez sensu jest angażować uC o wartości rynkowej ponad 50zł do banalnego zadania gdzie znikoma część możliwości takiego uC zostanie wykorzystana - praktycznie tylko fakt że ma w swej strukturze 16 bitowy przetwornik.

Zatem wydaje się że od strony ekonomicznej warto zastanowić sie nad przetwornikiem 18bit za 10zł + uC za kilka (naście) złotych.
By "badać" przebieg o f=100Hz wystarcza częstotliwość próbkowania 1000 razy większa = 100 KHz góra 1MHz więc nie są to wygórowane wymagania, jedynie rozdzielczość 16bit jako minimum.

elmłot napisał:

By "badać" przebieg o f=100Hz wystarcza częstotliwość próbkowania 1000 razy większa = 100 KHz góra 1MHz

Bardzo ciekawa teoria.

Rozdzielczość przetwornika można zwiększyć nadpróbkowaniem.

elmłot napisał:

Zatem wydaje się że od strony ekonomicznej warto zastanowić sie nad przetwornikiem 18bit za 10zł + uC za kilka (naście) złotych.

Przy 18 bitach będziesz musiał przyłożyć się do poprawnego zaprojektowania całości łącznie z PCB, ale zakładam, że jesteś tego świadomy.

Jak każdy kij ma dwa końce taki rozwiązanie z uC+przetwornik jako osobne elementy z jednej strony oki to z drugiej niestety już nie.
Płytka nie może być za duża , ale i tak to ktoś będzie musiał zrobić - zakładzik jakiś, wiec mama nadzieje że specjaliści dadzą sobie radę z pcb.

Słowo "badać" jest w cudzysłowie wiec to nie moja teoria a moja potrzeba takiego "badania" w granicy 1000 do 10 000 razy w ciągu okresu.

I niestety jak na razie to wszystko tylko nie sugestia konkretnego modelu się TU pojawia.

Witam

Mam pytanie jak się zabrać za obsługę panelu TFT 7 calowego, którego dokumentacja znajduje się tutaj: http://www.allparts.cn/files/lcd/datasheet/AT070TN84%2812041%292007.10.30.pdf
Posiadam taki moduł http://www.noritake-itron.com/tft/specs/TU800x480C-xxx.pdf jednak to co producent oferuje za te pieniądze to istna kpina. Banda dzieciaków zrobiła sobie panel + sterownik na ARMie oraz zbudowali własne środowisko do jego programowania, które jest zawalone ich bugami. Zero stabilności, system strasznie niepewny, dokumentacja zawierająca błędy a do tego support jest tragiczny - nawet ciężko im odpowiedzieć na pytanie typu dlaczego komenda działająca na starszym firmware przestała działać po aktualizacji. Z tego powodu chciałbym (o ile to realne) zbudować własny układ odpowiedzialny za generowanie obrazów na takim 7 calowym panelu TFT + touch panel. Widziałem tego typu drivery na układach FPGA jednak sam chciałbym zbudować taki driver na jakimś (w miarę możliwości prostym) ARMie np STM32. Da się to wykonać? Jak się obsługuje taki panel?

Na FPGA mam gotowe kontrolery do paneli 3.5 oraz 5.6 (ten drugi zasilaczem spaliłem )
Rozebrałem ten moduł ismart, on jest na AT91SAM9RL64CU (posiada LCD kontroler). Na płycie wiele nie ma, sdram x2 i nand flash. A bawiłeś się SSD1963?

W zasadzie to można by to zrobić, mam w końcu gotową platformę na biurku jednakże bez żadnego schematu, obudowa BGA, płyta wielowarstwowa - zerowe szanse na ustalenia linii I/O
Ponadto układ jest bardzo drogi (700netto). Już w PL można kupić moduły z 7" z kontrolerem SSD1963 za nieco ponad 200 netto a całe platformy na arm11 i masą peryferiów mozńa dostać za nieco ponad 400netto takzę te 700 to przesada.
Chociaż sam za to nie płacę to używanie takich drogich, nieoptymalnych sprzętów jest bezsensowne przy obecnej dostępności innych rozwiązań.
PS. Dodam, że panel TFT od zestawu i-smart kosztuje u chińczyków ok 60zł

sterowniki SSD1963 są super a sprzętowe wspomaganie operacji na LCD które jest w nie wbudowane powoduje, że nawet z poziomu 8-bitowców można je pięknie obsługiwać. No może nie 7" ale te mniejsze 3,5" czy 4,3" z pełnym powodzeniem i to jeszcze można wtedy korzystać z nieudokumentowanych opcji dodatkowo wspomagających pracę. Dla maksymalnych rozdzielczości już nie da się z nich skorzystać ale i tak sam sterownik w połączeniu ze sterowaniem z procka ARM pozwoli cuda na nim czynić. Ja mogę je śmiało polecić a tu LINK widać próbkę możliwości na 8-bitowcach z SSD1963

Szukam mikrokontrolera to zastosowan w motoryzacji.
Na razie zwrocilem uwage na mikrokontrolery od Silabs. Szkoda ze to tylk o 8 bitow.
Czy istnieja 32-bitowe jednostki przystosowane to pracy w srodowisku "automotive" (odpornosc na zaklocenia, peryferia)?

Pytasz, czy w ogóle istnieją, czy też czy istnieją jakieś dostępne dla śmiertelnika? W tym drugim przypadku to sukcesem będzie zakupu nawet 8-bitowca w wersji automotive

Wersja automotive potrzebna bedzie jak projekt dojdzie do etapu wdrozenia. Na razie na prototyp wystarczy pewnie wersja dla zakresu pracy przemyslowego.

Z procesorem do automotive (szczegolnie 32 bitowym) moze byc problem, ze jesli nie kupisz x tysiecy sztuk rocznie przez nastepne y lat, to nie sprzedadza tobie. W tym przypadku projekt warto zaczac od skontaktowania sie z lokalnym dostawca. Dopiero wiedzac to, wybrac procesor (standartowo dostepny przez nastepne 10 lat). 32 bitowa architektore dedykowana dla automotive ma kazy duzy producent mikroprocesorow. Przykladowo (producent - nazwa architektory):
* Renesas - v850, SH2
* Frescale - PowerPC
* Infineon - Tricore
* ST - PowerPC
* TI - ARM, TMS320C2000

Ten ostatni chce sie wbic w rynek i moze byc prosciej u niego kupic... Olimex ze swoim starter kitem jakos to robi:
https://www.olimex.com/Products/ARM/TI/TMS570-CAN/
Na to chyba jest juz port FreeRTOS nawet...

Rok temu jak TI zaczynalo produkcje tego procesora to lokalny przedstawiciel handlowy w rozmowie, twierdzil ze nie ma minimalnej ilosci... im drozszy model tym mniej mozna zamowic.

Jesli nie musi to byc 32 bitowa architektora, to moze byc prosciej... firmy jakos chetniejsze sa do sprzedazy 16 bitowych procesorow dla automotive w mniejszych ilosciach. Jesli twoj projekt ma tylko wymagania temperaturowe i nie musi spelaniac wszystkich aktualnych norm EU, ISO etc. odnosnie elektroniki w pojezdzie* to sprawdz Microchip i dsPIC (wiekszosc z nich jest odporna na temp. + 125'C i wiecej)

* z drugiej strony jesli nie budujesz komputera silnika, ABS czy deski rozdzielczej, tylko "radio" (infotament) to nie musisz stosowac czesc automotive grade (za to nie recze, sam musisz sprawdzic)

powodzenia, i daj znac co udalo sie wybrac i kupic...

Panowie, pytanko mam. Czy dla programowania-odczytu przez JTAG układu xc95144xl wszystkie nóżki zasilania GND i VCCIO ew. (VCCINT) muszą być ze sobą połączone?.

Jaki mikrokontroler obsługuje I2S , tak by obsłużył przetwornik WM8788 :

http://www.farnell.com/datasheets/1306734.pdf