ATTiny 1-Series - Zegarek na baterię CR2023

[pmochocki]

Czasami można tu na forum przeczytać, że projekt powstał z tego co jest w szufladzie. Jako, że nie zajmowałem się elektroniką ponad dekadę to w mojej szufladzie nic nie ma. Człowiek wraca do swojego hobby i okazuje się, że procki, których kiedyś używał produkuje już ktoś inny. No bo tak w 2016 roku Microchip Technology przejęła firmę Atmel Corporation. Jeszcze tego samego roku firma wypuściła nową serię procków ATTiny 1-Series. Mimo, że od tego czasu minęło już pół dekady, chyba procki nie zyskały popularności w kraju nad Wisłą. W sumie to dziwne, bo jak na "tiny" to procki są wypasione: przynajmniej dwa liczniki 16bit (jak mi tego brakowało w ATTiny13), RTC, System Zdarzeń, "Configurable Custom Logic", AC, ADC, DAC, itd. Do tego są tańsze od startych ATTiny. W 2018 Microchip wypuścił też serię 0 - która jest jeszcze tańsza. Nowe ATTiny mocno zbliżyły się do ATMega'i. Jedyne co by mnie skłoniło do zapłacenia więcej za ATMega'ę to moduł DMA, którego w ATTiny brakuje.

Więcej można przeczytać tu: https://ep.com.pl/podzespoly/12452-113-mikrokontrolery-avr-z-technologiami-z-picow 

Jako, że mamy obecnie kryzys na rynku przewodników nie miałem okazji kupić najmniejszych ośmio-nożkowych wersji. Za to w tym tygodniu dotarły ATTiny414-SS i ATTiny816-S. Używając ich planuję zrobić zegarek na baterię CR2023.

Tak jak widać na załączonym obrazku niestety nie ma wersji z obudową DIP. Ja zamówiłem egzemplarze w obudowach SOIC. Są to obudowy, które bez większych problemów będzie można przylutować.
Do programowania nowych ATTiny używa się tylko jednego pinu. Super rozwiązanie, ale jak zobaczyłem opis programatora UPDI się troszkę przeraziłem: https://ep.com.pl/projekty/projekty-ep/14803-supdi-programator-updi-dla-mikrokontrolerow-avr . Na całe szczęście jest o wiele prostszy sposób programowania tych układów o czym napiszę wkrótce.

 

 

[H1M4W4R1]

11 godzin temu, pmochocki napisał:

Mimo, że od tego czasu minęło już pół dekady, chyba procki nie zyskały popularności w kraju nad Wisłą. W sumie to dziwne, bo jak na "tiny" to procki są wypasione: przynajmniej dwa liczniki 16bit (jak mi tego brakowało w ATTiny13), RTC, System Zdarzeń, "Configurable Custom Logic", AC, ADC, DAC, itd. Do tego są tańsze od startych ATTiny. W 2018 Microchip wypuścił też serię 0 - która jest jeszcze tańsza. Nowe ATTiny mocno zbliżyły się do ATMega'i. Jedyne co by mnie skłoniło do zapłacenia więcej za ATMega'ę to moduł DMA, którego w ATTiny brakuje.

Osobiście porzuciłem AVR ze względu na ceny... I dość skromny wybór. (Oczywiście trochę procków AVR czy ESP32 mam w szufladzie).

Aktualnie siedzę sobie na ARM'ach wszelkiej maści, w szczególności RP2040 czy STM32. Zazwyczaj wychodzi w przybliżeniu tyle samo co za AVR (np. ATMegę 328P), a jednak mają znacznie więcej mocy obliczeniowej... Kości FLASH też mam "w szufladzie", więc brak wbudowanej pamięci mnie nie przeraża 😉 

