Brak sprzętu na początkowych etapach tworzenia oprogramowania sprzętowego. Typowe strategie radzenia sobie z tym to:

1. Poświęć czas na dokładne zaprojektowanie systemu, zanim napiszesz jakikolwiek kod. Oczywiście i tak powinieneś to zrobić, ale w tym przypadku jest to nawet ważniejsze niż zwykle. O wiele łatwiej jest debugować dobrze przemyślane oprogramowanie niż bałagan oparty na makaronie.

2. Prawidłowo zmodularyzuj wszystko, minimalizując interfejsy między modułami. Pomoże to w usunięciu błędów w poszczególnych modułach i umożliwi łatwiejsze testowanie poszczególnych modułów.

3. Pisz kod od dołu do góry, sterowniki dotykające sprzętu idą jako pierwsze, logika aplikacji wysokiego poziomu na końcu. Pozwala to na wczesne wykrycie niedogodności narzuconych przez architekturę. Nie bój się zmieniać architektury, gdy wyjdą na jaw realia sprzętowe, ale upewnij się, że cała dokumentacja jest odpowiednio aktualizowana.

4. Symuluj. Większość firm zajmujących się mikrokontrolerami dostarcza symulatory oprogramowania swoich mikrokontrolerów. Mogą to zajść tylko do tej pory, ale nadal mogą być bardzo przydatne. Symulowanie wejść i mierzenie wyjść sprzętu może być trudne, ale sprawdzenie logiki wyższego poziomu w ten sposób nie powinno być zbyt trudne.

   W tym miejscu ponownie pomaga konstrukcja modułowa. Jeśli nie możesz rozsądnie zasymulować niektórych interakcji sprzętowych niskiego poziomu, używasz innej wersji modułu, która dotyka tego sprzętu, ale przekazuje własne symulowane działania na wyższe poziomy. Wyższe poziomy nie będą wiedzieć, że to się dzieje. W ten sposób nie będziesz sprawdzać modułu niskiego poziomu, ale prawie wszystko inne.

Krótko mówiąc, używaj dobrych praktyk projektowania oprogramowania, które oczywiście powinieneś i tak robić.

Bez żadnego wglądu w to, co opracowujesz, ani na rodzinę mikrokontrolerów, na których będzie oparty Twój sprzęt, większość rodzin mikrokontrolerów ma dostępne tanie systemy programistyczne z zestawem typowych urządzeń peryferyjnych, które mogą pozwalają zasymulować przynajmniej część ostatecznego sprzętu docelowego.

W zależności od tego, jak zależna będzie od sprzętu aplikacja, możesz po prostu rozpocząć wdrażanie projektu na standardowym komputerze (Windows, Linux ...). Większość dostępu do urządzeń peryferyjnych i tak powinna być abstrakcyjna, więc zaimplementowanie niektórych fikcyjnych funkcji, które zostaną później zastąpione, nie jest wielkim problemem. Jeśli nie można zasymulować jakiegoś zachowania, możesz przynajmniej zrobić makietę systemu (API ...), aby rzeczywista implementacja przebiegała znacznie szybciej i wyraźniej, gdy tylko sprzęt będzie gotowy.

Jest oczywiście wiele rzeczy, których nie można zasymulować, na przykład zachowanie w czasie rzeczywistym lub złożone sterowniki sprzętu. Z drugiej strony kontroler ADC sterowany przerwaniami można łatwo zasymulować za pomocą wątku, który odczytuje wartości z pliku lub portu sieciowego.

Oczywiście wszystko to zależy w dużym stopniu od różnych czynników:

• Czy możesz używać tego samego / podobnego łańcucha narzędzi na kontrolerze i komputerze (np. gcc)?
• Jak zależny jest sprzęt od systemu?
• Jakie masz doświadczenie w programowaniu na PC?

Przede wszystkim projektuję prawie każdy moduł oprogramowania układowego na komputerze.

Spróbuj zdobyć symulator dla swojego chipa. Powinieneś zasymulować wszystkie oczekiwane dane wejściowe, a także niektóre nieoczekiwane. Modularyzuj / streszczaj w miarę możliwości i pisz testy jednostkowe. Jeśli możesz, testy te mogą stać się częścią twojego rzeczywistego kodu i zamieniają się w funkcję (autotest płytki).

Jeśli nie możesz uzyskać symulatora, abstrakcyjne jak tylko możesz, HAL (warstwa abstrakcji sprzętu). Wszyscy kierowcy za tym stoją. Spróbuj wyodrębnić wszystkie zestawy specyficzne dla platformy za jakimś wywołaniem funkcji C i potraktuj je również jako sterowniki. Resztę napisz jako przenośny kod C / C ++ i stwórz cienką warstwę HAL dla x86 i uruchom ją na swojej maszynie ze wszystkimi przypadkami testowymi.

W ten sposób, gdy otrzymasz sprzęt, będziesz musiał tylko debugować HAL. Im jest cieńszy, tym szybciej go debugujesz i wszystko będzie działać. Pamiętaj, że jeśli używasz asemblacji specyficznej dla platformy do szybszych operacji, chcesz BARDZO DUŻO , aby uzyskać testy z dokładnością bitową.

Twoje pytanie jest dość szerokie. Sprzęt (HW) może oznaczać w pełni niestandardowy rozwój ASIC / FPGA, programowane przez asemblera DSP lub „tylko” typowy system wbudowany oparty na gotowych mikroprocesorach / mikrokontrolerach / SoC itp. które możesz chcieć zaprogramować ...). W przypadku dużych ilości sprzedaży, uczynienie go ASIC nie jest rzadkością.

Ale w przypadku dwumiesięcznego projektu spodziewam się, że będzie oparty na jakimś mikrokontrolerze:

W każdym razie powinieneś podkreślić zespół zajmujący się sprzętem, aby dał ci prototyp, dzięki któremu możesz rozpocząć testowanie kodu przed ostatecznym terminem - może to po prostu składać się z ogólnej płyty programistycznej, jak niektórzy już wspominali, ale w moim zdaniem ich zadaniem jest dostarczenie ci odpowiedniego, a potencjalnie także niektórych wymaganych / podobnych urządzeń peryferyjnych do testowania.

Symulatory są również możliwe do pewnego stopnia, ale nadal możesz potrzebować scharakteryzować jakiś rzeczywisty świat czujniki / dane, które możesz uzyskać. Tutaj zespół sprzętowy również musi ci przynajmniej pomóc.

Poza tym projekt oprogramowania można już wykonać, a wszystkie moduły wysokiego poziomu można (i powinny być) zaimplementowane i przetestowane jednostkowo bez rzeczywistego Idealnie byłoby również zdefiniować API wraz z zespołem sprzętowym, a oni zapewnią Ci funkcje najniższego poziomu, więc wszelkie zmiany, które wprowadzą po stronie sprzętowej (np. po prostu przedefiniują, których pinów portu używają) będą nie zawsze być dla Ciebie krytycznym.

We wszystkich przypadkach komunikacja jest kluczowa.

Tak, możesz opracować kod swojej płyty docelowej, zanim płyta zostanie wyprodukowana.

Jak?

Najpierw musisz poznać główny cel tego systemu. Więc z tego możesz odpowiednio wybrać kontroler z ogromnego dostępnego źródła, takiego jak digikey, mouser.

I wybierz symulator taki jak Proteus. To zasymuluje dokładny procesor / kontroler, teraz możesz rozpocząć kodowanie. Ale nie można oczekiwać dokładności sprzętowej.