Który LGT8F328P użyć do urządzenia na baterię?

[Bullseye]

Hej, potrzebuję zrobić sobie płytkę pod prosty projekt, jako że ceny gotowych modułów są niskie to chciałem takowy użyć.
Podpowiecie który moduł lepiej użyć pod deepsleep tak by zjadał możliwie mało prądu?

Ten z USU byłby wygodniejszy:

 

Czy może dużo lepiej wypadnie ten:

[H1M4W4R1]

1 godzinę temu, Bullseye napisał:

Podpowiecie który moduł lepiej użyć pod deepsleep tak by zjadał możliwie mało prądu?

Raspberry Pi Pico... nie no żartuję, właśnie sprawdziłem pobory i są strasznie duże.

Osobiście raczej wybrałbym STM32 z serii L, ale jak cena jest istotna to możesz kombinować z tą płytką z USB-C  

Edytowano Kwiecień 19, 2024 przez H1M4W4R1

[Bullseye]

Wdg schematu CH340 jest na stałe zasilany z 5V wtedy, i boje się że on pobierze najwięcej prądu
Chyba ze na PCB zrobić LDO3.3V, wtedy CH byłby zasiany tylko w momencie podłaczenia USB czyli programowania.

Jestem wtedy w stanie zejść z poborem do okolic 10mA?

[ethanak]

10mA? To ja już wolałbym takie coś: https://www.hackster.io/anupamvarghese/lolin32-fix-for-low-deep-sleep-current-5cf11d

Trochę mniej niż 10 mA...

[jand]

4 godziny temu, Bullseye napisał:

Wdg schematu CH340 jest na stałe zasilany z 5V

Dlatego w tym przypadku moim zdaniem lepiej jest wybrać moduł bez portu USB, choć wtedy programowanie jest bardziej skomplikowane.

4 godziny temu, Bullseye napisał:

Jestem wtedy w stanie zejść z poborem do okolic 10mA?

Zgodnie z danymi katalogowymi układ ten w deep sleep pobiera 1µA. Trzeba tylko pousuwać wszystko, co niepotrzebne.

Na pewno się przyda ten artykuł. 

[Bullseye]

47 minut temu, jand napisał:

Dlatego w tym przypadku moim zdaniem lepiej jest wybrać moduł bez portu USB, choć wtedy programowanie jest bardziej skomplikowane.

Dlatego pytam ile realnie uzyskam zasilać tą płytkę z 3.3V (pominę wtedy CH340).

[jand]

Pobór prądu ok. 10mA dotyczy normalnej pracy, a nie stanu deep sleep.

Jeśli z płytki usuniesz wszystkie niepotrzebne układy (CH340, LDO, diodę LED) to możesz procesor zasilać bezpośrednio z akumulatorka 3.7V (zakres napięć roboczych procesora to  1.8V ~ 5.5V) i wtedy jest szansa na osiągnięcie tego 1µA.

[kaczakat]

Co do zasady lepsza jest ta zielona płytka bez konwertera USB-UART, programowanie nie jest jakiś skomplikowane, po prostu możesz użyć konwertera USB-UART. Niestety mnie się nie udało dojść do deklarowanych poziomów zużycia energii, choć wyłączałem wszystko zgodnie z datasheet.  Dużo lepsze efekty uzyskiwałem na płytce PRO Mini z Atmega328p, po wylutowaniu leda od stanu zasilania w stanie powerdown pobór prądu spada poniżej 200nA (3.3V), po wybudzeniu program rusza z miejsca gdzie go uśpiłeś, a tego nie potrafi ani LGT, ani ESP czy ARM,  u nich w największym uśpieniu, po wybudzeniu program rusza od nowa tak jak po resecie,  jak coś pomieszałem to mnie wyprowadźcie z błędu. No i nawet z tą niedogodnością to są raczej uA niż nA (ESP).

Choć być może ten problem został rozwiązany dla lgt w ostatnich latach, moje testy były jednak jakiś czas temu, dzisiaj znalazłem to: https://github.com/dbuezas/lgt8fx/issues/202 , muszę to przetestować. Miałem tak jak jeden z piszących w tamtych wątku coś około setek uA.

 

Edytowano Kwiecień 20, 2024 przez kaczakat

[ethanak]

Przypominam, że w ESP w deep sleep procesor w ogóle nie jest zasilany i trudno by było wymagać aby pamiętał co robił w zeszłym tygodniu. W AVR zatrzymywany jest jedynie zegar. 

Po prostu AVR-y i ESP służą do innych celów i jakiekolwiek próby porównania kojarzą mi się z porównywaniem ładowarki Liebherra do motocykla Kawasaki.

[kostuch]

ESP mają protezę w postaci "koprocesora" ULP.

Nigdy się nim nie bawiłem, ale chyba da się na nim po prostu zatrzymać i wznowić wykonywanie kodu po wybudzeniu.

[kaczakat]

Dnia 20.04.2024 o 12:57, ethanak napisał:

Po prostu AVR-y i ESP służą do innych celów

No faktycznie, ale ja niekumaty, jeden to uC, a drugi to rakietka do ping-ponga.  A czy wolno takim nierozgarniętym jak ja porównywać ilość RAM, flash, IO, ADC i MHz,  czy też nie? Ech, na wszelki wypadek już nie będę.

A faktycznie oba służą głównie do migania ledem w Arduino.

 

[jand]

8 godzin temu, kostuch napisał:

chyba da się na nim po prostu zatrzymać i wznowić wykonywanie kodu po wybudzeniu

Nie.

ULP może w trakcie uśpienia wykonywać tylko  swój własny kod, niezależny od kodu głównego.

[jand]

7 godzin temu, kaczakat napisał:

A faktycznie oba służą głównie do migania ledem w Arduino.

Dlatego odpowiedzi na przedstawione na forum pytania powinna być dostosowana do oczekiwań i poziomu pytającego, ale niekoniecznie idealne pod względem technicznym.

Edytowano Kwiecień 22, 2024 przez jand

[kostuch]

8 godzin temu, jand napisał:

Nie.

ULP może w trakcie uśpienia wykonywać tylko  swój własny kod, niezależny od kodu głównego.

Też fajnie.

Zastanawiam się tylko jaki byłby sens "zatrzymywania kodu" i jego wznawiania od następnej instrukcji.

Z reguły jest to coś typu: zmierz, wyślij, zaśnij. A po wybudzeniu (i resecie) dokładnie taka sama sekwencja.

Jeżeli miałby znać stan z przed resetu, to wystarczy po prostu zrobić: odczytaj, zmierz, zapisz, wyślij, zaśnij

[ethanak]

1 godzinę temu, kostuch napisał:

Zastanawiam się tylko jaki byłby sens "zatrzymywania kodu" i jego wznawiania od następnej instrukcji.

 

Czasem się przydaje (np. do migania ledami w ATtiny)

Nie, poważnie, korzystałem z tego parę razy (właśnie na ATtiny13), ale w sumie było to dość skomplikowane miganie ledami...

Poza tym nie wiem jak inne, ale ESP32 ma coś co się nazywa pamięć RTC i idealnie się nadaje do przechowywania różnych danych między wybudzeniami. Czasami nawet ULP nie jest potrzebny...