Obecnie AVR są stosowane najczęściej tam, gdzie wymagana jest niezawodność w każdych warunkach, aczkolwiek też idą w odstawkę. Ostatnio pracowałem trochę z lampami samochodowymi (frontowymi) i w większości przypadków były to albo układy analogowe, albo procesory STM32 (czasami NXP). Urządzenia diagnostyczne to zwykle STM32 + FPGA... Po prostu AVR "odchodzą do lamusa" ze względu na swoje ceny... Jeżeli ATMega 328 (SMD) kosztuje w hurcie 1.8$, a w tej samej kwocie mogę mieć RP2040 z kością FLASH 16Mbit+ (na promocji nawet 128Mbit da radę wyciągnąć za ~80c)... Wybór nasuwa się sam 😉 

Aczkolwiek te nowe ATtiny mają naprawdę fajną cenę... Może nawet przy następnych zakupach się skuszę i wezmę kilka (tak z 50) do szuflady...  

11 godzin temu, pmochocki napisał:

Tak jak widać na załączonym obrazku niestety nie ma wersji z obudową DIP. Ja zamówiłem egzemplarze w obudowach SOIC. Są to obudowy, które bez większych problemów będzie można przylutować.

QFN też bez problemu się lutuje 😉 (zazwyczaj)... Najgorzej z BGA, ale póki nie jest to coś rzędu 100 kulek i wzwyż też da się akceptowalnie zrobić w warunkach domowych.

Edytowano Październik 29, 2021 przez H1M4W4R1

[pmochocki]

3 godziny temu, H1M4W4R1 napisał:

Osobiście porzuciłem AVR ze względu na ceny... I dość skromny wybór. (Oczywiście trochę procków AVR czy ESP32 mam w szufladzie).

Aktualnie siedzę sobie na ARM'ach wszelkiej maści, w szczególności RP2040 czy STM32. Zazwyczaj wychodzi w przybliżeniu tyle samo co za AVR (np. ATMegę 328P), a jednak mają znacznie więcej mocy obliczeniowej... Kości FLASH też mam "w szufladzie", więc brak wbudowanej pamięci mnie nie przeraża

Gdy ST Microelectronics inwestowało w integrację ARMa, Atmel pracował nad swoim XMega Core. Skończyło się tak, że Atmel został przejęty przez Microchip. I on zrobił co trzeba: duży core wrzucił do ATTiny, uzupełnił braki technologią z PICa i dał niska cenę. Rok później zrobił serię 0, która jest jeszcze tańsza. To jest jedyna szansa na powrót AVRów do gry. 

Do tej pory nie zajmowałem się programowaniem na ARMy, ale już zabawki czekają...

Edytowano Październik 29, 2021 przez pmochocki

[H1M4W4R1]

7 minut temu, pmochocki napisał:

To jest jedyna szansa na powrót AVRów do gry.

Patrząc na to co wyprawia Raspberry Pi i Espressif widzę nad nimi ciemne chmury... Rynek hobbystów raczej jest dla nich praktycznie stracony. Musieliby znów zdobyć przewagę rynkową, a na to się nie zapowiada - ani technologicznie, ani cenowo...

AVR przy życiu trzymają głównie części zamienne do starego sprzętu, wojsko i Arduino, ale i tak już raczej będzie powoli umierać, bo ARM jest znacznie bardziej uniwersalny... A jeszcze RISC-V im dokopał... Niestety, ale 8-bit pomału odchodzi do lamusa... 

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[Harnas]

Dnia 29.10.2021 o 11:52, H1M4W4R1 napisał:

Kości FLASH też mam "w szufladzie", więc brak wbudowanej pamięci mnie nie przeraża

Taki Flash podnosi nieco koszt.

Dnia 29.10.2021 o 11:52, H1M4W4R1 napisał:

albo procesory STM32 (czasami NXP). Urządzenia diagnostyczne to zwykle STM32 + FPGA

Można powiedzieć że całe pokolenie inżynierów wychowało się na STM32. STM stworzyło swego czasu HAL które sprawiło że nie trzeba było ogarniać 1000 stron manuala żeby uruchomić UART+PWM. Dla początkujących to było coś, doświadczeni narzekali na jakość tego HAL. No a teraz okazuje się że STM zrobiło strzał w 10.

