Marek_Skalski napisał: @BlueDraco:
Zgadzam się z Tobą i też się zastanawiam na czym polega ta dziwna maniera polecania zabytkowych, 8-bitowych AVR'ów? Pomijając ich ograniczenia strukturalne, za każdym razem wchodząc na Forum widzę problemy typu: jaki programator, programator nie działa, błędy zapisu, program jest dobry, a jednak nie działa... i tysiąc tego typu problemów nie znanych w innych systemach. Może to strach przed nowym powoduje, że niektórzy jak ognia boją się 32-bitów?
Skąd się biorą problemy? Ano stąd, że po AVR sięgają osoby nie znające nawet prawa Ohma. Ale jakoś sobie radzą. Chętnie bym zobaczył jak by to wyglądało, gdyby zaczynali od ARMa... Zresztą próbki już mamy - np. banalna sprawa jaką jest ustawienie stosu w skryptach Freddiego powoduje problemy u sporej części osób zaczynających z ARMami (nie takich znowu zielonych).
Marek_Skalski napisał: Edit:
@ tmf:
Cytat: Płytki z Cortexami może i są fajne, ale jeśli ktoś od nich rozpoczyna naukę, to proponuję zacząć od sekcji errata Smile Dopiero po jej wykuciu na pamięć możemy wystartować z resztą - znaczy jakieś 500 stron o rdzeniu, drugie tyle o peryferiach i trzecie tyle o tym co to skrypty linkera, strukturze generowanego kodu C itd.
Pokaż mi proszę, chociaż jedną Megę (Xmegę), która ma czyste konto. ADC, DAC, I2C... w Xmegach do dzisiaj nie realizują wszystkiego jak trzeba. USB do dzisiaj nie wysyła automatycznie ZLP, itd.
Budowa rdzenia Cortex jest istotna kiedy szukasz szczegółów, kiedy chcesz go obsłużyć w asm, kiedy chcesz go zmusić do pracy na max. możliwości, więc proszę, nie przesadzaj z tym 500 stron. Wystarcza konfiguracja (półautomatyczna) zegarów i SysTickTimer (podaj tylko częstotliwość).
Peryferia: XMEGA AU - manual 478 stron (rev.F), liczba układów trochę mniejsza, ich możliwości dużo bardziej ograniczone.
Skrypty linkera może są interesujące dla Ciebie, ale dla kogoś kto chce zacząć pracę, są kompletnie bez znaczenia, ponieważ wszystko załatwia środowisko (Eclipse - CooCox). A zanim wyczerpiesz 512kB flashu czy 192kB RAM, to jednak trochę czasu minie i zdążysz się z tym wszystkim zapoznać i oswoić.
Nie przesadzaj, errata do nowszych XMEGA (poza starą serią A1) ma kilka punktów, zresztą małokrytycznych. Problemy głównie polegają na większym błędzie nieliniowości ADC, większym szumie DAC w pewnych okolicznościach itd. Co jest praktycznie bez znaczenia. Nie ma tam właściwie krytycznych błędów wymagających jakiś super obejść. Proponuję to porównać do erraty dowolnego STM, koniecznie z uwzględnieniem informacji dostępnych na forach, bo errata ta bynajmniej nie jest kompletna.
Piszesz o większej mocy obliczeniowej itd. - kiedyś zapytałem do czego ta większa moc jest wam potrzebna? BlueDraco cośtam specyficznego dłubie i mu się przydaje, ty też się tym zawodowo zajmujesz i pewnie cośtam większego dłubiesz, ale dla większości elektrodowiczów nawet prosty PID jest poza zasięgiem, więc po co te DMIPSy? Nie żebym był przeciwko ARM, bo też sobie w tym dłubię, ale wystarczy na google wrzucić dowolny problem i na AVR masz zazwyczaj rozwiązane, na ARM cisza. Wbrew pozorom popularność i wsparcie community to najważniejsze cechy, przynajmniej dla hobbysty.
No i wiele z tych super cech ARM to głównie marketing. Podam dwa przykłady o których się boleśnie przekonałem na własnej skórze. Najpierw Freescale i SPI. Niestety zegar SPI jest ciągle pochodną zegara systemowego, co powoduje, że ma ograniczenie co do maksymalnej częstotliwości. W efekcie ten super ARM w mojej aplikacji, gdzie krytyczny był dostęp do karty SD okazał się niewiele szybszy niż XMEGA. Jasne, mogę wziąć wielkiego ARMa i go taktować 100 MHz, ale jakby nie o to chodzi, bo z tym wiążą się kolejne problemy. Drugi ból - chciałem sobie podłączyć ARMa do matrycy LCD, nawet nie jakiejś superwielkiej. Pierwsza sprawa - znaleźć prostego, taniego, dostępnego i nie w BGA ARM, który na pokładzie ma wystarczającą ilość SRAM (koło 1 MB coby double buffer zrobić). Potem niby super - mamy kontroler LCD on-board to będzie z górki, prawda? No cóż, magistrala danych kontrolera i CPU jest współdzielona, w efekcie jak podłączę matrycę to mi z tych super DMIPSów niewiele zostaje, bo większość pasma zajmuje transmisja danych do LCD... w efekcie i tak muszę zastosować zewnętrzny kontroler. Dla smaczku dodam, że prościej udało mi się to zrobić na XMEGA + trochę zewnętrznej magii opartej na 4 scalaki w SO16 (dla ścisłości, to samo oczywiście zadziała też na ARM). Także na papierze to wszystko wygląda super-hiper, a w praktyce to różnie. Generalnie nie zniechęcam się, chociaż i STM i Freescale próbują mnie zniechęcić - topornymi narzędziami, środowiskiem stylizowanym na późne lata 90-te i ogólnym bałaganem.
Dodano po 15 [minuty]: A żeby nie było, że jakąś krucjątę anty-ARM prowadzę
To dodam jeszcze kolejny przykład ogólny, dotyczący także XMEGA. Mamy fajny bajer - kontroler EBI, z możliwością współpracy z pamięciami SDRAM. Na XMEGA A1U mamy nawet w końcu pełen wypas - kontroler sterujący 8-bitowymi SDRAM (na ARM możemy wykorzystać także 16- i 32-bitowe). Pięknie. Postanowiłem sprawdzić jak to działa, bo wcześniej w A1 korzystałem z 4-bitowego SDRAM i powiedzmy szczerze - lepiej wrzucić SRAM. No to eagle i jedziemy. XMEGA128A1U w TQFP100, dodaję SDRAM, mały ból bo mamy w TSOP52 lub BGA
Na dzień dobry zżera mi to połowę pinów IO procesora (8-bitowy SDRAM wymaga konfiguacji 4-portowej, SRAM zadowala się 2 portami). No ale w TQFP100 mam tych pinów sporo, więc myślę sobie, bólu nie ma. Do czasu, aż odpalam autorouter. Płytka z automatu robi się jakaś dziwna - 260 przelotek, wire 6 milsów, przelotki 12 milsów, inaczej nie routuje
Rzut oka na to co stworzył - no nie, na 64 MHz (max EBI w XMEGA) to nie pójdzie. No to routujemy ręcznie... Dodałem do tego kilka jeszcze prostych układów i okazuje się że 2 warstwy to mało - nie tylko łamię wszelkie zasady prowadzenia sygnałów, to jeszcze po prostu fizycznie na małej płytce tego poroutować się nie da.To pytanie za 100 punktów - kto z amatorów ma licencję na cada z możliwością robienia płytek 4 i więcej warstwowych? A jak ma, to kto wyda 500 zł na prototyp takiej płytki? Ergo, mamy fajne bajery, którymi w takich akademickich dyskusjach możemy się podniecać, niemniej dla hobbysty one ciągle są poza możliwością praktycznego wykorzystania. A już na pewno dla początkującego hobbysty...
0
). Jeśli koszt zrobienia własnego zestawu będzie nieporównywalnie niższy do gotowego, nie ma problemu mogę kupić nową lutownicę. Wydaje mi się też, że łatwiej wtedy wymienić uszkodzony moduł. Znam podstawy C, troszkę Jave i średnio C++. Tutaj pojawia się pytanie, czy można programować mikrokontrolery w C++?
