AVR externe eeprom monitoren

Zoals gezegd: 'meekijken' kan niet. Een eeprom is een dom ding wat alleen doet wat je vraagt.
Je zult dus expliciet een read moeten sturen om de gewenste locatie(s) uit te lezen.
Met een multimaster systeem kan in die tijd de AVR niets met de bus doen omdat die bezet is...

Je kunt volgens mij ook gewoon met de schrijfacties van de AVR naar de EEPROM toe meeluisteren. Je emuleert dan gewoon een slave die op hetzelfde adres als de EEPROM zit, maar geen ACK/NACK genereert. (Sterker nog: die zou je óók mee moeten afvangen met je emulator, zodat je weet of een schrijfactie is geslaagd of niet.)

TS wil continu de inhoud bekijken, niet alleen schrijfacties...
Dat kan alleen als de AVR de eeprom uitleest (of een extra CPU)

zou hetgeen wat ik wil op een andere manier beter te realiseren zijn ?
technisch is het gewoon te doen, de snelheid waarmee het moet gebeuren is gewoon heel laag.
moeilijkste is het houden van overzicht.

edit: niet gezien dat arco gepost had, bij een extra cpu moet je regelmatig de volledige eprom uitlezen en dan nog ergens weergeven.

[Bericht gewijzigd door trix op (25%)]

TS wil continu de inhoud bekijken, niet alleen schrijfacties...
Dat kan alleen als de AVR de eeprom uitleest (of een extra CPU)

Vroeger had je daar z.g. dual port geheugens voor. Daar kon je tegelijkertijd met twee verschillende cpu systemen in een geheugen lezen en schrijven. Het waren prijzige systemen die alleen voor speciale toepassingen gebruikt werden. Hoe ze het oplosten als er op hetzelfde moment op hetzelfde bit gelezen en geschreven moest worden weet ik niet. Misschien hadden ze een voorangschakeling ofzo.

Ik denk alleen niet dat de TS dit bedoelt. Ik denk dat de ts misschien een soort van monitor programma waarmee je stap voor stap door het het asssembly programma kunt lopen wil gebruiken. Vroeger veel mee gewerkt. En dat werkt erg handig. O.a. de microprofessor en eurocom computertjes hadden iets dergelijks.

Motorola had het background debugging systeem. Daar was het in hardware in de chip gebakken. Dat werkte pas echt leuk. Die HC11 cpu waren wat dat betreft echt superleuk.

Ik denk alleen dat dit soort van dingen met seriële e(e)proms moeizaam en traag gaan werken. Bij bijvoorbeeld de microprofessor werd dan elke opcode naar een ander stuk geheugen gecopieerd en in onder een interupt uitgevoerd. Alle registers werde dan ook gewoon heen en terug gecopieerd en zichtbaar gemaakt op het 7 segments display schermpje. Bij de z-80 werd natuurlijk heen en weer geschakeld tussen de gewone en de schaduw registers. Het werkte erg leuk. In een gewone geheugen-cpu omgeving is dit goed te doen. Met een serieel geheugen kan dit natuurlijk ook maar dan is wel een stuk lastiger programmaatje nodig dat ook nog eens niet echt snel kan zijn.

In plaats van maar een paar simpele opcodes te executeren om 1 stap te doen in je programma moet je een heel i2c of spi comunicatie programma doorlopen. En dat kost je gewoon meer tijd.

Ik denk dat je makkelijker naar een emulator kunt uitkijken en die gebruiken.

bij een extra cpu moet je regelmatig de volledige eprom uitlezen en dan nog ergens weergeven.

Dat moet je toch altijd als je de inhoud monitort? Je zegt zelf dat je continu de inhoud wilt bekijken. Dan moet je het toch ergens weergeven of verwerken???

wat is de reden dat je dit wilt als ik vragen mag?
Een eeprom is niet gemaakt om heel vaak hele bakken met data naar toe te schrijven.
Wat je ook kunt doen is een hook functie maken die de write functie van je eeprom vervangt door een print van adres en data naar de uart.
Dan kun je in C# bijvoorbeeld makkelijk een view van je eeprom maken (soort eeprom simulator), als het je toch puur om de data layout gaat

hieronder een v.b. van zo'n matrix, de letter P. (geen 300x300 maar het gaat om het v.b.).

die P wil ik later na tekenen.

voor ik aan die P kom moet ik wat gaan filteren, dus b.v.
een 1 omgeven met 8x een 0 = een 1

000
010
000

als die P eenmaal "strak" is wil ik hem dus natekenen.
dit vergt vooral overzicht v/h totaal.

het hoeft trouwens niet met een eprom, het gaat mij er over hoe ik mijn doel bereik.

Ik begrijp nog steeds de bedoeling niet goed. Als je alleen wilt 'natekenen', kun je toch gewoon de hele bitmap uitsturen?
(je hoeft niet eens te weten wat erin staat)

