BlueDraco nie mówię, że ma być zero - nawet przy założeniu, że wszystko poniżej 0,5V to PWM = 0% układ nie działał poprawnie. Chodzi mi bardziej o zwrócenie uwagi, że coś, co sprawdzało się X razy przy założeniach Y, może nie zadziałać, gdy zmienimy założenia.
Co do C - tak, tylko assembler - bo mamy pełną kontrolę nad każdym taktem procesora i pełną kontrolę nad samym procesorem. Skręcam półki z płyty OSB w piwnicy to używam suwmiarki zamiast metra stolarskiego żeby Broń Boże jedna nie była niżej o 0,5mm....
A tak poważnie:
1. Jak się czyta ze zrozumieniem dokumentację i ZNA się dobrze język C to nie ma problemu (tzn. nie tylko składnie, ale jak działa, w jakiej kolejności sprawdzane są np. warunki).
2. Za C przemawia:
-przejrzystość kodu
-łatwiejsza możliwość modyfikacji
-możliwość przeniesienia części kodu z jednej platformy na drugą
I to nie są czcze banały, mogę przytoczyć parę przykładów z pracy zawodowej...
Mam program na Megę, który zajmuje kilkanaście ekranów. Nad monitorem przybiłem sobie tablicę korkową, na której mam 8 kartek A4 z narysowanym algorytmem, timingami, formatem ramek RS485, jakie funkcje dawać do których bibliotek przy pisaniu (bo wykorzystuję ją w w jeszcze innym programie), nazewnictwo zmiennym, konwencja w opisywaniu stałych, "złote myśli" dla "wysokopoziomowego" programisty, który pisze obsługę tego urządzenia z poziomu PC. OK, ogarnę to w assemblerze, tylko wcześniej szef mnie wywali na zbity pysk, albo sobie włosy z głowy wyrwę próbując to wszystko opanować. A za rok, jak na moim miejscu będzie ktoś inny to patrząc na kod stwierdzi, że szybciej mu będzie napisać to od początku, niż grzebać się w tym kodzie...