Czasami programy mogą mieć błędy w czasie wykonywania. Czasami są trudne do znalezienia i można je łatwo przeoczyć. Czy jest jakiś sposób przetestowania programu przed wypaleniem go na płycie?
Czasami programy mogą mieć błędy w czasie wykonywania. Czasami są trudne do znalezienia i można je łatwo przeoczyć. Czy jest jakiś sposób przetestowania programu przed wypaleniem go na płycie?
Odpowiedzi:
Istnieje kilka projektów Arduino Simulator.
Być może jednym z bardziej dojrzałych jest Virtronics Simulator for Arduino , film na YouTube tutaj .
Strona Virtronics, do której prowadzi powyższy link, zawiera także kilka innych symulatorów Arduino, zarówno bezpłatnych, jak i płatnych.
Biorąc pod uwagę zainteresowanie, jakie wywołuje Arduino, istnieje prawdopodobnie więcej takich symulatorów, więc nie ma sensu próbować wymieniać je wszystkie w odpowiedzi tutaj.
Warto zauważyć, że istnieje także aplikacja Arduino Simulator na iPhone'a : nie jest to zalecenie, ponieważ nie widziałem jej jeszcze w działaniu.
Na marginesie:
Arduino samo w sobie jest płytką do prototypowania / eksperymentowania. Jest idealny do programowania eksperymentalnego kodu, debugowania go, modyfikowania, a następnie ponownego flashowania świeżego kodu, prawie tyle razy, ile się chce . Jeśli kod się zawiesi, zresetuj go i wprowadź ponownie zmiany ze zmianami.
Dlatego wątpliwe jest, czy użycie symulatora, który nigdy nie będzie w stanie idealnie naśladować różnych rzeczywistych czasów lub innych problemów, z którymi może się spotkać aplikacja.
Jeśli chodzi o koszt Arduino, istnieje kilka opcji:
Błędy czasu wykonania można znaleźć, jeśli można ręcznie przejść przez program z podłączonym Arduino i debugować ( po pobraniu kodu do Arduino). Jest to dostępne w Visual Micro, chociaż wymaga Visual Studio. Możesz ustawiać punkty przerwania, oceniać zmienne i zmieniać wartości zmiennych. Możesz także uzyskać wizualizację pamięci w czasie:
Jednym ze sposobów na to byłoby utworzenie programu otoki dla rzeczywistego kodu, który symuluje wszystkie dane wejściowe i akceptuje dane wyjściowe (tworząc w ten sposób pętlę sprzężenia zwrotnego) zgodnie z rzeczywistym środowiskiem. Wymagałoby to różnego wysiłku w zależności od rodzaju programu, stopnia testowania i liczby danych wejściowych.
Pamiętaj, że pisząc program otoki, powinieneś postępować zgodnie z podejściem „ czarnej skrzynki” .
W przeciwnym razie Twój zewnętrzny kod może nie przetestować programu tak dobrze, jak to możliwe, ponieważ pamiętając o rzeczywistym kodzie podczas tworzenia kodu testowego, możesz stronić od ignorowania przypadków granicznych lub obszarów problemowych (zaobserwowano to podczas wykonywania Testów White-Box, które jest alternatywą).