waar stuur ik die dan naar toe ? uiteindelijk zal het toch iets moeten worden met step/dir (stappenmotor of servo)

dat natekenen is met een viltstift op een papieren blad.
daarnaast wil ik ook nog wat instellingen kunnen doen b.v.:
de lijnen wat dikker. de hele P wat naar boven.

Het zou al schelen als je duidelijk uitlegt wat de uiteindelijke bedoeling is... ;)
(er komt steeds meer bij, nu weer een stappenmotor. Wat moet die doen?)

net edit gedaan.

Je wilt dus eigenlijk de plotter opnieuw uitvinden...
Da's niet zo simpel, daar moet je minstens 3 stappenmotors voor aansturen. (X,Y, en pen up/down)
Zoiets: http://www.arnabkumardas.com/topics/cnc/how-to-make-an-arduino-drawing…

zo ongeveer ja, maar dan alleen X & Y. geen schuine lijnen, of creatieve krullen. echt zo abstract als die letter P.

neem die link vanavond even door, ik moet nu weg, gaan oberen bij mijn moeder die is jarig en word 83 en dan zorg ik er voor dat iedereen zijn kofie en gebak heeft en de afwas word gedaan. dat kunnen ze zelf niet meer te hectisch......het is wel gezellig en leuk,..maar van een dag gewoon werken word je lang niet zo moe ;)

arco, bedankt voor de inzet

zo ongeveer ja, maar dan alleen X & Y. geen schuine lijnen, of creatieve krullen. echt zo abstract als die letter P.

En nu komt eindelijk de aap uit de mouw. Ooit zoiets gemaakt met een eurocom computertje. En naderhand met de microprofessor omdat die eurocom te weinig geheugen had. Ik kon alle letters maken met rondingen er in. Eerst gebruikte ik een berekening die met de sinusfunctie de rondingen uitrekende. Later vanwege geheugen problemen een sinustabel geloof ik. Ik programmeerde niet zo efficiënt denk ik. Wel alles in assembly natuurlijk.

Maar het werkte wel.

De TS wil met bitmaps werken begrijp ik. Hmm vraag me af dat handig is. Een plotter zet lijnen van een bepaalde lengte op een bepaalde plek. Je zult dan een bitmap moeten gaan omzetten naar een soort van lijn-map of vectortabel? Kun je niet beter zelf een karakterset definieren die zegt welke lijn waar moet komen? Dat lijkt mij een stuk makkelijker.

Verder begrijp ik je verhaal over het hele geheugen in een keer lezen niet zo erg. Wil je het geheugen benaderen zoals een mens een symbool op een stuk papier ziet? In 1 keer dus? Dat gaat niet zomaar met de gewone technieken. Dan zul je van zoiets als een transputer gebruik moeten gaan maken. Bestaat de transputer eigenlijk nog wel? Maar dat is allemaal nergens voor nodig. Je moet het probleem opdelen in stukken en die apart analyseren en daar een programmeeroplossing voor bedenken.

Met alleen rechtlijnige bitmaps is het vrij simpel te doen.
Je scant de bitmap per regel tot je een '1' tegenkomt. Da's het begin. Dan verder scannen tot je een '0' tegenkomt, da's het eind.
Dan x stepper naar beginpos, pen laten zakken, en naar eindpos, pen weer omhoog.
Zo alle regels af en daarna de kolommen en Y stepper...
Niet het meest efficiente, maar voor simpele tekeningen voldoet het wel...

Op 9 april 2019 10:27:02 schreef Ex-fietser:
[...]
Wil je het geheugen benaderen zoals een mens een symbool op een stuk papier ziet? In 1 keer dus?

dat was het idee eigenlijk, dat geeft overzicht.

het voorstel van arco heeft als nadeel dat je een verticale lijn opbouwd met allemaal horizontale lijntjes.

een probleem is dat in de AVR met bytes worde gewerkt b.v. in een array, en ik wil eigenlijk met losse bits werken.

even hardop denken voor een stappenplan:

- ik ga de matrix op delen in rijen en kolommen.
- losse/ verdwaalde bits weg filteren.
- scannen (van links naar rechts en boven naar beneden) tot dat je een 1
ziet deze X,Y pos. onthouden tot je een 0 ziet, weer X,Y pos. onthouden.
- de volgende rij geeft dan hetzelfde resultaat met de Y pos. 1 lager enz.
- scannen tot dat het boven genoemde patroon wijzigt = einde hor. lijn
- vervolgens de opgegeven instellingen er op los laten (dikker lijn, tot.
lijn 1 cm, hoger).
- teken volgorde bepalen (om transport te minimaliseren)
- als laatste de stepper/servo aansturen

het voorstel van arco heeft als nadeel dat je een verticale lijn opbouwd met allemaal horizontale lijntjes.

