byte opdelen en in verschillende registers stoppen (SED1531 aansturen met AVR)

Hoi allen!

Eeuwen geleden dat ik me hier nog eens getoond heb, maar gisteren kwam ik een aantal topics van CO tegen tijdens het googlen naar wat info over wat spulletjes, en begon het te kriebelen om hier terug wat actiever op te worden :)

Ik breng gelijk ook een vraagje voor jullie mee!

Ik ben de laatste dagen weer wat aan het spelen met 8-bit AVR's, om er wat ervaring mee op te doen (want persoonlijk vind ik dit nog een te groot gat in mijn kennisgebied, dat ik niet kan verantwoorden om in mijn sector actief te zijn...). Ik vond in de kast een LCD'tje zonder opschrift, maar waarvan ik me herinnerde dat ik het ooit op samenkopen.net (een site die ondertussen niet meer bestaat?) gekocht had.

Tijdens het googlen kwam ik deze thread op CO tegen, waarin blijkbaar ook een aantal CO'ers deze display op dezelfde samenkopen actie gekocht hadden! (Overigens is er voor de rest nauwelijks info te vinden op het net over deze display. Enkel nog een paar andere topics op dit forum).

De informatie die ik hier vond was goud waard, en ben meteen aan de slag gegaan met de library van Patrick de Zeester. Deze library gebruikte port B voor de datapins en een aantal pins van port D voor een aantal controlesignalen. Dit was een probleem, want op PB4 en PB5 hangt bij een atmega328p de externe klok... Geen probleem, gewoon even snel de defines omgewisseld: PortB zijn nu de controlesignalen, portD de datapins. Nu werkte het perfect! Zeer mooi en logisch opgebouwde library!

Maarrrr... nu komt het probleem! PD0 en PD1 zijn TX en RX voor U(S)ART. Deze hou ik uiteraard het liefst vrij, zodat ik het LCD ook in combinatie met een seriële verbinden kan gebruiken.

Geen probleem dacht ik, ik splits gewoon de data-byte op, en stuur de eerste 2 bits naar de eerste 2 pins van port C (dan moet er nie geklooid worden met bitshifts), en de laatste 6 blijven gewoon op portD staan, want die stoorden niets. (Alles op portC zetten ging niet omdat portC blijkbaar maar 7 pins heeft ipv. 8)
Het leek me dat dit vrij eenvoudig zou moeten zijn, maar helaas kreeg ik het niet werkend. Ik moet iets fout gedaan hebben, maar kan niet meteen vinden wat. Hopelijk kan een meer ervaren AVR-programmeur me in de juiste weg wijzen? :)

Dit was de beginsituatie die werkte (na het omwisselen van PortB en PortD):

c code:


#define GLCD_IO_DATA_OUTPUT(data)       PORTD = (data)
#define GLCD_IO_DATA_DIR_INPUT()        DDRD = 0x00;    
#define GLCD_IO_DATA_DIR_OUTPUT()       DDRD = 0xFF;

Dit is de aanpassing die ik geprobeerd heb:

c code:


#define GLCD_IO_DATA_OUTPUT(data) \
    {PORTD = ((PORTD & 0b00000011) | (data & 0b11111100));\
        PORTC = ((PORTC & 0b11111100) | (data & 0b00000011));}

#define GLCD_IO_DATA_DIR_INPUT()        {DDRD &= ~(0b11111100); DDRC &= ~(0b00000011);   }
#define GLCD_IO_DATA_DIR_OUTPUT()       {DDRD |= 0b11111100; DDRC |= 0b00000011;}

Helaas werkte dit niet. Ik dacht... Er hangt momenteel toch nog niets op de overige pins van portD en portC, dus laat ik de volledige byte eens gewoon op beide porten zetten? Dan MOET het toch wel werken?

c code:


#define GLCD_IO_DATA_OUTPUT(data)       PORTD = (data); PORTC = (data)
#define GLCD_IO_DATA_DIR_INPUT()        DDRD = 0x00;   \
                                                DDRC = 0x00  
#define GLCD_IO_DATA_DIR_OUTPUT()       DDRD = 0xFF;   \
                                                DDRC = 0xFF

Maar... Neen. Het werkte nog steeds niet? De LCD geeft geen kik. Wanneer ik het terug op de oorspronkelijke situatie zet werkt alles terug wel naar behoren, dus de LCD werkt wel nog steeds.

