tuxcnc pisze: ↑

20 paź 2024, 21:35

A na koniec klasyczne korpo, czyli wszyscy udowadniają, że to nie ich wina...

I tu, niestety, masz 100% racji

drzasiek90 pisze: ↑

20 paź 2024, 12:16

Cały temat jest krzywy.
Nawalił programista podając niepełną informację: "Potrzebujemy paru bajtów pamięci nieulotnej na płytce nad którą pracujesz na licznik operacji"

Pełny cytat: "Potrzebujemy paru bajtów pamięci nieulotnej na płytce nad którą pracujesz na licznik operacji. Coś co przetrwa zanik zasilania" - i naprawdę wystarczyłoby parę bajtów, 4 byłyby w sam raz Naprawdę muszę wybierać konkretną technologię? Mam też iść do technologa i specyfikować przebieg temperatury w piecu?

EEPROM zdecydowanie nie jest dobrym rozwiązaniem - w tej chwili szukam "akceptowalnego" na wypadek jeśli się okaże że dobre rozwiązania (SPI MRAM) nie działa.
Powiedzmy że mam paranoje Jeśli ktoś pracował z wczesnymi wersjami MAX32590 pewnie wie dlaczego. Jeśli ktoś zamierza użyć tego procesora - mogę tylko doradzić żeby koniecznie zdobyć pełną specyfikację (wymaga NDA) i wyszukać wszystkie "gwiazdki"...

atom1477 pisze: ↑

19 paź 2024, 19:08

Od kiedy to potrzebne jest jakiekolwiek wsparcie?
Mi zawsze wystarczało że użycie nie było blokowane (albo dokumentacja utajniona).

Nie każdy potrafi pisać sterowniki na poziomie kernela linuxa - dokumentacje mamy, książkę z koniem ("Linux Device Drivers") mamy, może jakoś to będzie

Przypuszczam że to dość typowy przypadek kiedy przy projektowaniu elektroniki najwięcej do powiedzenia mają księgowi.
uC bez flash jest (powiedzmy) 10centów tańszy, precyzyjny RTC kosztuje ze dwa euro a 1MB MRAMu to po prostu rozbój... więc niech programista nie wydziwia tylko programuje.

"Ale w STM da się emulować eeprom. W czym problem zająć trochę Flash?" - "Flash endurance min 10K cycles".
Chcę zapisywać co kilka sekund - w takim tempie szybko go wykończę.
Nie, nie mogę trzymać tego w RAMie i zapisywać przy wyłącznie urządzenia - po zaniku zasilania procesor zbyt szybko "pada"
Tak, "są sposoby" - nie można zapisywać do cały czas tej samej lokacji, trzeba wykrywać zniszczone bloki itd. (dyski SSD robią to od lat) - ale bądźmy szczerzy, to "rzeźbienie w brązie"

mikrokontroler to STM32 - według elektroników nie ma flascha na pokładzie.
Szczerze mówiąc - to nawet nie jest wina elektronika. Płytka jest "dość" złożona, ten uC to tylko koprocesor którego głównym zadaniem jest obsługa komunikacji z peryferiami więc nic dziwnego że projektant zapomniał o jakimś szczególe.
Najzabawniejsze jest to że na płycie jest przewidziany spory kawałek MRAMu ale nie ma gwarancji że będzie działał bo główny procesor, zgodnie z dokumentacją, ma interfejs SPI ale producent nie zapewnia sterowników ani wsparcia... i nie chce powiedzieć dlaczego

Rozmowa z elektronikim kilka miesięcy temu:
Potrzebujemy paru bajtów pamięci nieulotnej na płytce nad którą pracujesz na licznik operacji. Coś co przetrwa zanik zasilania.
Elektronik: nie ma problemu, mikrokontroler ma na pokładzie parę kilobjatów.

Dzisiaj, wszelki wypadek, postanowiłem zapytać ile cykli zapisu wytrzymuje.
Elektronik: to jest sram, nie ma limitu cykli, ale potrzebujemy paru uA do podtrzymania a na płytce nie ma miejsca na baterie...