Dnia 29.10.2021 o 11:52, H1M4W4R1 napisał:

Po prostu AVR "odchodzą do lamusa" ze względu na swoje ceny

Koszty obudowy, dystrybucji i lutowania robią swoje. Struktura krzemowa przy tym wszystkim to marginalny koszt, stąd ta popularność innych, mocniejszych rodzin wśród hobbystów, a klasyków w starszych projektach.

 

[pmochocki]

Płytka NUCLEO-L476RG jest już ze mną i czeka na wolny wieczór. 1/3 kursu STM32L4 przeczytana na sucho i dwa moje komentarze czekają na odpowiedź autora, ale... jak się obiecało to należy słowa dotrzymać:

Dnia 29.10.2021 o 00:26, pmochocki napisał:

Do programowania nowych ATTiny używa się tylko jednego pinu. Super rozwiązanie, ale jak zobaczyłem opis programatora UPDI się troszkę przeraziłem: https://ep.com.pl/projekty/projekty-ep/14803-supdi-programator-updi-dla-mikrokontrolerow-avr . Na całe szczęście jest o wiele prostszy sposób programowania tych układów o czym napiszę wkrótce.

Na tej stronie (jtag2updi.md) znalazłem dwa sposoby na zaprogramowanie nowych ATTiny. Jeden za pomocą konwertera USB-RS232 drugi za pomocą Arduino. Konwertery dopiero zamówiłem, a Arduino UNO znalazłem w piwnicy. Kupione kilka lat temu dla brata, którego chciałem zainteresować elektroniką. Jako, że płytka znalazła się u mnie w piwnicy, domyślacie się, że brat się nie zainteresował za bardzo. Autor sugeruje używać konwertera USB-RS232, ale ja użyłem togo co miałem.

Więc ściągamy źródła z jtag2updi.md i w Arduino IDE kompilujemy program naszego programatora i wgrywamy do Android UNO. Następnie podłączamy płytkę Ardunio jak na rysunku zaczerpniętym z tej strony.

To samo w formie tekstowej mojego autorstwa:

Arduino UNO           ATTiny
     5V <------------> VCC
    GND <------------> GND
  Pin 6 <--[ 0.5k ]--> UPDI

Teraz trzeba skonfigurować Arduino IDE zgodnie ze stroną: https://github.com/SpenceKonde/megaTinyCore.
Musimy użyć wersji 2.4.2 - ani poprzednie, ani następne wersje nie działają poprawnie w momencie pisania tego worklogu:

W Arduino IDE w Plik -> Preferencje należy dodać ten URL: http://drazzy.com/package_drazzy.com_index.json:

Potem przechodzimy do Menadżera płytek:

Wyszukujemy megaTinyCore i pamiętamy o właściwej wersji:

Następnie możemy wybrać już nasz procek w Arduino IDE:

Programator ustawiamy na jtag2updi:

Piszemy prosty programik do mrugania diodą:

// Arduino pins
const int Red_LED = 16; // PA3 LED pin

void setup() {
  // put your setup code here, to run once:
  pinMode(Red_LED, OUTPUT);
}

void loop() {
  delay(500);
  digitalWrite(Red_LED, !digitalRead(Red_LED));
}

Wciskamy przycisk wgraj. Po kilku sekundach program się wgrywa i dioda zaczyna świecić. Nie możemy uwierzyć, że wszystko udało się za pierwszym razem, bo takie rzeczy się nie zdarzają... Otwieramy 🍺 i patrząc na mrugającą diodę myślimy sobie, że więcej będzie tego opisywania na forum niż było roboty przy uruchomieniu.

 

PS:

• Skąd wiadomo, że pin 16 to PA3 w ATTiny816?
  • Stąd: https://github.com/SpenceKonde/megaTinyCore/blob/master/megaavr/extras/ATtiny_x16.md
• To bez sensu, ja to chcę pisać bez bibliotek Arduino, tylko w czystym C.
  • No to pisz, Arduino IDE potrafi to skompilować.
