Sterrenhemel

Dit topic is gesloten

Arco

Special Member

Ik ben bezig met een printje voor de Northernsoftware chip (en dus hun programmer software) Misschien ook interessant, kan heel veel types aan en is erg snel.
https://www.northernsoftware.com/nsdsp/brd/

Deze pics worden ondersteund: https://www.northernsoftware.com/dev/

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
Bavelt

Golden Member

Fouten zijn het bewijs dat je het probeert..
Bavelt

Golden Member

In afwachting op de Pickit 2 dan maar weer even met de MPLAB X IPE.

Ik heb een proefje genomen met het ontkoppelen van de poort:

pic basic code:


Spi1_Remappable_Init()                                      'Init SPI1

Unlock_IOLOCK()
PPS_Mapping(_RB0, _OUTPUT, 0)                               'Unmap RB0
Lock_IOLOCK()

Unlock_IOLOCK()
PPS_Mapping(_RB0, _OUTPUT, 0x15)                            'nmap RB0 Output
Lock_IOLOCK()

Unlock_IOLOCK()
PPS_Mapping(_RB0, _INPUT, 0x15)                             'map RB0 Input
Lock_IOLOCK()]

Dit werkt echter niet.

Het enige waarmee ik de SPI echt aan de praat krijg is met:

pic basic code:


RB0PPS = 0x15                                               'Transfer SDO1 to PORT B.0
Spi1_Init()                                                 'Init SPI1

En dan in déze volgorde. (dus éerst assignment en dán pas Init)

Omdraaien werkt niet..

Raar he?

Fouten zijn het bewijs dat je het probeert..
Arco

Special Member

En dan in déze volgorde. (dus éerst assignment en dán pas Init) Omdraaien werkt niet..

Spi1_Init() doet waarschijnlijk alles zoals het moet, dus incusief een _unlock() en _lock().
Aangezien alles daarna gelocked is, kun je dus niets meer veranderen.

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
Bavelt

Golden Member

Ok, maar eerder schreef je dat het eigenlijk wel andersom moet:

SPI1_Init() zet altijd de port pin weer terug naar default. RB0PPS = 0x15 moet dus na de Init() komen.

Fouten zijn het bewijs dat je het probeert..
Arco

Special Member

Dat kan, maar dan moet je wel netjes een unlock doen, anders kun je niks schrijven. (wat de init exact doet is onbekend, dus dat blijft gissen)
Het PPSLOCK bit in de CONFIG settings moet dan wel op '0' staan...

