Sterrenhemel

Op 17 januari 2021 23:57:42 schreef Arco:
Als de niet werkende complete code post wil ik wel eens kijken...

Nou ja, als jij daar nog even naar wilt kijken, dat zou wel heel fijn zijn.
Ik ben razend benieuwd of jou het lukt.

Ik had inmiddels al veel versies gemaakt.

Dus daarom deze gestripte versie, waarbij de tijd van een DS3231 I2C moduultje op de led matrixen wordt getoond. Tenminste, dat is de bedoeling.

Standaard SPI1, met de SCK1 op default Port C.3, SDO1 naar Port B.0
Standaard I2C2, met de SCL3 op default Port B.1 en de SDA2 op PORT B.2

De matrixen (Dus SPI) werken.

De I2c Blijft hangen na de Read van de DS3231...

(Edit: licht bijgewerkte versie, De matrixen werden niet geschreven).

Wat in ieder geval niet klopt is dit:

 TRISB      = %00000110                                      'B1, B2 Input
 TRISC      = %00000000                                      'All output

 RB0PPS = 0x15                                               'Transfer SDO1 to PORT B.0

 SPI1_Init()                                                 'Init SPI1
 I2C2_init(100000)                                           'Init i2c2 port 100kHz

SPI1_Init() zet altijd de port pin weer terug naar default. RB0PPS = 0x15 moet dus na de Init() komen.
Heb daar ook discussie over gehad met support, die zeggen dat het is gedaan om het voor de minder begaafde programmeurs simpeler te maken...
Heb gevraagd of ze dan in ieder geval in de help willen aangeven welke pin wordt gemapped, want er is geen default in de datasheet...
Je kunt beter dan SPI1_Remapped_Init() gebruiken...

Dank Arco.

Ik had ook wel geëxperimenteerd met SPI1_Remapped_Init().

Maar in dit geval is het merkwaardige dat de SPI gewoon werkt! (Met of zonder Remapped).Ik kan zo een getal op de matrixen tonen, die doen het wel.

Maar het is de I2C2 die niet wil werken...

Op 18 januari 2021 23:38:28 schreef Arco:
Wat in ieder geval niet klopt is dit:

pic basic code:

 TRISB      = %00000110                                      'B1, B2 Input
 TRISC      = %00000000                                      'All output

 RB0PPS = 0x15                                               'Transfer SDO1 to PORT B.0

 SPI1_Init()                                                 'Init SPI1
 I2C2_init(100000)                                           'Init i2c2 port 100kHz

SPI1_Init() zet altijd de port pin weer terug naar default. RB0PPS = 0x15 moet dus na de Init() komen.
Heb daar ook discussie over gehad met support, die zeggen dat het is gedaan om het voor de minder begaafde programmeurs simpeler te maken...
Heb gevraagd of ze dan in ieder geval in de help willen aangeven welke pin wordt gemapped, want er is geen default in de datasheet...
Je kunt beter dan SPI1_Remapped_Init() gebruiken...

En toch...werkt het in de praktijk (bij mij in ieder geval) anders.

Doe ik de RB0PPS ná de init(), dan werkt het niet..

Plaats ik hem ervóór (wat niet zou moeten), dan werkt de SPI en dus de matrixen wél).

Ergens klopt er dus iets niet...Het lijkt er nl op dat de poorten éérst moeten worden vastgelegd, en dat je dan pas de Init kan doen. Ik begrijp dat ook een beetje uit de Help van MickroBasic bij de SPI_Init().
Die heeft het niet over terugzetten naar de default pinnen...

Op die manier zit de SDO aan de oude en de nieuwe pin vast, dat veroorzaakt de meest vreemde verschijnselen.
De oude pin moet je unmappen zodat die pin weer vrijkomt (anders kan een andere peripheral die op die pin gemapped wordt er door gehinderd worden)

Het remappen van een pin maakt niet automatisch de oude mapping ongedaan: als je wilt kun je bijv. SDO naar 4 verschillende pinnen tegelijk mappen...

Het remappen van een pin maakt niet automatisch de oude mapping ongedaan: als je wilt kun je bijv. SDO naar 4 verschillende pinnen tegelijk mappen...

Ok...Dus je 'vervangt' hem niet maar koppelt hem aan een pin en wat er was blijft, tenzij je hem ontkoppelt.

Ofschoon mijn programma werkt met de software_I2c blijf ik wel proberen het via MSSP te doen.

Ik contreeer me dan nu even op de I2C. Eens kijken of ik dit aan de praat krijg.
Ik heb daarom de SPI er even uit gehaald, zodat alleen I2C2 blijft. Met testledjes kijk ik hoever hij komt.

I2C2_Start()
  lata.1 = 1
  I2C2_Wr(0xD0)
  lata.2 = 1
  I2C2_Wr(0x00)
  lata.3 = 1
  I2C2_Repeated_Start()
  lata.4 = 1
  I2C2_Wr(0xD1)
  lata.6 = 1
  Time[0] = Bcd2Dec(I2C2_Rd(1))  '<---- deze werkt niet; controller hangt  
  lata.7 = 1
  Time[1] = Bcd2Dec(I2C2_Rd(1))
  Time[2] = Bcd2Dec(I2C2_Rd(1) And 0x3F)
  Time[3] = Bcd2Dec(I2C2_Rd(1))
  Time[4] = Bcd2Dec(I2C2_Rd(1))
  Time[5] = Bcd2Dec(I2C2_Rd(1) And 0x7F)
  Time[6] = Bcd2Dec(I2C2_Rd(0))
  I2C2_Stop()