Ik vermoed dat ik ofwel gewoon iets fout doe met het herschrijven van de macro's, dat ik ervanuit ga dat iets op een bepaalde manier werkt, terwijl het niet zo is; OF dat er hardwarematig iets is dat ervoor zorgt dat het niet op deze manier kan werken.

Iemand die me in de juiste richting kan wijzen?

Alvast bedankt!

Groeten,
Opifex

ps. Het gaat om deze library: https://sourceforge.net/p/glcdsed1531lib/wiki/Home/ (geschreven door een CO'er die nog steeds hier actief is, zag ik net op zijn profiel :) )

Ik zou zoiets nooit met macros oplossen. Dan kun je allerlei onverwachte bij-effecten krijgen.

Maar in principe zou het wel moeten werken.

Probeer het anders eens met een echte funktie definitie:

code:


void GLCD_IO_DATA_OUTPUT(unsigned char data)
{  PORTD = ((PORTD & 0b00000011) | (data & 0b11111100));
   PORTC = ((PORTC & 0b11111100) | (data & 0b00000011));
}
 
void GLCD_IO_DATA_DIR_INPUT()
{  DDRD &= ~(0b11111100); 
   DDRC &= ~(0b00000011);
}

void GLCD_IO_DATA_DIR_OUTPUT()
{  DDRD |= 0b11111100;
   DDRC |= 0b00000011;
}
 

Ik ben zelf ook niet iemand die veel macro's gebruikt, maar omdat het in deze lib zo mooi en overzichtelijk in elkaar gestoken was met macro's, wou ik dat behouden.

Heb nu geprobeerd ze te vervangen met functies, zoals je beschreef, maar helaas. Het gedrag blijft.

Heb voor de zekerheid ook nog de oorspronkelijke (werkende) code ook omgezet naar functies, en daarbij werkt het wel.

Er is dus nog iets anders dat tegenwerkt...

Dit soort "het zou moeten werken" dingen zit vaak niet in datgene waar je denkt dat het zit. Voor zover ik kan zien: De code die je geeft zou moeten werken.

Je had als test toch gewoon de data naar beide poorten gestuurd? Als DIE code er in zit, werkt het dan als je de boel aansluit op gewoon de originele poort?

Dus de code:

code:


void GLCD_IO_DATA_OUTPUT(unsigned char data)
{  
  PORTD = PORTC = data;
}

De volgende test is dan om 1 voor 1 draadjes van de portD naar portC te verhuizen en te kijken waar het misgaat.

[Bericht gewijzigd door rew op 6 juni 2019 08:36:31 (12%)]

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
EricP

mét CE

Zonder ook maar iets van de rest van de source te kennen: je gefrutsel met macro's is eng.

Je begint met

c code:

#define GLCD_IO_DATA_OUTPUT(data)       PORTD = (data)

Daar maak je van

c code:

#define GLCD_IO_DATA_OUTPUT(data) \
    {PORTD = ((PORTD & 0b00000011) | (data & 0b11111100));\
        PORTC = ((PORTC & 0b11111100) | (data & 0b00000011));}

Stel nou eens dat je ergens in je source tegen komt

c code:

GLCD_
IO_DATA_OUTPUT(ietsMetData + ietsMetAndereData)

De pre-processor gaat dat netjes voor je verwerken. De compiler krijgt voor z'n kiezen

c code:

#define GLCD_IO_DATA_OUTPUT(data) \
    {PORTD = ((PORTD & 0b00000011) | (ietsMetData + ietsMetAndereData & 0b11111100));\
        PORTC = ((PORTC & 0b11111100) | (ietsMetData + ietsMetAndereData & 0b00000011));}

Dat gaat (meestal) wat anders opleveren! Ofwel: haakjes, haakjes en nog meer haakjes.

Waarom het met 'alles naar beide poorten' ff niet werkt... ff geen idee. Rew verwoordt het al heel mooi: ergens zal er iets de mist in gaan op een manier die je niet verwacht.

En dan toch te nieuwsgierig... En ff kijken wat meneer Zeester gebakken heeft. Ik kom daar een GLCD_IO_DATA_INPUT tegen - blijkbaar doet die lib ook reads van je LCD. Ook die zul je ff moeten aanpassen. Anders gaat het nooit werken natuurlijk...