• Ale ja chcę w AVR Studio.
  • Ja na razie jeszcze nie próbowałem, ale jak się Tobie uda to daj znać 😉
• Ale Ty masz tam coś jeszcze podłączane na tej płytce?
  • Bo pisanie workloga okazało się strasznie żmudnym zadaniem i mam już materiał na jeden czy dwa wpisy - w następnej odsłonie usypianie nowych ATTiny
     

 

 

Edytowano Listopad 3, 2021 przez pmochocki

[pmochocki]

23 godziny temu, pmochocki napisał:

w następnej odsłonie usypianie nowych ATTiny

Wygląda na to, że tu dużo się nie zmieniło. Ponoć nie trzeba już oddzielnie wyłączać przetwornika ADC, ale przydałoby się potwierdzić to w nocie katalogowej. Pamiętamy, żeby nieużywane piny albo ustawić jako wyjścia i przylutować do masy, albo nie podłączać i ustawić jako wejścia i włączyć rezystor podciągający. Bezwzględnie należy się upewnić, że BOD jest wyłączone:

 

Ustawiamy tryb power down i wołamy sleep_enable:

void SleepSetup () {
  set_sleep_mode(SLEEP_MODE_PWR_DOWN);
  sleep_enable();
}

Następnie gdy zawołamy sleep_cpu() ATTiny idzie w stan uśpienia i pobiera około 0.1uA (na granicy dokładności mojego miernika).

Jest to zgodne z notą katalogową Tabela 36-5. (Power Consumption in Power-Down, Standby, and Reset Mode):

Jest to jednak wynik w jakimś stopniu rozczarowujący. Tyle samo prądu w trybie power down pobierała stary ATTiny13A. Gorzej... Przez kolegę @H1M4W4R1zacząłem porównywać nowe ATTiny z 32bitowym mikrokontrolerem STM32L476RG, który jest używany w kursie STM32L4. Okazuje się, że ATTiny (przynajmniej w teorii) wypada gorzej w normlanych temperaturach użytkowania.

W kolejnym "odcinku" będę uruchamiał RTC.

EDIT: Poniżej kod, który używałem.

#include <avr/sleep.h>

// Arduino pins
const int Red_LED = 16;   // PA3 LED pin

void flashLed (int wait) {
  digitalWrite(Red_LED, HIGH);
  delay(wait);
  digitalWrite(Red_LED, LOW);
  delay(wait);
}

void SleepSetup () {
  set_sleep_mode(SLEEP_MODE_PWR_DOWN);
  sleep_enable();
}

void setup() {
  // put your setup code here, to run once:
  pinMode(Red_LED, OUTPUT);
  digitalWrite(Red_LED, LOW);
    // Don't leave unused pins floating
  pinMode(0, INPUT_PULLUP);
  pinMode(1, INPUT_PULLUP);
  pinMode(2, INPUT_PULLUP);
  pinMode(3, INPUT_PULLUP);
  pinMode(4, INPUT_PULLUP);
  pinMode(5, INPUT_PULLUP);
  pinMode(6, INPUT_PULLUP);
  pinMode(7, INPUT_PULLUP);
  pinMode(8, INPUT_PULLUP);
  pinMode(9, INPUT_PULLUP);
  pinMode(10, INPUT_PULLUP);
  pinMode(11, INPUT_PULLUP);
  pinMode(12, INPUT_PULLUP);
  pinMode(13, INPUT_PULLUP);
  pinMode(14, INPUT_PULLUP);  
  pinMode(15, INPUT_PULLUP);
  SleepSetup();
}

void loop() {
  for( int i = 0; i < 5; i ++) {
    flashLed (500);
  }
  sleep_cpu();
}

 

 

Edytowano Listopad 3, 2021 przez pmochocki

[H1M4W4R1]

1 godzinę temu, pmochocki napisał:

