SNARK BAKER – modyfikacja kodu celem wprowadzenia komunikacji z SPI

Część

Przymierzam się do budowy SNARK BAKERA - kopi SB 1.0. Mam ściągnięty z GitHuba wsad do DSP1321 czyli uC 8051 przekonwertowany z hex na Asembler oraz z Asemblera na C

Do czego zmierzam?
Zamierzam za 8051 dać 89S8252 i chodzi o zmodyfikowanie kodu tak aby zamiast wysłać dane portem P1 do DAC wysłać i odbierać dane po SPI od/do VS1063( sprzętowy dekoder MP3 , WAV, WMV itd. z DAC 16 bit). Do portu P1 w oryginale podłączony jest zewnętrzny 8 bitowy DAC.
Jeszcze jedno , 89S8252 ma 4 linie a VS1063 aż 6 linii SPI ,wobec czego linie SPI należy podłączyć tak?

MOIS z SI
MISO-S0
SCK-SCK
SS z XCS czy XDCS ?
DREQUEST z DREQ?
RESET z XRESET?

Poniżej oryginalny kod z DSP1321

Jeśli był by ktoś wstanie wprowadzić zmiany w kodzie od DSP1321 i wprowadzić komunikację SPI to było by super.

Pozdrawiam

Zapomniałeś jeszcze o tym, że w VS1063 należy skonfigurować wewnętrzne rejestry aby w ogóle działał. Jest takie powiedzenie "mierz siły na zamiary", dlatego trzymam kciuki i czekam na feedback. Daj znać jak Ci poszło to przeprogramowywanie.

Zamiast "konwertować" kod maszynowy zmień ten procesor na coś bardziej współczesnego (ARM) i przepisz software - przynajmniej jakiś projekt

oscil1 napisał:

Zamiast "konwertować" kod maszynowy

+1

Brzydkie to jak cholera, i nie ma żadnych cech "wysokopoziomowych", w tym merytorycznie nazwanych funkcji, stałych itd.
Prawdopodobnie nadwyżka "fałszywych" funkcji nie występujących w oryginalnym kodzie źródłowym (oczywisty efekt disasemblacji)
To się nie nadaje do zrozumienia "co poeta miał na myśli" a to warunek by odwzorować tę samą logikę na zupełnie odmienną platformę.

Tak jak zawsze wygląda wyjście z jakiegoś disasemblera

JacekCz napisał:

oscil1 napisał:

Zamiast "konwertować" kod maszynowy

+1

Brzydkie to jak cholera, i nie ma żadnych cech "wysokopoziomowych", w tym merytorycznie nazwanych funkcji, stałych itd.
Prawdopodobnie nadwyżka "fałszywych" funkcji nie występujących w oryginalnym kodzie źródłowym (oczywisty efekt disasemblacji)
To się nie nadaje do zrozumienia "co poeta miał na myśli" a to warunek by odwzorować tę samą logikę na zupełnie odmienną platformę.

Tak jak zawsze wygląda wyjście z jakiegoś disasemblera

Składniowo to i jest poprawny ale dał by zancznie większy plik niż plik w asemblerze. O C to można w tym przypadku zapomnieć - jak zauważył na triodzie atom1477 prawdopodobnie oryginalny kod został napisany jako krytyczny czasowo i musi być cycle-accurate.


No więc dzisiaj skorzystałem z pomocy ChatGPT i mam prawie gotowy plik asemblerze 51 jutro jak odświeży mi się tylko limit na analizę danych to dołożę konfigurację VS1063(taką jak bitrate , konfiguracja DREQ itd.) Prezentacja samej karty będzie w osobnym temacie

No więc mam już kod z dodaną pełną obsługę VS1063 wraz z obsługą komend tekstowych , EQ , Presety EQ , Volume , Bass i Treble , Ballance , I2C z AT89S8253 przez SPI ( sterowanie potencjometrami cyfrowymi- VS1063 ma I2C ale tylko do obsługi external DAC) , sterowanie przekaźnikami realizującymi wyciszenie wejść .
Poniżej w pełni kompilujący się kod - kompilacja trwa mniej niż 1 sekundę . Po kompilacji uzyskuje HEX o wadze 16kB - bin waży ok, 6-7kB. Kod dostosowany do M-IDE for MSC-51. Oryginalny kod był pisany najpewniej w Kelly'm co skutkowało całą masą - ponad 1,3 tys błędów bowiem w oryginalnym kodzie np. adresy były w formacie w stylu 0x01 a M-IDE wymaga zapisu adresu w stylu 001H - MIDE akceptuje tylko zapis szesnastkowy adresu. Przy każdym innsym sposobie wywali błąd w stylu "Illegal constant" , przy takim zapisie z kolei " djnz Register_1B,Address_5D7 " M-IDE wywalał " symbol not define" . To wymagało nieml napisania kodu od nowa zgodnie z wymaganiami M-IDE gdyż M-IDE używa Native Asemblera .