Eric, er is een code tag niet goed gegaan. Fixed. Fijn. @eric hieronder: Oeps. Fijn dat je het ziet. :-) Suf dat het me lukt om in dezelfde post als dat ik jou op deze fout wijs precies dezelfde fout te maken. Oh well...

En dan nog even dit. Dat met de accolades dat werkt wel, maar niet voor 100%.

code:


if (something) 
  GLCD_IO_DATA_OUTPUT(data);
else 
  GLCD_IO_DATA_OUTPUT(data + 1);

dit is een normale constructie toch?

Maak je nu daar de

code:


#define GLCD_IO_DATA_OUTPUT(data) \
    {PORTD = ((PORTD & 0b00000011) | (data & 0b11111100));\
        PORTC = ((PORTC & 0b11111100) | (data & 0b00000011));}

definitie voor dan werkt het niet. Na de accolades binnen de if mag geen ; voor de else.

Dit werkt wel altijd:

code:


#define GLCD_IO_DATA_OUTPUT(data) \
    do {PORTD = ((PORTD & 0b00000011) | (data & 0b11111100));\
        PORTC = ((PORTC & 0b11111100) | (data & 0b00000011));} while (0)

[Bericht gewijzigd door rew op 6 juni 2019 18:04:44 (11%)]

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
EricP

mét CE

Op 6 juni 2019 11:22:39 schreef rew:
Eric, er is een code tag niet goed gegaan.

Fixed. En eh... bij jou ook niet :+

Op 6 juni 2019 08:35:43 schreef rew:
Dit soort "het zou moeten werken" dingen zit vaak niet in datgene waar je denkt dat het zit.

"Het zou moeten werken", is dat niet hegene wat elke programmeur zegt als zijn code niet werkt? :p

Je had als test toch gewoon de data naar beide poorten gestuurd? Als DIE code er in zit, werkt het dan als je de boel aansluit op gewoon de originele poort?

De volgende test is dan om 1 voor 1 draadjes van de portD naar portC te verhuizen en te kijken waar het misgaat.

Verdorie! Waarom heb ik hier niet eerder aan gedacht?!
Net even uitgeprobeerd, en bij het verhuizen van het eerste draadje loopt het al meteen mis. Zou er iets zijn met portC waardoor deze niet gebruikt kan worden voor een lcd aan te sturen?
In de datasheet staat dat deze pins ook een ADC hebben. Maar dat zou toch geen invloed mogen hebben?

Op 6 juni 2019 10:02:27 schreef EricP:
Zonder ook maar iets van de rest van de source te kennen: je gefrutsel met macro's is eng.

Klopt, ben ik me ook van bewust. Heb ondertussen op suggestie van deKees alles omgezet in functies, maar had oorspronkelijk geprobeerd zoveel mogelijk de structuur van de library, met dat gefrutsel met macro's, te behouden.

En dan toch te nieuwsgierig... En ff kijken wat meneer Zeester gebakken heeft. Ik kom daar een GLCD_IO_DATA_INPUT tegen - blijkbaar doet die lib ook reads van je LCD. Ook die zul je ff moeten aanpassen. Anders gaat het nooit werken natuurlijk...

Deze had ik inderdaad aangepast (ondanks dat het hierboven er niet bij stond).
Deze heeft echter relatief weinig invloed heb ik de indruk. Bij de aanpassing van portB naar portD was ik deze pin ook eerst vergeten aan te passen, en toen werkte alles gewoon. Als ik het goed heb is dit gewoon een stukje feedback dat hij voor sommige functies in zijn demo-bestandje gebruikt, bijvoorbeeld bij het inverteren van pixels op het scherm.

EDIT: ook nog even reageren over de haakjes/accolade-discussie.
Oorspronkelijk had ik geen accolades staan, enkel zuivere instructies gescheiden door een puntkomma (zonder een puntkomma achter de laatste instructie). Haakjes stonden rond de single-instructies die meerdere bit-operaties uitvoerden.
Toen werd ik er elders op gewezen dat dit problemen kon geven als deze macro's in if-statements zouden worden opgeroepen, en dat ik er dan beter accolades kon rondzetten. Als je dit doet, moet er wél een puntkomma achter de laatste instructie staan.

[Bericht gewijzigd door Opifex op 6 juni 2019 18:03:00 (12%)]

EricP

mét CE

Probeer elke bit eens, 1 voor 1.
Dat gaat natuurlijk hopeloos de mist in met reads, maar als jij zegt dat die niet gebruikt worden...