Tot de read lijkt het goed te gaan. De I2C2_Rd(1) laat het hangen (ik vermoed dat de controller op een reactie wacht die niet komt).

Maar omdat de start, write, repeated start wél doorgaat, mag ik dan de conclusie trekken dat de I2C goed is geconfigureert maar er ergens anders iets niet goed gaat waardoor ik geen lees-resultaat krijg?

Of kan het gebeuren dat je een foute configuratie pas merkt bij de Read?

Het frappante is dat wanneer je de SDA1 en SCL1 koppelt aan de pinnen, die eigenlijk al default zijn, het werkt..

RC3PPS     = 0x14    'map pin to SCL1
  RC4PPS     = 0x15    'map pin to SDA1

En wat ook wel vreemd is, dat de voorbeelden in de Help van MB tot compiler-errors leidt...

Bijvoorbeeld:

Unlock_IOLOCK()

PPS_Mapping_NoLock(15, _INPUT, _RX2_DT2)   ' Sets pin 15 to be Input, and maps RX2/DT2 Input to it
PPS_Mapping_NoLock(5, _OUTPUT, _TX2_CK2)   ' Sets pin 5 to be Output, and maps EUSART2 Asynchronous Transmit/Synchronous Clock Output to it

Lock_IOLOCK()

(Bij I2C soortgelijks. Het lijkt wel of de compiler de juiste (eventueel gewijzigde) syntax niet bijwerkt).

Ik vond deze devicefile op het Microchip forum. Die kan de 18857 programmeren.
(schijnt dat de hele programmeerboel veranderd is bij de 16f18857, dat vergt een nieuwe family en diverse nieuwe scripts)

Alleen de eeprom lezen/schrijven gaat niet, daarvoor moet het pickit3 programma aangepast worden en opnieuw gecompileerd.
Voor de pickit2 is er wel een gewijzigd programma beschikbaar.

Meteen geprobeerd natuurlijk...

Dan zou ik van dat MPLAB X verlost zijn.

De pic wordt herkend, hij kan lezen, erasen, maar schrijven geeft:

Wellicht is de package een issue? Ik heb een 28 pins DIL versie.

[Bericht gewijzigd door Bavelt op dinsdag 19 januari 2021 17:56:40 (17%)

Hier kan ik er alles mee doen zonder fouten. (wel met de pickit2)

Wellicht is de package een issue? Ik heb een 28 pins DIL versie.

Ik ook. Kunnen kleine verschillen in de pickit2/3 firmware of programma zitten.
Maar om in die sourcecode te gaan roeren (C#) zie ik niet echt zitten...

Kan ik die 5 configuration Words ergens in de datasheet vinden?
Om dat vervolgens aan te passen in de config?

Ik heb overigens onderstaande OS van Pickit in gebruik:

Ik zou dan eens een Pickit3 moeten opduiken en installeren. Ik heb er een paar maar die heb ik al jaren niet meer gebruikt.

En is het niet downward compatible? Ik bedoel dan dat ik de Pickit2 firmware in de Pickit3 stop?

Heb ik zojuist geprobeerd. Werkt niet. Alleen als ik de Verify on write uitvink lijkt het goed te gaan. Maar schijn bedriegt..Jammer...

[Bericht gewijzigd door Bavelt op dinsdag 19 januari 2021 19:45:21 (46%)

Of wellicht een PickIt2 op de kop tikken?
Als die er al zijn...

De pickit2 heeft een 18F processor, en de pixckit3 een 24F, dus niet compatible. Pickit2 clones zijn er genoeg en werken prima...
https://nl.aliexpress.com/wholesale?catId=0&initiative_id=SB_20210…

De Chinezen verkopen zelfs een Pickit 3.5, wat dat is weet ik ook niet...

Dat wordt dan wel een weekje op 8 - 10 wachten...

De Chinezen verkopen zelfs een Pickit 3.5, wat dat is weet ik ook niet...

Dat moet haast wel een COVID-PickKit zijn...

Hier staat het gewijzigde pickit2 programma + devicefile:
https://www.microchip.com/forums/m1034543.aspx

Mooi!

De Pickit2 is inmiddels besteld, Met Alie Standard Shipping. Gaat wat sneller. Levering rond 13-2-2021.
Dus ik parkeer dit nu even...

Wat ik wel zat te overpeinzen:

In deze wereld van PIC's, met Microchip als hoofdrolspeler, staat m.i. de kwaliteit van de controllers toch in contrast staat met de ontwikkel-tools.

Men heeft natuurlijk 'hun' MPLAB X IDE en IPE , maar dat is toch een gedrocht vind ik met enorm veel ballast.
Ondertussen ontmoedigt het bedrijf een stukje gereedschap dat nou net reuze handig én praktisch is: de stand alone Pickit. Deze is vele malen handiger
om de PIC's te programmeren. Zeker in combinatie met de compilers van MikroE.
Maar ik zie dat er niet meer in wordt geïnvesteeerd, en dat dat alleen op basis van open source en forums gebeurt.

Nou is dit natuurlijk mijn persoonlijke ervaring en zijn er wellicht anderen die met MPAB X uitstekend uit de voeten kunnen...