[Bericht gewijzigd door Arco op woensdag 20 januari 2021 15:32:31 (19%)

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
Bavelt

Golden Member

Dan zou dit dus goed moeten zijn:

pic basic code:

Spi1_Remappable_Init()                                      'Init SPI1
 Unlock_IOLOCK()
 PPS_Mapping(_RB0, _OUTPUT, 0)                               'Unmap RB0
 Lock_IOLOCK()

 Unlock_IOLOCK()
 PPS_Mapping(_RB0, _OUTPUT, 0x15)                            'map RB0 to Output
 Lock_IOLOCK()

 Unlock_IOLOCK()
 PPS_Mapping(_RB0, _INPUT, 0x15)                             'Unmap RB0 to Input
 Lock_IOLOCK()

 Unlock_IOLOCK()
 PPSLOCK = 0x00

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

Niet dus...

Fouten zijn het bewijs dat je het probeert..
Arco

Special Member

Heb je het PPS bit in de Config registers wel gecleared zoals eerder gezegd? (anders werkt 't zeker niet)
PPSLOCK moet je niet rechtstreeks beschrijven, dat regelen de LOCK/UNLOCK functies...

[Bericht gewijzigd door Arco op woensdag 20 januari 2021 16:34:02 (29%)

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
Bavelt

Golden Member

Ih heb nu de asm uit de datasheet gehaald:

avr asm code:

asm
 BCF INTCON,GIE
; BANKSEL PPSLOCK ; set bank
; required sequence, next 5 instructions
MOVLW 0x55
MOVWF PPSLOCK
MOVLW 0xAA
MOVWF PPSLOCK
; Set PPSLOCKED bit to disable writes or
; Clear PPSLOCKED bit to enable writes
BSF PPSLOCK,PPSLOCKED
; restore interrupts
BSF INTCON,GIE
 
 end asm

Ik weet alleen niet wat nu SET en wat nu CLEAR is...

Fouten zijn het bewijs dat je het probeert..
Arco

Special Member

Nogmaals: het gaat over de CONFIG registers. (met name het PPS1WAY bit in CONFIG2, dat moet gecleared worden)
Het PPSLOCK register is wat totaal anders.

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
Bavelt

Golden Member

Ok, dat zie ik nu.

Ik moet bit 11 van het CONFIG2 Word op 0 zetten.
Nu kan dat in Pickit, maar ja, die werkt dus niet met de 18857...

En in MLAB X IDE zie ik geen opties om de Config Words te zetten...

Fouten zijn het bewijs dat je het probeert..
Arco

Special Member

Heeft ook niks met pickit of mplabx te maken. Project -> Edit Project in Mikrobasic.

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
Bavelt

Golden Member

Op 20 januari 2021 17:35:37 schreef Arco:
Heeft ook niks met pickit of mplabx te maken. Project -> Edit Project in Mikrobasic.

Is toch niet helemaal juist? Je kunt de waarden van de 5 config register words toch standaard zetten in de CONF bij Pickit3?

Maar idd ook in de MB-project settings:

Maar nu met deze code:

pic basic code:

Spi1_Remappable_Init()                                      'Init SPI1

 Unlock_IOLOCK()
 PPS_Mapping(_RB0, _OUTPUT, 0)                               'Unmap RB0
 Lock_IOLOCK()

 Unlock_IOLOCK()
 PPS_Mapping(_RB0, _OUTPUT, 0x15)                            'map RB0 to Output
 Lock_IOLOCK()

 Unlock_IOLOCK()
 PPS_Mapping(_RB0, _INPUT, 0x15)                             'Unmap RB0 to Input
 Lock_IOLOCK()

 Unlock_IOLOCK()

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

Werkt de SPI1 niet. De matrixen flikkeren wat randon..

In feite kan ik het probleem samenvatten: ik krijg SPI1 bij deze PIC niet aan de praat met de statements zoals ze zijn bedoeld....

Fouten zijn het bewijs dat je het probeert..
Arco

Special Member

Config bits aanpassen in pickit programma is alleen voor noodgevallen, standaard doe je dat in het mikrobasic project.
(anders moet je dat ook na iedere compilatie opnieuw doen, een beetje zinloos...)

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
Bavelt

Golden Member

Op 20 januari 2021 21:42:25 schreef Arco:
Config bits aanpassen in pickit programma is alleen voor noodgevallen, standaard doe je dat in het mikrobasic project.
(anders moet je dat ook na iedere compilatie opnieuw doen, een beetje zinloos...)

Ja dat is natuurlijk ook zo. Het nog mooiere zou zijn als de configs in de source kunnen worden opgegeven. Maar dat had jij al aangekaart bij MB begreep ik.

Fouten zijn het bewijs dat je het probeert..
Bavelt

Golden Member

Maar wat kan ik nu nog proberen met dat SPI?

(Ik zou kunnen overwegen toch naar een andere PIC om te kijken. Die iets 'makkelijker' werkt, zoals de 1847.
Is wel een beetje vluchtgedrag, het liefste had ik dat ik SPI(1 en 2) aan de praat krijg.
Het moet de combinatie SPI2 en I2C1 OF SPI1 en I2C2 worden.
Dan kan ik zowel de MAX7219-matrixen als de Klokmodule DS1307 gebruiken.

Maar tot nu toe geen succes..

Fouten zijn het bewijs dat je het probeert..
Arco

Special Member

Dan kan ik zowel de MAX7219-matrixen als de Klokmodule DS1307 gebruiken.

Ik heb geen van beiden, dus ik kan het niet uittesten voor je... ;)

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
Bavelt

Golden Member

Ik heb het waarachtig voor elkaar! ;)

I2C1 en SPI2. Beide tegelijk! ;)

Hoe deed ik het:
De I2c sluit ik aan op RC3 en RC4:

SCL1 --> RC3
SDA1 --> RC4
Dit zijn de default pinnen voor I2C1

Maar.. Wel eerst even de SDA1/SDO1 en SCL1/SCK1 verhuizen naar een dummy (ongebruikte) pin: RC1 en RC2.

Dan de SPI2 naar RB5 en RB6
SCK2 --> RB5
SDO2 --> RB6

pic basic code:


RC1PPS = 0x14                                               
RC2PPS = 0x15
RB5PPS = 0x16                                               
RB6PPS = 0x17

----
----
I2c1_INit(100000)
Spi2_Init()

En dan werken ze beiden!

De 'dummy pin move' kan ik niet verklaren. Daar zal vast wel iets achter zitten (bv de I2C en SPI van elkaar scheiden of zoiets)...

Fouten zijn het bewijs dat je het probeert..
Bavelt

Golden Member

Na wat opschoonwerk in het programma, een nieuwe dag met vooral nieuwe kansen :), etc, blijkt dat het nog wat simpeler kan.

De 'Dummy' move van de SDA1 / SCL1 naar Poorten C1 en C2 hoeft niet.
Gelukkig maar, omdat ik anders straks een programma had lopen waarvan ik niet weet waarom die het überhaupt zou doen..