Het zou natuurlijk zomaar kunnen dat om de een of andere reden de boel de mist in gaat met de eerste bit die je probeert...

[open deur]Je hebt wel de juiste controller geselecteerd? Feitelijk is een PORT (DDR, PIN) niks anders dan een address in I/O space. Als je een andere controller hebt, dan zou het zomaar kunnen dat daar iets anders gemapped is...[deur weer dicht]
Laat desnoods de boel ff lopen als het werk en ga op een pin van de port die het niet doet ff een bit staan togglen en kijk met de scope of die het ook doet... Toch wel heel spannend wat er hier (niet) gebeurt.

Over de accolades: Ja dat is een truuk die de boel al in veel gevallen oplost, maar helaas niet altijd, vandaar dat de do ... while (0) vaak gebruikt wordt. Gewoon zo min mogelijk verrassingen.

Moet ik nog uitleggen waarom het zonder niet werkt?

code:


#define DATA_OUT(x) PORTD=x&0xfc;PORTC=x&0x3

if (something)
   DATA_OUT (thedata);

Daar maakt de preprocessor van:

code:


if (something)
   PORTD=thedata&0xfc;PORTC=thedata&0x3;

en dan nog denk je: dat zou toch moeten werken? Maar dan zit je fout. De gebruikelijke manier om dit te schrijven is namelijK:

code:


if (something)
   PORTD=thedata&0xfc;
PORTC=thedata&0x3;

en "witruimte" maakt in de taal C niet uit en ik heb alleen een <return> er tussen gezet. En dat is witruimte!

