Według mnie porównanie z samochodem jest niezbyt trafne. Samochód to już gotowy produkt, wsiadasz, jakoś odpalasz i jedziesz. Zamiast tego powiedz mi, gdybyś miał zrobić samochód, to wolałbyś zrobić samochód jak te pierwsze samochody, do którego bierzesz ramę, wkładasz silnik, chłodnicę, trochę obsługi i jedziesz? Jeśli coś źle zrobisz, to samochód się spali, ale przynajmniej chwile pojedzie i zobaczysz efekty swojej pracy. Czy raczej samochód do którego musisz dać silnik, sto czujników, modułów, odpowiednie podzespoły, odpowiednio wszystko podłączyć, skalibrować i naczytać się jak co do czego podłączyć? Przykład mrugania diodą przez DMA jest spoko, ALE czy jeśli twoim jedynym zadaniem jest mruganie diodą, to jest to konieczne? Jeśli jedyne co twój procesor robi to mruga diodą, dla użytkownika jest różnica czy mrugasz w pętli czy na DMA? Pomijając aspekty zużycia prądu. Powiedz mi, jak szybko jesteś w stanie napisać mruganie diodą na AVR, od zera w C, a w ile jesteś w stanie zrobić to na STM, BEZ UŻYCIA CUBE, który generuje za ciebie tonę kodu. To że ty tego kodu nie piszesz, nie znaczy że go tam nie ma i nie jest pewnym zawyżeniem progu wejściowego. Sama wymagana wiedza również jest utrudnieniem. No i czy procesor ma znaczenie? W przypadku basica, można dokładnie tak samo prosto napisać coś na prosty jak i na skomplikowany procesor. W przypadku microPythona również. Kwestia co i jak porównujemy.
@nomadc4 jak na STM chcesz mieć mały kod to pisz używając LL. Robiłem kurs na ten temat. Pisze się łatwo jak w HAL a kod jest mały i szybki. Nie trzeba "rzeźbić" na rejestrach jak w AVR.
@@eR-MIK Ale ja się z tym zgadzam. Tylko jak porównywać łatwość pisania na coś? Jeśli porównujemy bezpośrednio biblioteki, no to na atmegę również mogą być HALe czy inne podobne rozwiązania. MicroPython? Czy STM czy RP2040 czy coś innego, zadziała tak samo. W tym przypadku będziemy porównywać nie łatwość programowania, tylko dostępne środowiska programistyczne. Nawet taki HAL w przypadku STM32 nie będzie prosty w użyciu, jeśli nie użyjemy Cube, który nam wygeneruje konfiguracje pinów i szkielet projektu.
łatwiej się pisze na to co się zna.. i tyle.. na pewno pełne poznanie możliwości wiekszego uC jest trudniejsze, bo ma tych mozliwiści więcej, z kolei na małym uC trudniej jest napisać coś bardziej wymagającego bo nie mamy żadnego marginesu ani zasobów ani wydajności - program musi być optymalny a to jest bardzo trudne i wymaga czasem robienia trików, których nie przewidział nawet twórca sprzętu. Hackerzy z demosceny na C64 robili takie cuda, które twórcom tego komputerka sie nie śniły.
@@michalp.1484 Da sie zrobić jak dodasz "trochę" elektroniki ale się namęczysz. Tak czysto programowo: zrób na AVR (nie Xmega tylko AVR) emulator 1-Wire w trybie OverDrive. Da się (zrobiłem) ale się namęczysz na STM32 czy CPLD/FPGA zrobisz bez problemu.
@@michalp.1484 Obecnie nawet ARM-y są tak tanie (RP2350 - dwurdzeniowy Cortex M33 z możliwością przełączenia rdzeni na architekturę RISC-V kupiłem wczoraj za 25zł, gotowy moduł na płytce, zakup w Polsce, oficjalnie z VAT-em itd.), że używanie prostych mikrokontrolerów 8-bitowych w nowych projektach nie ma większego sensu. No chyba, że mówimy o projektach pokroju sterowania miganiem lampek choinkowych lub kontekstach wymagających ekstremalnie niskiego poboru energii. Kilkanaście lat temu Arduino/AVR to był świetny projekt - pozwalał dzieciom z podstawówki i osobom prawie zupełnie nietechnicznym wejść łatwo w świat mikrokontrolerów i realizowanie wielu projektów hobbystycznych czy prostej automatyki domowej a to wszystko w stosunkowo niskiej cenie i z niskim progiem wejścia jeśli chodzi o wymagane umiejętności (plusem Arduino była prostota z punktu widzenia początkującego programisty oraz wiele gotowych "sheldów", z których można było składać projekty jak z klocków LEGO, łącząc je funkcjonalnie w całość za pomocą gotowych bibliotek i kilkunastu linijek kodu). Teraz moim zdaniem nie ma sensu wchodzić w 8-bitowce, bo to technologia wymierająca w świecie mikrokontrolerów.
Jeżeli chodzi o porównania, mnie by interesowało jak się ma architektura, rozwiązania układowe, struktura/logika połączeń (topologia) poszczególnych układów scalonych etc. popularnych niegdyś mikrokomputerów 8-bitowych C64, Atari 800 XL, ZX Spectrum. Jedno to warstwa sprzętowa. Ale również warstwa programowa. Takiego kompleksowego, dogłębnego porównania brakuje. Ponadto interesowałoby mnie jak mają się tamte rozwiązania do nowoczesnych mikrokontrolerów, takich jak STM32. Byłbym wdzięczny za omówienie tego tematu.
@piotrw9940 Aby zrobić to o czym piszesz musiałbym bardzo dobrze znać "Szmatati 800" i "Gumaka". Nie ma sensu abym się tego uczył bo i po co? Aby udowodnić udowodnione?
Heh, akurat samochody to kiepskie porównanie, bo osoba co jeździła maluchem może się tak samo odnaleźć w ID.7 jak osoba pracująca na 8051 przy Aurix TC3xx ... Uważasz, że ST zrobiło Cube z możliwością konfiguracji CPU graficznie bo wszystko jest takie proste, łatwe i przyjemne? Żeby był jednocześnie dobrze ustawiony uart z niskim BERR, żeby działało usb, żeby pamięć była z niskimi waitstate ... CPU są bardziej skomplikowane i jest więcej rzeczy do setup potrzebne. A potem... potem to się po prostu pisze co to ma robić, większej różnicy nie ma na jakiej platformie.
@@eR-MIK myślę, że nie rozumiesz, taki ARM ma generalnie generator frakcyjny dla uart ale to trzeba skonfigurować, tak samo trzeba skonfigurować pll i dzielniki zegara dla usb. I innych peryferiów. Robienie tego ręcznie to jest właśnie to na czym polegnie większość "avrowców" którzy mają generalnie jeden zegar i co najwyżej dzielniki dla takiego ADC i uart. Polec mogą też na nvic. Albo kilku bankach RAM w różnych obszarach przestrzeni adresowej. Nie wszystko oczywiście jest potrzebne do "blinking led", ale generalnie trzeba więcej ustawić na start niż w megaavr, czy 8051. A im więcej peryferiów się wykorzystuje tym większe rozbieżności.
![Kodak Black - Catch Fire [Official Music Video]](http://i.ytimg.com/vi/A4ch-olIuZo/mqdefault.jpg)
Według mnie porównanie z samochodem jest niezbyt trafne. Samochód to już gotowy produkt, wsiadasz, jakoś odpalasz i jedziesz. Zamiast tego powiedz mi, gdybyś miał zrobić samochód, to wolałbyś zrobić samochód jak te pierwsze samochody, do którego bierzesz ramę, wkładasz silnik, chłodnicę, trochę obsługi i jedziesz? Jeśli coś źle zrobisz, to samochód się spali, ale przynajmniej chwile pojedzie i zobaczysz efekty swojej pracy. Czy raczej samochód do którego musisz dać silnik, sto czujników, modułów, odpowiednie podzespoły, odpowiednio wszystko podłączyć, skalibrować i naczytać się jak co do czego podłączyć?
Przykład mrugania diodą przez DMA jest spoko, ALE czy jeśli twoim jedynym zadaniem jest mruganie diodą, to jest to konieczne? Jeśli jedyne co twój procesor robi to mruga diodą, dla użytkownika jest różnica czy mrugasz w pętli czy na DMA? Pomijając aspekty zużycia prądu. Powiedz mi, jak szybko jesteś w stanie napisać mruganie diodą na AVR, od zera w C, a w ile jesteś w stanie zrobić to na STM, BEZ UŻYCIA CUBE, który generuje za ciebie tonę kodu. To że ty tego kodu nie piszesz, nie znaczy że go tam nie ma i nie jest pewnym zawyżeniem progu wejściowego. Sama wymagana wiedza również jest utrudnieniem.
No i czy procesor ma znaczenie? W przypadku basica, można dokładnie tak samo prosto napisać coś na prosty jak i na skomplikowany procesor. W przypadku microPythona również. Kwestia co i jak porównujemy.
@nomadc4 jak na STM chcesz mieć mały kod to pisz używając LL. Robiłem kurs na ten temat. Pisze się łatwo jak w HAL a kod jest mały i szybki. Nie trzeba "rzeźbić" na rejestrach jak w AVR.
@@eR-MIK Ale ja się z tym zgadzam. Tylko jak porównywać łatwość pisania na coś? Jeśli porównujemy bezpośrednio biblioteki, no to na atmegę również mogą być HALe czy inne podobne rozwiązania. MicroPython? Czy STM czy RP2040 czy coś innego, zadziała tak samo. W tym przypadku będziemy porównywać nie łatwość programowania, tylko dostępne środowiska programistyczne. Nawet taki HAL w przypadku STM32 nie będzie prosty w użyciu, jeśli nie użyjemy Cube, który nam wygeneruje konfiguracje pinów i szkielet projektu.
łatwiej się pisze na to co się zna.. i tyle.. na pewno pełne poznanie możliwości wiekszego uC jest trudniejsze, bo ma tych mozliwiści więcej, z kolei na małym uC trudniej jest napisać coś bardziej wymagającego bo nie mamy żadnego marginesu ani zasobów ani wydajności - program musi być optymalny a to jest bardzo trudne i wymaga czasem robienia trików, których nie przewidział nawet twórca sprzętu. Hackerzy z demosceny na C64 robili takie cuda, które twórcom tego komputerka sie nie śniły.
@michalp.1484 Możesz dobrze znać Z80 czy 6502 i nie napiszesz softu obsługującego TFt 480x320 16-bit z 30fps.
@@eR-MIK no wiadomo, że twardych ograniczeń sprzętowych nie da się przeskoczyć
@@michalp.1484 Da sie zrobić jak dodasz "trochę" elektroniki ale się namęczysz.
Tak czysto programowo: zrób na AVR (nie Xmega tylko AVR) emulator 1-Wire w trybie OverDrive. Da się (zrobiłem) ale się namęczysz na STM32 czy CPLD/FPGA zrobisz bez problemu.
@@michalp.1484 Obecnie nawet ARM-y są tak tanie (RP2350 - dwurdzeniowy Cortex M33 z możliwością przełączenia rdzeni na architekturę RISC-V kupiłem wczoraj za 25zł, gotowy moduł na płytce, zakup w Polsce, oficjalnie z VAT-em itd.), że używanie prostych mikrokontrolerów 8-bitowych w nowych projektach nie ma większego sensu. No chyba, że mówimy o projektach pokroju sterowania miganiem lampek choinkowych lub kontekstach wymagających ekstremalnie niskiego poboru energii. Kilkanaście lat temu Arduino/AVR to był świetny projekt - pozwalał dzieciom z podstawówki i osobom prawie zupełnie nietechnicznym wejść łatwo w świat mikrokontrolerów i realizowanie wielu projektów hobbystycznych czy prostej automatyki domowej a to wszystko w stosunkowo niskiej cenie i z niskim progiem wejścia jeśli chodzi o wymagane umiejętności (plusem Arduino była prostota z punktu widzenia początkującego programisty oraz wiele gotowych "sheldów", z których można było składać projekty jak z klocków LEGO, łącząc je funkcjonalnie w całość za pomocą gotowych bibliotek i kilkunastu linijek kodu). Teraz moim zdaniem nie ma sensu wchodzić w 8-bitowce, bo to technologia wymierająca w świecie mikrokontrolerów.
Jeżeli chodzi o porównania, mnie by interesowało jak się ma architektura, rozwiązania układowe, struktura/logika połączeń (topologia) poszczególnych układów scalonych etc. popularnych niegdyś mikrokomputerów 8-bitowych C64, Atari 800 XL, ZX Spectrum. Jedno to warstwa sprzętowa. Ale również warstwa programowa. Takiego kompleksowego, dogłębnego porównania brakuje. Ponadto interesowałoby mnie jak mają się tamte rozwiązania do nowoczesnych mikrokontrolerów, takich jak STM32. Byłbym wdzięczny za omówienie tego tematu.
@piotrw9940 Aby zrobić to o czym piszesz musiałbym bardzo dobrze znać "Szmatati 800" i "Gumaka". Nie ma sensu abym się tego uczył bo i po co? Aby udowodnić udowodnione?
Heh, akurat samochody to kiepskie porównanie, bo osoba co jeździła maluchem może się tak samo odnaleźć w ID.7 jak osoba pracująca na 8051 przy Aurix TC3xx ... Uważasz, że ST zrobiło Cube z możliwością konfiguracji CPU graficznie bo wszystko jest takie proste, łatwe i przyjemne? Żeby był jednocześnie dobrze ustawiony uart z niskim BERR, żeby działało usb, żeby pamięć była z niskimi waitstate ... CPU są bardziej skomplikowane i jest więcej rzeczy do setup potrzebne. A potem... potem to się po prostu pisze co to ma robić, większej różnicy nie ma na jakiej platformie.
@Promilus1984 Jeśli potrzebujesz niski BERR i USB wybierz odpowiedni uC, który ma dedykowany generator dla USB.
@@eR-MIK myślę, że nie rozumiesz, taki ARM ma generalnie generator frakcyjny dla uart ale to trzeba skonfigurować, tak samo trzeba skonfigurować pll i dzielniki zegara dla usb. I innych peryferiów. Robienie tego ręcznie to jest właśnie to na czym polegnie większość "avrowców" którzy mają generalnie jeden zegar i co najwyżej dzielniki dla takiego ADC i uart. Polec mogą też na nvic. Albo kilku bankach RAM w różnych obszarach przestrzeni adresowej.
Nie wszystko oczywiście jest potrzebne do "blinking led", ale generalnie trzeba więcej ustawić na start niż w megaavr, czy 8051. A im więcej peryferiów się wykorzystuje tym większe rozbieżności.