defecte an80c196kb ?

De 8742AH heeft geen (externe) adresbus, alleen een databus voor communicatie...

Ik zeg niet dat de bus wazig is, ik bedoel de nummering.
Maar ik heb nu de datasheet op een groter scherm. Het is een niet zo'n beste copie maar ik vond geen betere.

Mel: Die 10 bit bus haal ik er niet uit. Een adresbus kan ik ook niet vinden

Het is een slave processor met eprom. Dat kende ik nog niet.

Het is toch niet zo wazig genummerd.
Hij heeft 2 bidirectionele poorten. poort 1 ofwel P10-P17 en poort 2 ofwel P20-P27
Die poorten worden gebruikt voor data of instructies. Dat wordt bepaald door de status van A0
Die poorten zitten aan de display drivers.

Het buffer is een 74AC245 en die is goed, er zit ook nog een 4013 en 74AC32

De 8742 was een fijne controller (Intel noemde het een UPI: Universal Peripheral Interface)
Ik heb ze heel veel gebruikt in datingsystemen en babbelboxen. (in iedere box zaten er 63 die via die databus per 21 werden aangestuurd door een controller)

Tussen hoofdprocessor en deze UPI zit een 74AC245 die D0-D7 onderbreekt/doorlaat. Dat deel werkt want ik meet ook direct op de UPI de data. Ook hier tel-achtige data.

Klopt mijn redenatie hieronder (ik wil er van leren)

Dan zou ik naar IBF, OBF moeten kijken. Als ik het goed begrijp gaat de data van de hoofdprocessor via de 245 naar de UPI. Daar worden CS, RD, WR en A0 bij gebruikt.

Daarna moet het naar de drivers via port 1 en port 2.

De UPI zet (2x ?) 8 bit data van de databus over naar de output buffer. Als dat er in zit wordt IBF hoog gemaakt wat de hoofdprocessor ziet en stopt tot er weer een WR komt. Daarna gaat het naar de output buffer. Als deze vol is wordt OBF laag gemaakt en ik denk dat dit als een READ voor de displaydrivers wordt gebruikt. Of door de hoofdprocessor want dat zou logischer zijn. Zo kan de processor de display bedienen met de UPI als interface.