Maar als je de twee poorten parallel laat werken, dan kan je 8 draden 1 voor 1 omzetten. (als het na 1 omzetter niet werkt, Ik wil weten of het NOOIT werkt of dat er een paar zijn. Dat geeft een hint over wat er mis is.

Volgende debug-stap is: PortC en PORTD moeten gewoon 100% dezelfde waardes hebben, toch? Als je dan twee ledjes anti-parallel plaatst en dan een serieweerstand en dat dan tussen PD0 en PC0 plaatst. En vervolgens PC1 en PD1 en dan steeds weer de "hij werkt" test draait. Zie je dan de led knipperen? Dan zijn PCx en PDx niet gelijk! En om te kijken of je led het doet: plaats hem tussen PD1 en PD2: Dan moet je eea zien knipperen.

(Hij mag HEEL licht knipperen omdat je PORTD eerder schrijft als PORTC. Eerlijk gezegd: dat zou alleen zichtbaar mogen zijn in het stikke-donker. Ik heb even een test-compile gedaan, met parallel naar PORTD en PORTC zijn de pulsjes van de leds zo'n 50ns.... Het zou kunnen dat dat te weinig is, maar het zou ook kunnen van niet...)

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

Op 6 juni 2019 18:22:57 schreef EricP:
Probeer elke bit eens, 1 voor 1.
Dat gaat natuurlijk hopeloos de mist in met reads, maar als jij zegt dat die niet gebruikt worden...

Wat bedoel je juist met elke bit, 1 voor 1? Versteken, zoals rew voorstelde?
Dat probeerde ik zojuist (zie vorige bericht), en hierbij liep het mis vanaf ik het eerste draadje verstak. Als ik het terugstak van waar het kwam ging alles weer goed.

Ik zeg niet dat het niet gebruikt wordt, maar wel dat het ook (grotendeels) werkte toen ik die regel nog vergeten te vervangen was. Maar in ieder geval is die ondertussen wel al lang aangepast op een gelijkaardige manier:

c code:

#define GLCD_IO_DATA_INPUT()            ((PIND & 0b11111100) | (PINC & 0b00000011))  

[open deur]Je hebt wel de juiste controller geselecteerd? Feitelijk is een PORT (DDR, PIN) niks anders dan een address in I/O space. Als je een andere controller hebt, dan zou het zomaar kunnen dat daar iets anders gemapped is...[deur weer dicht]
Laat desnoods de boel ff lopen als het werk en ga op een pin van de port die het niet doet ff een bit staan togglen en kijk met de scope of die het ook doet... Toch wel heel spannend wat er hier (niet) gebeurt.

Juiste controller geselecteerd, ja :+ . Ben er al de hele week mee aan het spelen, allerhande probeerseltjes gemaakt, en heeft altijd goed gewerkt :)

Op 6 juni 2019 18:28:24 schreef rew:

Maar als je de twee poorten parallel laat werken, dan kan je 8 draden 1 voor 1 omzetten. (als het na 1 omzetter niet werkt, Ik wil weten of het NOOIT werkt of dat er een paar zijn. Dat geeft een hint over wat er mis is.

Nope, zoals ik reeds zei loopt alles fout na het overzetten van slechts één pin van D naar C. Als ik het daarna terugsteek (zonder opnieuw te flashen), werkt het gewoon weer perfect. Er lijkt dus toch iets fout te zijn met portC?

Volgende debug-stap is: PortC en PORTD moeten gewoon 100% dezelfde waardes hebben, toch? Als je dan twee ledjes anti-parallel plaatst en dan een serieweerstand en dat dan tussen PD0 en PC0 plaatst. En vervolgens PC1 en PD1 en dan steeds weer de "hij werkt" test draait. Zie je dan de led knipperen? Dan zijn PCx en PDx niet gelijk! En om te kijken of je led het doet: plaats hem tussen PD1 en PD2: Dan moet je eea zien knipperen.

(Hij mag HEEL licht knipperen omdat je PORTD eerder schrijft als PORTC. Eerlijk gezegd: dat zou alleen zichtbaar mogen zijn in het stikke-donker. Ik heb even een test-compile gedaan, met parallel naar PORTD en PORTC zijn de pulsjes van de leds zo'n 50ns.... Het zou kunnen dat dat te weinig is, maar het zou ook kunnen van niet...)

Ik vrees dat deze inderdaad zal verschillen. Als ze gelijk zouden lopen zou het gewoon werken. Dat lijkt me evident?

In ieder geval, ik test het zo meteen even uit!

EDIT: Net even uitgeprobeerd.
Beide leds in anti-parallel, tussen PD0 en PC0 --> Geen geflikker. Geen led brandt.
tussen PD0 en GND --> één led flikkert
tussen PC0 en GND --> leds doen niks.

Dus er gebeurt toch nog iets anders dan je voorspelde, rew? :) Moet toegeven dat ik er ook niet helemaal aan uit kan. Waarschijnlijk doe ik iets heel doms :p

EricP

mét CE

Op 6 juni 2019 19:16:18 schreef Opifex:
[...]
Wat bedoel je juist met elke bit, 1 voor 1? Versteken, zoals rew voorstelde?
Dat probeerde ik zojuist (zie vorige bericht), en hierbij liep het mis vanaf ik het eerste draadje verstak. Als ik het terugstak van waar het kwam ging alles weer goed.

Dan gaat het dus met bit0 fout. En met bit1??

Juiste controller geselecteerd, ja :+ . Ben er al de hele week mee aan het spelen, allerhande probeerseltjes gemaakt, en heeft altijd goed gewerkt :)

OK. Soms werkt het deels - omdat die addressen toevallig overeen komen tussen wat je hebt en wat de compiler denkt dat je hebt. 'Het werkt' wil nog niet zeggen dat het goed is!

EDIT: Net even uitgeprobeerd.
Beide leds in anti-parallel, tussen PD0 en PC0 --> Geen geflikker. Geen led brandt.
tussen PD0 en GND --> één led flikkert
tussen PC0 en GND --> leds doen niks.

Dat klinkt alsof PC0 niet als output gedefinieerd is. Immers... Als PD0 wel 'leeft' en PC0 is 'fixed' hoog of laag, dan zou er wat met een LED gebeuren. Dit lijkt op HighZ (of weak pull-up). Dat impliceert input...

Op 6 juni 2019 21:50:04 schreef EricP:
Dan gaat het dus met bit0 fout. En met bit1??

Heb net even iets anders getest, want ik had de indruk dat portC gewoon volledig niet werkte.
Heb gewoon eens blinky proberen op te zetten: gespiegeld dezelfde bits naar portB en portC sturen. PortB lichtte op, portC niet!
Iemand stelde voor om eens een volle byte er in te stoppen. Wat bleek? in portC blinkte het ledje overal, behalve op PB0! Mogelijks een slecht contact? of een defecte pin?

OK. Soms werkt het deels - omdat die addressen toevallig overeen komen tussen wat je hebt en wat de compiler denkt dat je hebt. 'Het werkt' wil nog niet zeggen dat het goed is!

Wees gerust, ik heb een atmega328p. compiler argument is -mmcu=atmega328p, avrdude argument: -p m328p. Dit zou allebei juist moeten zijn ;)

