Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Początki z STM32 - Ethernet i kilka innych kwestii
478 views
Skip to first unread message
Atlantis
May 16, 2014, 6:06:31 AM5/16/14
to
Przymierzam się powoli do zrobienia kolejnego kroku w nauce
programowania MCU (do tej pory tylko AVR-y) i wypróbowania 32-bitowych
układów STM.
Mam jednak kilka pytań:
1) Ponieważ w wielu swoich projektach wykorzystuję interfejs Ethernet,
chciałbym się dowiedzieć jak to jest realizowane na tej platformie.
Przeważnie korzysta się z ENC28J60, tak samo jak na ATmegach, czy może
warto zainteresować się układami z wbudowanym kontrolerem? Pytam,
ponieważ te które widziałem nie posiadały wbudowanego transceivera i
trzeba było dołączyć do nich zewnętrzny układ PHY. Które rozwiązanie
zapewnia większą wygodę i wydajność?
2) Jaki stos powinienem zastosować? Coś w rodzaju uIP, czy też z uwagi
na większe zasoby sprzętowe warto od razu zainteresować się lwIP?
3) Jakich transferów mogę się spodziewać? Podejrzewam, że będzie lepiej
niż na duecie Mega328 + ENC28J60. Jak bardzo lepiej? ;)
4) Warto zainwestować w jakąś płytkę ewaluacyjną? Gdy zaczynałem naukę
programowania AVR-ów skleciłem sobie prostą płytkę z Megą8 i łącząc z
płytką stykową budowałem proste układy. Potem eksperymentując z
Ethernetem również skleciłem PCB z Megą328 i ENC28J60. Prawie z niej nie
korzystałem... Podobnie zakupione jakiś czas temu Arduino od paru
miesięcy leży w szufladzie. Po prostu gdy chcę zbudować jakiś układ ze
znanych sobie i/lub dobrze opisanych części, po prostu robię projekt
płytki, wytrawiam ją i buduję co mam zbudować. Nie tworzę tego samego
dwa razy, za pierwszym razem na pająku/płytce stykowej. Czy takie
podejście sprawdzi się również w przypadku STM32, czy tutaj jednak
powinienem zainwestować w jakieś płytkę prototypową?
5) Jak taki MCU radzi sobie z szyfrowaniem AES? Powinienem się
spodziewać zauważalnych przestojów?
programowania MCU (do tej pory tylko AVR-y) i wypróbowania 32-bitowych
układów STM.
Mam jednak kilka pytań:
1) Ponieważ w wielu swoich projektach wykorzystuję interfejs Ethernet,
chciałbym się dowiedzieć jak to jest realizowane na tej platformie.
Przeważnie korzysta się z ENC28J60, tak samo jak na ATmegach, czy może
warto zainteresować się układami z wbudowanym kontrolerem? Pytam,
ponieważ te które widziałem nie posiadały wbudowanego transceivera i
trzeba było dołączyć do nich zewnętrzny układ PHY. Które rozwiązanie
zapewnia większą wygodę i wydajność?
2) Jaki stos powinienem zastosować? Coś w rodzaju uIP, czy też z uwagi
na większe zasoby sprzętowe warto od razu zainteresować się lwIP?
3) Jakich transferów mogę się spodziewać? Podejrzewam, że będzie lepiej
niż na duecie Mega328 + ENC28J60. Jak bardzo lepiej? ;)
4) Warto zainwestować w jakąś płytkę ewaluacyjną? Gdy zaczynałem naukę
programowania AVR-ów skleciłem sobie prostą płytkę z Megą8 i łącząc z
płytką stykową budowałem proste układy. Potem eksperymentując z
Ethernetem również skleciłem PCB z Megą328 i ENC28J60. Prawie z niej nie
korzystałem... Podobnie zakupione jakiś czas temu Arduino od paru
miesięcy leży w szufladzie. Po prostu gdy chcę zbudować jakiś układ ze
znanych sobie i/lub dobrze opisanych części, po prostu robię projekt
płytki, wytrawiam ją i buduję co mam zbudować. Nie tworzę tego samego
dwa razy, za pierwszym razem na pająku/płytce stykowej. Czy takie
podejście sprawdzi się również w przypadku STM32, czy tutaj jednak
powinienem zainwestować w jakieś płytkę prototypową?
5) Jak taki MCU radzi sobie z szyfrowaniem AES? Powinienem się
spodziewać zauważalnych przestojów?
tusk, donald tusk
May 16, 2014, 6:29:19 AM5/16/14
to
nie wiem czy ty nie z unii, ale jeśli nie to może napisał byś coś o
"stosach" IP na AVR?
"stosach" IP na AVR?
jacek pozniak
May 16, 2014, 7:49:19 AM5/16/14
to
Atlantis wrote:
> Przymierzam się powoli do zrobienia kolejnego kroku w nauce
> programowania MCU (do tej pory tylko AVR-y) i wypróbowania 32-bitowych
> układów STM.
Nie warto, lepiej sobie kup RPi; bedziesz miał Ethernet.
> Przymierzam się powoli do zrobienia kolejnego kroku w nauce
> programowania MCU (do tej pory tylko AVR-y) i wypróbowania 32-bitowych
> układów STM.
Tak naprawdę AVR i STM to tylko wydajność wyróżnia (no i może jakieś
peryferia).
Komputerki klasy RPi to jest dopiero przełom bo są wyposażone w system
operacyjny z prawdziwego zdarzenia, w którym możesz w C/C++, Python, Bashu,
czy co tam chcesz, programować.
Nie wiem co robisz ale jeśli nie jest to produkcja większej ilości szt.
jakiegoś wydajnego urządzenia, to zamiana AVR na STM nie da Ci korzyści,
poza kwestią poznawczą oczywiście.
jp
Atlantis
May 16, 2014, 8:00:53 AM5/16/14
to
W dniu 2014-05-16 13:49, jacek pozniak pisze:
> Komputerki klasy RPi to jest dopiero przełom bo są wyposażone w system
> operacyjny z prawdziwego zdarzenia, w którym możesz w C/C++, Python, Bashu,
> czy co tam chcesz, programować.
Nie mogę się do końca zgodzić. Po pierwsze komputerki takie jak RasPi,
Beaglebone czy Cubbie Board są tak naprawdę właśnie platformami
ewaluacyjnymi. Sam czekam na RPi Compute Module...
Taka płytka z OS-em ma jednak dość istotne wady. Największą jest dość
długi cykl resetu. Zresetowany (np. watchdogiem) MCU niemal natychmiast
wznowi swoją pracę. W przypadku "komputerka" trzeba odczekać
kilkadziesiąt sekund albo nawet kilka minut. Poza tym zobacz z jaką
prędkością można "machać" stanem pinu na RasPi, gdzie CPU jest taktowany
zegarem 700 MHz. System i rozmaite usługi zajmują mnóstwo cykli. Pisząc
wasd bezpośrednio do mikrokontrolera masz do dyspozycji nieporównywalnie
więcej zasobów.
Nie wspomnę już o tym, że stosując MCU na płytce własnego projektu można
sobie pozwolić na większą elastyczność. Nie potrzebujemy jakiegoś
interfejsu? Po prostu nie uwzględniamy go w projekcie. Złącze nie
zajmuje nam niepotrzebnie miejsca, a zwolnione w ten sposób piny GPIO
możemy wykorzystać do innego celu.
> Nie wiem co robisz ale jeśli nie jest to produkcja większej ilości szt.
> jakiegoś wydajnego urządzenia, to zamiana AVR na STM nie da Ci korzyści,
> poza kwestią poznawczą oczywiście.
Bardziej chodzi mi tutaj właśnie o moc obliczniową i zintegrowane
peryferia. Gdybym na przykład kiedyś chciuał szyfrować komunikację
pomiędzy komputerem a urządzeniem zbudowaym na MCU, to dodatkowe zasoby
się przydadzą. Obsługa pełniejszego stosu TCP/IP to też wielka zaleta.
Co jeszcze? Obsługa kolorowych, graficznych wyświetlaczy - tutaj
dodatkowe cykle i kilobajty mają spore znaczenie.
> Komputerki klasy RPi to jest dopiero przełom bo są wyposażone w system
> operacyjny z prawdziwego zdarzenia, w którym możesz w C/C++, Python, Bashu,
> czy co tam chcesz, programować.
Beaglebone czy Cubbie Board są tak naprawdę właśnie platformami
ewaluacyjnymi. Sam czekam na RPi Compute Module...
Taka płytka z OS-em ma jednak dość istotne wady. Największą jest dość
długi cykl resetu. Zresetowany (np. watchdogiem) MCU niemal natychmiast
wznowi swoją pracę. W przypadku "komputerka" trzeba odczekać
kilkadziesiąt sekund albo nawet kilka minut. Poza tym zobacz z jaką
prędkością można "machać" stanem pinu na RasPi, gdzie CPU jest taktowany
zegarem 700 MHz. System i rozmaite usługi zajmują mnóstwo cykli. Pisząc
wasd bezpośrednio do mikrokontrolera masz do dyspozycji nieporównywalnie
więcej zasobów.
Nie wspomnę już o tym, że stosując MCU na płytce własnego projektu można
sobie pozwolić na większą elastyczność. Nie potrzebujemy jakiegoś
interfejsu? Po prostu nie uwzględniamy go w projekcie. Złącze nie
zajmuje nam niepotrzebnie miejsca, a zwolnione w ten sposób piny GPIO
możemy wykorzystać do innego celu.
> Nie wiem co robisz ale jeśli nie jest to produkcja większej ilości szt.
> jakiegoś wydajnego urządzenia, to zamiana AVR na STM nie da Ci korzyści,
> poza kwestią poznawczą oczywiście.
peryferia. Gdybym na przykład kiedyś chciuał szyfrować komunikację
pomiędzy komputerem a urządzeniem zbudowaym na MCU, to dodatkowe zasoby
się przydadzą. Obsługa pełniejszego stosu TCP/IP to też wielka zaleta.
Co jeszcze? Obsługa kolorowych, graficznych wyświetlaczy - tutaj
dodatkowe cykle i kilobajty mają spore znaczenie.
jacek pozniak
May 16, 2014, 8:14:34 AM5/16/14
to
Atlantis wrote:
> W dniu 2014-05-16 13:49, jacek pozniak pisze:
>
>> Komputerki klasy RPi to jest dopiero przełom bo są wyposażone w system
>> operacyjny z prawdziwego zdarzenia, w którym możesz w C/C++, Python,
>> Bashu, czy co tam chcesz, programować.
>
> Nie mogę się do końca zgodzić. Po pierwsze komputerki takie jak RasPi,
> Beaglebone czy Cubbie Board są tak naprawdę właśnie platformami
> ewaluacyjnymi. Sam czekam na RPi Compute Module...
>
> Taka płytka z OS-em ma jednak dość istotne wady. Największą jest dość
> długi cykl resetu. Zresetowany (np. watchdogiem) MCU niemal natychmiast
> wznowi swoją pracę. W przypadku "komputerka" trzeba odczekać
> kilkadziesiąt sekund albo nawet kilka minut.
To fakt, ale chyba przyznasz, że celem działania systemu nie jest
> W dniu 2014-05-16 13:49, jacek pozniak pisze:
>
>> Komputerki klasy RPi to jest dopiero przełom bo są wyposażone w system
>> operacyjny z prawdziwego zdarzenia, w którym możesz w C/C++, Python,
>> Bashu, czy co tam chcesz, programować.
>
> Nie mogę się do końca zgodzić. Po pierwsze komputerki takie jak RasPi,
> Beaglebone czy Cubbie Board są tak naprawdę właśnie platformami
> ewaluacyjnymi. Sam czekam na RPi Compute Module...
>
> Taka płytka z OS-em ma jednak dość istotne wady. Największą jest dość
> długi cykl resetu. Zresetowany (np. watchdogiem) MCU niemal natychmiast
> wznowi swoją pracę. W przypadku "komputerka" trzeba odczekać
> kilkadziesiąt sekund albo nawet kilka minut.
permanentne resetowanie się.
> Poza tym zobacz z jaką
> prędkością można "machać" stanem pinu na RasPi, gdzie CPU jest taktowany
> zegarem 700 MHz. System i rozmaite usługi zajmują mnóstwo cykli. Pisząc
> wasd bezpośrednio do mikrokontrolera masz do dyspozycji nieporównywalnie
> więcej zasobów.
złożonym, pisanym przez Ciebie też może się okazać, że nie będziesz mógł
machać tym pinem tak często jak chcesz.
>
> Nie wspomnę już o tym, że stosując MCU na płytce własnego projektu można
> sobie pozwolić na większą elastyczność. Nie potrzebujemy jakiegoś
> interfejsu? Po prostu nie uwzględniamy go w projekcie. Złącze nie
> zajmuje nam niepotrzebnie miejsca, a zwolnione w ten sposób piny GPIO
> możemy wykorzystać do innego celu.
Tu się nie wypowiem bo nie wiem
> Nie wspomnę już o tym, że stosując MCU na płytce własnego projektu można
> sobie pozwolić na większą elastyczność. Nie potrzebujemy jakiegoś
> interfejsu? Po prostu nie uwzględniamy go w projekcie. Złącze nie
> zajmuje nam niepotrzebnie miejsca, a zwolnione w ten sposób piny GPIO
> możemy wykorzystać do innego celu.
>
>
>> Nie wiem co robisz ale jeśli nie jest to produkcja większej ilości szt.
>> jakiegoś wydajnego urządzenia, to zamiana AVR na STM nie da Ci korzyści,
>> poza kwestią poznawczą oczywiście.
>
> Bardziej chodzi mi tutaj właśnie o moc obliczniową i zintegrowane
> peryferia. Gdybym na przykład kiedyś chciuał szyfrować komunikację
> pomiędzy komputerem a urządzeniem zbudowaym na MCU, to dodatkowe zasoby
> się przydadzą. Obsługa pełniejszego stosu TCP/IP to też wielka zaleta.
> Co jeszcze? Obsługa kolorowych, graficznych wyświetlaczy - tutaj
> dodatkowe cykle i kilobajty mają spore znaczenie.
No to chyba tylko coś w rodzaju RPi, tam masz to już oprogramowane, ew
>
>> Nie wiem co robisz ale jeśli nie jest to produkcja większej ilości szt.
>> jakiegoś wydajnego urządzenia, to zamiana AVR na STM nie da Ci korzyści,
>> poza kwestią poznawczą oczywiście.
>
> Bardziej chodzi mi tutaj właśnie o moc obliczniową i zintegrowane
> peryferia. Gdybym na przykład kiedyś chciuał szyfrować komunikację
> pomiędzy komputerem a urządzeniem zbudowaym na MCU, to dodatkowe zasoby
> się przydadzą. Obsługa pełniejszego stosu TCP/IP to też wielka zaleta.
> Co jeszcze? Obsługa kolorowych, graficznych wyświetlaczy - tutaj
> dodatkowe cykle i kilobajty mają spore znaczenie.
dopisujesz własny driver do swojego hardware.
jp
Adam Wysocki
May 16, 2014, 8:38:03 AM5/16/14
to
Atlantis <marekw19...@wp.pl> wrote:
> Poza tym zobacz z jak� pr�dko�ci� mo�na "macha�" stanem pinu na RasPi,
W sumie stosuj�c SCHED_FIFO powinno si� da� ca�kiem szybko. Ale MCU
oczywi�cie wygraj�.
--
SELECT finger FROM hand WHERE id = 3;
http://www.chmurka.net/
> Poza tym zobacz z jak� pr�dko�ci� mo�na "macha�" stanem pinu na RasPi,
W sumie stosuj�c SCHED_FIFO powinno si� da� ca�kiem szybko. Ale MCU
oczywi�cie wygraj�.
--
SELECT finger FROM hand WHERE id = 3;
http://www.chmurka.net/
Piotr Gałka
May 16, 2014, 10:58:39 AM5/16/14
to
Użytkownik "jacek pozniak" <jacek....@flowservice.pl> napisał w
wiadomości news:5375fb3f$0$2247$6578...@news.neostrada.pl...
>
> Komputerki klasy RPi to jest dopiero przełom bo są wyposażone w system
> operacyjny z prawdziwego zdarzenia, w którym możesz w C/C++, Python,
> Bashu,
> czy co tam chcesz, programować.
>
Nie wiem jak ludzie tego używają.
> Komputerki klasy RPi to jest dopiero przełom bo są wyposażone w system
> operacyjny z prawdziwego zdarzenia, w którym możesz w C/C++, Python,
> Bashu,
> czy co tam chcesz, programować.
>
Ktoś chciał aby mu zrobić na tym urządzenie.
Nigdzie nie idzie znaleźć normalnej dokumentacji, aby np. zaprojektować
mechanikę (znalazłem tylko przez kogoś pomierzone i rozrysowane).
Nigdzie nie idzie znaleźć dokumentacji portu przeznaczonego do podłączenia
LCD.
Jak w takich warunkach można zaprojektować urządzenie. Jeszcze nie spotkałem
elementu czy modułu do którego byłoby tak mało dokumentacji.
P.G.
Atlantis
May 16, 2014, 11:34:38 AM5/16/14
to
W dniu 2014-05-16 14:14, jacek pozniak pisze:
> To fakt, ale chyba przyznasz, że celem działania systemu nie jest
> permanentne resetowanie się.
Oczywiście. Co nie znaczy, że taką sytuację też powinno się przewidzieć.
Lepszy reset, niż zawieszenie systemu wywołane np. jakimś silnym
zakłóceniem elektromagnetycznym. W przypadku MCU użytkownik pewnie nawet
nie zauważy, że urządzenie na moment przestało działać. Nie można już
mieć takiej pewności, jeśli zastosujemy OS, który będzie potrzebował
paru minut na ponowne uruchomienie siebie samego i wszystkich usług.
Kolejna sprawa to odzyskanie sprawności po utracie zasilania. W
niektórych przypadkach lepiej, żeby system wstał natychmiast. Weźmy na
przykład jakąś stację monitorującą jakiś proces lub zjawisko. Każda
minuta przestoju to przeoczone dane.
> Zgadzam się ale dodam, że to zależy od zastosowania projektu, w bardziej
> złożonym, pisanym przez Ciebie też może się okazać, że nie będziesz mógł
> machać tym pinem tak często jak chcesz.
Przewaga i tak ciągle pozostaje po stronie MCU. Pisząc wsad sami
decydujemy jakie działania zostaną podjęte. Tymczasem nawet mały system
operacyjny ma cały zestaw swoich usług, które nie zawsze można tak łatwo
wyłączyć, nawet jeśli z nich nie korzystamy. Dobrze napisany program na
MCU (zdarzenia, brak pętli opóźniających) będzie działał o wiele
sprawniej niż to samo odpalone na jakimś systemie.
Oczywiście nie mówię, że komputerki na kawałku małego PCB są złe.
Wszystko zależy od zastosowania. Prostej stacji pogodowej, zegara nixie
albo zamka elektronicznego nie budowałbym na RasPi, tylko posłużyłbym
się zwykłym MCU. Tutaj nawet zwykła ATmega się sprawdzi.
Natomiast robiąc radio internetowe albo odtwarzacz sieciowych
multimediów nie bawiłbym się w pisanie wszystkiego od podstaw, tylko
wziąłbym RasPi, odpaliłbym na nim MPD i dopisał prosty program do
obsługi sprzętowego interfejsu.
> No to chyba tylko coś w rodzaju RPi, tam masz to już oprogramowane, ew
> dopisujesz własny driver do swojego hardware.
Mówisz o szyfrowaniu czy kolorowych wyświetlaczach? Wydaje mi się, że
pod STM32 też są do tego narzędzia i biblioteki.
> To fakt, ale chyba przyznasz, że celem działania systemu nie jest
> permanentne resetowanie się.
Lepszy reset, niż zawieszenie systemu wywołane np. jakimś silnym
zakłóceniem elektromagnetycznym. W przypadku MCU użytkownik pewnie nawet
nie zauważy, że urządzenie na moment przestało działać. Nie można już
mieć takiej pewności, jeśli zastosujemy OS, który będzie potrzebował
paru minut na ponowne uruchomienie siebie samego i wszystkich usług.
Kolejna sprawa to odzyskanie sprawności po utracie zasilania. W
niektórych przypadkach lepiej, żeby system wstał natychmiast. Weźmy na
przykład jakąś stację monitorującą jakiś proces lub zjawisko. Każda
minuta przestoju to przeoczone dane.
> Zgadzam się ale dodam, że to zależy od zastosowania projektu, w bardziej
> złożonym, pisanym przez Ciebie też może się okazać, że nie będziesz mógł
> machać tym pinem tak często jak chcesz.
decydujemy jakie działania zostaną podjęte. Tymczasem nawet mały system
operacyjny ma cały zestaw swoich usług, które nie zawsze można tak łatwo
wyłączyć, nawet jeśli z nich nie korzystamy. Dobrze napisany program na
MCU (zdarzenia, brak pętli opóźniających) będzie działał o wiele
sprawniej niż to samo odpalone na jakimś systemie.
Oczywiście nie mówię, że komputerki na kawałku małego PCB są złe.
Wszystko zależy od zastosowania. Prostej stacji pogodowej, zegara nixie
albo zamka elektronicznego nie budowałbym na RasPi, tylko posłużyłbym
się zwykłym MCU. Tutaj nawet zwykła ATmega się sprawdzi.
Natomiast robiąc radio internetowe albo odtwarzacz sieciowych
multimediów nie bawiłbym się w pisanie wszystkiego od podstaw, tylko
wziąłbym RasPi, odpaliłbym na nim MPD i dopisał prosty program do
obsługi sprzętowego interfejsu.
> No to chyba tylko coś w rodzaju RPi, tam masz to już oprogramowane, ew
> dopisujesz własny driver do swojego hardware.
pod STM32 też są do tego narzędzia i biblioteki.
jacek pozniak
May 16, 2014, 12:13:50 PM5/16/14
to
Piotr Gałka wrote:
> Nie wiem jak ludzie tego używają.
> Ktoś chciał aby mu zrobić na tym urządzenie.
> Nigdzie nie idzie znaleźć normalnej dokumentacji, aby np. zaprojektować
> mechanikę (znalazłem tylko przez kogoś pomierzone i rozrysowane).
> Nigdzie nie idzie znaleźć dokumentacji portu przeznaczonego do podłączenia
> LCD.
> Jak w takich warunkach można zaprojektować urządzenie. Jeszcze nie
> spotkałem elementu czy modułu do którego byłoby tak mało dokumentacji.
> P.G.
Ja też nie wiem jak tego używają ale zauważ, że mówimy raczej o
> Nie wiem jak ludzie tego używają.
> Ktoś chciał aby mu zrobić na tym urządzenie.
> Nigdzie nie idzie znaleźć normalnej dokumentacji, aby np. zaprojektować
> mechanikę (znalazłem tylko przez kogoś pomierzone i rozrysowane).
> Nigdzie nie idzie znaleźć dokumentacji portu przeznaczonego do podłączenia
> LCD.
> Jak w takich warunkach można zaprojektować urządzenie. Jeszcze nie
> spotkałem elementu czy modułu do którego byłoby tak mało dokumentacji.
> P.G.
zastosowaniach czysto amatorskich, pewnie jakaś stacja pogodowa czy inny
sterownik węża ogrodowego. Oczywiście do zastosowań komercyjnych nigdy bym
nikomu nie zalecał stosowania RPi ani jego zabudowywania.
A w zastosowaniach amatorskich, jeśli chciałbyś mieć webserwer, webkamerkę,
Ethernet jakieś I/O (być może wymaga expandera jakiegoś) i do tego prosto
programowane, to wybór jest jak najbardziej zasadny.
Oczywiście nie będzie tym zainteresowany ktoś kto chce programować do gołego
metalu.
A wątkotwórca chce przejść z AVR na STM i w związku z tym podważałem
zasadność ponieważ za chwilę zderzy się z jakimiś bibliotekami, nie do końca
działającymi i innymi takimi samymi kreatorami aplikacji.
jp
walker
May 16, 2014, 12:27:53 PM5/16/14
to
On 05/16/2014 01:49 PM, jacek pozniak wrote:
> Nie warto, lepiej sobie kup RPi; bedziesz miał Ethernet.
rpi nie polecam, zeby to sie uruchomilo musi byc binarny sterownik
> Nie warto, lepiej sobie kup RPi; bedziesz miał Ethernet.
graficzny, nawet jak sie grafiki na uzywa np. na serwerach, czyli zaden
system w pelni open source na tym nie pojdzie
debian armhf na tym nie pojdzie (trzeba instalowac jakies dziwactwa
pokroju raspbian) zeby zamiast broadcam bylo cortex-a7 + mali to juz
byloby cos
Marek Borowski
May 16, 2014, 1:56:30 PM5/16/14
to
On 5/16/2014 12:06 PM, Atlantis wrote:
> Przymierzam się powoli do zrobienia kolejnego kroku w nauce
> programowania MCU (do tej pory tylko AVR-y) i wypróbowania 32-bitowych
> układów STM.
>
> Mam jednak kilka pytań:
>
> 1) Ponieważ w wielu swoich projektach wykorzystuję interfejs Ethernet,
> chciałbym się dowiedzieć jak to jest realizowane na tej platformie.
> Przeważnie korzysta się z ENC28J60, tak samo jak na ATmegach, czy może
> warto zainteresować się układami z wbudowanym kontrolerem? Pytam,
> ponieważ te które widziałem nie posiadały wbudowanego transceivera i
> trzeba było dołączyć do nich zewnętrzny układ PHY. Które rozwiązanie
> zapewnia większą wygodę i wydajność?
RMII/MI nie jest naprostszym sposobem podlaczeniem wymaga sporo lini,
> Przymierzam się powoli do zrobienia kolejnego kroku w nauce
> programowania MCU (do tej pory tylko AVR-y) i wypróbowania 32-bitowych
> układów STM.
>
> Mam jednak kilka pytań:
>
> 1) Ponieważ w wielu swoich projektach wykorzystuję interfejs Ethernet,
> chciałbym się dowiedzieć jak to jest realizowane na tej platformie.
> Przeważnie korzysta się z ENC28J60, tak samo jak na ATmegach, czy może
> warto zainteresować się układami z wbudowanym kontrolerem? Pytam,
> ponieważ te które widziałem nie posiadały wbudowanego transceivera i
> trzeba było dołączyć do nich zewnętrzny układ PHY. Które rozwiązanie
> zapewnia większą wygodę i wydajność?
niektore uklady PHY konfiguruja sie na podstawie stanu mulipleksowanych
po resecie lini, trzeba pamietac o tym ze PHY tez ma wlasny adress.
Sam kontroler ethernetu w STM32 ma dedykowane DMA i dziala bez zarzutu.
> 2) Jaki stos powinienem zastosować? Coś w rodzaju uIP, czy też z uwagi
> na większe zasoby sprzętowe warto od razu zainteresować się lwIP?
Od razu sie nastaw ze zapoznanie sie z tym stosem to nie bedzie 5 minut.
Na 128kB udalo mi sie postawic webserver, mailserver i pare dedykowanych
"demonow". Ale powiedzmy sobie szczerze do sieci to jest min. 8MB i linux.
> 3) Jakich transferów mogę się spodziewać? Podejrzewam, że będzie lepiej
> niż na duecie Mega328 + ENC28J60. Jak bardzo lepiej? ;)
> 4) Warto zainwestować w jakąś płytkę ewaluacyjną? Gdy zaczynałem naukę
> programowania AVR-ów skleciłem sobie prostą płytkę z Megą8 i łącząc z
> płytką stykową budowałem proste układy. Potem eksperymentując z
> Ethernetem również skleciłem PCB z Megą328 i ENC28J60. Prawie z niej nie
> korzystałem... Podobnie zakupione jakiś czas temu Arduino od paru
> miesięcy leży w szufladzie. Po prostu gdy chcę zbudować jakiś układ ze
> znanych sobie i/lub dobrze opisanych części, po prostu robię projekt
> płytki, wytrawiam ją i buduję co mam zbudować. Nie tworzę tego samego
> dwa razy, za pierwszym razem na pająku/płytce stykowej. Czy takie
> podejście sprawdzi się również w przypadku STM32, czy tutaj jednak
> powinienem zainwestować w jakieś płytkę prototypową?
uruchamianie wlasnych urzadzen.
> 5) Jak taki MCU radzi sobie z szyfrowaniem AES? Powinienem się
> spodziewać zauważalnych przestojów?
>
Ale nie mam w tym temacie doswiadczen.
Pozdrawiam
Marek
jacek pozniak
May 16, 2014, 2:59:06 PM5/16/14
to
Atlantis wrote:
> W dniu 2014-05-16 14:14, jacek pozniak pisze:
>
>> To fakt, ale chyba przyznasz, że celem działania systemu nie jest
>> permanentne resetowanie się.
>
> Oczywiście. Co nie znaczy, że taką sytuację też powinno się przewidzieć.
> Lepszy reset, niż zawieszenie systemu wywołane np. jakimś silnym
> zakłóceniem elektromagnetycznym. W przypadku MCU użytkownik pewnie nawet
> nie zauważy, że urządzenie na moment przestało działać. Nie można już
> mieć takiej pewności, jeśli zastosujemy OS, który będzie potrzebował
> paru minut na ponowne uruchomienie siebie samego i wszystkich usług.
> Kolejna sprawa to odzyskanie sprawności po utracie zasilania. W
> niektórych przypadkach lepiej, żeby system wstał natychmiast. Weźmy na
> przykład jakąś stację monitorującą jakiś proces lub zjawisko. Każda
> minuta przestoju to przeoczone dane.
Powiem wprost; nie wiem co jest lepsze, to są akademickie dyskusje ponieważ
> W dniu 2014-05-16 14:14, jacek pozniak pisze:
>
>> To fakt, ale chyba przyznasz, że celem działania systemu nie jest
>> permanentne resetowanie się.
>
> Oczywiście. Co nie znaczy, że taką sytuację też powinno się przewidzieć.
> Lepszy reset, niż zawieszenie systemu wywołane np. jakimś silnym
> zakłóceniem elektromagnetycznym. W przypadku MCU użytkownik pewnie nawet
> nie zauważy, że urządzenie na moment przestało działać. Nie można już
> mieć takiej pewności, jeśli zastosujemy OS, który będzie potrzebował
> paru minut na ponowne uruchomienie siebie samego i wszystkich usług.
> Kolejna sprawa to odzyskanie sprawności po utracie zasilania. W
> niektórych przypadkach lepiej, żeby system wstał natychmiast. Weźmy na
> przykład jakąś stację monitorującą jakiś proces lub zjawisko. Każda
> minuta przestoju to przeoczone dane.
nikt nie powinien do krytycznych zastosowań wybierać rozwiązania opartego na
RPi ani na jakimś niesprawdzonym STM, AVR, PICu.
Do takich zastosowań to przede wszystkim rozwiązania SPRAWDZONE.
>
>
>> Zgadzam się ale dodam, że to zależy od zastosowania projektu, w bardziej
>> złożonym, pisanym przez Ciebie też może się okazać, że nie będziesz mógł
>> machać tym pinem tak często jak chcesz.
>
> Przewaga i tak ciągle pozostaje po stronie MCU. Pisząc wsad sami
> decydujemy jakie działania zostaną podjęte. Tymczasem nawet mały system
> operacyjny ma cały zestaw swoich usług, które nie zawsze można tak łatwo
> wyłączyć, nawet jeśli z nich nie korzystamy. Dobrze napisany program na
> MCU (zdarzenia, brak pętli opóźniających) będzie działał o wiele
> sprawniej niż to samo odpalone na jakimś systemie.
wiele sprawniej"
>
> Oczywiście nie mówię, że komputerki na kawałku małego PCB są złe.
> Wszystko zależy od zastosowania. Prostej stacji pogodowej, zegara nixie
> albo zamka elektronicznego nie budowałbym na RasPi, tylko posłużyłbym
> się zwykłym MCU. Tutaj nawet zwykła ATmega się sprawdzi.
> Natomiast robiąc radio internetowe albo odtwarzacz sieciowych
> multimediów nie bawiłbym się w pisanie wszystkiego od podstaw, tylko
> wziąłbym RasPi, odpaliłbym na nim MPD i dopisał prosty program do
> obsługi sprzętowego interfejsu.
Zgadzam się.
> Wszystko zależy od zastosowania. Prostej stacji pogodowej, zegara nixie
> albo zamka elektronicznego nie budowałbym na RasPi, tylko posłużyłbym
> się zwykłym MCU. Tutaj nawet zwykła ATmega się sprawdzi.
> Natomiast robiąc radio internetowe albo odtwarzacz sieciowych
> multimediów nie bawiłbym się w pisanie wszystkiego od podstaw, tylko
> wziąłbym RasPi, odpaliłbym na nim MPD i dopisał prosty program do
> obsługi sprzętowego interfejsu.
>
>
>> No to chyba tylko coś w rodzaju RPi, tam masz to już oprogramowane, ew
>> dopisujesz własny driver do swojego hardware.
>
> Mówisz o szyfrowaniu czy kolorowych wyświetlaczach? Wydaje mi się, że
> pod STM32 też są do tego narzędzia i biblioteki.
Może są, ale np. taki xWindows (jęśli robiłbym coś a'la kiosk albo coś
>
>> No to chyba tylko coś w rodzaju RPi, tam masz to już oprogramowane, ew
>> dopisujesz własny driver do swojego hardware.
>
> Mówisz o szyfrowaniu czy kolorowych wyświetlaczach? Wydaje mi się, że
> pod STM32 też są do tego narzędzia i biblioteki.
innego graficznego) lub ssh (jeśli robiłbym szyfrowane połaczenia) lub
webserwer (co mi obsłuży wiele połaczeń na raz) lub baza danych lub
cokolwiek bardziej zaawansowanego niż "machanie pinem" to wolałbym wziąć
raczej z Linuksa niż z jakichś bibliotek do STM32.
Ja nie mówię, że STM jest zły. Po prostu świat idzie do przodu i opieranie
się na "gołym metalu", jakikolwiek szlachetny on by nie był, nie wnosi nic
nowego.
To tak jak z Indianami i przysłowiowymi koralikami i lusterkami, które im z
Europy przywożono; ładnie błyszczały, kolorowe były, ale i tak nic nowego
nie wnosiły, bo naprawdę wartościowe było złoto.
jp
Atlantis
May 16, 2014, 6:14:06 PM5/16/14
to
W dniu 2014-05-16 19:56, Marek Borowski pisze:
> RMII/MI nie jest naprostszym sposobem podlaczeniem wymaga sporo lini,
Chyba jednak nie jest aż tak źle, jak w przypadku np. RTL8019? ;)
> niektore uklady PHY konfiguruja sie na podstawie stanu mulipleksowanych
> po resecie lini, trzeba pamietac o tym ze PHY tez ma wlasny adress.
> Sam kontroler ethernetu w STM32 ma dedykowane DMA i dziala bez zarzutu.
Jak mniemam istnieją jakieś biblioteki, które ułatwiają skonfigurowanie
układu i nawiązanie komunikacji?
> Stosuje LwIP, ma multum opcji konfiguracyjnych, bardzo rozbudowane logi.
> Od razu sie nastaw ze zapoznanie sie z tym stosem to nie bedzie 5 minut.
Przymierzam się do zakupu tej książki:
http://www.kamami.pl/index.php?productID=178588
To chyba powinno być dobre wprowadzenie do tematyki.
> Na 128kB udalo mi sie postawic webserver, mailserver i pare dedykowanych
> "demonow". Ale powiedzmy sobie szczerze do sieci to jest min. 8MB i linux.
Tutaj nie chodzi o rozwiązania "do sieci" ale raczej o urządzenia
pełniące określoną funkcję, które mogą się kontaktować z użytkownikiem i
światem przez sieć. Czyli jak już wspominałem - nie budowałbym w ten
sposób internetowego radia, routera albo jakiejś pamięci NAS. Jednak
zegar z synchronizacją czasu i konfiguracją przez WWW/telnet, zamek
raportujący zdarzenia do zewnętrznego serwera, jakiś zestaw czujników -
to już inna sprawa.
> wget mi pokazuje 2.6 MB/s.
Więc faktycznie jest zauważalna różnica w porównaniu z AVR-ami i
ENC28J60. ;)
> RMII/MI nie jest naprostszym sposobem podlaczeniem wymaga sporo lini,
> niektore uklady PHY konfiguruja sie na podstawie stanu mulipleksowanych
> po resecie lini, trzeba pamietac o tym ze PHY tez ma wlasny adress.
> Sam kontroler ethernetu w STM32 ma dedykowane DMA i dziala bez zarzutu.
układu i nawiązanie komunikacji?
> Stosuje LwIP, ma multum opcji konfiguracyjnych, bardzo rozbudowane logi.
> Od razu sie nastaw ze zapoznanie sie z tym stosem to nie bedzie 5 minut.
http://www.kamami.pl/index.php?productID=178588
To chyba powinno być dobre wprowadzenie do tematyki.
> Na 128kB udalo mi sie postawic webserver, mailserver i pare dedykowanych
> "demonow". Ale powiedzmy sobie szczerze do sieci to jest min. 8MB i linux.
pełniące określoną funkcję, które mogą się kontaktować z użytkownikiem i
światem przez sieć. Czyli jak już wspominałem - nie budowałbym w ten
sposób internetowego radia, routera albo jakiejś pamięci NAS. Jednak
zegar z synchronizacją czasu i konfiguracją przez WWW/telnet, zamek
raportujący zdarzenia do zewnętrznego serwera, jakiś zestaw czujników -
to już inna sprawa.
> wget mi pokazuje 2.6 MB/s.
ENC28J60. ;)
Marek
May 16, 2014, 6:19:38 PM5/16/14
to
On Fri, 16 May 2014 12:06:31 +0200, Atlantis <marekw19...@wp.pl>
wrote:
układ pochodził trochę (aż koty zaczynanały z nudów wyciągać kabelki
z tego pająka) to robilem płytkę docelową. Po kilku układach
zorientowałem się, że buduje układy z powtarzających się elementów,
więc może zaprojektować taką uniwersalną płytkę (i zrobić ją w kilku
egz.) która będzie miała miejsce na wszystkie najczęściej używane
podzespoły, wlutowywane na miarę potrzeb. I tak powstała prywatna
płytka "ewaluacyjna" z pic32, encj, can, usb host, rfm12b, 5
przekaźników, 2 we 230V przez optoizolacje, złącze z 8 uniwersalnych
I/O, złącze do tel. gsm, złącze do zasilania (i ładowania) z aku 12V
(płytka w 1 wersji robi za centralkę alarmową) itd. Teraz właściwie
każdy pomysł realizuje na tej plytce wlutowując tylko to, co
potrzeba. Nawet teraz na pająku nic nie testuję tylko od razu tą
uniwersalną płytkę składam.
--
Marek
wrote:
>Potem eksperymentując z
> Ethernetem również skleciłem PCB z Megą328 i ENC28J60. Prawie z
niej nie
> korzystałem... Podobnie zakupione jakiś czas temu Arduino od paru
> miesięcy leży w szufladzie. Po prostu gdy chcę zbudować jakiś układ
ze
> znanych sobie i/lub dobrze opisanych części, po prostu robię projekt
> płytki, wytrawiam ją i buduję co mam zbudować. Nie tworzę tego
samego
> dwa razy, za pierwszym razem na pająku/płytce stykowej.
Robilem bardzo podobnie, tzn. najpierw pająk na stykowej. Jak taki
> Ethernetem również skleciłem PCB z Megą328 i ENC28J60. Prawie z
niej nie
> korzystałem... Podobnie zakupione jakiś czas temu Arduino od paru
> miesięcy leży w szufladzie. Po prostu gdy chcę zbudować jakiś układ
ze
> znanych sobie i/lub dobrze opisanych części, po prostu robię projekt
> płytki, wytrawiam ją i buduję co mam zbudować. Nie tworzę tego
samego
> dwa razy, za pierwszym razem na pająku/płytce stykowej.
układ pochodził trochę (aż koty zaczynanały z nudów wyciągać kabelki
z tego pająka) to robilem płytkę docelową. Po kilku układach
zorientowałem się, że buduje układy z powtarzających się elementów,
więc może zaprojektować taką uniwersalną płytkę (i zrobić ją w kilku
egz.) która będzie miała miejsce na wszystkie najczęściej używane
podzespoły, wlutowywane na miarę potrzeb. I tak powstała prywatna
płytka "ewaluacyjna" z pic32, encj, can, usb host, rfm12b, 5
przekaźników, 2 we 230V przez optoizolacje, złącze z 8 uniwersalnych
I/O, złącze do tel. gsm, złącze do zasilania (i ładowania) z aku 12V
(płytka w 1 wersji robi za centralkę alarmową) itd. Teraz właściwie
każdy pomysł realizuje na tej plytce wlutowując tylko to, co
potrzeba. Nawet teraz na pająku nic nie testuję tylko od razu tą
uniwersalną płytkę składam.
--
Marek
Marek
May 16, 2014, 6:39:08 PM5/16/14
to
On Fri, 16 May 2014 20:59:06 +0200, jacek pozniak
<jacek....@flowservice.pl> wrote:
> cokolwiek bardziej zaawansowanego niż "machanie pinem" to wolałbym
wziąć
> raczej z Linuksa niż z jakichś bibliotek do STM32.
> Ja nie mówię, że STM jest zły. Po prostu świat idzie do przodu i
opieranie
> się na "gołym metalu", jakikolwiek szlachetny on by nie był, nie
wnosi nic
> nowego.
Linuxa używam od 20 lat (wyłącznie), jednak np. taki mikroserwerek
<jacek....@flowservice.pl> wrote:
> cokolwiek bardziej zaawansowanego niż "machanie pinem" to wolałbym
wziąć
> raczej z Linuksa niż z jakichś bibliotek do STM32.
> Ja nie mówię, że STM jest zły. Po prostu świat idzie do przodu i
opieranie
> się na "gołym metalu", jakikolwiek szlachetny on by nie był, nie
wnosi nic
> nowego.
tcp postawiony na mcu i realizujący konkretne zadania niczym Linuxowi
nie ustępuje a osobiście uważam, że ma zalety: szybki "boot"
(sekunda), niski pobór prądu, mniejsza komplikacja softu do
debugowania (jeśli coś działa niezgodnie z oczekiwaniami), prosta
konstrukcja sprzętowa do ew. napraw. itp. Nie twierdzę, że Raspi jest
źle, ale nie mogę się do niego.przekonać, dla mnie to PC , tyle że
"sfilcowany". Rozmiary są chyba jego jedyną zaletą, a wady
odziedziczył po PC, bo w środku to nadal PC z cała jego komplikacją.
--
Marek
Atlantis
May 17, 2014, 5:59:14 AM5/17/14
to
W dniu 2014-05-17 00:39, Marek pisze:
> napraw. itp. Nie twierdzę, że Raspi jest źle, ale nie mogę się do
> niego.przekonać, dla mnie to PC , tyle że "sfilcowany". Rozmiary są
> chyba jego jedyną zaletą, a wady odziedziczył po PC, bo w środku to
> nadal PC z cała jego komplikacją.
Podejrzewam, że za kilka lat pojawią i upowszechnią się układy, które w
jednej obudowie TQFP/LQFP będą mieściły cały linuksowy komputerek. CPU,
kilkaset MB RAM-u i parę GB flasha z zapisanym systemem operacyjnym.
Niech tylko prawo Moore'a popracuje jeszcze trochę. ;)
Nie powiem nie, chętnie bym skorzystał z czegoś takiego. Jenak nie
wydaje mi się, żeby miało to kiedyś zastąpić tradycyjne MCU. W pewnych
sytuacjach prostota zapewniana przez MCU daje przewagę. Lepiej odpalić
program bezpośrednio na rdzeniu procesora, niż stawiać po drodze
pośrednie platformy w rodzaju systemu operacyjnego, maszyny wirtualnej
(jak to ma miejsce w Androidzie) itp.
> napraw. itp. Nie twierdzę, że Raspi jest źle, ale nie mogę się do
> niego.przekonać, dla mnie to PC , tyle że "sfilcowany". Rozmiary są
> chyba jego jedyną zaletą, a wady odziedziczył po PC, bo w środku to
> nadal PC z cała jego komplikacją.
jednej obudowie TQFP/LQFP będą mieściły cały linuksowy komputerek. CPU,
kilkaset MB RAM-u i parę GB flasha z zapisanym systemem operacyjnym.
Niech tylko prawo Moore'a popracuje jeszcze trochę. ;)
Nie powiem nie, chętnie bym skorzystał z czegoś takiego. Jenak nie
wydaje mi się, żeby miało to kiedyś zastąpić tradycyjne MCU. W pewnych
sytuacjach prostota zapewniana przez MCU daje przewagę. Lepiej odpalić
program bezpośrednio na rdzeniu procesora, niż stawiać po drodze
pośrednie platformy w rodzaju systemu operacyjnego, maszyny wirtualnej
(jak to ma miejsce w Androidzie) itp.
mk
May 17, 2014, 12:37:05 PM5/17/14
to
W dniu 2014-05-16 12:06, Atlantis pisze:
mikrokontroler z wbudowanym Ethernetem.
Wygoda? Rzecz względna, ale faktycznie ENC28J60 pod pewnymi względami
może być wygodniejsze (np. design PCB).
> 2) Jaki stos powinienem zastosować? Coś w rodzaju uIP, czy też z uwagi
> na większe zasoby sprzętowe warto od razu zainteresować się lwIP?
uIP tylko do najprostszych aplikacji typu wysłanie lub odbieranie
pojedynczych pakietów UDP, czy też najprostsze połączenia TCP (ale
naprawdę najprostsze typu po połączeniu wysyłam parę bajtów i rozłączamy
się).
Na sensowną wydajność z uIP nie licz przy przesyłaniu danych strumieniem
TCP. Stos ten nie wyśle żadnego kolejnego pakietu dopóki poprzednik nie
odbierze ACK poprzedniego pakietu. A druga strona będzie zwlekać z
wysłaniem pakietu potwierdzenia, ze względu na algorytm Nagle'a.
lwIP -- jakiś czas temu trenowałem go trochę zarówno na STM32 jak i
Luminary Micro.
Wrażenia mieszane: z jednej strony widać że w ten projekt włożono dużo
pracy, wiele parametrów podlega konfiguracji, możliwość wyrzucania
komunikatów diagnostycznych, widać że ma potencjał co do wydajności i
wierzę, że w odpowiednich rękach ten stos może dawać stabilne rozwiązania.
Z drugiej strony skąpa dokumentacja, kod źródłowy ze względu na mnogość
opcji nie jest łatwy w analizie, a miejscami po prostu paskudny i trudny
do debugowania (zwłaszcza realizacja generyczności kodu przez "#define,
#include, #undefine, #define, #include, #undefine, ...").
lwIP to taka machina z wieloma gałkami, pokrętłami i z modułami które
można podmieniać, ale nie w każdej konfiguracji stabilnie działa. Raczej
dla bardzo cierpliwego użytkownika, który nie boi się, a wręcz lubi
pogrzebać w bebechach swojej maszyny.
lwIP również warto ożenić z jakimś RTOS, np. z FreeRTOS. Bez
wielowątkowości tworzenie aplikacji sieciowych, poza tymi najprostszymi,
szybko stanie się koszmarem.
> 3) Jakich transferów mogę się spodziewać? Podejrzewam, że będzie lepiej
> niż na duecie Mega328 + ENC28J60. Jak bardzo lepiej? ;)
Testowo z lwIP i STM32F107 (64kB RAM, 72 MHz, gdy to testowałem ST nic
lepszego jeszcze nie miało w ofercie) byłem w stanie (ledwo, ledwo ale
jednak) zapchać rurę 100 Mbit/s przy transmisji w sieci lokalnej --
serwer TCP, który po podłączeniu generował pseudolosowy strumień danych,
klient (aplikacja na PC) odbierał dane i weryfikował. Testowałem aż mi
się nie znudziło, dziesiątki GB danych szły bez problemów.
Po ożenieniu lwIP+FreeRTOS wydajność spadła ale wciąż było to
kilkadziesiąt Mbit/s. A w praktycznej aplikacji wąskim gardłem i tak
okazała się magistrala SPI (18 MHz) na której wisiała pamięć Flash z
której czerpałem dane.
> 4) Warto zainwestować w jakąś płytkę ewaluacyjną? Gdy zaczynałem naukę
> programowania AVR-ów skleciłem sobie prostą płytkę z Megą8 i łącząc z
> płytką stykową budowałem proste układy. Potem eksperymentując z
> Ethernetem również skleciłem PCB z Megą328 i ENC28J60. Prawie z niej nie
> korzystałem... Podobnie zakupione jakiś czas temu Arduino od paru
> miesięcy leży w szufladzie. Po prostu gdy chcę zbudować jakiś układ ze
> znanych sobie i/lub dobrze opisanych części, po prostu robię projekt
> płytki, wytrawiam ją i buduję co mam zbudować. Nie tworzę tego samego
> dwa razy, za pierwszym razem na pająku/płytce stykowej. Czy takie
> podejście sprawdzi się również w przypadku STM32, czy tutaj jednak
> powinienem zainwestować w jakieś płytkę prototypową?
Moim zdaniem warto, bo Ethernet to już szybkie przebiegi i łatwo
popełnić jakiś błąd w projekcie. Układ może mieć nawet pozory działania,
ale będą gęsto i często np. ginąć pakiety, transmisja będzie się
zacinać. Nie będziesz wiedzieć czy soft Ci szwankuje czy może jednak
hardware. Lepiej oprzeć się na czymś sprawdzonym.
> 5) Jak taki MCU radzi sobie z szyfrowaniem AES? Powinienem się
> spodziewać zauważalnych przestojów?
Co prawda, dla PIC32, ale dla wyrobienia poglądu wystarczy:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en537998
Jeśli zależy Ci na wyższej wydajności wybierz MCU z hardwarowym
wsparciem AES.
pzdr
mk
> Przymierzam się powoli do zrobienia kolejnego kroku w nauce
> programowania MCU (do tej pory tylko AVR-y) i wypróbowania 32-bitowych
> układów STM.
>
> Mam jednak kilka pytań:
>
> 1) Ponieważ w wielu swoich projektach wykorzystuję interfejs Ethernet,
> chciałbym się dowiedzieć jak to jest realizowane na tej platformie.
> Przeważnie korzysta się z ENC28J60, tak samo jak na ATmegach, czy może
> warto zainteresować się układami z wbudowanym kontrolerem? Pytam,
> ponieważ te które widziałem nie posiadały wbudowanego transceivera i
> trzeba było dołączyć do nich zewnętrzny układ PHY. Które rozwiązanie
> zapewnia większą wygodę i wydajność?
Jeśli krytyczna jest wydajność to nie ma co się zastanawiać:
> programowania MCU (do tej pory tylko AVR-y) i wypróbowania 32-bitowych
> układów STM.
>
> Mam jednak kilka pytań:
>
> 1) Ponieważ w wielu swoich projektach wykorzystuję interfejs Ethernet,
> chciałbym się dowiedzieć jak to jest realizowane na tej platformie.
> Przeważnie korzysta się z ENC28J60, tak samo jak na ATmegach, czy może
> warto zainteresować się układami z wbudowanym kontrolerem? Pytam,
> ponieważ te które widziałem nie posiadały wbudowanego transceivera i
> trzeba było dołączyć do nich zewnętrzny układ PHY. Które rozwiązanie
> zapewnia większą wygodę i wydajność?
mikrokontroler z wbudowanym Ethernetem.
Wygoda? Rzecz względna, ale faktycznie ENC28J60 pod pewnymi względami
może być wygodniejsze (np. design PCB).
> 2) Jaki stos powinienem zastosować? Coś w rodzaju uIP, czy też z uwagi
> na większe zasoby sprzętowe warto od razu zainteresować się lwIP?
pojedynczych pakietów UDP, czy też najprostsze połączenia TCP (ale
naprawdę najprostsze typu po połączeniu wysyłam parę bajtów i rozłączamy
się).
Na sensowną wydajność z uIP nie licz przy przesyłaniu danych strumieniem
TCP. Stos ten nie wyśle żadnego kolejnego pakietu dopóki poprzednik nie
odbierze ACK poprzedniego pakietu. A druga strona będzie zwlekać z
wysłaniem pakietu potwierdzenia, ze względu na algorytm Nagle'a.
lwIP -- jakiś czas temu trenowałem go trochę zarówno na STM32 jak i
Luminary Micro.
Wrażenia mieszane: z jednej strony widać że w ten projekt włożono dużo
pracy, wiele parametrów podlega konfiguracji, możliwość wyrzucania
komunikatów diagnostycznych, widać że ma potencjał co do wydajności i
wierzę, że w odpowiednich rękach ten stos może dawać stabilne rozwiązania.
Z drugiej strony skąpa dokumentacja, kod źródłowy ze względu na mnogość
opcji nie jest łatwy w analizie, a miejscami po prostu paskudny i trudny
do debugowania (zwłaszcza realizacja generyczności kodu przez "#define,
#include, #undefine, #define, #include, #undefine, ...").
lwIP to taka machina z wieloma gałkami, pokrętłami i z modułami które
można podmieniać, ale nie w każdej konfiguracji stabilnie działa. Raczej
dla bardzo cierpliwego użytkownika, który nie boi się, a wręcz lubi
pogrzebać w bebechach swojej maszyny.
lwIP również warto ożenić z jakimś RTOS, np. z FreeRTOS. Bez
wielowątkowości tworzenie aplikacji sieciowych, poza tymi najprostszymi,
szybko stanie się koszmarem.
> 3) Jakich transferów mogę się spodziewać? Podejrzewam, że będzie lepiej
> niż na duecie Mega328 + ENC28J60. Jak bardzo lepiej? ;)
lepszego jeszcze nie miało w ofercie) byłem w stanie (ledwo, ledwo ale
jednak) zapchać rurę 100 Mbit/s przy transmisji w sieci lokalnej --
serwer TCP, który po podłączeniu generował pseudolosowy strumień danych,
klient (aplikacja na PC) odbierał dane i weryfikował. Testowałem aż mi
się nie znudziło, dziesiątki GB danych szły bez problemów.
Po ożenieniu lwIP+FreeRTOS wydajność spadła ale wciąż było to
kilkadziesiąt Mbit/s. A w praktycznej aplikacji wąskim gardłem i tak
okazała się magistrala SPI (18 MHz) na której wisiała pamięć Flash z
której czerpałem dane.
> 4) Warto zainwestować w jakąś płytkę ewaluacyjną? Gdy zaczynałem naukę
> programowania AVR-ów skleciłem sobie prostą płytkę z Megą8 i łącząc z
> płytką stykową budowałem proste układy. Potem eksperymentując z
> Ethernetem również skleciłem PCB z Megą328 i ENC28J60. Prawie z niej nie
> korzystałem... Podobnie zakupione jakiś czas temu Arduino od paru
> miesięcy leży w szufladzie. Po prostu gdy chcę zbudować jakiś układ ze
> znanych sobie i/lub dobrze opisanych części, po prostu robię projekt
> płytki, wytrawiam ją i buduję co mam zbudować. Nie tworzę tego samego
> dwa razy, za pierwszym razem na pająku/płytce stykowej. Czy takie
> podejście sprawdzi się również w przypadku STM32, czy tutaj jednak
> powinienem zainwestować w jakieś płytkę prototypową?
popełnić jakiś błąd w projekcie. Układ może mieć nawet pozory działania,
ale będą gęsto i często np. ginąć pakiety, transmisja będzie się
zacinać. Nie będziesz wiedzieć czy soft Ci szwankuje czy może jednak
hardware. Lepiej oprzeć się na czymś sprawdzonym.
> 5) Jak taki MCU radzi sobie z szyfrowaniem AES? Powinienem się
> spodziewać zauważalnych przestojów?
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en537998
Jeśli zależy Ci na wyższej wydajności wybierz MCU z hardwarowym
wsparciem AES.
pzdr
mk
Marek
May 17, 2014, 12:58:25 PM5/17/14
to
On Sat, 17 May 2014 18:37:05 +0200, mk <reverse_lp.pw@myzskm> wrote:
> Testowo z lwIP i STM32F107 (64kB RAM, 72 MHz, gdy to testowałem ST
nic
> lepszego jeszcze nie miało w ofercie) byłem w stanie (ledwo, ledwo
ale
> jednak) zapchać rurę 100 Mbit/s przy transmisji w sieci lokalnej --
72Mhz i zapchałeś 100Mbit ethernet? Ten stm był z wbudowanym eth.
> Testowo z lwIP i STM32F107 (64kB RAM, 72 MHz, gdy to testowałem ST
nic
> lepszego jeszcze nie miało w ofercie) byłem w stanie (ledwo, ledwo
ale
> jednak) zapchać rurę 100 Mbit/s przy transmisji w sieci lokalnej --
użyty był dma?
--
Marek
mk
May 17, 2014, 2:51:48 PM5/17/14
to
W dniu 2014-05-17 18:58, Marek pisze:
STM32F107, czyli miał wbudowany kontroler Ethernet.
DMA był użyty. W ogóle w STM32 DMA od Ethernetu to już całkiem
zaawansowana maszynka, ale jej potencjał nie był dobrze wykorzystywany
przez drivery jakie (wtedy, nie wiem jak dziś) dostarczało ST (np.
stosowanie pooling w oczekiwaniu na zwolnienie przez DMA bufora, gdy
wszystkie bufory wysyłkowe się zapchały, a mamy już gotową porcję
danych; kopiowanie danych między lwIP, a diverem).
Mimo to rura TCP była w stanie przenosić pod 11 MB/s, co (uwzględniając
narzuty) jest bliskie nasycenia Ethernetu 100M.
Też byłem mile zaskoczony. Biblioteki komercyjne (np. od Express Logic)
zaczęły się chwalić możliwością nasycenia Ethernetu dopiero wraz z
nadejściem STM32F207 (120 MHz, 128 kB RAM).
pzdr
mk
DMA był użyty. W ogóle w STM32 DMA od Ethernetu to już całkiem
zaawansowana maszynka, ale jej potencjał nie był dobrze wykorzystywany
przez drivery jakie (wtedy, nie wiem jak dziś) dostarczało ST (np.
stosowanie pooling w oczekiwaniu na zwolnienie przez DMA bufora, gdy
wszystkie bufory wysyłkowe się zapchały, a mamy już gotową porcję
danych; kopiowanie danych między lwIP, a diverem).
Mimo to rura TCP była w stanie przenosić pod 11 MB/s, co (uwzględniając
narzuty) jest bliskie nasycenia Ethernetu 100M.
Też byłem mile zaskoczony. Biblioteki komercyjne (np. od Express Logic)
zaczęły się chwalić możliwością nasycenia Ethernetu dopiero wraz z
nadejściem STM32F207 (120 MHz, 128 kB RAM).
pzdr
mk
Atlantis
May 19, 2014, 2:15:39 AM5/19/14
to
W dniu 2014-05-17 00:19, Marek pisze:
> miarę potrzeb. I tak powstała prywatna płytka "ewaluacyjna" z pic32,
> encj, can, usb host, rfm12b, 5 przekaźników, 2 we 230V przez
Ja mam podobnie. To znaczy zauważyłem, że ciągle korzystam z tego samego
optymalnego połączenia pomiędzy obwodem zasilania, ATMegą i ENC28J60.
Praktycznie to samo ustawienie elementów, tak samo prowadzone ścieżki
itp. Tylko zależnie od projektu dookoła umieszczam różne peryferia.
Teraz projektując płytkę biorę "podstawę" pożyczoną z jakiegoś
wcześniejszego projektu i na jej podstawie kontynuuję projektowanie
tego, co chcę uzyskać.
> optoizolacje, złącze z 8 uniwersalnych I/O, złącze do tel. gsm, złącze
> do zasilania (i ładowania) z aku 12V (płytka w 1 wersji robi za
> centralkę alarmową) itd. Teraz właściwie każdy pomysł realizuje na tej
> plytce wlutowując tylko to, co potrzeba.
Mi trochę szkoda byłoby miejsca. Zwykle zmierzam do uzyskania
maksymalnie kompaktowego PCB, przynajmniej jak na moje amatorskie
warunki. :)
> miarę potrzeb. I tak powstała prywatna płytka "ewaluacyjna" z pic32,
> encj, can, usb host, rfm12b, 5 przekaźników, 2 we 230V przez
optymalnego połączenia pomiędzy obwodem zasilania, ATMegą i ENC28J60.
Praktycznie to samo ustawienie elementów, tak samo prowadzone ścieżki
itp. Tylko zależnie od projektu dookoła umieszczam różne peryferia.
Teraz projektując płytkę biorę "podstawę" pożyczoną z jakiegoś
wcześniejszego projektu i na jej podstawie kontynuuję projektowanie
tego, co chcę uzyskać.
> optoizolacje, złącze z 8 uniwersalnych I/O, złącze do tel. gsm, złącze
> do zasilania (i ładowania) z aku 12V (płytka w 1 wersji robi za
> centralkę alarmową) itd. Teraz właściwie każdy pomysł realizuje na tej
> plytce wlutowując tylko to, co potrzeba.
maksymalnie kompaktowego PCB, przynajmniej jak na moje amatorskie
warunki. :)
Atlantis
May 19, 2014, 2:32:54 AM5/19/14
to
W dniu 2014-05-17 18:37, mk pisze:
> Jeśli krytyczna jest wydajność to nie ma co się zastanawiać:
> mikrokontroler z wbudowanym Ethernetem.
> Wygoda? Rzecz względna, ale faktycznie ENC28J60 pod pewnymi względami
> może być wygodniejsze (np. design PCB).
Hmm... Istnieje jakiś standard układu wyprowadzeń w MCU z wbudowanym
kontrolerem Ethernetu i zewnętrznym interfejsie PHY? Można w miarę łatwo
poprowadzić magistralę złożoną z równoległych ścieżek, czy raczej trzeba
będzie się bawić w zworki i przelotki?
> uIP tylko do najprostszych aplikacji typu wysłanie lub odbieranie
> pojedynczych pakietów UDP, czy też najprostsze połączenia TCP (ale
> naprawdę najprostsze typu po połączeniu wysyłam parę bajtów i rozłączamy
> się).
Do tego spokojnie wystarczy Tuxgraphics, który jest w dodatku banalny w
obsłudze i konfiguracji. Czegoś lepszego potrzebowałbym np. do obsługi
telnetu.
> lwIP również warto ożenić z jakimś RTOS, np. z FreeRTOS. Bez
> wielowątkowości tworzenie aplikacji sieciowych, poza tymi najprostszymi,
> szybko stanie się koszmarem.
To raczej jeszcze daleko przede mną. Poza tym gdybym potrzebował
wielowątkowości do jakiegoś poważniejszego projektu, pewnie sięgnąłbym
po jakąś linuksową płytkę. Zresztą zanim w moim przypadku zajdzie taka
potrzeba, to na rynku pojawią się tanie MCU SoC, mieszczące kompletny
linuksowy komputerek w obudowie LQFP. ;)
> Moim zdaniem warto, bo Ethernet to już szybkie przebiegi i łatwo
> popełnić jakiś błąd w projekcie. Układ może mieć nawet pozory działania,
Mówimy o Fast Ethernet czy o Ethernecie w ogólności. Bo zaprojektowałem
już kilka płytek z ENC28J60 i nie miałem jak dotąd żadnych problemów.
Pingi dochodzą bez gubienia pakietów. Nie pamiętam, żebym kiedyś nie
otrzymał odpowiedzi na wysłany pakiet UDP.
> ale będą gęsto i często np. ginąć pakiety, transmisja będzie się
> zacinać. Nie będziesz wiedzieć czy soft Ci szwankuje czy może jednak
> hardware. Lepiej oprzeć się na czymś sprawdzonym.
Gdybym jednak chciał zaprojektować własną płytkę, to o czym przede
wszystkim powinienem pamiętać?
> Jeśli krytyczna jest wydajność to nie ma co się zastanawiać:
> mikrokontroler z wbudowanym Ethernetem.
> Wygoda? Rzecz względna, ale faktycznie ENC28J60 pod pewnymi względami
> może być wygodniejsze (np. design PCB).
kontrolerem Ethernetu i zewnętrznym interfejsie PHY? Można w miarę łatwo
poprowadzić magistralę złożoną z równoległych ścieżek, czy raczej trzeba
będzie się bawić w zworki i przelotki?
> uIP tylko do najprostszych aplikacji typu wysłanie lub odbieranie
> pojedynczych pakietów UDP, czy też najprostsze połączenia TCP (ale
> naprawdę najprostsze typu po połączeniu wysyłam parę bajtów i rozłączamy
> się).
obsłudze i konfiguracji. Czegoś lepszego potrzebowałbym np. do obsługi
telnetu.
> lwIP również warto ożenić z jakimś RTOS, np. z FreeRTOS. Bez
> wielowątkowości tworzenie aplikacji sieciowych, poza tymi najprostszymi,
> szybko stanie się koszmarem.
wielowątkowości do jakiegoś poważniejszego projektu, pewnie sięgnąłbym
po jakąś linuksową płytkę. Zresztą zanim w moim przypadku zajdzie taka
potrzeba, to na rynku pojawią się tanie MCU SoC, mieszczące kompletny
linuksowy komputerek w obudowie LQFP. ;)
> Moim zdaniem warto, bo Ethernet to już szybkie przebiegi i łatwo
> popełnić jakiś błąd w projekcie. Układ może mieć nawet pozory działania,
już kilka płytek z ENC28J60 i nie miałem jak dotąd żadnych problemów.
Pingi dochodzą bez gubienia pakietów. Nie pamiętam, żebym kiedyś nie
otrzymał odpowiedzi na wysłany pakiet UDP.
> ale będą gęsto i często np. ginąć pakiety, transmisja będzie się
> zacinać. Nie będziesz wiedzieć czy soft Ci szwankuje czy może jednak
> hardware. Lepiej oprzeć się na czymś sprawdzonym.
wszystkim powinienem pamiętać?
Waldemar Krzok
May 19, 2014, 5:26:51 AM5/19/14
to
używany AVR. Szef "rozkazał" przejście z różnych powodów, ale główną
przyczyną była cena. Używamy gotowych modułów, które kosztują
praktycznie śmieszną cenę. Jako, że robimy małe serie (10-100 sztuk)
robienie płytki pod gołe procesory i ich wlutowywanie po prostu się nie
opłaca. Taki STM32F3xx kosztuje jako moduł ok. 8EUR, solo może połowę,
ale trzeba zrobić layout i to ścierwo wlutować z całą menażerią dookoła.
Przy cenie godziny pracy ok. 50EUR to ne je ono.
W tej chwili mamy w użyciu dwa systemy, jeden oparty na F3, drugi na F4.
Na F3 są robione urządzenia, które są łączone z hostem przez USB/RS232,
na F4 z ethernetem. Choć nasze urządzenia są same w sobie proste, to
systemy mogą być dość skomplikowane. Np. taki jeden F4, który robi
kolega, steruje 32 RS232, 32 GPIO. Całość to ok. 100 urządzeń
połączonych ethernetem.
Moje urządzonko hula sobie na F3, ale będę je w tym tygodniu portował na
F4, bo potrzebuję sterować ethernetem, a do F3 nie wejdzie mi tcp/ip.
Jak już pisałem używamy gotowych płytek prototypowych. Jest na nich
wszystko, co potrzeba. Na mojej płytce robię co muszę, a STMa wstawiam
jak starego dobrego DILa do gniazdka i już wsio lata.
Waldek
--
My jsme Borgové. Sklopte štíty a vzdejte se. Odpor je marný.
jer...@gmail.com
May 19, 2014, 10:56:54 AM5/19/14
to
W dniu piątek, 16 maja 2014 12:06:31 UTC+2 użytkownik Atlantis napisał:
> Przymierzam się powoli do zrobienia kolejnego kroku w nauce
>
> programowania MCU (do tej pory tylko AVR-y) i wypróbowania 32-bitowych
>
> układów STM.
>
>
>
> Mam jednak kilka pytań:
>
>
>
> 1) Ponieważ w wielu swoich projektach wykorzystuję interfejs Ethernet,
> chciałbym się dowiedzieć jak to jest realizowane na tej platformie.
Wbudowany MAC z DMA.
> Przymierzam się powoli do zrobienia kolejnego kroku w nauce
>
> programowania MCU (do tej pory tylko AVR-y) i wypróbowania 32-bitowych
>
> układów STM.
>
>
>
> Mam jednak kilka pytań:
>
>
>
> 1) Ponieważ w wielu swoich projektach wykorzystuję interfejs Ethernet,
> chciałbym się dowiedzieć jak to jest realizowane na tej platformie.
>
> 2) Jaki stos powinienem zastosować? Coś w rodzaju uIP, czy też z uwagi
> na większe zasoby sprzętowe warto od razu zainteresować się lwIP?
wersji procesora.
, np.:
- ChibiOS/RT http://www.chibios.org/dokuwiki/doku.php
- eCos http://ecos.sourceware.org/
- mBed https://mbed.org/
- NuttX http://nuttx.org/
i nie bawic sie w wynajdowanie kola.
> 3) Jakich transferów mogę się spodziewać? Podejrzewam, że będzie lepiej
> niż na duecie Mega328 + ENC28J60. Jak bardzo lepiej? ;)
> 4) Warto zainwestować w jakąś płytkę ewaluacyjną?
a czasem wręcz rozdaje;)
STM32F4DISCOVERY (moduł z kontrolerem):
http://pl.mouser.com/ProductDetail/STMicroelectronics/STM32F4DISCOVERY/?qs=J2qbEwLrpCGdWLY96ibNeQ==
STM32F4DIS-BB (płyta bazowa z PHY):
http://pl.mouser.com/Search/ProductDetail.aspx?qs=tp9Gh8MiPay9fbHGaE7oZQ%3d%3d
Z powodzeniem nisko-seryjna produkcje można oprzeć o moduły ewaluacyjne.
mk
May 19, 2014, 2:37:34 PM5/19/14
to
W dniu 2014-05-19 08:32, Atlantis pisze:
Pinologia MII/RMII STM32 taka sobie... na jednej warstwie raczej nie da
rady.
>> uIP tylko do najprostszych aplikacji typu wysłanie lub odbieranie
>> pojedynczych pakietów UDP, czy też najprostsze połączenia TCP (ale
>> naprawdę najprostsze typu po połączeniu wysyłam parę bajtów i rozłączamy
>> się).
>
> Do tego spokojnie wystarczy Tuxgraphics, który jest w dodatku banalny w
> obsłudze i konfiguracji. Czegoś lepszego potrzebowałbym np. do obsługi
> telnetu.
uIP dosyć szybko i bezproblemowo uruchomiłem, ale nie będę bronił, czy
lobbował za uIP.
>> lwIP również warto ożenić z jakimś RTOS, np. z FreeRTOS. Bez
>> wielowątkowości tworzenie aplikacji sieciowych, poza tymi najprostszymi,
>> szybko stanie się koszmarem.
>
> To raczej jeszcze daleko przede mną. Poza tym gdybym potrzebował
> wielowątkowości do jakiegoś poważniejszego projektu, pewnie sięgnąłbym
> po jakąś linuksową płytkę. Zresztą zanim w moim przypadku zajdzie taka
> potrzeba, to na rynku pojawią się tanie MCU SoC, mieszczące kompletny
> linuksowy komputerek w obudowie LQFP. ;)
W jakiś RTOS warto zainwestować. Warto stosować nawet mało-średnich
projektach. Jak przedstawiłeś jesteś na etapie przesiadki 8 do 32-bitów.
Jeśli jeszcze nie masz w arsenale swoich kompetencji budowania aplikacji
mikrokontrolerowych opartych o RTOS, to ja na Twoim miejscu bym się tym
zajął niż jakimiś Ethernetami. A przy aplikacjach Ethernetowych wiedza
ta będzie tylko procentować.
Jeśli chodzi o pingwina stawianego na małych platformach, to się już z
nim przepraszam od jakiegoś czasu. Zgadzam się, że Ethernet na
mikrokontrolerze to zawsze mniejsza lub większa rzeźba. Nawet jak się
wyrzeźbi to apetyt rośnie w miarę jedzenia: a to przydała by możliwość
równoległej obsługi większej liczby połączeń, a to jeszcze jeden serwis,
a to jeszcze wypaśniejsze i ładniejsze www (czyli trzeba je komuś
zlecić, kto się tym profesjonalnie zajmuje; a jak ktoś zrobi, to zrobi
np. na Ruby on Rails :-) ), a w urządzeniu które na początku miało być
prostym rejestratorem danych w końcu dochodzi się do konkluzji: a
dlaczego by zmagazynowanych danych nie udostępniać w postaci bazy
danych... Ale z drugiej strony jakieś proste, ale bardzo szybkie I/O,
czy jakieś inne ustrojstwa mające pracować w rygorze czasu rzeczywistego
(STM32 np. wspiera IEEE1588).
>> Moim zdaniem warto, bo Ethernet to już szybkie przebiegi i łatwo
>> popełnić jakiś błąd w projekcie. Układ może mieć nawet pozory działania,
>
> Mówimy o Fast Ethernet czy o Ethernecie w ogólności. Bo zaprojektowałem
> już kilka płytek z ENC28J60 i nie miałem jak dotąd żadnych problemów.
> Pingi dochodzą bez gubienia pakietów. Nie pamiętam, żebym kiedyś nie
> otrzymał odpowiedzi na wysłany pakiet UDP.
Piszę o Fast Ethernecie i raczej o połączeniach na drodze PHY-wtyk.
A "u mnie działa" nie równa się "u klienta działa" :)
>> ale będą gęsto i często np. ginąć pakiety, transmisja będzie się
>> zacinać. Nie będziesz wiedzieć czy soft Ci szwankuje czy może jednak
>> hardware. Lepiej oprzeć się na czymś sprawdzonym.
>
> Gdybym jednak chciał zaprojektować własną płytkę, to o czym przede
> wszystkim powinienem pamiętać?
Poprawny dobór elementów (czasami nie tylko co do wartości znamionowych
głównego parametru), właściwe zasilanie, właściwy design płytki (patrz
pdfy z zaleceniami), sprawdzenie częstotliwości pracy generatora, trochę
szczęścia.
Inna jeszcze sprawa czy robisz dla siebie, czy robisz produkt który musi
przejść testy EMC.
pzdr
mk
> W dniu 2014-05-17 18:37, mk pisze:
>
>> Jeśli krytyczna jest wydajność to nie ma co się zastanawiać:
>> mikrokontroler z wbudowanym Ethernetem.
>> Wygoda? Rzecz względna, ale faktycznie ENC28J60 pod pewnymi względami
>> może być wygodniejsze (np. design PCB).
>
> Hmm... Istnieje jakiś standard układu wyprowadzeń w MCU z wbudowanym
> kontrolerem Ethernetu i zewnętrznym interfejsie PHY? Można w miarę łatwo
> poprowadzić magistralę złożoną z równoległych ścieżek, czy raczej trzeba
> będzie się bawić w zworki i przelotki?
Jeśli istnieje to nie zauważyłem :)
>
>> Jeśli krytyczna jest wydajność to nie ma co się zastanawiać:
>> mikrokontroler z wbudowanym Ethernetem.
>> Wygoda? Rzecz względna, ale faktycznie ENC28J60 pod pewnymi względami
>> może być wygodniejsze (np. design PCB).
>
> Hmm... Istnieje jakiś standard układu wyprowadzeń w MCU z wbudowanym
> kontrolerem Ethernetu i zewnętrznym interfejsie PHY? Można w miarę łatwo
> poprowadzić magistralę złożoną z równoległych ścieżek, czy raczej trzeba
> będzie się bawić w zworki i przelotki?
Pinologia MII/RMII STM32 taka sobie... na jednej warstwie raczej nie da
rady.
>> uIP tylko do najprostszych aplikacji typu wysłanie lub odbieranie
>> pojedynczych pakietów UDP, czy też najprostsze połączenia TCP (ale
>> naprawdę najprostsze typu po połączeniu wysyłam parę bajtów i rozłączamy
>> się).
>
> Do tego spokojnie wystarczy Tuxgraphics, który jest w dodatku banalny w
> obsłudze i konfiguracji. Czegoś lepszego potrzebowałbym np. do obsługi
> telnetu.
lobbował za uIP.
>> lwIP również warto ożenić z jakimś RTOS, np. z FreeRTOS. Bez
>> wielowątkowości tworzenie aplikacji sieciowych, poza tymi najprostszymi,
>> szybko stanie się koszmarem.
>
> To raczej jeszcze daleko przede mną. Poza tym gdybym potrzebował
> wielowątkowości do jakiegoś poważniejszego projektu, pewnie sięgnąłbym
> po jakąś linuksową płytkę. Zresztą zanim w moim przypadku zajdzie taka
> potrzeba, to na rynku pojawią się tanie MCU SoC, mieszczące kompletny
> linuksowy komputerek w obudowie LQFP. ;)
projektach. Jak przedstawiłeś jesteś na etapie przesiadki 8 do 32-bitów.
Jeśli jeszcze nie masz w arsenale swoich kompetencji budowania aplikacji
mikrokontrolerowych opartych o RTOS, to ja na Twoim miejscu bym się tym
zajął niż jakimiś Ethernetami. A przy aplikacjach Ethernetowych wiedza
ta będzie tylko procentować.
Jeśli chodzi o pingwina stawianego na małych platformach, to się już z
nim przepraszam od jakiegoś czasu. Zgadzam się, że Ethernet na
mikrokontrolerze to zawsze mniejsza lub większa rzeźba. Nawet jak się
wyrzeźbi to apetyt rośnie w miarę jedzenia: a to przydała by możliwość
równoległej obsługi większej liczby połączeń, a to jeszcze jeden serwis,
a to jeszcze wypaśniejsze i ładniejsze www (czyli trzeba je komuś
zlecić, kto się tym profesjonalnie zajmuje; a jak ktoś zrobi, to zrobi
np. na Ruby on Rails :-) ), a w urządzeniu które na początku miało być
prostym rejestratorem danych w końcu dochodzi się do konkluzji: a
dlaczego by zmagazynowanych danych nie udostępniać w postaci bazy
danych... Ale z drugiej strony jakieś proste, ale bardzo szybkie I/O,
czy jakieś inne ustrojstwa mające pracować w rygorze czasu rzeczywistego
(STM32 np. wspiera IEEE1588).
>> Moim zdaniem warto, bo Ethernet to już szybkie przebiegi i łatwo
>> popełnić jakiś błąd w projekcie. Układ może mieć nawet pozory działania,
>
> Mówimy o Fast Ethernet czy o Ethernecie w ogólności. Bo zaprojektowałem
> już kilka płytek z ENC28J60 i nie miałem jak dotąd żadnych problemów.
> Pingi dochodzą bez gubienia pakietów. Nie pamiętam, żebym kiedyś nie
> otrzymał odpowiedzi na wysłany pakiet UDP.
A "u mnie działa" nie równa się "u klienta działa" :)
>> ale będą gęsto i często np. ginąć pakiety, transmisja będzie się
>> zacinać. Nie będziesz wiedzieć czy soft Ci szwankuje czy może jednak
>> hardware. Lepiej oprzeć się na czymś sprawdzonym.
>
> Gdybym jednak chciał zaprojektować własną płytkę, to o czym przede
> wszystkim powinienem pamiętać?
głównego parametru), właściwe zasilanie, właściwy design płytki (patrz
pdfy z zaleceniami), sprawdzenie częstotliwości pracy generatora, trochę
szczęścia.
Inna jeszcze sprawa czy robisz dla siebie, czy robisz produkt który musi
przejść testy EMC.
pzdr
mk
tusk, donald tusk
May 20, 2014, 12:12:09 PM5/20/14
to
a może Ktoś napisać czym programuje się te procki, jaki toolchain? może
jakieś wprowadzenie w dziedzinę, byłbym zobowiązany...
jakieś wprowadzenie w dziedzinę, byłbym zobowiązany...
Andrzej
May 20, 2014, 1:49:38 PM5/20/14
to
W dniu 2014-05-20 18:12, tusk, donald tusk pisze:
2. Attolic True Studio
Obie aplikacje darmowe dla 32kB kodu. Niestety sama biblioteka panela
dotykowego to ponad 40kB.
3. CooCox (darmowy)
4. Literatura po polsku - książki z wydawnictwa BTC (drogie)
5. Płytka - mnóstwo w Kamami, AVT, Propox itd. Godne polecenia (IMHO)
-Maple mini - moduł w formie DIL
-seria Disco(very)
Ciekawy jest również moduł HY-miniSTM32V (zawiera kolorowy wyświetlacz z
panelem dotykowym cena ok 50$).
> a może Ktoś napisać czym programuje się te procki, jaki toolchain? może
> jakieś wprowadzenie w dziedzinę, byłbym zobowiązany...
>
1. Keil uVision
> jakieś wprowadzenie w dziedzinę, byłbym zobowiązany...
>
2. Attolic True Studio
Obie aplikacje darmowe dla 32kB kodu. Niestety sama biblioteka panela
dotykowego to ponad 40kB.
3. CooCox (darmowy)
4. Literatura po polsku - książki z wydawnictwa BTC (drogie)
5. Płytka - mnóstwo w Kamami, AVT, Propox itd. Godne polecenia (IMHO)
-Maple mini - moduł w formie DIL
-seria Disco(very)
Ciekawy jest również moduł HY-miniSTM32V (zawiera kolorowy wyświetlacz z
panelem dotykowym cena ok 50$).
tusk, donald tusk
May 20, 2014, 2:06:27 PM5/20/14
to
W dniu 2014-05-20 19:49, Andrzej pisze:
dziękuję, ale potrzebuję małych wyjaśnień, jeśli chodzi o Keila to
mówisz o tym: KEIL MDK ARM? jeśli nie to jak brzmi pełna nazwa programu?
mówisz o tym: KEIL MDK ARM? jeśli nie to jak brzmi pełna nazwa programu?
Andrzej
May 20, 2014, 2:25:45 PM5/20/14
to
W dniu 2014-05-20 20:06, tusk, donald tusk pisze:
Tak MDK-ARM Version 5.10 (ostatnia wersja).
tusk, donald tusk
May 20, 2014, 2:45:20 PM5/20/14
to
W dniu 2014-05-20 20:25, Andrzej pisze:
dzięki, a patrzyłem tak sobie na USB, piszą że kod dostępny tylko w
MDK-Professional, a może da się skądś zassać?
MDK-Professional, a może da się skądś zassać?
tusk, donald tusk
May 20, 2014, 2:48:04 PM5/20/14
to
a jeśli chodzi o rozeznanie w samym TCP/IP to jaką książką warto by się
zainteresować?
zainteresować?
tusk, donald tusk
May 20, 2014, 2:50:24 PM5/20/14
to
jak to wszystko ogarąć? z jednej avr z drugiej ethernet z ENC28J60?
biblioteki do tego scalaka... jak obczaić to ze strony teoretycznej?
jest gdzies opis tego SPI scalaka od ethernetu?
biblioteki do tego scalaka... jak obczaić to ze strony teoretycznej?
jest gdzies opis tego SPI scalaka od ethernetu?
Andrzej
May 20, 2014, 3:07:55 PM5/20/14
to
W dniu 2014-05-20 20:50, tusk, donald tusk pisze:
Chyba w BTC są książki na temat USB i Ethernetu i w książce Paprockiego
jest rozdział nt. USB.
Niektóre STM32 mają wbudowaną obsługę USB-OTG (seria connectivity line).
> jak to wszystko ogarąć? z jednej avr z drugiej ethernet z ENC28J60?
> biblioteki do tego scalaka... jak obczaić to ze strony teoretycznej?
> jest gdzies opis tego SPI scalaka od ethernetu?
Tak daleko jeszcze nie zaszedłem. Ja zajmuję się całkiem inną tematyką.
> biblioteki do tego scalaka... jak obczaić to ze strony teoretycznej?
> jest gdzies opis tego SPI scalaka od ethernetu?
Chyba w BTC są książki na temat USB i Ethernetu i w książce Paprockiego
jest rozdział nt. USB.
Niektóre STM32 mają wbudowaną obsługę USB-OTG (seria connectivity line).
Michał Lankosz
May 20, 2014, 5:05:03 PM5/20/14
to
W dniu 2014-05-20 20:50, tusk, donald tusk pisze:
> jest gdzies opis tego SPI scalaka od ethernetu?
W dokumentacji producenta tego scalaka.
--
Michał
Marek
May 20, 2014, 6:37:59 PM5/20/14
to
nie jest na prostym poziomie abstrakcjii sieci jak np. z układami
wiznet, które mają stos tcp "wcbudowany".
--
Marek
Atlantis
May 21, 2014, 2:08:56 AM5/21/14
to
W dniu 2014-05-20 20:50, tusk, donald tusk pisze:
> jak to wszystko ogarąć? z jednej avr z drugiej ethernet z ENC28J60?
Zacznij od Tuxgraphics. Na początek naprawdę nie warto zaprzątać sobie
głowy niczym trudniejszym. I tak prawdopodobnie nie będziesz wysyłał za
jednym razem partii danych, która liczy więcej niż kilkaset bajtów.
Problem pojawia się, gdy potrzebujesz obsługi czegoś w rodzaju telnetu.
Wtedy coś jak uIP już się przydaje i pewnie niedługo się za niego zabiorę.
Tuxgraphics przestaje też wystarczać, gdy pojawia się potrzeba
wygenerowania większej strony WWW. Tyle tylko, że ja bym się poważnie
zastanowił, zanim zacząłbym myśleć o stawianiu większego "serwera" HTTP
na ATmedze. Kod HTML bardzo szybko zapcha nam flasha. :)
Atlantis
May 21, 2014, 6:08:57 AM5/21/14
to
W dniu 2014-05-19 20:37, mk pisze:
> Jeśli istnieje to nie zauważyłem :)
> Pinologia MII/RMII STM32 taka sobie... na jednej warstwie raczej nie da
> rady.
Z gdyby zaprząc do pracy przelotki ponad niepasującymi ścieżkami, albo
wręcz krzyżujące się połączenia kynarem bezpośrednio pomiędzy
konkretnymi pinami? Czy w przypadku połączenia pomiędzy MCU a PHY może
to mieć jakieś znaczenie? Pojemności montażowe i te sprawy... :)
> uIP dosyć szybko i bezproblemowo uruchomiłem, ale nie będę bronił, czy
> lobbował za uIP.
Jednak do prostego telnetu się nada?
Niby pakietami UDP też się da przesyłać komendy do urządzenia, ale
czasem wolałbym wpiąć się za pomocą PuTTY, tak samo jak przez UART,
zamiast preparować pakiety PacketSenderem. Zresztą przecież jedno nie
wyklucza drugiego. ;)
> Poprawny dobór elementów (czasami nie tylko co do wartości znamionowych
> głównego parametru), właściwe zasilanie, właściwy design płytki (patrz
> pdfy z zaleceniami), sprawdzenie częstotliwości pracy generatora, trochę
> szczęścia.
Rozumiem jednak, że to nie jest żadna czarna magia i przy przestrzeganiu
pewnych zasad można uzyskać dobry efekt w amatorskich warunkach, nawet
robiąc płytkę termotransferem? ;)
> Inna jeszcze sprawa czy robisz dla siebie, czy robisz produkt który musi
> przejść testy EMC.
Wszystkie moje konstrukcje są czysto amatorskie, na własny użytek. ;)
> Jeśli istnieje to nie zauważyłem :)
> Pinologia MII/RMII STM32 taka sobie... na jednej warstwie raczej nie da
> rady.
wręcz krzyżujące się połączenia kynarem bezpośrednio pomiędzy
konkretnymi pinami? Czy w przypadku połączenia pomiędzy MCU a PHY może
to mieć jakieś znaczenie? Pojemności montażowe i te sprawy... :)
> uIP dosyć szybko i bezproblemowo uruchomiłem, ale nie będę bronił, czy
> lobbował za uIP.
Niby pakietami UDP też się da przesyłać komendy do urządzenia, ale
czasem wolałbym wpiąć się za pomocą PuTTY, tak samo jak przez UART,
zamiast preparować pakiety PacketSenderem. Zresztą przecież jedno nie
wyklucza drugiego. ;)
> Poprawny dobór elementów (czasami nie tylko co do wartości znamionowych
> głównego parametru), właściwe zasilanie, właściwy design płytki (patrz
> pdfy z zaleceniami), sprawdzenie częstotliwości pracy generatora, trochę
> szczęścia.
pewnych zasad można uzyskać dobry efekt w amatorskich warunkach, nawet
robiąc płytkę termotransferem? ;)
> Inna jeszcze sprawa czy robisz dla siebie, czy robisz produkt który musi
> przejść testy EMC.
Andrzej
May 21, 2014, 7:58:25 AM5/21/14
to
W dniu 2014-05-21 12:08, Atlantis pisze:
rastrze 0,5mm. Dlatego chętnie korzystam z gotowych modułów, np. Maple
Mini, który ma wymiary procesora 8051 w obudowie DIL. Tylko warto
poszukać najlepszej oferty cenowej.
> W dniu 2014-05-19 20:37, mk pisze:
>
>
> Wszystkie moje konstrukcje są czysto amatorskie, na własny użytek. ;)
>
Nie wnikając w TCPIP, ja jednak mam kłopoty z termotransferem przy
>
rastrze 0,5mm. Dlatego chętnie korzystam z gotowych modułów, np. Maple
Mini, który ma wymiary procesora 8051 w obudowie DIL. Tylko warto
poszukać najlepszej oferty cenowej.
jacek pozniak
May 21, 2014, 9:30:31 AM5/21/14
to
>
>> uIP dosyć szybko i bezproblemowo uruchomiłem, ale nie będę bronił, czy
>> lobbował za uIP.
>
> Jednak do prostego telnetu się nada?
Bez problemu, nawet wiele połaczeń jednocześnie Ci obsłuży.
>> uIP dosyć szybko i bezproblemowo uruchomiłem, ale nie będę bronił, czy
>> lobbował za uIP.
>
> Jednak do prostego telnetu się nada?
jp
Atlantis
May 21, 2014, 10:17:32 AM5/21/14
to
W dniu 2014-05-21 13:58, Andrzej pisze:
> Nie wnikając w TCPIP, ja jednak mam kłopoty z termotransferem przy
> rastrze 0,5mm.
Hmm... Do tej pory najmniejszą obudową, jaką lutowałem na samodzielnie
wytrawionej płytce była TSSOP28. Najcieńsze ścieżki sygnałowe miały
jakieś 10-12 milsów. Najcieńsza ścieżka jaką w ogóle udało mi się
wytrawić miała 5 milsów. Nie liczę jej dlatego, że nie była częścią
układu - pełniła jedynie funkcję "obwódki" wyznaczającej miejsce
przycięcia płytki. Nie zmienia to faktu, że wyszła ładnie i równo,
zachowując ciągłość po wytrawieniu i cynowaniu. Oczywiście kluczowe było
pilnowanie czasu trawienia, żeby po zniknięciu miedzi w szczelinach
płytka nie leżała zbyt długo w roztworze.
W świetle powyższego wydaje mi się, że nie powinno być problemów z
przygotowaniem płytki pod LQFP. Myślę, że najbliższym czasie przetestuję
tę hipotezę. ;)
Swego czasu też naczytałem się opowieści o tym, że przy małych obudowach
SMD to tylko metoda fotograficzna wchodzi w grę. Moje doświadczenie
wskazuje jednak na coś innego. Kluczem do sukcesu jest dobry papier i
zastosowanie laminatora zamiast żelazka. ;)
> Dlatego chętnie korzystam z gotowych modułów, np. Maple
> Mini, który ma wymiary procesora 8051 w obudowie DIL. Tylko warto
> poszukać najlepszej oferty cenowej.
To też jest jakieś rozwiązanie. Tyle tylko, że budując projekty na
AVR-ach zdążyłem się już przyzwyczaić do zwartych rozwiązań, gdzie
(prawie) wszystkie elementy mieszczą się na jednej płytce.
BTW jak to jest z programowaniem STM32? Wystarczy kabelek USB, czy może
przy budowaniu tego samodzielnie trzeba najpierw posiadać jakiś
dedykowany programator, którym dopiero wgrywa się bootloader?
> Nie wnikając w TCPIP, ja jednak mam kłopoty z termotransferem przy
> rastrze 0,5mm.
wytrawionej płytce była TSSOP28. Najcieńsze ścieżki sygnałowe miały
jakieś 10-12 milsów. Najcieńsza ścieżka jaką w ogóle udało mi się
wytrawić miała 5 milsów. Nie liczę jej dlatego, że nie była częścią
układu - pełniła jedynie funkcję "obwódki" wyznaczającej miejsce
przycięcia płytki. Nie zmienia to faktu, że wyszła ładnie i równo,
zachowując ciągłość po wytrawieniu i cynowaniu. Oczywiście kluczowe było
pilnowanie czasu trawienia, żeby po zniknięciu miedzi w szczelinach
płytka nie leżała zbyt długo w roztworze.
W świetle powyższego wydaje mi się, że nie powinno być problemów z
przygotowaniem płytki pod LQFP. Myślę, że najbliższym czasie przetestuję
tę hipotezę. ;)
Swego czasu też naczytałem się opowieści o tym, że przy małych obudowach
SMD to tylko metoda fotograficzna wchodzi w grę. Moje doświadczenie
wskazuje jednak na coś innego. Kluczem do sukcesu jest dobry papier i
zastosowanie laminatora zamiast żelazka. ;)
> Dlatego chętnie korzystam z gotowych modułów, np. Maple
> Mini, który ma wymiary procesora 8051 w obudowie DIL. Tylko warto
> poszukać najlepszej oferty cenowej.
AVR-ach zdążyłem się już przyzwyczaić do zwartych rozwiązań, gdzie
(prawie) wszystkie elementy mieszczą się na jednej płytce.
BTW jak to jest z programowaniem STM32? Wystarczy kabelek USB, czy może
przy budowaniu tego samodzielnie trzeba najpierw posiadać jakiś
dedykowany programator, którym dopiero wgrywa się bootloader?
badworm
May 21, 2014, 12:16:22 PM5/21/14
to
Dnia Fri, 16 May 2014 14:00:53 +0200, Atlantis napisaďż˝(a):
> Nie mog� si� do ko�ca zgodzi�. Po pierwsze komputerki takie jak RasPi,
> Beaglebone czy Cubbie Board s� tak naprawd� w�a�nie platformami
> ewaluacyjnymi. Sam czekam na RPi Compute Module...
Nie wiem czy siďż˝ doczekasz bowiem moduďż˝ ten wedle zapowiedzi ma byďż˝
dost�pny tylko w ilo�ciach hurtowych (przynajmniej u producenta).
--
Pozdrawiam Bad Worm badworm[maupa]post{kropek}pl
GG#2400455 ICQ#320399066
> Nie mog� si� do ko�ca zgodzi�. Po pierwsze komputerki takie jak RasPi,
> Beaglebone czy Cubbie Board s� tak naprawd� w�a�nie platformami
> ewaluacyjnymi. Sam czekam na RPi Compute Module...
Nie wiem czy siďż˝ doczekasz bowiem moduďż˝ ten wedle zapowiedzi ma byďż˝
dost�pny tylko w ilo�ciach hurtowych (przynajmniej u producenta).
--
Pozdrawiam Bad Worm badworm[maupa]post{kropek}pl
GG#2400455 ICQ#320399066
tusk, donald tusk
May 21, 2014, 3:04:22 PM5/21/14
to
znalazłem coś ciekawego:
http://unidk.com/zagruzki/udk-32f107v-zagruzki/biblioteki
chyba zakupię płytkę prototypową i zacznę się bawić,
coś takiego:
http://allegro.pl/core107v-stm32f107vet6-f-vat-sklep-i4195898171.html
tylko jak to się programuje Ktoś wie?
http://unidk.com/zagruzki/udk-32f107v-zagruzki/biblioteki
chyba zakupię płytkę prototypową i zacznę się bawić,
coś takiego:
http://allegro.pl/core107v-stm32f107vet6-f-vat-sklep-i4195898171.html
tylko jak to się programuje Ktoś wie?
tusk, donald tusk
May 21, 2014, 3:06:36 PM5/21/14
to
> tylko jak to się programuje Ktoś wie?
http://allegro.pl/segger-jlink-j-link-v8-jtag-arm-cortex-i4239435966.html
czym to się obsługuje? preferowane pod windę...
Atlantis
May 21, 2014, 3:18:10 PM5/21/14
to
W dniu 2014-05-21 18:16, badworm pisze:
> Nie wiem czy się doczekasz bowiem moduł ten wedle zapowiedzi ma być
> dostępny tylko w ilościach hurtowych (przynajmniej u producenta).
Tak. Zwykłe RasPi na początku też było sprzedawane z limitem jedna
sztuka na jedną osobę. ;)
Naprawdę myślisz, że nikt nie zamówi większej partii i nie zacznie ich
sprzedawać na Ebay-u/Allegro? ;)
> Nie wiem czy się doczekasz bowiem moduł ten wedle zapowiedzi ma być
> dostępny tylko w ilościach hurtowych (przynajmniej u producenta).
Tak. Zwykłe RasPi na początku też było sprzedawane z limitem jedna
sztuka na jedną osobę. ;)
Naprawdę myślisz, że nikt nie zamówi większej partii i nie zacznie ich
sprzedawać na Ebay-u/Allegro? ;)
tusk, donald tusk
May 21, 2014, 3:26:21 PM5/21/14
to
a co to za głupie żarty z tą dokumentacją? Ktoś czai?
CD00220364.pdf niby miał być pdfem, a tam tylko abstrakty, żadnej
treści... znaczy gdzie leżą dokumenty do STM32F107?
CD00220364.pdf niby miał być pdfem, a tam tylko abstrakty, żadnej
treści... znaczy gdzie leżą dokumenty do STM32F107?
Andrzej
May 21, 2014, 3:42:31 PM5/21/14
to
W dniu 2014-05-21 21:06, tusk, donald tusk pisze:
http://www.stm32.eu/porady
>> tylko jak to się programuje Ktoś wie?
>
> http://allegro.pl/segger-jlink-j-link-v8-jtag-arm-cortex-i4239435966.html
>
> czym to się obsługuje? preferowane pod windę...
http://www.stm32.eu/node/19
>
> http://allegro.pl/segger-jlink-j-link-v8-jtag-arm-cortex-i4239435966.html
>
> czym to się obsługuje? preferowane pod windę...
http://www.stm32.eu/porady
Andrzej
May 21, 2014, 3:51:57 PM5/21/14
to
W dniu 2014-05-21 21:26, tusk, donald tusk pisze:
sobie książkę - polecam jedną z dwu cegieł z BTC: Paprocki oraz
Galewski. Tam zapoznasz się z tym jak to się je (całkiem inaczej niż AVR).
> a co to za głupie żarty z tą dokumentacją? Ktoś czai?
> CD00220364.pdf niby miał być pdfem, a tam tylko abstrakty, żadnej
> treści... znaczy gdzie leżą dokumenty do STM32F107?
Albo będziesz szukał po różnych rozproszonych notach, albo zorganizujesz
> CD00220364.pdf niby miał być pdfem, a tam tylko abstrakty, żadnej
> treści... znaczy gdzie leżą dokumenty do STM32F107?
sobie książkę - polecam jedną z dwu cegieł z BTC: Paprocki oraz
Galewski. Tam zapoznasz się z tym jak to się je (całkiem inaczej niż AVR).
tusk, donald tusk
May 21, 2014, 4:17:26 PM5/21/14
to
no znalazłem te książki, ale wolałbym mieć jeszcze pdfa z dokładnym
opisem, bo jak pisałem znalezione przeze mnie zawierają tylko abstrakty
zamiast opisu peryferów...
opisem, bo jak pisałem znalezione przeze mnie zawierają tylko abstrakty
zamiast opisu peryferów...
tusk, donald tusk
May 21, 2014, 4:27:50 PM5/21/14
to
dzięki Panie Kolego!
a bawiłeś się może USB?
a bawiłeś się może USB?
Michał Lankosz
May 21, 2014, 5:04:48 PM5/21/14
to
W dniu 2014-05-21 21:26, tusk, donald tusk pisze:
> a co to za głupie żarty z tą dokumentacją? Ktoś czai?
> CD00220364.pdf niby miał być pdfem, a tam tylko abstrakty, żadnej
> treści... znaczy gdzie leżą dokumenty do STM32F107?
Boś wziął sam Datasheet, czyli specyfikę konkretnego układu z rodziny.
> CD00220364.pdf niby miał być pdfem, a tam tylko abstrakty, żadnej
> treści... znaczy gdzie leżą dokumenty do STM32F107?
Wspólny opis dla rodziny zawiera reference manual RM0008 (CD00171190.pdf)
Masz jeszcze Programming manual, errata i trochę application note - z
nich często można się dowiedzieć ciekawych rzeczy. No i żeby zacząć
programować najlepiej od przykładów z punktu Related Tools and Software.
--
Michał
mk
May 21, 2014, 5:54:55 PM5/21/14
to
W dniu 2014-05-21 12:08, Atlantis pisze:
> W dniu 2014-05-19 20:37, mk pisze:
>
>> Jeśli istnieje to nie zauważyłem :)
>> Pinologia MII/RMII STM32 taka sobie... na jednej warstwie raczej nie da
>> rady.
>
> Z gdyby zaprząc do pracy przelotki ponad niepasującymi ścieżkami, albo
> wręcz krzyżujące się połączenia kynarem bezpośrednio pomiędzy
> konkretnymi pinami? Czy w przypadku połączenia pomiędzy MCU a PHY może
> to mieć jakieś znaczenie? Pojemności montażowe i te sprawy... :)
Da rade. Myślę że jakby dobrze pokombinować to dla RMII wystarczy kilka
>
>> Jeśli istnieje to nie zauważyłem :)
>> Pinologia MII/RMII STM32 taka sobie... na jednej warstwie raczej nie da
>> rady.
>
> Z gdyby zaprząc do pracy przelotki ponad niepasującymi ścieżkami, albo
> wręcz krzyżujące się połączenia kynarem bezpośrednio pomiędzy
> konkretnymi pinami? Czy w przypadku połączenia pomiędzy MCU a PHY może
> to mieć jakieś znaczenie? Pojemności montażowe i te sprawy... :)
rezystorów 0R do przeskoczenia kilku ścieżek i da radę na jednej
warstwie (nie liczę drugiej przeznaczonej na GND). (Oczywiście!) Kynaru
do poprawek też używałem (z powodzeniem, bo czemu nie).
Przy zachowaniu minimum zdrowego rozsądku (np. umieszczamy PHY w bliskim
sąsiedztwie MCU), nie przejmowałbym się za bardzo połączeniem MCU-PHY --
zwłaszcza jeśli masz gdzieś EMC i nie przejmujesz się pogorszonym
odbiorem pobliskich odbiorników radiowych :)
>> uIP dosyć szybko i bezproblemowo uruchomiłem, ale nie będę bronił, czy
>> lobbował za uIP.
>
> Jednak do prostego telnetu się nada?
> Niby pakietami UDP też się da przesyłać komendy do urządzenia, ale
> czasem wolałbym wpiąć się za pomocą PuTTY, tak samo jak przez UART,
> zamiast preparować pakiety PacketSenderem. Zresztą przecież jedno nie
> wyklucza drugiego. ;)
Ja, mając już za sobą przegryzanie się przez lwIP (trochę potu to
wymagało), nie mam zamiaru wracać do uIP nawet w najprostszych
aplikacjach (jedynym uzasadnieniem byłoby jakieś koszmarne ograniczenie
zasobów pamięciowych).
>> Poprawny dobór elementów (czasami nie tylko co do wartości znamionowych
>> głównego parametru), właściwe zasilanie, właściwy design płytki (patrz
>> pdfy z zaleceniami), sprawdzenie częstotliwości pracy generatora, trochę
>> szczęścia.
>
> Rozumiem jednak, że to nie jest żadna czarna magia i przy przestrzeganiu
> pewnych zasad można uzyskać dobry efekt w amatorskich warunkach, nawet
> robiąc płytkę termotransferem? ;)
Inaczej: powinno się udać.
Ale: ryzyko, że coś się skopie nie jest też małe i nie należy go ignorować.
Dołóż do tego ryzyko softwarowe: pewnie zaczniesz od jakichś przykładów,
ale w tych też są błędy lub były przygotowane na hardware różniące się
jakimś drobnym szczegółem, który przeoczyłeś lub trzeba coś przynajmniej
pokonfigurować w nagłówkach lub w innym miejscu którego się nie
spodziewasz...
No i jeśli coś źle pójdzie, to zacznie się czarna magia, bo nawet nie
wiadomo gdzie szukać.
Zatem, gorąco sugeruje zacząć od starter kita (też bywają skopane, ale
ryzyko jednak mniejsze)... i nie piszę, że musisz na nim kończyć.
Starter kit pomoże uruchomić układ na własnej płytce.
Co do zasad... chyba nie ma w praktyce takich, które dadzą Ci
*gwarancję* sukcesu. Czarna magia w tym temacie czasami daje o sobie
znać, a wina niekoniecznie musi leżeć po twojej stronie (o czym się
dowiesz w przyszłości czytając erraty, których jeszcze nie opublikowano,
ale może za jakiś czas ;-) ).
Z drugiej strony nie ma co panikować -- podobno można z powodzeniem na
niewielkiej odległości zastąpić skrętkę sznurem od żelazka... osobiście
nie sprawdzałem, ale też wiele innych zbrodni bez ponoszenia
konsekwencji popełniłem. Nie ma co za bardzo audiofilować :-)
>> Inna jeszcze sprawa czy robisz dla siebie, czy robisz produkt który musi
>> przejść testy EMC.
>
> Wszystkie moje konstrukcje są czysto amatorskie, na własny użytek. ;)
pzdr
mk
Grzegorz Niemirowski
May 21, 2014, 7:27:53 PM5/21/14
to
Atlantis <marekw19...@wp.pl> napisał(a):
poczytania:
http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/CD00167594.pdf
Albo możesz użyć JTAGa, np. ZL30PRG (z tego korzystam).
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 7 days, 11 hours, 31 minutes and 35 seconds
> BTW jak to jest z programowaniem STM32? Wystarczy kabelek USB, czy może
> przy budowaniu tego samodzielnie trzeba najpierw posiadać jakiś
> dedykowany programator, którym dopiero wgrywa się bootloader?
Bootloader już jest wgrany. Obsługuje interfejsy szeregowe, w tym USB. Do
> przy budowaniu tego samodzielnie trzeba najpierw posiadać jakiś
> dedykowany programator, którym dopiero wgrywa się bootloader?
poczytania:
http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/CD00167594.pdf
Albo możesz użyć JTAGa, np. ZL30PRG (z tego korzystam).
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 7 days, 11 hours, 31 minutes and 35 seconds
Andrzej
May 22, 2014, 1:33:05 AM5/22/14
to
W dniu 2014-05-21 22:27, tusk, donald tusk pisze:
Zobacz jeszcze:
http://www.mikrokontroler.pl/content/STMCC
tam na dole, po reklamie książki Galewskiego są pliki źródłowe do
ćwiczeń z tej książki. To da Ci wyobrażenie co i jak.
> dzięki Panie Kolego!
>
> a bawiłeś się może USB?
>
Jak już mówiłem zajmuję się czym innym.
>
> a bawiłeś się może USB?
>
Zobacz jeszcze:
http://www.mikrokontroler.pl/content/STMCC
tam na dole, po reklamie książki Galewskiego są pliki źródłowe do
ćwiczeń z tej książki. To da Ci wyobrażenie co i jak.
badworm
May 22, 2014, 12:55:42 PM5/22/14
to
Dnia Wed, 21 May 2014 21:18:10 +0200, Atlantis napisaďż˝(a):
> Tak. Zwyk�e RasPi na pocz�tku te� by�o sprzedawane z limitem jedna
> sztuka na jednďż˝ osobďż˝. ;)
To wynika�o ZTCW z braku wystarczaj�cych mocy produkcyjnych -
popularno�� komputerka mocno zaskoczy�a jego tw�rc�w.
> Naprawd� my�lisz, �e nikt nie zam�wi wi�kszej partii i nie zacznie ich
> sprzedawaďż˝ na Ebay-u/Allegro? ;)
Zapewne tak si� stanie ale a� tak du�ej popularno�ci w zastosowaniach
amatorskich temu modu�owi nie wr��. Jaka� tam cz�� projekt�w na RasPi
to po��czenie komputerka z p�ytk� stykow� albo czym� niewiele bardziej
z�o�onym w monta�u. Przylutowanie do PCB samego z��cza dla Compute
Module b�dzie dla wielu os�b niewykonalne.
> Tak. Zwyk�e RasPi na pocz�tku te� by�o sprzedawane z limitem jedna
> sztuka na jednďż˝ osobďż˝. ;)
To wynika�o ZTCW z braku wystarczaj�cych mocy produkcyjnych -
popularno�� komputerka mocno zaskoczy�a jego tw�rc�w.
> Naprawd� my�lisz, �e nikt nie zam�wi wi�kszej partii i nie zacznie ich
> sprzedawaďż˝ na Ebay-u/Allegro? ;)
Zapewne tak si� stanie ale a� tak du�ej popularno�ci w zastosowaniach
amatorskich temu modu�owi nie wr��. Jaka� tam cz�� projekt�w na RasPi
to po��czenie komputerka z p�ytk� stykow� albo czym� niewiele bardziej
z�o�onym w monta�u. Przylutowanie do PCB samego z��cza dla Compute
Module b�dzie dla wielu os�b niewykonalne.
tusk, donald tusk
May 22, 2014, 2:13:39 PM5/22/14
to
> Boś wziął sam Datasheet, czyli specyfikę konkretnego układu z rodziny.
> Wspólny opis dla rodziny zawiera reference manual RM0008 (CD00171190.pdf)
dzięki, 1000 stron, ale przynajmniej jakiś opis, chyba zacznę jednak od
> Wspólny opis dla rodziny zawiera reference manual RM0008 (CD00171190.pdf)
tych STMów...
> Masz jeszcze Programming manual, errata i trochę application note - z
> nich często można się dowiedzieć ciekawych rzeczy. No i żeby zacząć
> programować najlepiej od przykładów z punktu Related Tools and Software.
Atlantis
May 22, 2014, 6:52:38 PM5/22/14
to
W dniu 2014-05-22 18:55, badworm pisze:
> Zapewne tak si� stanie ale a� tak du�ej popularno�ci w zastosowaniach
> amatorskich temu modu�owi nie wr��. Jaka� tam cz�� projekt�w na RasPi
> to po��czenie komputerka z p�ytk� stykow� albo czym� niewiele bardziej
No i w�a�nie chodzi o to, �e "konstrukcja amatorska" to bardzo szerokie
poj�cie. Po jednej stronie mamy jakie� proste projekty oparte na
Arduino/RPi z dodatkow� p�ytk� prototypow�, na kt�rej po��czenia
wykonano kynarem. Nieco dalej umie�ci�bym urz�dzenia zmontowane na
samodzielnie wytrawionej p�ytce, przy wykorzystaniu tylko i wy��cznie
element�w przewlekanych, po��czonych (zachowawczo) bardzo grubymi
�cie�kami. Na drugim ko�cu tego spektrum znajduj� si� miniaturowe
urz�dzenia, z g�sto upakowanymi elementami SMD o niewielkich rozmiarach.
To oczywiste, �e osoba korzystaj�ca do tej pory z RPi i p�ytki
stykowej/prototypowej raczej po ten modu� nie si�gnie. Jednak je�li kto�
budowa� uk�ady z element�w TSSOP/LQFP na samodzielnie wytrawionych
p�ytkach, to Compute Module nie b�dzie dla niego wi�kszym wyzwaniem.
Zostanie on po prostu potraktowany jak specyficzny, nieco wi�kszy MCU,
kt�ry chodzi na Linuksie. :)
Zreszt� ju� par� razy powtarza�em, �e pewnie trend b�dzie post�powa�. Za
kilka lat zobaczymy co� takiego na ma�ym module do monta�u SMD,
przypominaj�cym dzisiejsze modu�y GSM, GPS, WiFi albo Bluetooth. W jaki�
czas p�niej pewnie uda si� wcisn�� ca�e RasPi do jednego uk�adu. np. w
obudowie LQFP. ;)
> z�o�onym w monta�u. Przylutowanie do PCB samego z��cza dla Compute
> Module b�dzie dla wielu os�b niewykonalne.
Nie powinno byďż˝ trudniejsze, niďż˝ wlutowanie np. scalaczka w obudowie
TSSOP. :)
> Zapewne tak si� stanie ale a� tak du�ej popularno�ci w zastosowaniach
> amatorskich temu modu�owi nie wr��. Jaka� tam cz�� projekt�w na RasPi
> to po��czenie komputerka z p�ytk� stykow� albo czym� niewiele bardziej
poj�cie. Po jednej stronie mamy jakie� proste projekty oparte na
Arduino/RPi z dodatkow� p�ytk� prototypow�, na kt�rej po��czenia
wykonano kynarem. Nieco dalej umie�ci�bym urz�dzenia zmontowane na
samodzielnie wytrawionej p�ytce, przy wykorzystaniu tylko i wy��cznie
element�w przewlekanych, po��czonych (zachowawczo) bardzo grubymi
�cie�kami. Na drugim ko�cu tego spektrum znajduj� si� miniaturowe
urz�dzenia, z g�sto upakowanymi elementami SMD o niewielkich rozmiarach.
To oczywiste, �e osoba korzystaj�ca do tej pory z RPi i p�ytki
stykowej/prototypowej raczej po ten modu� nie si�gnie. Jednak je�li kto�
budowa� uk�ady z element�w TSSOP/LQFP na samodzielnie wytrawionych
p�ytkach, to Compute Module nie b�dzie dla niego wi�kszym wyzwaniem.
Zostanie on po prostu potraktowany jak specyficzny, nieco wi�kszy MCU,
kt�ry chodzi na Linuksie. :)
Zreszt� ju� par� razy powtarza�em, �e pewnie trend b�dzie post�powa�. Za
kilka lat zobaczymy co� takiego na ma�ym module do monta�u SMD,
przypominaj�cym dzisiejsze modu�y GSM, GPS, WiFi albo Bluetooth. W jaki�
czas p�niej pewnie uda si� wcisn�� ca�e RasPi do jednego uk�adu. np. w
obudowie LQFP. ;)
> z�o�onym w monta�u. Przylutowanie do PCB samego z��cza dla Compute
> Module b�dzie dla wielu os�b niewykonalne.
TSSOP. :)
Atlantis
May 23, 2014, 2:47:26 AM5/23/14
to
W dniu 2014-05-21 15:30, jacek pozniak pisze:
> Bez problemu, nawet wiele połaczeń jednocześnie Ci obsłuży.
A nie będzie problemu z równoległą obsługą kilku "aplikacji"? Weźmy na
ten przykład pakiety UDP + telnet + proste strony WWW po HTTP?
Z jakim użyciem flasha i RAM-u trzeba się liczyć? Zastanawiam się
którego AVR-a przeznaczyć do eksperymentów z tym stosem. Spokojnie
wystarczy ATmega328/644 czy raczej powinienem celować w coś takiego jak
ATmega128/2556?
> Bez problemu, nawet wiele połaczeń jednocześnie Ci obsłuży.
ten przykład pakiety UDP + telnet + proste strony WWW po HTTP?
Z jakim użyciem flasha i RAM-u trzeba się liczyć? Zastanawiam się
którego AVR-a przeznaczyć do eksperymentów z tym stosem. Spokojnie
wystarczy ATmega328/644 czy raczej powinienem celować w coś takiego jak
ATmega128/2556?
jacek pozniak
May 23, 2014, 3:44:00 AM5/23/14
to
Atlantis wrote:
> W dniu 2014-05-21 15:30, jacek pozniak pisze:
>
>> Bez problemu, nawet wiele połaczeń jednocześnie Ci obsłuży.
>
> A nie będzie problemu z równoległą obsługą kilku "aplikacji"? Weźmy na
> ten przykład pakiety UDP + telnet + proste strony WWW po HTTP?
Jak odpowiednio napiszesz "funkcję aplikacji" to spokojnie, w pdf jest to
> W dniu 2014-05-21 15:30, jacek pozniak pisze:
>
>> Bez problemu, nawet wiele połaczeń jednocześnie Ci obsłuży.
>
> A nie będzie problemu z równoległą obsługą kilku "aplikacji"? Weźmy na
> ten przykład pakiety UDP + telnet + proste strony WWW po HTTP?
opisane. Nie jest to tak wygodne jak w klasycznych socketach ale do urządzeń
embeded; można się przemęczyć.
> Z jakim użyciem flasha i RAM-u trzeba się liczyć? Zastanawiam się
> którego AVR-a przeznaczyć do eksperymentów z tym stosem. Spokojnie
> wystarczy ATmega328/644 czy raczej powinienem celować w coś takiego jak
> ATmega128/2556?
Nie jestem specjalistą od AVR ale, w ramach próby, przeportowałem prosty
> którego AVR-a przeznaczyć do eksperymentów z tym stosem. Spokojnie
> wystarczy ATmega328/644 czy raczej powinienem celować w coś takiego jak
> ATmega128/2556?
program (dhcp, telnet, www) z PICa, na którym nijak nie mogłem tego na
działająco skompilować, na Atmega32 i coś koło 12K Flasha zajęło.
Co do wymagań RAM to zależy od wielkości bufora, poczytaj sobie.
jp
tusk, donald tusk
May 23, 2014, 5:26:52 AM5/23/14
to
> Programming manual
mógłybś podać mi numerek tego pdfa?
i napisać gdzie lezą application notes?
mógłybś podać mi numerek tego pdfa?
i napisać gdzie lezą application notes?
Michał Lankosz
May 23, 2014, 7:19:17 AM5/23/14
to
W dniu 2014-05-23 11:26, tusk, donald tusk pisze:
www potrzebujesz?
Wszystko na jednej stronie.
Wchodzisz na www.st.com/stm32, wybierasz interesujący Cię uC, któryś z
konkretnych zaczynających się na STM32F107 (takie chcesz?) i potem masz
pierwszą stronę z takim overview, klikasz na all documents czy jakoś tak
i czytasz najpierw _całą_ stronę, w celu zaznajomienia się co na niej
możesz znaleźć; wszystko co wymieniłem.
Tylko uważaj, masz antyeuropejskie zapędy więc może wybierz jakiś Texas
Instruments albo wskrzesz projekt procesora Warszawa.
--
Michał
>> Programming manual
>
> mógłybś podać mi numerek tego pdfa?
>
> i napisać gdzie lezą application notes?
Ty jakiś Amerykanin jesteś chyba. Wideo przewodnik z poruszania się po
>
> mógłybś podać mi numerek tego pdfa?
>
> i napisać gdzie lezą application notes?
www potrzebujesz?
Wszystko na jednej stronie.
Wchodzisz na www.st.com/stm32, wybierasz interesujący Cię uC, któryś z
konkretnych zaczynających się na STM32F107 (takie chcesz?) i potem masz
pierwszą stronę z takim overview, klikasz na all documents czy jakoś tak
i czytasz najpierw _całą_ stronę, w celu zaznajomienia się co na niej
możesz znaleźć; wszystko co wymieniłem.
Tylko uważaj, masz antyeuropejskie zapędy więc może wybierz jakiś Texas
Instruments albo wskrzesz projekt procesora Warszawa.
--
Michał
tusk, donald tusk
May 23, 2014, 7:45:46 AM5/23/14
to
dzięki, jak natrafię na nierozwiązywalny problem to mogę pisać?
widzę w manualach getting started,ale mam pytanie, czy aby rozpocząć
pracę takiego STM32F107 trzeba w jakiś sposób inicjoować hardware, czy
po resecie wszystko jest wyłączone i nie trzeba sie o nic martwić?
widzę w manualach getting started,ale mam pytanie, czy aby rozpocząć
pracę takiego STM32F107 trzeba w jakiś sposób inicjoować hardware, czy
po resecie wszystko jest wyłączone i nie trzeba sie o nic martwić?
tusk, donald tusk
May 23, 2014, 7:48:11 AM5/23/14
to
a bawiłeś się może USB hostem?
Jan
May 23, 2014, 12:04:52 PM5/23/14
to
Użytkownik "Michał Lankosz" napisał w wiadomości grup
dyskusyjnych:llnar1$244$1...@srv.chmurka.net...
inteligencji i kindersztuby. A mentalnie przebija nawet Antka-policmajstra.
Michał Lankosz
May 23, 2014, 12:31:46 PM5/23/14
to
W dniu 2014-05-23 13:45, tusk, donald tusk pisze:
Domyślnie większość powyłączana. Działa wewnętrzny generator, rdzeń,
flash, ram, co tam jeszcze... Trzeba pamiętać włączyć zegar danego
peryferium, żeby móc cokolwiek z nim zrobić.
ST ma program do automatycznego generowania kodu inicjalizującego
wybrane peryferia, nazywa się STM32CubeMX (były microXplorer?). Nie
używałem go, ale może pomóc. Może też zainteresuje Cię CooCox - pełne
IDE i też ma jakiś kreator konfiguracji peryferiów.
Ja używam Eclipse plus cały łańcuszek narzędzi, ale trzeba się trochę
pomęczyć przy składaniu środowiska, raczej sobie nie poradzisz.
--
Michał
flash, ram, co tam jeszcze... Trzeba pamiętać włączyć zegar danego
peryferium, żeby móc cokolwiek z nim zrobić.
ST ma program do automatycznego generowania kodu inicjalizującego
wybrane peryferia, nazywa się STM32CubeMX (były microXplorer?). Nie
używałem go, ale może pomóc. Może też zainteresuje Cię CooCox - pełne
IDE i też ma jakiś kreator konfiguracji peryferiów.
Ja używam Eclipse plus cały łańcuszek narzędzi, ale trzeba się trochę
pomęczyć przy składaniu środowiska, raczej sobie nie poradzisz.
--
Michał
Michał Lankosz
May 23, 2014, 12:33:49 PM5/23/14
to
W dniu 2014-05-23 13:48, tusk, donald tusk pisze:
--
Michał
> a bawiłeś się może USB hostem?
To jest wiedza tajemna. Fora internetowe milczą na ten temat.
--
Michał
tusk, donald tusk
May 23, 2014, 3:00:10 PM5/23/14
to
znalazłem jakies liby do tego procka, w środku jest help, ale w helpie
jedynie spis funkcji... przydał by się jakiś działający przykład...
czy Ktoś tu przerabiał temat i wie czy lib zmieści się w 32 kB?
jedynie spis funkcji... przydał by się jakiś działający przykład...
czy Ktoś tu przerabiał temat i wie czy lib zmieści się w 32 kB?
tusk, donald tusk
May 23, 2014, 3:01:07 PM5/23/14
to
dzięki, zaczynam...
wpadł byś na moją stronę ;o)
wpadł byś na moją stronę ;o)
tusk, donald tusk
May 23, 2014, 3:03:32 PM5/23/14
to
byle nie z europy śmieciu (zgodnie z ustaleniami)...
Michał Lankosz
May 23, 2014, 5:43:38 PM5/23/14
to
W dniu 2014-05-23 21:01, tusk, donald tusk pisze:
--
Michał
> dzięki, zaczynam...
>
> wpadł byś na moją stronę ;o)
>
Ale tam nic nie ma ciekawego o USB host, ani nawet device.
>
> wpadł byś na moją stronę ;o)
>
--
Michał
Jan
May 23, 2014, 5:55:22 PM5/23/14
to
Użytkownik "tusk, donald tusk" napisał w wiadomości grup
dyskusyjnych:llo626$9nc$4...@node1.news.atman.pl...
byle nie z europy śmieciu (zgodnie z ustaleniami)...
O znowu katolickie słowa miłości bliźniego.
dyskusyjnych:llo626$9nc$4...@node1.news.atman.pl...
byle nie z europy śmieciu (zgodnie z ustaleniami)...
tusk, donald tusk
May 24, 2014, 4:36:02 AM5/24/14
to
no właśnie, można by zacząć...
Andrzej
May 24, 2014, 11:13:09 AM5/24/14
to
W dniu 2014-05-24 10:36, tusk, donald tusk pisze:
> no w�a�nie, mo�na by zacz��...
No dobrze leniuszku. Przecie� podawa�em Ci link do �wicze� z ksi��ki
Galewskiego. I tam jest taki katalog "wzorzec", a tam pliki startowe.
W du�ym skr�cie trzeba zrobi�:
//konfigurowanie sygna��w taktuj�cych
- ustawi� mno�nik PLL (kwarc razy n)
- w��czy� PLL
-w��czenie taktowania wej��/wyj��
//konfigurowanie kontrolera przerwaďż˝
//konfigurowanie ko�c�wek (kt�re maj� by� wejsciowe, wyjsciowe, i ich
tryb (np dla wej�� floating, analog, pull-down, pull up) i szybko�c z
zakresu 2-50MHz.
Wszystko to masz w tych �wiczeniach i jeszcze ze 20 program�w napisanych
pod Keil'a.
> no w�a�nie, mo�na by zacz��...
No dobrze leniuszku. Przecie� podawa�em Ci link do �wicze� z ksi��ki
Galewskiego. I tam jest taki katalog "wzorzec", a tam pliki startowe.
W du�ym skr�cie trzeba zrobi�:
//konfigurowanie sygna��w taktuj�cych
- ustawi� mno�nik PLL (kwarc razy n)
- w��czy� PLL
-w��czenie taktowania wej��/wyj��
//konfigurowanie kontrolera przerwaďż˝
//konfigurowanie ko�c�wek (kt�re maj� by� wejsciowe, wyjsciowe, i ich
tryb (np dla wej�� floating, analog, pull-down, pull up) i szybko�c z
zakresu 2-50MHz.
Wszystko to masz w tych �wiczeniach i jeszcze ze 20 program�w napisanych
pod Keil'a.
tusk, donald tusk
May 25, 2014, 12:59:27 PM5/25/14
to
szybkie pytanie, co to jest sterta w STM? czym r�ni si� od stosu i jak
rozumie� to, �e nigdy nie maleje?
rozumie� to, �e nigdy nie maleje?
tusk, donald tusk
May 25, 2014, 2:41:47 PM5/25/14
to
Chłopaki macie może pełną wersję biblioteki: STM32_OTG_LIB.zip
te w necie są mocno poobcinane, cała zajmuje 22MB a w necie są pocięte
po 2MB... może Ktoś ma i mógłby się podzielić?
te w necie są mocno poobcinane, cała zajmuje 22MB a w necie są pocięte
po 2MB... może Ktoś ma i mógłby się podzielić?
Grzegorz Niemirowski
May 25, 2014, 2:46:33 PM5/25/14
to
tusk, donald tusk <NOSPAM_te...@go2.pl> napisał(a):
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 1 day, 22 hours, 31 minutes and 28 seconds
> Chłopaki macie może pełną wersję biblioteki: STM32_OTG_LIB.zip
> te w necie są mocno poobcinane, cała zajmuje 22MB a w necie są pocięte po
> 2MB... może Ktoś ma i mógłby się podzielić?
Nie możesz normalnie ściągnąć ze strony ST?
> te w necie są mocno poobcinane, cała zajmuje 22MB a w necie są pocięte po
> 2MB... może Ktoś ma i mógłby się podzielić?
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
tusk, donald tusk
May 25, 2014, 2:48:44 PM5/25/14
to
> Nie możesz normalnie ściągnąć ze strony ST?
no nie mogę bo nie ma, nie ma nawet wzmianki o tym libie...
Grzegorz Niemirowski
May 25, 2014, 2:51:00 PM5/25/14
to
tusk, donald tusk <NOSPAM_te...@go2.pl> napisał(a):
>> Nie możesz normalnie ściągnąć ze strony ST?
> no nie mogę bo nie ma, nie ma nawet wzmianki o tym libie...
A to to co to jest?
> no nie mogę bo nie ma, nie ma nawet wzmianki o tym libie...
http://www.st.com/web/en/catalog/tools/FM147/CL1794/SC961/SS1743/PF257882#
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
tusk, donald tusk
May 25, 2014, 3:02:44 PM5/25/14
to
jeszcze pięć minut temu tego nie było...
a co Koledzy na to:
http://www.sourcecodedownloads.com/158139/
chętnie bym to zasssał, 22MB...
a co Koledzy na to:
http://www.sourcecodedownloads.com/158139/
chętnie bym to zasssał, 22MB...
Grzegorz Niemirowski
May 25, 2014, 3:19:33 PM5/25/14
to
tusk, donald tusk <NOSPAM_te...@go2.pl> napisał(a):
> jeszcze pięć minut temu tego nie było...
Jasne... I dziwisz się, że ludzie mają Cię dość...
> a co Koledzy na to:
> http://www.sourcecodedownloads.com/158139/
> chętnie bym to zasssał, 22MB...
biblioteka jest do pobrania na stronie oficjalnej?
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
tusk, donald tusk
May 26, 2014, 4:15:23 AM5/26/14
to
dzięki
Atlantis
Jun 29, 2014, 3:41:30 AM6/29/14
to
BTW mam jeszcze jedno pytanie:
Czy jeśli nie potrzebuję Fast Ethernetu, mogę wykorzystać któryś z
tańszych STM-ów (bez wbudowanego Ethernetu) i podłączyć do niego
ENC28J60? Istnieją gotowe rozwiązania, które pozwolą mi wykorzystać ten
układ z lwIP pod tymi prockami (a może nawet pod FreeRTOS)? Czy może
raczej nikt się w coś takiego nie bawi i nie znajdę gotowych rozwiązań?
Czy jeśli nie potrzebuję Fast Ethernetu, mogę wykorzystać któryś z
tańszych STM-ów (bez wbudowanego Ethernetu) i podłączyć do niego
ENC28J60? Istnieją gotowe rozwiązania, które pozwolą mi wykorzystać ten
układ z lwIP pod tymi prockami (a może nawet pod FreeRTOS)? Czy może
raczej nikt się w coś takiego nie bawi i nie znajdę gotowych rozwiązań?
Zbych
Jun 29, 2014, 2:07:57 PM6/29/14
to
STM32CubeMX which is a graphical software configuration tool that allows
generating C initialization code using graphical wizards.
This platform includes the STM32Cube HAL (an STM32 abstraction layer
embedded software, ensuring maximized portability across STM32
portfolio), plus a consistent set of middleware components (RTOS, USB,
TCP/IP and graphics). All embedded software utilities come with a full
set of examples.
Nie używałem i nie wiem ile to jest warte, ale spróbuj od tego zacząć.
0 new messages