???
Je trekt een vertikale lijn van de eerste '1' tot de laatste '1' in een kolom, niks horizontale lijntjes...

in dat geval word de horizontale lijn met vertikale lijntjes op gebouwd :).

...
een probleem is dat in de AVR met bytes worde gewerkt b.v. in een array, en ik wil eigenlijk met losse bits werken.
...

Dit is heel goed mogelijk met Arduino/C++ je kunt de bits in een byte een waarde geven door bits te flippen of door een specifieke (hexa)decimale waarde toe te kennen die overeen komt met het bitpatroon.

Voor bitflipping kun je hier eens kijken (specifiek naar de XOR functie maar andere bit-wise operators kunnen ook worden gebruikt):
https://stackoverflow.com/questions/19617248/how-to-flip-a-specific-bi…

Verder zoals eerder aangegeven lijkt het me makkelijker om met lijnen te werken, je wilt toch geen rondingen enz gaan verwerken in je karakters. Waarom niet gewoon lijnen / vectors opslaan, hiervoor heb je in jou geval 8 bytes nodig per lijn start X positie (2 bytes want 300pixels > 256) start y positie, stop x positie, stop y positie. Eventueel kun je ook nog een lijndikte specificeren dan kom je op 9 bytes per lijn.

[Bericht gewijzigd door NarwhalLeo op (27%)]

in dat geval word de horizontale lijn met vertikale lijntjes op gebouwd :).

Geen idee wat je bedoelt.
Een horizontale lijn is een horizontale, en een vertikale een vertikale. Niks vertikale lijntjes in horizontale lijn...

ik dacht dat je bedoelde om de de volledige letter P te tekenen met alleen verticale bewegingen, bij vert. lijnen worden dat lange lijnen natuurlijk, maar bij de hor. lijnen worden dat dan allemaal vert. lijntjes naast elkaar.

maar je bedoelde natuurlijk de letter P tekenen met hor. & vert. bewegingen.

verkeerd geinterpeteerd van mijn zijde, sorry voor het misverstand.

Op 12 april 2019 16:02:06 schreef NarwhalLeo:
[...]
Verder zoals eerder aangegeven lijkt het me makkelijker om met lijnen te werken, je wilt toch geen rondingen enz gaan verwerken in je karakters. Waarom niet gewoon lijnen / vectors opslaan, hiervoor heb je in jou geval 8 bytes nodig per lijn start X positie (2 bytes want 300pixels > 256) start y positie, stop x positie, stop y positie. Eventueel kun je ook nog een lijndikte specificeren dan kom je op 9 bytes per lijn.

zoiets inderdaad, maar daar zitten nog wat stappen voor, het bepalen waar die X,Y pos. b.v. is.
er is een methode in C om in een 2D array te werken met losse bits.

http://www.mathcs.emory.edu/~cheung/Courses/255/Syllabus/1-C-intro/bit…

Heb je wel eens een Logic Analyser geprobeerd?

Tegenwoordig kun je voor < EUR10 een logic analyser kopen met 8 kanalen die uitermate geschikt is om allerlij seriele protocollen (I2C, SPI, UART, enzo) te bestuderen. Je kunt niet alleen de data bekijken, maar met Sigrok / Pulseview kun je ook hele protocollen decoderen. Bij I2C EEprommetjes kan hij bevoorbeeld adressen en data uit elkaar halen, en lees en schrijf opdrachten van elkaar onderscheiden. Ook situaties die niet in overeenstemming zijn met het geselecteerde protocol worden vaak herkend en deze fouten worden dan in rood weergegeven. Erg handig! Op het moment ondersteunt Sigrok ongeveer 100 verschillende protocollen, en bijna elke maand komt er wel eentje bij.

Deze hardware werkt dan samen met Sigrok / Pulseview. Dit is Open Source software en daarmee dus ook niet duur :)

Sigrok werkt met best veel verschillende hardware:
https://www.sigrok.org/wiki/Supported_hardware

Voor beginners wil ik aanraden om op Ebay / Ali / China hardware te kopen die luistert naar de string "24MHZ 8ch"
https://www.aliexpress.com/wholesale?SearchText="24MHz+8ch"

Ik ben van mening dat zo'n logic analyser een vast onderdeel zou moeten zijn van elk "arduino" starters pakket. Ik heb zelf ook een Rigol oscilloscoop, maar als ik met microcontrollers bezig ben maak ik meer gebruik van mijn EUR7 Logic Analyser dan van mijn EUR300 Oscilloscoop!

nee nog niet geprobeerd, staat wel op mijn verlang lijstje. me eens een keer in verdiepen.

Als er firmware bestaat om bitmaps te tekenen, is het simpel om een 'echte' bitmapfile ervan te maken (alleen header en color table toevoegen)
Kans dat er al eens iets voor is gemaakt is voor echte .BMP files denk ik groter...