Jest to jednak wynik w jakimś stopniu rozczarowujący. Tyle samo prądu w trybie power down pobierała stary ATTiny13A. Gorzej... Przez kolegę @H1M4W4R1zacząłem porównywać nowe ATTiny z 32bitowym mikrokontrolerem STM32L476RG, który jest używany w kursie STM32L4. Okazuje się, że ATTiny (przynajmniej w teorii) wypada gorzej w normlanych temperaturach użytkowania.

Nie ma co porównywać STM serii L z AVR, seria L w domyśle jest "Low-Power", czyli do zastosowań "bateryjnych" 😉 Jest ona projektowana głównie pod jak najniższe zużycie. Bardziej bym przejrzał noty np. STM32F103.

1 godzinę temu, pmochocki napisał:

pinMode(0, INPUT_PULLUP); pinMode(1, INPUT_PULLUP); pinMode(2, INPUT_PULLUP); pinMode(3, INPUT_PULLUP); pinMode(4, INPUT_PULLUP); pinMode(5, INPUT_PULLUP); pinMode(6, INPUT_PULLUP); pinMode(7, INPUT_PULLUP); pinMode(8, INPUT_PULLUP); pinMode(9, INPUT_PULLUP); pinMode(10, INPUT_PULLUP); pinMode(11, INPUT_PULLUP); pinMode(12, INPUT_PULLUP); pinMode(13, INPUT_PULLUP); pinMode(14, INPUT_PULLUP); pinMode(15, INPUT_PULLUP);

Pętle 'for' po coś istnieją... 😄 

[pmochocki]

14 godzin temu, H1M4W4R1 napisał:

Nie ma co porównywać STM serii L z AVR, seria L w domyśle jest "Low-Power", czyli do zastosowań "bateryjnych" 😉 Jest ona projektowana głównie pod jak najniższe zużycie. Bardziej bym przejrzał noty np. STM32F103.

Jakoś nie mogę się z tym zgodzić. Cały czas żyje AVRami sprzed dekady. A gdzie słynne PicoPower i rewolucyjne konstrukcje: A, PA? Przecież nowe ATTiny "by design" powinny być "Low-Power", a tu przez 10 lat żadnego postępu nie widzę. 

14 godzin temu, H1M4W4R1 napisał:

Pętle 'for' po coś istnieją... 😄 

No tak - forma to pozostałość po eksperymentach. Jak wszystkie piny były "floating" mój miernik wskazywał 0.2uA. Badałem jak się układ zachowa jak zostawię co drugi lub trzeci nie pin niepodłączony. Patrzyłem co będzie jak jeden port poprawnie ustawię, a drugi nie. To samo z połówkami portów. Starałem się wymuszać zakłócenia. Jednak mając takie narzędzie pomiarowe, wnioski nie są jednoznaczne więc nic o tym nie pisałem. Kod natomiast w tej formie wygląda jak u przedszkolaka 😛

Edytowano Listopad 4, 2021 przez pmochocki

[H1M4W4R1]

1 minutę temu, pmochocki napisał:

Jakoś nie mogę się z tym zgodzić. Cały czas żyje AVRami sprzed dekady. Ale gdzie słynne PicoPower i rewolucyjne konstrukcje: A, PA? Przecież nowe ATTiny "by design" powinny być "Low-Power", a tu przez 10 lat żadnego postępu nie widzę. 

Kwestia kosztów, mogłyby zużywać mniej prądu, ale trzeba byłoby zjechać z procesem technologicznym parę poziomów "w dół", a to już jest raczej nieopłacalne. Są tanie, ale przez to zużywają więcej prądu, bo mają większe tranzystory w strukturze krzemowej.

[pmochocki]

6 godzin temu, H1M4W4R1 napisał:

Kwestia kosztów, mogłyby zużywać mniej prądu, ale trzeba byłoby zjechać z procesem technologicznym parę poziomów "w dół", a to już jest raczej nieopłacalne. Są tanie, ale przez to zużywają więcej prądu, bo mają większe tranzystory w strukturze krzemowej.