Wat heb ik nu geprobeerd? Wel... 2 pins van portB gebruikt, ipv. portC. Dit wou ik eerst niet doen, omdat het alles ineens veel complexer maakte (veel grotere kans op fouten) omdat het nu ook shifts nodig had op een port waar ook andere pins van in gebruik zijn (controlesignalen), maaarrr... lo and behold... het werkt!
Heb enkel mijn SPI pins moeten opofferen nu, maar die gebruik ik waarschijnlijk toch niet. Ben meer fan van I²C :)

Op 6 juni 2019 19:16:18 schreef Opifex:
Nope, zoals ik reeds zei loopt alles fout na het overzetten van slechts één pin van D naar C. Als ik het daarna terugsteek (zonder opnieuw te flashen), werkt het gewoon weer perfect. Er lijkt dus toch iets fout te zijn met portC?

Steeds blijf je het formuleren dat het mogelijk is dat je maar 1 draad OOIT hebt overgezet. Wat ik wil weten is of het blijft werken als je datalijn nul overzet? Nee? Dan zet je die terug en probeer je de volgende, D1. Werkt die ook niet? Dan zet je hem weer terug en probeer je WEER de volgende. Enz.

Op 6 juni 2019 19:16:18 schreef Opifex:
Ik vrees dat deze inderdaad zal verschillen. Als ze gelijk zouden lopen zou het gewoon werken. Dat lijkt me evident?

Maar door het WERKELIJKE experiment te doen, verkrijgen we informatie over wat er nu daadwerkelijk mis gaat.

EDIT: Net even uitgeprobeerd.
Beide leds in anti-parallel, tussen PD0 en PC0 --> Geen geflikker. Geen led brandt.
tussen PD0 en GND --> één led flikkert
tussen PC0 en GND --> leds doen niks.

Prima experiment: Hier leren we veel van!

De twee leds mogen ook tussen een pin en de 5V geschakeld worden. Dan moet de andere led flikkeren.

uit dit experiment blijkt dat /of/ PC0 is als input geconfigureerd, OF PC0 blijft altijd "laag". in het eerste geval blijven de ledjes uit tussen PC0 en 5V anders gaat er 1 aan en blijft aan.

