[TadeuszZ]

Witam,
znalazłem taki projekt: https://www.youtube.com/watch?v=5qVzMdR0zOA
chciałbym go zrealizować, zamówiłem już wszystko co mi będzie potrzebne do niego, od strony
montażu to nie jest problem, ale z zaprogramowaniem, to znaczy z przeniesieniem gotowego wsadu do procka mam problem, proszę o jakieś wskazówki, jak się za to zabrać, będę wdzięczny za pomoc.

https://github.com/andyhighnumber/Attiny...tinyArcade

https://raw.githubusercontent.com/andyhi...Attiny.png

[semi]

Zerknąłem na źródła i według mnie rozwiązanie

Kod:

audio = digitalRead(inputPin); // What is the tone decoder doing?
     if (audio) {
        keyIsDown();
        while(audio) {
          beep(50,250);
          audio = digitalRead(inputPin);
        }

(chodzi o while) dyskwalifikuje ten kod. podobnych "kwiatków" jest więcej

Kod:

while(digitalRead(0) == HIGH) {

Upychanie na siłę kodu w mały uC może mieć sens, gdy chcesz produkować urządzenie w dużych ilościach, jak, nie to  po co się męczyć?
Nie analizowałem w jaki sposób uczy się program czasów, jak będę miał chwilową przerwę w pracy to przyjrzę się co kryje kod (jakie jeszcze "kwiatki).


Zrobiłem podobny dekoder. Potrafi dekodować sygnał do 100 WPM a czasy mogą znacznie odbiegać od normy. Ze względu na to, że zdekodowane informacje wyświetlane są na kolorowym LCD 320x240 wykorzystałem KA-NUCLEO-F411CE (z STM32F411CE taktowanym 96MHz). Parę fotek, filmów,  HEX, BIN i schemat: http://es2.noip.pl/pic/mors/
Program do KA-NUCLEO wgrywa się kopiując plik BIN (np przeciągając ikonę) do urządzenia tworzonego przez programator. KA-NUCLEO kosztuje prawie dwa razy mniej niż oryginalne UNO a zawiera poza szybkim uC z 512kB FLASH i 128kB RAM (UNO ma 64 razy mniej! Całe 2kB ), programator/debuger. Jak taką "rakietę" można kupić za mniej niż 50zł, to nie ma sensu bawić się w UNO.

[Jarewa0606]

fajne sa delay(); na poziomach 1,5s

[semi]

fajne sa delay();  na poziomach 1,5s

Szkoda czasu na analize kodu. Po tym jak zobaczyłem

Kod:

void setup() {
  DDRB = 0b00000010;    // set PB1 as output (for the speaker)
  PCMSK = 0b00000001; // pin change mask: listen to portb bit 1
  GIMSK |= 0b00100000;  // enable PCINT interrupt
  sei();          // enable all interrupts
}

to stwierdziłem, że autor kodu nie wie, ze przerwania włącza Arduinolib, bo niby jak działa millis?
while( ), delay.  Kolejne "kwiatki"

Kod:

int stopRunning = 0;
...
ISR(PCINT0_vect){ // PB0 pin button interrupt         
  stopRunning = 1; // stop the programme :)
}

Po co int? gdzie volatile?
Kod niewart uwagi.

W kodzie, który napisałem, dekodowanie odbywa się na przerwaniach. W pętli głównej tylko odczytuje się zkeodowane znaki z bufora. Na przerwaniach mierzone są czasy sygnału i pauz i zapisywane w buforze. Algorytm analizuje je i dostosowuje czasy do nadawcy. Dzieje się to on-line, dzięki czemu gdy zmienia się tempo nadawania czy np tylko czas pauz, algorytm dostosowuje się na bieżąco do nowych parametrów. Wykrywane są przerwy nie tylko pomiędzy znakami ale także pomiędzy wyrazami.

Można się zastanawiać, jak zmieściłem bufor LCD w 128kB RAM. Z obliczeń wynika, że potrzeba 153kB 9320x240x2). W RAM trzymam dane o pikselach 8-bit (76kB). Ze względu na to, że DMA nie może "w locie" transkodować danych z 8 na 16-bit a użycie przerwań zbyt bardzo obciążałoby CPU, użyłem RTOS. Jeden task zajmuje się transmisją danych, dlatego jest ona przerywana przez inne taski. Spowalnia to niego wysyłanie danych ale nie widać "rysowania" czcionek. Oo takich bajerach na Arduino można zapomnieć.

[TadeuszZ]

Czy byli byście w stanie przerobić ten kod tak, żebym mógł go w eclipsie otworzyć, i wrzucić np. do attimy85, lub
czegoś większego, np atmega328?
podoba mi się jak to z tym kluczem działa i tym małym wyświetlaczem.
Jak by nie było klucz już mi przyszedł, jeszcze na wyświetlacz czekam.

[semi]

Czy byli byście w stanie przerobić ten kod tak, żebym mógł go w eclipsie otworzyć, i wrzucić np. do attimy85, lub
czegoś większego, np atmega328?
podoba mi się jak to z tym kluczem działa i tym małym wyświetlaczem.
Jak by nie było klucz już mi przyszedł, jeszcze na wyświetlacz czekam.

Z pewnością wiele osób na tym forum może poprawić kod ale to wymaga czasu i wątpię, czy znajdzie się ktoś, co za free to zrobi, tym bardziej, że nie jest to zajęcie na godzinę czy dwie. Nawet jeśli były by to dwie godziny, to wole zająć się czymś innym.
Osobiście, jak miałbym przerabiać kod na powolnego, drogiego mega328 to wolałbym użyć tańszego, szybszego ARM.

[Jarewa0606]

attiny słabo do tego się nadaje dlatego kod jest taki jaki jest bo dostepne tylko PCINT, już lepiej wygląda atmega328 timer2 w trybie ICP to co kolega wyżej pisał "Na przerwaniach mierzone są czasy sygnału i pauz i zapisywane w buforze"

[semi]

timer2 w trybie ICP  to co kolega wyżej pisał  "Na przerwaniach mierzone są czasy sygnału i pauz i zapisywane w buforze"

Tyle, że ICP nie nadaje się do tego, chyba, że sprzętowo rozwiąże się problem drżenia styków.

Wracając do Tiny85, to taka sztuka dla sztuki niczym w zeszłym tysiącleciu dema na C-64, "Szmatari". Niczemu nie służą tylko pokazaniu co można wycisnąc z komputera.
Tyny85 w TME kosztuje od 4,4zł w górę natomiast STM32G030 od 2,8zł https://www.tme.eu/pl/details/stm32g030j...ectronics/
Porównywanie "Trabanta" do "Ferrari" nie ma sensu ale w przeciwieństwie do samochodów "Ferrari" jest tańsze o 30% niż "Trabant"!
Teraz chyba nikogo nie dziwi, ze w wycenach projekt na AVR jest droższy niż na ARM. To co bez problemu można zrobić na ARM, w przypadku AVR wymaga "gimnastyki", sztuczek, liczenia cykli, każdego bajtu RAM.


Rodzina STM32G0, chciał nie chciał, doprowadzi do upadku architektury AVR! Kiedy to nastąpi? Nie wiadomo ale wystarczy przeczytać tematy zakładane na Elektrodzie. Jeszcze kilka lat temu głównie były to tematy dotyczące AVR, teraz to STM32. Naturalnie, można na siłę udowadniać, że AVR długo jeszcze będzie używany ale to jak stwierdzić, że 8051 żyje, bo chiny nadal go używają 
Co mądrzejsze firmy, naturalnie za moim pośrednictwem, wycofują się z AVR na rzecz ARM. Nowe wersje urządzeń modyfikuję na STM32 co wynika z niższych kosztów produktu oraz zapewnia mu wsparcie na długie lata. AVR owszem, będzie długo produkowany ale ceny będą rosnąc, asortyment układów będzie się zmniejszał, co w przypadku niektórych układów wywinduje ceny, jak niegdyś 8051.

[elvis]

A tak ze zwykłej ciekawości zapytam - skoro F0 jest już dość długo dostępny i jakoś nie doprowadził do wycofania AVR, to co takiego ma w sobie G0 że "doprowadzi do upadku architektury AVR" ?

[semi]

A tak ze zwykłej ciekawości zapytam - skoro F0 jest już dość długo dostępny i jakoś nie doprowadził do wycofania AVR, to co takiego ma w sobie G0 że "doprowadzi do upadku architektury AVR" ?

Cenę!
Nowy projekt zrobisz na drogim AVR, na którego kod pisze się dłużej więc trzeba za niego więcej zapłacić czy na ARM?

Gdybym zlecił Ci wykonanie urządzenia, co byś wybrał? AVR czy ARM? Tylko nie szukaj na siłę założeń w rodzaju zasilanie z baterii 4,1V.