Oczywiście mógłbym się kłócić, że nowszy proces to większy "device yield". Ale pewnie masz rację, używany jest stary proces, pewnie jeszcze te same fabryki, których używał Atmel. Bo nawet gdyby zmniejszyli użycie prądu o połowę w AVRach, to nie staną się one dzięki temu bardziej konkurencyjne. Ale zmniejszenie ceny, tak jak zrobili, to już inna kwestia...

[pmochocki]

Dnia 3.11.2021 o 23:06, pmochocki napisał:

W kolejnym "odcinku" będę uruchamiał RTC.

Najpierw część sprzętowa. Do pinów oznaczonych TOSC1 i TOSC2 należy podpiąć kwarc.

Jaki to ma być kwarc jest dość dobrze udokumentowane:

Należałoby podpiąć jakieś kondensatory:

Możemy zgrubnie obliczyć jakie powinniśmy zastosować używając wzoru:

C = 2 * (C_L - C_parasitic - C_PCB)

Mam kwarc o C_L = 12.5pF więc szacując pojemność na płytce stykowej na około 0.75pF mamy:

C = 2 * (12.5pF - 2.75pF - 0.75pF)

C ≈ 15pF lub 20pF

Tak na prawdę układ będzie pracował nawet bez kondensatorów, ale pewnie jego częstotliwość rezonansowa nie będzie odpowiadała częstotliwości oczekiwanej. Dobierając odpowiednio kondensatory możemy sprawić, że układ będzie pracował precyzyjniej. Ale to może być temat na jeden z kolejnych odcinków.

Teraz można przystąpić do programowania. Tu pomocna okaże się "application note" TB3213 dostępna pod adresem: http://ww1.microchip.com/downloads/en/Appnotes/TB3213-Getting-Started-with-RTC-DS90003213.pdf 

W stosunku do poprzedniej wersji programu mamy funkcję RTCSetup(), która została napisana na podstawie wyżej wymienionego dokumentu. Jest mała funkcja pomocnicza WriteToXOSC32KCTRLA(uint8_t value) aby wygodnie ustawić rejestr chroniony CLKCTRL. Jako ostatni element została dodana Obsługa przerwania RTC_PTI.

#include <avr/sleep.h>
#include <avr/io.h>
#include <avr/interrupt.h>

// Arduino pins
const int Red_LED = 16;   // PA3 LED pin

void SleepSetup() {
  set_sleep_mode(SLEEP_MODE_PWR_DOWN);
  sleep_enable();
}

void WriteToXOSC32KCTRLA(uint8_t value) {
    // Enable writing to protected register
  CPU_CCP = CCP_IOREG_gc;
  CLKCTRL.XOSC32KCTRLA = value;
}

void RTCSetup() {
  uint8_t temp;
  
  /* Initialize 32.768kHz Oscillator: */
  /* Disable oscillator: */
  temp = CLKCTRL.XOSC32KCTRLA;
  temp &= ~CLKCTRL_ENABLE_bm;
  WriteToXOSC32KCTRLA(temp);
  
  while(CLKCTRL.MCLKSTATUS & CLKCTRL_XOSC32KS_bm) {
    ; /* Wait until XOSC32KS becomes 0 */
  }
  
  /* SEL = 0 (Use External Crystal): */
  temp = CLKCTRL.XOSC32KCTRLA;
  temp &= ~CLKCTRL_SEL_bm;
  WriteToXOSC32KCTRLA(temp);
  
  /* Enable oscillator: */
  temp = CLKCTRL.XOSC32KCTRLA;
  temp |= CLKCTRL_ENABLE_bm;
  WriteToXOSC32KCTRLA(temp);
  
  /* Initialize RTC: */
  while (RTC.STATUS > 0) {
    ; /* Wait for all register to be synchronized */
  }

  /* 32.768kHz External Crystal Oscillator (XOSC32K) */
  RTC.CLKSEL = RTC_CLKSEL_TOSC32K_gc;

  /* Run in debug: enabled */
  RTC.DBGCTRL = RTC_DBGRUN_bm;
  
  RTC.PITINTCTRL = RTC_PI_bm; /* Periodic Interrupt: enabled */
  
  RTC.PITCTRLA = RTC_PERIOD_CYC32768_gc /* RTC Clock Cycles 32768 */
         | RTC_PITEN_bm; /* Enable: enabled */
}

