Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Komunikacja CAN między stm32 nucleo-f767ZI

19 Lut 2019 16:01 507 13
  • Poziom 4  
    Witam,

    Mam pytanie odnośnie komunikacji CAN między nucleo-f767zi. Tworzymy system telemetrii oparty na tych płytkach (5 sztuk). Jedna płytka ma być głównym "data loggerem", a do pozostałych mają być podłączone czujniki. Wszystkie dane z pomiarów z czterech STM mają docierać do jednego CAN'em a następnie do pendrive. Tylko nucleo-f767zi nie ma wbudowanego interfejsu CAN, trzeba dodać transreceiver (MCP2551). I tu pojawia się pytanie, czy to ma sens czy lepiej wymienić na płytkę STM z wbudowanym interfejsem? Czy CubeMX będzie odpowiednim środowiskiem do ogarnięcia takiego projektu?
  • Poziom 32  
    Chef_C napisał:
    czy lepiej wymienić na płytkę STM z wbudowanym interfejsem


    Wszystko zależy od kilku czynników:
    Czy planowana aplikacja dla data logera tj. tego mikrokontrolera centralnego (pewnie takiego "mastera" w sieci CAN) jest bardzo wymagająca obliczeniowo czy nie(bo STM32F7 to dość wypasione mikrokontrolery pod tym względem). Czy oprócz zapisu danych ma być wykonywana jakaś akwizycja lub czy ilość zapisywanych danych w jednostce czasu będzie znaczna lub czy na danych będą jeszcze prowadzone "w locie" jakieś złożone obliczenia.
    Jakie mają być koszty...płytki nucleo są jednak stosunkowo tanie i często ich cena jest porównywalna z zakupem samego mikrokontrolera.

    Dołożeni samego transrecivera dla magistrali CAN nie jest czymś strasznym...są pewnie nawet małe gotowce.

    Chef_C napisał:
    Czy CubeMX będzie odpowiednim środowiskiem do ogarnięcia takiego projektu?


    Po pierwsze CubeMX środowiskiem bym nie nazwał. To raczej program do generowania kodu służącemu inicjalizacji poszczególnych komponentów mikrokontrolera STM32.
    Czy to się może przydać...trudno stwierdzić- wszystko zależy od umiejętności i preferencji programisty.
    Środowisko pozwala szybko wyklikać konfigurację mikrokontrolera i bardzo szybko ruszyć z miejsca mniej doświadczonym programistom...niestety obarczone jest to jakimś naddatkiem kodu którego niektórzy nie tolerują. Niektóre funkcje w bibliotekach HAL (na której w przeważającej części opierają się wygenerowane kody), też -moim zdaniem- bywają średnio szczęśliwe.

    Tak więc jednoznaczne odpowiedzi raczej tu nie padną...trzeba samemu podjąć kluczowe decyzje.
  • Poziom 1  
  • Poziom 4  
    Tak, jest to projekt studencki na dodatkowe koło naukowe :) Dzięki za odpowiedź, więc raczej zostaniemy przy nucleo i po prostu dodamy transreceivery. Danych w przyszłości na pewno może być dużo, na razie to jest kwestia 15-20 czujników maksymalnie, może dojść do 30-40. W przyszłości planujemy to rozbudować o transmisję bluetooth i odczyt danych live na komputerze, na razie jednak będzie sam zapis.

    Jakby ktoś był zainteresowany, jest to koło PGRacing Team. Wcześniej nie było elektroniki poza ECU, także dopiero startujemy z takim projektem telemetrii. Wiem, że czeka nas dużo pracy, żeby sygnały z różnych czujników miały odpowiedni format dla STM i sama aplikacja pewnie nie będzie łatwa do napisania. Chciałem się jeszcze zapytać, czy nucleo-F767ZI będzie odpowiednią płytką bazową do takiego projektu
  • Specjalista - Mikrokontrolery
    Chef_C napisał:
    Chciałem się jeszcze zapytać, czy nucleo-F767ZI będzie odpowiednią płytką bazową do takiego projektu

    Wygląda na 20x za mocną i 10x za dużą. Do zbierania danych przez CAN to wystarczy któreś Nucleo-32 i nic większego wam nie potrzeba - byle miało CAN i potrzebne interfejsy dodatkowe. Na tym węźle na którym te dane będą odbierane i potem jakoś przetwarzane/zapisywane _MOŻE_ będzie sens dać coś większego, ale tylko _MOŻE_. Osobiście jakiś projekt z CANem realizowałem ostatnio na NUCLEO-F042K6. Program zajmował finalnie całe 3.4 kB pamięci flash, wiec sam sobie odpowiedz, czy potrzebny Ci układ który ma 2 MB flash i 0.5 MB RAMu.
  • Poziom 32  
    Chef_C napisał:
    Chciałem się jeszcze zapytać, czy nucleo-F767ZI będzie odpowiednią płytką bazową do takiego projektu


    Trudno powiedzieć...
    Problem jest zarysowany dość ogólnie.
    Sam mikrokontroler to dość wydajna obliczeniowo jednostka i raczej powinna bez problemu sobie z takimi zadaniami poradzić. Mam nawet wrażenie, że jest nieco nadmiarowa a temat można by pociągnąć na serii F4 lub nawet F1. Jednak zawsze lepszy naddatek niż niedobór.
    Co do samej płytki...na zabawy "na stole" pewnie będzie ok. lecz docelowo pewnie i tak trzeba będzie robić dedykowaną płytkę drukowaną.

    Dodano po 21 [minuty]:

    Freddie Chopin napisał:
    Wygląda na 20x za mocną i 10x za dużą. Do zbierania danych przez CAN to wystarczy któreś Nucleo-32 i nic większego wam nie potrzeba - byle miało CAN i potrzebne interfejsy dodatkowe. Na tym węźle na którym te dane będą odbierane i potem jakoś przetwarzane/zapisywane _MOŻE_ będzie sens dać coś większego, ale tylko _MOŻE_. Osobiście jakiś projekt z CANem realizowałem ostatnio na NUCLEO-F042K6. Program zajmował finalnie całe 3.4 kB pamięci flash, wiec sam sobie odpowiedz, czy potrzebny Ci układ który ma 2 MB flash i 0.5 MB RAMu.


    Ja (nie wiem czemu) zrozumiałem, iż tylko jednostka centralna ma być STM32F7...w roli tych obsługujących czujniki to widział bym raczej niskie serie typu stm32F0.

    Jednostka centralna może być wydajniejsza... to projekt studencki więc i pomysły mogą być różne. To, że dziś to tylko zbieranie i zapis danych wcale nie oznacza, iż to ostateczny pomysł.

    Ważnym- nieporuszanym tu jeszcze- aspektem w tego typu projektach jest masa urządzeń, ich odporność na niekorzystne warunki środowiskowe oraz niski pobór energii. Warto już na etapie doboru elementów brać te kwestie pod uwagę.
  • Specjalista - Mikrokontrolery
    Steryd3 napisał:
    Ja (nie wiem czemu) zrozumiałem, iż tylko jednostka centralna ma być STM32F7...w roli tych obsługujących czujniki to widział bym raczej niskie serie typu stm32F0.

    Jak dla mnie z pierwszego postu wynika, że wszystkie płytki maja być takie same.
  • Poziom 4  
    Tak, mamy wszystkie 5 płytek takich samych. Zamysł był taki, żeby w przyszłości nie było ograniczeń w ilości użytych czujników, właśnie ze względu na np. zbyt mało pamięci flash/RAM. Zgadzam się, że są to wydajniejsze płytki niż potrzebujemy, lecz nie zmienia to faktu, że możemy ich użyć i nie będzie większego problemu?

    Odnośnie wyboru transceivera, MCP2551 ma zasilanie 5V, z STM jest output 3,3V. Poszukać lepiej transceivera zasilanego 3,3V, np. SN65HVD232QD?
  • Poziom 32  
    Nie wiem jaki kierunek kolega studiuje ale gdy ja studiowałem EiT to mieliśmy bodaj na 2 roku przedmiot który nazywał się Projektowanie Układów Cyfrowych. Gnębiono nas tam z różnych rzeczy ale pamiętam, iż układ cyfrowy ma przedział napięcia który interpretuje jako logiczny stan niski i taki który uważa za wysoki. Trzeba też wspomnieć, iż te przedziały są różne dla wejść i wyjść tych układów.

    W tajemnicy nadmienię, iż dla mikrokontrolerów STM32 oraz innych układów w tym MCP... w internecie można odnaleść noty katalogowe które zawierają wspomniane parametry.
    Wystarczy, że np. przedział napięcia wyjściowego STM'a dla stanu niskiego zawiera się w przedziale napięcia wejściowego dla tego stanu ...i już wiemy, iż ten przypadek jest ok. To samo dla stanu wysokiego oraz analogicznie tych sytuacji gdy to układ MCP ma wyjście a STM wejście sygnału.

    Powodzenia:)
  • Poziom 11  
    Może zainteresuj się F103.
    Posiada kontroler CAN, a chińskie płytki uruchomieniowe są dosyć tanie - ok 15zl.
  • Poziom 1  
  • Poziom 11  
    chodziło mi o STM32F103C8T6.
    Pisząc F104 wkradł się błąd w ostatnim znaku.
  • Poziom 12  
    Nie ma mowy że braknie zasobów.

    Skomplikowane Body Computery w autach które obsługują często ponad 200 różnych typów ramek CAN mają zegary na poziomie 64-80MHz, FLASH w okolicach 1.5-2MB i 512-768KB RAM.

    STM32F769 jest lekko licząc 4 razy bardziej "zasobny".
    Zwracam też uwagę, że typowy CAN w autach zasuwa w tempie 250kbit/s co jest prędkością żałośnie niską w porównaniu nawet do bardzo lichego
    ETH czy WiFi.