Als je gedaan had wat ik gevraagd had (na het terugzetten van Data-0 draadje op PD0 vervolgens data-1 op PC1 had gezet, dan had je duidelijk gezien dat het maar 1 bitje van de PORTC port is.

Wat /ik/ nu vermoed is dat je ERGENS in je code (bewust of onbewust) PC0 weer op "input" zet.

[Bericht gewijzigd door rew op 7 juni 2019 07:06:02 (48%)]

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
EricP

mét CE

Heb gewoon eens blinky proberen op te zetten: gespiegeld dezelfde bits naar portB en portC sturen. PortB lichtte op, portC niet!

Heb je het met 8 LEDs gelijktijdig geprobeerd???

Iemand stelde voor om eens een volle byte er in te stoppen. Wat bleek? in portC blinkte het ledje overal, behalve op PB0! Mogelijks een slecht contact? of een defecte pin?

Het lijkt me logisch dat wanneer je wat met bit 0 van portC doet, er op bit 0 van port B niet zoveel gebeurt...

Wat /ik/ nu vermoed is dat je ERGENS in je code (bewust of onbewust) PC0 weer op "input" zet.

Of dat er met PC0 ooit wat naars gebeurd is en dat die gewoon overleden is. Al kunnen AVRs best veel hebben (in elk geval toen ze nog door Atmel gemaakt werden), het kan ook stuk...

Op 7 juni 2019 06:57:12 schreef rew:
[...]Steeds blijf je het formuleren dat het mogelijk is dat je maar 1 draad OOIT hebt overgezet. Wat ik wil weten is of het blijft werken als je datalijn nul overzet? Nee? Dan zet je die terug en probeer je de volgende, D1. Werkt die ook niet? Dan zet je hem weer terug en probeer je WEER de volgende. Enz.

[...]
Maar door het WERKELIJKE experiment te doen, verkrijgen we informatie over wat er nu daadwerkelijk mis gaat.
[...]Prima experiment: Hier leren we veel van!

De twee leds mogen ook tussen een pin en de 5V geschakeld worden. Dan moet de andere led flikkeren.

uit dit experiment blijkt dat /of/ PC0 is als input geconfigureerd, OF PC0 blijft altijd "laag". in het eerste geval blijven de ledjes uit tussen PC0 en 5V anders gaat er 1 aan en blijft aan.

Als je gedaan had wat ik gevraagd had (na het terugzetten van Data-0 draadje op PD0 vervolgens data-1 op PC1 had gezet, dan had je duidelijk gezien dat het maar 1 bitje van de PORTC port is.

Wat /ik/ nu vermoed is dat je ERGENS in je code (bewust of onbewust) PC0 weer op "input" zet.

Sorry voor de onduidelijkheid, maar ik had wel degelijk meerdere pinnen verstoken, zoals je voorstelde. Wel enkel de eerste 2, omdat dat de pinnen waren die ik voor poortC had ingesteld. (Meer kon niet, omdat er voor de feedback niet zomaar gewerkt kan worden met het returnen van de volledige byte)
Beide experimenten gaven niet het resultaat dat jij beoogde. De leds gingen niet branden.

De test met blinky, zoals ik hierboven beschreef heb ik wél op de volledige poort C uitgeprobeerd, al zei het wel maar met één led waarvan ik het draadje continue verstak, ipv. alle leds tegelijkertijd.

Op 7 juni 2019 07:40:33 schreef EricP:

Heb je het met 8 LEDs gelijktijdig geprobeerd???

Tegelijkertijd niet (deze AVR kan volgens mij ook nie voldoende stroom geven voor 8 leds). Gewoon blinky programma op volledige portC gezet, en dan het draadje op het breadbord blijven herprikken van pin naar pin. Zo de volledige portC afgegaan: ledje blinkte op alle pins, behalve op die van PC0.

Het lijkt me logisch dat wanneer je wat met bit 0 van portC doet, er op bit 0 van port B niet zoveel gebeurt...

Dat was uiteraard een typo, en moest PC0 zijn. pin 0 van PoortC doet niks. Geen blinky, en werkt niet met de lcd. Dit was waarschijnlijk de boosdoener.

Of dat er met PC0 ooit wat naars gebeurd is en dat die gewoon overleden is. Al kunnen AVRs best veel hebben (in elk geval toen ze nog door Atmel gemaakt werden), het kan ook stuk...

Heb poortC nog niet aangeraakt vooraleer dit opdook. Ik zet mijn geld op een slecht contact op de plaats waar de header via de gatenprint aan het pinnetje van de µC hangt :)

EricP

mét CE

Tegelijkertijd niet (deze AVR kan volgens mij ook nie voldoende stroom geven voor 8 leds). Gewoon blinky programma op volledige portC gezet, en dan het draadje op het breadbord blijven herprikken van pin naar pin. Zo de volledige portC afgegaan: ledje blinkte op alle pins, behalve op die van PC0.

Duidelijk. Blijkbaar geen developmentboard waar torretjes als driver op zitten en ook geen low-current LED (doet het op 1mA ook al). Kan ik van hier af niet zien he!

Heb poortC nog niet aangeraakt vooraleer dit opdook. Ik zet mijn geld op een slecht contact op de plaats waar de header via de gatenprint aan het pinnetje van de µC hangt :)

Dat kan een multimeter je natuurlijk zo vertellen. Maar wel fijn dat je in elk geval wat gevonden hebt wat je misère kan verklaren.

Ha, ik kwam dit topic per toeval tegen. Ik heb inderdaad een aantal jaar geleden deze schermpjes op sk.net verpatst.
Als je nog wat documentatie mist, neem gerust contact op, ik heb nog het e.e.a. liggen qua documentatie en voorbeeldcode.

Hoi Marco!

Heb het ondertussen perfect werkend gekregen, maar alle documentatie is zeker welkom! (Want vele bronnen op het internet zijn ondertussen dode links geworden helaas... )

Ik dacht, 'ik stuur je een mailtje'. Maar wat merk ik wanneer ik je email adres probeer in te vullen? Dat m'n Gmail dat mailadres al als suggestie geeft!

Ik even op dat adres gezocht in m'n mailbox, en vond daar het gesprek van toen je de LCD's verkocht! :D

Had ik niet verwacht :p

EricP

mét CE

Jaja... choochel weet meer over je dan jij. En ook dan jij weet wat ze weten. Maar blijf ze maar voeren met data hoor!