Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

HEX BIN edytor do komórek 16bitowych, pamięć 27C1024

Andrzej L. 11 Kwi 2016 13:02 918 7
  • #1 11 Kwi 2016 13:02
    Andrzej L.
    Poziom 26  

    Pamięć 27C1024 ma organizację komórek 16bitową (2 Bajty każda komórka).
    Większość edytorów pracuje na słowach 8 bitowych.
    Edytor dołączony do oprogramowania programatorów Wellon
    http://www.programatory.com/index.php?d=aktualnosci
    jest mizerny, bo umożliwia edycję w danym momencie tylko jednej komórki, nie da się hurtowo tam podmienić n-komórek. Trzeba klepać jedną po drugiej - kolejno.
    W edytorze http://mh-nexus.de/en/hxd/ jak sobie ustawię rozmiar grupy na
    2 Bajty to niestety każdą 2 Bajtową (16 bitową) "paczkę" program traktuje
    jako dwie osobne, kolejne komórki z osobnymi adresami i adresowanie w
    kolumnie jest ze skokiem
    n+2 zamiast poruszać się co 1 z adresowaniem.
    Podejrzewam, że utworzonego w ten sposób pliku wsadowe co druga komórka
    zostanie tylko zaprogramowana?
    Czy jest jakiś program, który bezproblemowo będzie pracował z komórkami 16
    bitów, komórka po komórce i umożliwi także hurtową ich edycję (bo np. dany
    ciąg wartości w n-kolejnych komórkach cyklicznie się powtarza).
    Gdzie znajdę dobrą rozprawkę na temat plików wsadowych *.BIN, bo jak widzę w gołym notatniku nie da się tego za bardzo edytować, bo widać kwadraciki i i inne krzaczki. Tworzenie zaś ręczne plików HEX też jest dość kłopotliwe, bo trzeba generować sumę kontrolną dla każdej linii.

    0 7
  • #3 11 Kwi 2016 20:27
    ALIBABA I
    Poziom 22  

    Jest tez takie coś jak, 010 Editor , dalej binary Vewer

    0
  • #4 15 Kwi 2016 14:48
    Andrzej L.
    Poziom 26  

    Czy ten HEXEDITOR to jest http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm?
    Kolejne propozycje 010 Editor i binary Viewer nie uruchamiają się w xp 64bit. Sprawdzone zarówno wersji 32 i 64bit instalek oraz wersje portable.
    Wskazany program, z którego korzystam HxD ma tą wadę, że przy scaleniu dwóch komórek aby otrzymać słowa 16 bitowe zapisuje je potem tak, że mniej znaczące bity słowa (pierwsze osiem licząc od "prawej" do "lewej" strony słowa) zamiast wylądować w komórce o niższym adresie lądują w komórce o wyższym adresie i potem w oprogramowaniu programatora zamiast słów 16bitowych np. ABCD
    otrzymuje się komórki 16bitowe z zapisem CDAB. I nie ma tam hurtowego narzędzia aby odwrócić 16bitowe komórki. Trzeba by było od razu klepać odwrócone wsady.
    Narzędzie do odwracania "Swap 16bit" zawarte w edytorze bufora programatora Wellon ma jakiś problem, bo potem dziwnym trafem jedna z komórek z 65536 w programowaniu "odwróconym" w buforze wsadzie dostaje inną zawartość niż by to wynikało z podglądu "odwróconego" bufora.
    I przy programowaniu odwróconego w locie wsadu dostaję:
    Device Address:0000C033H Device Data:A480H Buffer Address:00018066H Buffer Data:90A4H
    Sprawdzone na kilku kostkach, także przy innym "odwracanym" w locie wsadzie też ta sama komórka. Ta sama komórka C033H przy zapisie całej pamięci samymi zerami nie ma żadnych problemów i pięknie się programuje. Wynika więc, że coś kuleje w narzędziu odwracającym kolejność paczek 8 bitowych.

    0
  • #6 16 Kwi 2016 13:28
    Andrzej L.
    Poziom 26  

    Zawartości komórek mają mieć następujące odwrócenie, np:

    C0B0 odwrócone ma być na B0C0
    C099 na 99C0
    C092 na 92C0
    C082 na 82C0
    C0F8 na F8C0
    C080 na 80C0

    Czyli młodsze Bajty (z paczki dwóch Bajtów, komórka 16bitowa) tutaj fizycznie, w projekcie są to w hex Bajty: B0, 99, 92, 82, F8 80 i to one podglądane w edytorze hex jako paczki 8bitowe mają lądować pod niższym adresem niż bardziej znaczące bity z Bajtu hex: C0

    W ogóle widzę, że coś jest nie halo w samej linii błędu programatora, przy weryfikacji zaprogramowanej przed chwilą pamięci.
    Device Address:0000C033H Device Data:F990H Buffer Address:00018066H Buffer Data:C0B0H

    Nie wiem skąd tam się bierze adres 18066H skoro adresowanie 27c1024 kończy się na FFFFH - czyli łącznie 65536 komórek.
    A błąd stwierdza, że bufor ma bałagan na 98406 komórce.
    Czyli jakaś wirtualna komórka z kosmosu nie będąca fizycznie we wskazanej kości.
    Czy możesz potwierdzić poprawność wygenerowanego pliku BIN, z którego programuję? Bo może jakiś bubel jest w samym pliku i programator głupieje? Sam plik po załadowaniu do programatora, podglądy w buforze nie budzi żadnych zastrzeżeń.
    plik BIN z nazwą "27c1024_nieodwrocone" ładuję do programatora. Tam robię operację Show 16bit aby mi wyświetlał scalone bloki 16bitowe, następnie robię Swap 16bit i z tak zmodyfikowanego bufora programuję.
    Zapisany bufor po odwróceniu paczek 8bitowych to plik "27c1024_odwrocone".
    Co ciekawe sama weryfikacja poprawności programowania zgłasza tylko jeden wskazany błąd dotyczący komórki 0000C033H
    Ale już funkcja Compare (czyli porównanie bufora z tym co jest wgrane do kości zgłasza już tysiące błędów i oczywiście adresy z kosmosu spoza puli kości 27c1024.
    Na ten moment podejrzewam, że coś jest skopane w oprogramowaniu producenta programatora (?)
    Na tej samej zasadzie jak się bawię dużo mniejszą pamięcią typu 27c64 (z tą różnicą, że ta to typowa pamięć z typową organizacją komórek po jednym Bajcie) i zmienię ręcznie zawartość jednego z bitu w buforze, to weryfikacja oraz porównanie (Compare) zgłasza prawidłowo błąd dotyczący tylko tej jednej zmodyfikowanej ręcznie komórki, adresy są prawidłowe i nic nie generuje kosmicznych adresowań.

    0
  • #7 16 Kwi 2016 13:42
    11111olo
    Poziom 43  

    Andrzej L. napisał:
    W ogóle widzę, że coś jest nie halo w samej linii błędu programatora

    W ogóle to nie wiem o czym piszesz.
    Andrzej L. napisał:
    Nie wiem skąd tam się bierze adres 18066H skoro adresowanie 27c1024 kończy się na FFFFH - czyli łącznie 65536 komórek.

    Pamięć kończy się na 1FFFF.
    Andrzej L. napisał:
    Czyli jakaś wirtualna komórka z kosmosu nie będąca fizycznie we wskazanej kości.

    Oczywiście taka komórka jest.

    Jak masz 4GB ramu w komputerze to tyle go jest i nie ma znaczenia czy będziesz odczytywał ośmiobitowo, szesnastobitowo, trzydziestodwubitowo... itd.

    Andrzej L. napisał:
    Sam plik po załadowaniu do programatora, podglądy w buforze nie budzi żadnych zastrzeżeń.

    A czemu miałby budzić zastrzeżenia?
    Andrzej L. napisał:
    Tam robię operację Show 16bit aby mi wyświetlał scalone bloki 16bitowe, następnie robię Swap 16bit i z tak zmodyfikowanego bufora programuję.

    Pytanie brzmi PO CO?
    Andrzej L. napisał:
    Na ten moment podejrzewam, że coś jest skopane w oprogramowaniu producenta programatora (?)

    Zawsze winny jest programator a nie użytkownik, ech...
    Andrzej L. napisał:
    Na tej samej zasadzie jak się bawię dużo mniejszą pamięcią typu 27c64 i zmienię ręcznie zawartość jednego z bitu w buforze, to weryfikacja oraz porównanie (Compare) zgłasza prawidłowo błąd dotyczący tylko tej jednej zmodyfikowanej ręcznie komórki, adresy są prawidłowe i nic nie generuje kosmicznych adresowań.

    Ta kość ma 8kB i czyli max. 1FFF.

    0
  • #8 16 Kwi 2016 13:54
    Andrzej L.
    Poziom 26  

    Nie napisałem, że na pewno jest winny tylko, że podejrzewam, a to zmienia postać rzeczy, gdybam, bo nie wiem, a chciałbym znaleźć rozwiązanie. Jakbym wiedział to bym nie pytał, nie chodzi mi o przerzucanie się między wierszami epitetami: "nie wiesz? taki głupi jesteś?" tylko o konstruktywne rozwiązanie dla początkującego. Chcę zwyczajnie ustalić gdzie tkwi problem, uzyskać wyjaśnienie co robię źle i jak to ugryźć aby wyeliminować usterkę i błędy. Wytłumacz mi więc skąd te wysokie adresy znalazły się w logu błędu z programowania, gdzie komunikat jasno wskazuje, że informuje nas o bloku 2 Bajtowym (zapis np. F990H) a adres daleko wykracza poza osiągalny dla bloków 2Bajtowych, które to adresowanie w tym przypadku kończy się na FFFF (65536 komórek po 16bitów każda), bo więcej pamięci już nie ma.
    Czy mam rozumieć, że w samej strukturze jest organizacja Bitowa i tam w środku i adresów tam już musi być 2x więcej? Analogia do podglądu zawartości, który domyślnie zgłasza się jako bloki Bajtowe z adresowaniem do 1FFFF czyli "2x więcej adresów". Każda komórka 2 Bajtowa i tak jest wewnątrz tej kości rozbita na dwa osobne bloki 8 bitów, dla każdego bloku dostaje wtedy osobny "wewnętrzny" adres? Czyli np. pierwszy blok 16bit 0H zostaje rozbity wewnątrz na dwa adresowane jako 0H i 1H, a drugi blok 1H 16bit dostaje po rozbiciu wewnątrz 2H i 3H (?) Tylko nawet jak tak jest to użytkownika to powinno średnio interesować skoro tego nie może namacalnie stwierdzić, bo nie ma wglądu do struktury wewnętrznej i adresuje kość i tak zgodnie z tym co przedstawia dokument do pamięci. Ustaliłem, że dla użytkownika są tylko osiągalne komórki 2Bajtowe z tej kostki (?) - przynajmniej nic innego nie wyczytałem z dokumentacji tej pamięci i nie wiadomo mi aby była tam jakaś nóżka, którą można przełączyć tą pamięć na inną organizację komórek. Czyżby zaprogramowanie jej w jakiś bliżej nieustalony mi sposób będzie powodować, że adresowanie na 16 liniach adresowych tej pamięci nagle się nam zwiększy do 131072 komórek 8bitowych? Z obecnych 65536 16bitowych.
    Podejrzewam po części sam soft obsługujący programator, bo już zgłaszałem uwagę do dystrybutora odnośnie pracy tamtejszego edytora bufora i zostały ona przekazana do chińczyka. W ogóle zastanawia mnie, bo w bazie softu programatora kość 27c1024 produkcji AMD ma zdefiniowane napięcie Vcc = 4V co już budzi u mnie wątpliwości. Czemu 4V a nie 5V?
    Bajty odwracam bo założeniem było to, że młodsze bity z komórki 16bitowej mają się pojawiać przy odczycie tej pamięci na młodszych wyjściach danych układu - to rodzaj pewnej matrycy dekodującej. A że przy tworzeniu pliku łatwiej jest się posługiwać nieodwróconym zapisem stąd potem odwracam je hurtowo, bo plik tworzyłem "ręcznie". Dlatego pytałem o program, który od razu prawidłowo lokuje komórkę 16bitową w pamięci bez potrzeby odwracania, tak aby zawsze mniej znaczące bity lądowały we wcześniejszej komórce 8 bitowej niż pozostała bardziej znacząca część 8 bitów komórki - tak jak to jest opisywane w książkach. Gdzie mniej znaczące bity mają zawsze być pod młodszym adresem a starsze pod adresem n+1.
    Co do tego, że 27c64 ma 8KB i że adresowanie jej kończy się na 1FFF to ja nie miałem żadnych wątpliwości, stąd podałem ją jako przykład, że mniejsze pamięci, z typową organizacją komórek po 8bitów, nie sprawiają mi problemu. Problem mam ze wskazaną 27c1024, która jako jedna z niewielu ma komórki 16bitowe, które rzadko spotyka się w konstrukcjach domowych majsterkowiczów.

    0