De IBF en OBF flags zijn er alleen om interrupt gestuurde dataoverdracht mogenlijk te maken (zodat de MCU nergens op hoeft te wachten.
(hij kan ook de IBF/OBF flags in het statusregister pollen)

Er zijn 2 inkomende buffers (status, A=1, en data, A=0), en 1 uitgaande databuffer.

P1. tot P1.7, en P2.0 tot P2.2 is wel degelijk te gebruiken als adresbus, worden gelatched met sync(pen 11).

Ja, kan soms in testgevallen bij single step om het adres te tonen, maar je ziet het in 'normale' toepassingen eigenlijk nooit. (ik heb het nog nooit gezien)
P20...23 worden wel gebruikt als adres voor de 8243 port extenders...

Even wat ander werk gedaan maar vandaag dacht ik, laat ik de VFD nog eens proberen.

Ik wil dat met mijn easypic 3 (met een pic 877A) doen. Eerdere pogingen deden niets. Maar dat ligt waarschijnlijk eerder aan mij dan aan het ding zelf.

De VFD wordt aangestuurd door twee SED2000F drivers. Die worden aangestuurd via de UPI. data gaat via een 74AC245 naar de UPI. Er zit een 4013 die iets met de klok van de UPI doet. En een 74AC32 tussen header en UPI, die als buffer wordt gebruikt. (Input A en B steeds aan elkaar)

Ik zou graag wat letters op het ding krijgen door de UPI via de pic aan te sturen. Het board kan zover ik kan vinden stand alone werken. De voeding komt daar binnen. Er zit een header op waar de data en controle lijnen van het andere board binnen komen. Maar door die 245 weet ik niet wat ik moet doen.

Ik denk: eerst de poorten "goed" zetten. Dan data op de bus zetten. Met de 245 binnen halen. Dat via de uitgang van de 245 op de databus van de UPI zetten middels /OE en /CS. Dan met WR het in de UPI schrijven en die zet dan waarschijnlijk de letter op de display (hoop ik) Ik ben alleen bang dat ik de UPI ook commandos moet geven want anders weet hij niet waar het heen moet lijkt me. Dave Jones doet ook zo iets met een arduino maar zover ik het kon volgen stuurde hij geen commando's. Ik wil alleen zien of het ding wat doet.

Signalen en pic-poorten:
Port B.0 tot B.7 Data, 8 bits
Port C.0, A0 (UPI) moet laag voor data
Port C.1 schakelen samen met C.4 de voeding in.
Port C.2 /CS (UPI) en /OE (74AC245) zitten aan elkaar L=output aan
Port C.3 /WR (UPI) L=write
Port C.4 power on H=on
Port C.5 T//R (74AC245) moet altijd hoog

Iets in deze geest ?

void main(){
TRISB=0b00000000; // port B output (data)
TRISC=0b00000000; // port C output (controle lijnen)

PORTC=0b00111110; // power aan en beginstand UPI

While(1) {
PORTB = 0b01100001 // Een ascii code op de bus zetten
PORTC = 0b00110010 // /OE en /CS laag om van 245 naar UPI te sturen
PORTC = 0b00110110 // WR laag om data in UPI in te lezen
delay_ms(1000) // letter 1 seconde zichtbaar

/*En dit 26 keer voor het hele alfabet.Of een loop met steeds de zelfde code. Als er maar wat zichtbaar is*/
}

Je kunt voor de data beter de PSP (portd) gebruiken, die is daar speciaal voor gemaakt... (maakt interface een stuk simpeler.)

Ehh, nu weet ik helemaal niet wat ik moet doen. Ik gebruikte deze poorten omdat ik zo de boel makkelijk kan aankoppelen via de connectors op de easypic. B en C hebben alle pinnen aan de headers

Het gaat voornamelijk om de volgorde van port settings. Ik wil alleen weten of het display deel werkt.

Ik heb die Easypic voor dit soort dingen. Er zit zo ongeveer alles op en aan wat handig is voor mijn gebruik (knoppen, interfaces, displays, leds etc.)
Maar de leercurve is flink wat steiler dan een Arduino waar je bergen projecten vind die je alleen wat moet aanpassen. De helpfile maakt het niet echt veel beter. Ik kan er echt niks in vinden. Zelfs niet hoe een for of while loop qua syntax moet. Of de pull-up weerstanden.
Ze schrijven in het boekje bv dat je ze op pull down moet zetten voor een logical zero om gelijk daarna te schrijven dat het belangrijk is om pull up te kiezen als je een logical zero op de input verwacht en vise versa. Schiet mij maar lek.

De UPI heeft pull ups dus die lijnen zijn standaard hoog maar ik weet nooit wat ik daar verder mee moet. (wel mbt meten maar niet met programmeren en hardware koppelen)

Ik kan er echt niks in vinden. Zelfs niet hoe een for of while loop qua syntax moet. Of de pull-up weerstanden.

Staat toch in de helpfile? (ik neem aan dat je de MikroC Pro compiler bedoelt?)
http://download.mikroe.com/documents/compilers/mikroc/pic/mikroc-pic-m… (blz. 224 t/m 226)
(pull-up weerstanden staan in de datasheet...)

Ik bedoelde de help die je activeert met de help knop. Ik heb versie 7.nogwat, de op een na nieuwste. Arduino is een stuk makkelijker maar ik vind deze IDE fijn met veel hulpjes. De arduino gebruikte ik met de atmel IDE en losse programmer.

Ik heb gisteren me te pletter gezocht op de site van mikro-electronica maar ik kan geen enkel manual vinden. Zelfs die van jou vind ik niet. Ik moet iets over het hoofd zien.

Die uit jou link is van 2009 maar beter dan niks of de nog oudere die ik had. De eerste keer heb ik dagen zitten ploeteren om ledjes te laten knipperen tot ik er achter kwam dat het manual van de CD te oud was voor de nieuwste versies. Ik deed niks fout, het commando bestond niet meer. Bedankt voor het zoeken.

Wat wel irritant is en vast aan mij ligt is dat ik na het programmeren vaak eerst een paar keer op reset moet duwen voor hij werkt.

Ik wil dit graag leren omdat het zo een heel handige tool kan zijn bij reparaties en zelfbouw. (Van wegen de displays, schakelaars, headers, interfaces, potmeters etc. Ik mis alleen de grote display. Ik wil hem in een soort kastje bouwen met een klep er boven om hem te beschermen.
Even firmware laden en ik kan het gebruiken. (voor dingen die je niet dagelijks gebruikt, scheelt een hoop werk mbt in-kasten) En als ik goed genoeg kan programmeren en het handig blijkt koop ik misschien wel een nieuwe Easypic

De help onder de F1 toets is inderdaad van bedroevende kwaliteit. (veel ontbreekt, is niet compleet, of gewoon onjuist... )
De compilers zelf werken prima, ik heb zelden problemen ermee gehad.
De IDE zitten wel wat gebreken in, maar hopelijk wordt dat ooit nog eens 'gerepareerd'...

Wat let je om het gewoon met een Arduino te doen?

Wel grappig dat fred precies omschrijft hoe ik destijds ook met dat pic-spul aan het vechten was en wat een verademing AVRs waren...

PIC's werken uitstekend!... (je moet wel weten waar je mee bezig bent natuurlijk... )
Dit ging over de programmeeromgeving, niet de hardware zelf. (het maakt voor een For...Next loop niet uit welke controller je gebruikt)
Ik heb bij arduino nooit begrepen waarom ze daar weer een nieuw taaltje (een c verbastering) hebben moeten uitvinden...

PIC's werken uitstekend!... (je moet wel weten waar je mee bezig bent natuurlijk... )

Laten we het er dan maar op houden dat zowel ik als een deel van mijn opdrachtgevers dat niet weten - toch leuk verdiend aan pic-ding ontwerpen omkrikken naar AVRs omdat eh... die pic-dingen zo goed werkten ofzo

Dit ging over de programmeeromgeving, niet de hardware zelf. (het maakt voor een For...Next loop niet uit welke controller je gebruikt)

Dan heb je dus ook niet de documentatie van een specifieke controller nodig... In theorie dan. In de praktijk blijkt het helaas lang niet altijd zo te zijn.

Ik heb bij arduino nooit begrepen waarom ze daar weer een nieuw taaltje (een c verbastering) hebben moeten uitvinden...

Nee, dat heb ik ook nooit gesnapt. Waarschijnlijk heeft iemand verzonnen dat het 'makkelijker' is ofzo. Aan de andere kant... zo 'nieuw' is dat taaltje ook niet. Het heeft wat C++ elementen - geen idee wat je daarmee moet, maar hey, ik heb het niet verzonnen.

Pak je standaard programmeer omgeving en programmeer iets simpels als: bekijk een paar inputs, afhankelijk van de waardes en hoe lang ze ingedrukt worden doe iets met een paar outputs. Iets als kort drukken eerst ouput 1, dan output twee en anders andersom. En met de andere knop 2x langer of zoiets.

Kijk dan eens naar hoeveel van je sourcecode echt met "de opdracht" te maken heeft en hoeveel met dingen er omheen. Timers starten om de tijd te bepalen, dat soort dingen.

Wat arduino heeft poberen te bereiken en daar redelijk in geslaagd is, dat is om simpele programmas simpel te houden. Weinig overhead. Weinig stuk programma wat je alsmaar weer copieert omdat het de boel netjes opstart en je direct met het programmeren van je code-van-vandaag kan beginnen.

Dew easypic van wege wat er op het board zit. Wat voor processor dat is maakt me niet uit, ik ben even beroerd in programmeren op beide. Ik doe het te weinig en vergeet dan de syntax. Het moeilijkste is het gedoe met voids, includes, libs etc. Daar loop ik altijd vast.

Ik vind de IDE van de Easypic best fijn. Zeker met het (tot nu toe) redelijk bruikbare manual. Wel vreemd dat ik geen nieuwer kan vinden. Browser probleem ?

Maar dat is het probleem niet. Ik wil weten of de VFD wat doet.
Daarom wil ik met een uP de master processor vervangen en de slave processor aansturen.

Het gaat er alleen maar om in welke volgorde ik welke lijnen hoe lang hoog of laag moet maken. Ik vind experimenteren wel leuk maar niet in het huidige geval. Als het niet werkt weet ik niet of het aan mij ligt of aan het display board dus ik kom niet verder.

Signalen en pic-poorten:
Port B.0 tot B.7 Data, 8 bits
Port C.0, A0 (UPI) moet laag voor data
Port C.1 schakelen samen met C.4 de voeding in.
Port C.2 /CS (UPI) en /OE (74AC245) zitten aan elkaar L=output aan
Port C.3 /WR (UPI) L=write
Port C.4 power on H=on
Port C.5 T//R (74AC245) moet altijd hoog

Ik houd niet zo van 'Programmeren voor dummies'...
Ik weet graag precies wat er gebeurt; zonder de datasheet ooit te hebben gelezen weet je dat niet.
(en dan maar klagen dat de processor 'vreemd' doet!... )

In veel kant en klare libraries gebeuren soms ook tenenkrommende dingen, indien mogelijk schrijf ik die functies liever zelf...
Vaak is niet eens bekend wat voor resources een library precies gebruikt, en dat is toch wel prettig om te weten...
Meeste i2c libraries bijvoorbeeld lopen vast bij een probleem op de i2c bus. Ik vind dat onacceptabel en het is ook onnodig.

Zoals reeds gezegd kun je beter PORTD (de PSP) gebruiken i.p.v. PORTB. (die is bedoeld voor databus communicatie)

Maar poort D is volgens jou plaatje bedoeld om als slave te werken. Mijn PIC moet de master zijn die tegen een slave (de upi) praat. Dat is net andersom. Volgens miju verandert dat ook niks aan mijn probleem. Namelijk minimaal 1x 1 groepje van 8 bitjes in een UPI pompen

Welke stappen moet ik doen om 8 bitjes naar de upi te sturen via de 245. Niet de C commanmdo's, die weet ik wel, ik weet de volgorde niet.

Wat ik nu denk:

1)Eerst de bus HiZ maken door /OE van de 245 hoog te maken
2)Dan de data vanuit de pic naar D0-D7 op de A inputs van de 245 zetten
3)Dan de /OE laagmaken waardoor de 245 het aan de upi databus aanbied.
4)Dan de /WR hoog en de /RD lijn van de upi laag maken (door de PIC) en zo data vanaf de 245 in de upi te lezen. Dus de UPI op luisteren zetten.
5)Dan de /RD weer hoog en de /WR lijn van de upi laag (door de PIC)om de data van upi naar vfd driver te sturen.

Ik loop vast op write/read. Als ik de /WR lijn van de UPI laag laat maken door de PIC, gaat de UPI dan zelf schrijven of zegt de PIC dat hij gaat schrijven ?

En bij /READ, zegt de PIC tegen de UPI dat de UPI moet luisteren of zegt de PIC zo dat de PIC klaar is om zelf te luisteren.