🚀 go-pugleaf

On Friday, March 13, 2020 at 1:12:44 AM UTC+1, Maciek Godek wrote:
> W dniu czwartek, 12 marca 2020 20:17:25 UTC+1 użytkownik brak napisał:
> > > Bo najwidoczniej alternatywy były jeszcze gorsze.
> > > 
> >  IMHO dyskusja C vs C++ nie powinna abstrahować od platformy na jakiej
> > uruchamiany jest program.
> 
> Moim zdaniem dyskusja C vs C++ zawsze będzie raczej biciem piany, niż wymianą argumentów. Nie bez przyczyny zwykło się mawiać "de gustibus non est disputandum".
> 
> A mówiąc ogólniej, dyskusje techniczne nie powinny abstrahować od uwarunkowań problemu, dla którego szuka się rozwiązania.
Dokładnie tak. Dlatego dołączyłem się do wątku. Zamiast ciekawej dyskusji jak
rozwiązać problem powstała wirtualna przepychana.

 
> Jeżeli masz projekt, który już działa na RTOSie, to zgadzam się z Tobą jak najbardziej: zdecydowanie lepiej użyć wątku, niż jakiegoś wątłego mechanizm w rodzaju tego, który zaproponowałem.
Osobiście odmawiam pisania na uC bez RTOS-a. Aczkolwiek ;) czasem jest wymaganie typu 8-bitowy AVR z 128 bajtami RAM-u.

> 
> Jednak tutaj sytuacja była o tyle osobliwa, że ze wstępnej analizy wyszło mi, że dla tworzonej aplikacji RTOS nie będzie potrzebny. Założyłem, że jeżeli potrzeba użycia go się pojawi, to go dodam.
> 
> I w trakcie rozwoju projektu wymagania lekko się zmieniły: uznaliśmy, że być może będziemy mieli jedno peryferium, które być może będzie potrzebowało odrębnego wątku (który na dodatek będzie musiał pracować w trybie uśpienia).
> 
> W dalszym ciągu nie jest pewne, czy zastosujemy peryferium w ostatecznym produkcie. Przeportowanie aplikacji na RTOSa jest pewnym kosztem, który musielibyśmy ponieść, żeby móc skorzystać z prawdziwego wątku.
> 
> Tymczasem koszt dodania do projektu takiej korutyny jest dużo niższy od strony czasowej, zaś w moim wyobrażeniu elastyczność korzystania z trybów low-power jest większa, niż w przypadku RTOSa, który zawsze nakłada na system jakieś swoje ograniczenia (już chociażby to, że oprócz dokumentacji kontrolera musielibyśmy wertować dokumentację albo źródła tego czy innego RTOSa podniosłoby koszt czasowy projektu).
> 
> Tym bardziej, że - jak wspominałem - ten wątek może się ostatecznie okazać niepotrzebny.
Zgadzam się w 100%. To wymagania oraz racjonalność decydują o użytych "klockach" a nie dogmat prawie religijny.
Tryb low-power na RTOS-ie to koszmar a narzut na portowanie jest zwykle tak duży, że programowanie barmetal w C jest w pełni uzasadnione i rozsądne.