// Interrupt called every second
ISR(RTC_PIT_vect) {
  RTC.PITINTFLAGS = RTC_PI_bm; 
  digitalWrite(Red_LED, !digitalRead(Red_LED));
}

void setup() {
  // put your setup code here, to run once:
  pinMode(Red_LED, OUTPUT);
  digitalWrite(Red_LED, LOW);
  // Don't leave unused pins floating
  for( int i = 0; i <= 15; i++ ) {
  pinMode(i, INPUT_PULLUP);
  }
  SleepSetup();
  RTCSetup();
}

void loop() {
  sleep_cpu();
}

Układ zapala i gasi diodę LED co jedną sekundę. Przy zgaszonej diodzie pobiera 1uA, co jest zgodne z oczekiwaniami.

 

Edytowano Listopad 5, 2021 przez pmochocki

[pmochocki]

Dnia 2.11.2021 o 23:34, pmochocki napisał:

Na tej stronie (jtag2updi.md) znalazłem dwa sposoby na zaprogramowanie nowych ATTiny. Jeden za pomocą konwertera USB-RS232 drugi za pomocą Arduino. Konwertery dopiero zamówiłem, a Arduino UNO znalazłem w piwnicy.

Konwertery dziś przyszły. Zgodnie z instrukcją na stronie (jtag2updi.md) wpiąłem diodę Schottkiego, a w Arduino IDE wybrałem SerialUPDI. Mimo dużej ilości czerwonego koloru w logach programowanie przebiegło pomyślnie:

No i to tyle dobrych wiadomości na dziś. Jako, że zegarek miał być na baterię CR2023 chciałem do wyświetlania zastosować e-papier (taki).
Jak skompilowałem bibliotekę pod swojego ATTiny z 8kB pamięci flash otrzymałem komunikat:

region `text' overflowed by 13134 bytes

E-papier chyba użyję gdy będę bawił się mikrokontrolerami z co najmniej 32kB flasha. Za to prosto z Chin przypłynie do mnie wyświetlacz EDC190. Koszt niecałe 10zł, za to brak jakiegokolwiek sterownika. Jestem ciekaw ile osób z tego forum bawiło się takim lub podobnym LCD sterując każdy segment samodzielnie... Planuje użyć czterech 74HC595. Ciekawe jak to wpłynie na pobór prądu mając na uwadze konieczność przełączania, aby nie uszkodzić wyświetlacza.

 

 

[_LM_]

Mam pytanko co do tego i papieru. Pisałeś sam dla niego libsa? Kiedyś kompilowałem program na atMege32 i problemem nie był flash tylko za mało ramu. Wiem że dużo można było zaoszczędzić gdy wyrzuciło się niepotrzebne grafiki i czcionki oraz niektóre funkcje. W sumie ten wyświetlacz nadal nie jest u mnie wykorzystany, jednak mam zamiar połączyć go z esp - 07 jako biurkowy termometr i rozwinąć projekt 

Co powinno dać zadowalające wyniki 🙂

[pmochocki]

9 godzin temu, _LM_ napisał:

Kiedyś kompilowałem program na atMege32 i problemem nie był flash tylko za mało ramu. Wiem że dużo można było zaoszczędzić gdy wyrzuciło się niepotrzebne grafiki i czcionki oraz niektóre funkcje.

Odchudzając bibliotekę i przykłady mogę zejść z użyciem flesha o 1/3. Więc gdybym miał 16kB to bym podjął walkę i pewnie natknął się na problem RAMu. 😀

Jak się domyślasz jest to projekt w którym chodzi o łapanie króliczka, a nie o złapanie króliczka. Nie mogę się doczekać kiedy przyjdzie LCD.