Wat blijft er dus:
- De I2C1 standaard pinnen gebruiken (RC3/RC4).
- De SPI2 pinnen verhuizen naar bv RB5 en RB6. (dus niet de standaard SPI2, die op RB1 en RB2 zitten).

Dat blijft nog even een vraagteken.
Normaliter zou je verwachten dat je ook daarvoor de standaard pinnen had kunnen nemen.
De enige verklaring voor mij kan zijn dat de SDI (MISO) wel wordt genoemd bij de standaard, maar de SDO (MOSI) niet.
Die zul je dan atijd moeten koppelen.

Ik hoop dat deze redenatie klopt...

Fouten zijn het bewijs dat je het probeert..
Arco

Special Member

Zoals gezegd zijn de _init() functies een beetje wazig.
Volgens support worden de outputs dan naar hun default positie gezet, terwijl er voor SDO (spi) en TX (uart) helemaal geen default pin bestaat!
Het zou handig zijn als men in de helpfile vermeldt naar welke pin er dan gemapped wordt. Nu moet je met een scoop kijken waar het signaal naar buiten komt...

Bij SCL/SDA (i2c) is het nog duisterder: die hebben ieder een in en output gemapped omdat ze bidirectioneel zijn...

Met zegt dit gedaan te hebben om het programmeren makkelijker te maken, maar ik vind dat het eerder het omgekeerde effect heeft...

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
Bavelt

Golden Member

Daar ben ik het helemaal mee eens. Met name het ontbreken van een default pin voor SDO (of het niet vermelden daarvan).

In ieder geval heb ik het nu aan de praat. Ik kan SCK2 zelfs koppelen aan de default op RB1 (zou eigenlijk niet hoeven), maar heb dat maar niet gedaan. Gevoelsmatig 'wegblijven' van dat default... ;).
Met SPI kan dat ook gewoon.
RB5 en RB6 lijken een 'veilige' :) keuze...

Ik sta nu wel voor de keuze:
Of ik implementeer dit in het Sterrenprogramma, of ik laat de Software_I2C staan.
Die laatste zal ongetwijfeld meer ruimte in beslag nemen. Keerzijde is dat deze PIC met zijn 32K ROM 'vet' in zijn jasje zit:

Zijn er wellicht nog andere overwegingen om tóch de MSSP te gebruiken? (bv stabiliteit, etc)

Fouten zijn het bewijs dat je het probeert..
Arco

Special Member

Als het alleen is om zo nu en dan data te versturen lijkt het me geen probleem.
Ik heb ook een paar keer een pic als ic2 slave gebruikt, dan gaat 't niet werken omdat je direct moet reageren op een inkomend signaal.
Dit omdat je als slave meteen moet antwoorden aan de master in hetzelfde bericht. (kan alleen met de hardware i2c)

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
Bavelt

Golden Member

Ok, nou dan kan ik me nu - na allerlei uitstapjes - weer concentreren op waar het allemaal voor is bedoeld: een sterrenhemel.

Zijn er wellicht nog restricties verbonden aan de lengte van de clock-en datalijn voor de SPI?

Dan bedoel ik zo'n 2-3 meter.

Fouten zijn het bewijs dat je het probeert..
Arco

Special Member

Eigenlijk is SPI niet voor zulke lange afstanden bedoeld, maar als je de bitrate laag houdt zal het best werken.
Het hangt allemaal af van de capacitieve belasting van de bus. Dus het soort kabel, aantal slaves, en de bussnelheid speelt ook mee.

Je moet de capacitieve belasting van de bus zo laag mogelijk houden. (men raadt aan < 1nF@500kHz)

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
Bavelt

Golden Member

Vertaald naar concreet:

Ik heb 8 panelen met sterren klaar. En ze als Matrix gesoldeerd: 8 rijen en 8 kolommen.
Ieder paneel is 120* 60 cm. Ieder paneel heeft 64 Leds. In totaal dus 240 * 240 cm met 512 leds.

Ik kan een print maken met de PIC, en 8 MAX7219 IC's. En dan de draden voor de lED's vanaf dat centrale punt naar de panelen. Dus 16 draden per paneel. Dan worden dus alleen de LED's aangestuurd.
Hiervoor wilde ik UTP kabel gebruiken, mooi met 8 aders en RJ45-plugjes op de print.

Een andere mogelijkheid is om een printje met alleen de PIC (en tijdmodule), en dan vanaf daar naar de panelen, waarbij op ieder paneel een voorgemonteerd printje zit met MAX7219.
In dat geval moet ik de printjes 'doorlussen', net zoals de LED matrixen op een printje.
Dat zouden dan draden zijn voor de +5V, de GND, De Latch, De Clock en Data. 5-aders dus.
Maar wel over een flinke lengte.

Wat zou hiervoor nu te adviseren zijn?

Fouten zijn het bewijs dat je het probeert..

Dit topic is gesloten