Sterrenhemel Deel2

Op 2 mei 2021 17:05:11 schreef Arco:
Ziet er goed uit.
Wat ook interessant is, is om te meten aan de Gnd tussen begin en eind van kabel met de scoop. Daar mag zeker niet meer als 0.8v verschil tussen zitten...

Is wat lastig te meten, mede vanwege de helderheid, maar dit is het verschil tussen de GND op het breadboard en de laatste MAX, dus met ca 15m UTP en nog ca een meter flat cable er tussen.
Véél meer dan in de daadwerkelijk opstelling...

De 'piefjes' aan het begin van de pulsen zijn ca 0,8v tt

Ik kan het signaal nog wat 'schoner' krijgen als ik er een HCT132 Schmitt-trigger tussen de PIC en de MAX zet.

DC verschil gemeten met Voltmeter is 138mv.

Het aardige is dat als ik de scope uit -en aan doe (zit o.a. een dikke trafo in) dan zie je het spul (ledjes) reageren. Maar door de MAX7219-Init() die ik nu in de loop heb meegenomen herstelt het spul zich.

Dat is wel hoopvol moet ik zeggen...(in het kader van de lekkende kraan wat verzachten)

De scope, een Philips PM3231 is een oud beestje maar wel een fijn ding.
Het enige probleem wat hij met zich meedraagt is dat wanneer je géén ÁC-signaal hebt, je ook geen beam krijgt. Daardoor kun je geen DC meten met het ding.

Daar zal in het trigger-circuit iets niet lekker zitten, maar heb ik nooit kunnen herstellen...

-

[Bericht gewijzigd door Bavelt op zondag 2 mei 2021 22:15:26 (100%)

Ik heb nu een clockfrequentie van 32Mhz, met als Prescaler 8, Post 1 en een PR van 99.
Dat levert een Timer Interrupt van 100 uS op met in het kiezelzog de afgeleide timers (voor o.a. de IR Remote).

Ik kan natuurlijk ook kiezen voor 16Mhz en dan de Post op 4 zetten. Dat levert wederom 100us Timer interrupt op.

Het voordeel is dat ik een dan nóg lagere frequentie voor de SPI kan instellen. Deze gaat dan van 31.250 naar 16.125 Khz.

Dat kan met

SSP2ADD  = %11111111 

Ik denk dat hoe lager hoe beter ivm mijn problemen.

Zit hier nog een denkfout of kleeft er wellicht een ander nadeel aan een lagere klok?

[Bericht gewijzigd door Bavelt op 2 mei 2021 21:23:34 (100%)]

Ondertussen had ik hier in de testopstelling de proef op de som genomen, 25 meter (!) UTP aangesloten, bestaande uit een paar kabels, met koppelstukjes.
Hele nacht probleemloos gedraaid zonder enige hapering...

Met de voorzichtige angst dat wanneer ik deze print straks installeer in de eindbestemming er weer allerlei problemen opduiken.

Dan ligt het zéker aan die losse Max-printjes met de kabels.

We gaan het meemaken.

Ik heb voor de zekerheid op de print achter de PIC16F1847 een 74HCT125 geplaatst, met een redelijk stevige Pull-Up van 4K7.
Vanaf daar gaat het nu naar de panelen, zodat die niet meer rechtstreeks aan de microcontroller hangen.
Dat heb ih gedaan voor de SCK, de SDO en de CS.

En nu maar eens kijken hoe dit zich manifesteert. Hier thuis loopt het allemaal nog steeds als een zonnetje..met een onwaarschijnlijke lengte aan UTP kabel...

Dit is het eindresultaat. De ledjes zijn ter test even in de connectors geplaatst.

Je leert toch steeds nieuwe (vaak onverwachte) dingen, meestal als er iets niet werkt...

Ik heb een applicatie waar de timer2 interrupt op 100uS staat. Timer wordt ook voor PWM gebruikt.
Ik gebruikte 16MHz wat goed werkte met setting prescaler 4, pr2=99.

Ik wilde het omzetten naar 32MHz dus ik dacht: wordt dan prescaler 4, pr2=199.
Op zich werkt dat ook, alleen doet de PWM dan raar. Tijd naar gezocht, blijkt dat de waarde in PR2 het aantal bits PWM resolutie beinvloedt.

Ik dacht altijd dat prescaler 4, pr2=199 gelijk was aan prescaler 8, pr2=99, maar dat is dus niet zo als je PWM gebruikt...
Het laatste werkt goed, het eerste niet (de PWM resolutie gaat dan naar 10 bits met alle vreemde verschijnselen van dien)

Op 3 mei 2021 16:24:57 schreef Arco:
Je leert toch steeds nieuwe (vaak onverwachte) dingen, meestal als er iets niet werkt...

Ik heb een applicatie waar de timer2 interrupt op 100uS staat. Timer wordt ook voor PWM gebruikt.
Ik gebruikte 16MHz wat goed werkte met setting prescaler 4, pr2=99.

Ik wilde het omzetten naar 32MHz dus ik dacht: wordt dan prescaler 4, pr2=199.
Op zich werkt dat ook, alleen doet de PWM dan raar. Tijd naar gezocht, blijkt dat de waarde in PR2 het aantal bits PWM resolutie beinvloedt.

Ik dacht altijd dat prescaler 4, pr2=199 gelijk was aan prescaler 8, pr2=99, maar dat is dus niet zo als je PWM gebruikt...
Het laatste werkt goed, het eerste niet (de PWM resolutie gaat dan naar 10 bits met alle vreemde verschijnselen van dien)

Ja, dat zijn dus van die dingen waar je achter komt als het niet werkt, zoals ik ook al vaak heb ervaren.
Maar zoals gezegd, dingen die niet werken zjn ook leer-en oefenstof..

Ik heb de module hier nog steeds draaiend. De print staat boven, de LED's via een hele lange kabel in een ander vertrek beneden.
Het blijft hier gewoon werken...

Op 2 mei 2021 17:46:33 schreef Bavelt:
De 'piefjes' aan het begin van de pulsen zijn ca 0,8v tt

Klinkt als "mwah, zou moeten kunnen"... Maar bij gebleken problemen: Ik zou de flanken proberen te verzachten door de door mij voorgestelde RC te implementeren.

Het blijft hier gewoon werken... ?

Heb je de watchdog nog aanstaan? Als je die aan hebt en de max-herinint dan ben je tolerant voor fouten. Als je de fouten ZOEKT, dan wil je dat juist niet.

[Bericht gewijzigd door rew op maandag 3 mei 2021 19:54:06 (26%)

Als ik de weerstand van 220 Ohm opneem in de CLK leiding dan gaat het mis; de matrixen slaan dan op hol.
Dat kan natuurlijk worden veroorzaakt doordat ik in elke MAX7219 moduultje op de panelen al een weerstand van 2K in de CLK en SDO had opgenomen.

Ik heb inderdaad de Watchdog aanstaan, en ook de powermodule werkt. De hoofdschakeling levert iedere 2 seconden een puls. Als die niet meer komt
- dat moet dan zijn omdat de processor hangt of in de stress zit - dan wordt de power voor 2 seconden uitgeschakeld en daarna weer aan gezet.
M.a.w. het spul hangt aan het infuus en de hartbewaking (omdat ik er een ledje aan heb gehangen zie je een ware hartslag )

Daarbij heb ik nog wat gewijzigd: de klokfrequentie van de SPI heb ik nu teruggbracht naar 15.625 Hz.
Dat is zó laag, dat je al in het audio gebied komt...

Het oogt stabieler. In mijn testopstelling thuis krijg ik het spul niet aan het hangen. Loopt gewoon door. Wat ik ook doe aan 'verslechteringen', zoals lange kabels, koppelstukken etc.

De 'productieonmgeving', dus de panelen aan het plafond, is nog niet maximaal gelukkig.
Het loopt wel door met die bewakingsapparatuur, maar het gebeurt na verloop van tijd dat er spontaan ergens op een willekeurig paneel zomaar een stuk of 5 Ledjes gaan branden, zonder dat die data er naar toe is gestuurd.
Dan doet zo'n Max-muduultje 'maar wat'...

Spanning er af, en het werkt weer zoals het hoort.

Nu moet ik het laatste paneel er nog even afhalen. Daar zit nog iets niet lekker in de bedrading. En bij dit paneel kan ik nog bij zonder een heuse verbouwing.

Daar zit dus het laastste Max-Moduultje (de 8e).

Zou het nog zin / nut hebben daar iets van een afsluitweerstand aan te brengen op CLK of SDO? Of heeft dat weinig zin met deze lage klokfrequentie?

Op 30 april 2021 11:28:55 schreef Arco:
[...]
Gewoon een account, speciale Nederlandse zijn er niet.
Volgens mij moet je onder de 50 euro gewoon porto betalen, alleen klanten met 'gold status' niet...
(vroeger was alles inderdaad gratis, maar zo'n bestelling van $1.42 zoals van @2N3055 worden ze natuurlijk niet echt blij van...)

Ik heb het net even geprobeerd. Account gemaakt en 3 Pic-jes besteld voor $5,44.

Worden geen verzend- of andere kosten in rekening gebracht. Betaald via PayPal..

Ondertussen heb ik mijn pijlen ook even gericht op de voeding.
(omdat Arco dat ook al noemde).

Want ik zie dat wanneer ik de scope aan-en uitzet, de processor en/of Max-en daar meteen op reageren. Ze verspringen, andere inhoud, etc.

Ook met een trafo aan-en uit zetten zie je reacties.

Daarom vroeg ik me af: omdat hij het hier altijd goed doet en daar waar hij nu is gemonteerd zich toch wel raar gedraagt, zou het wellicht kunnen dat door - bv het aanspringen van een verwarmingsketel (pomp, etc) 'rare' dingen gebeuren?

Een flinke pief op de voeding, op de kabels, zoiets?

De voeding is een geschakelde 5V adapter (2A) die aan het aansluitpunt van het plafond zit (waar normaal een plafonière hangt. Het huis heeft maar 3 groepen, dus alles hangt zo'n beetje aan elkaar.

Zou dat wellicht een storingsbron kunnen zijn?

Zoals je het beschrijft "doordat ik in elke MAX7219 moduultje op de panelen al een weerstand van 2K in de CLK en SDO had opgenomen." is het natuurlijk helemaal fout. Dus teken even een schema hoe je dat gemaakt hebt. Gewoon grote strepen snel thuis... module is een vierkant met draden in en draden uit en als interne componenten: die weerstand en hoe ie aangesloten is. (ik zou ook de max tekenen in het blokje, maar weglaten hoe ie precies is aangesloten. Nouja, de CLK draad is wel interessant).

Op 5 mei 2021 22:36:02 schreef rew:
Zoals je het beschrijft "doordat ik in elke MAX7219 moduultje op de panelen al een weerstand van 2K in de CLK en SDO had opgenomen." is het natuurlijk helemaal fout. Dus teken even een schema hoe je dat gemaakt hebt. Gewoon grote strepen snel thuis... module is een vierkant met draden in en draden uit en als interne componenten: die weerstand en hoe ie aangesloten is. (ik zou ook de max tekenen in het blokje, maar weglaten hoe ie precies is aangesloten. Nouja, de CLK draad is wel interessant).

Nou , hierbij dan een kladje (echt lange halen, snel thuis. Ik heb nog geen Programma onder de knie waarmee ik schema's kan tekenen).

waarmee ik schema's kan tekenen

Ben zelf fan van KiCad, is open-source ook nog en levert prima "maakbare" Gerbers op.

Ter info: "zoals je "nr 6" getekend hebt, dat is waar ik naar vroeg.

Je hebt dus vanaf de doorgaande lijn een serie weerstand van 2k naar de pin van de chip opgenomen. Dat houdt bij iets meer "ongein" de chip heel, maar eigenlijk zijn het dingen die je zowiezo niet wil.

Omdat daar toch geen stroom loopt, is de spanningsval over die 2k weerstand als het goed is ongeveer nul. (bij een AVR of PIC staat er iets van "max 1 µA" dus dan hebben we het over "max 2mV" aan spanningsval. Alles wat je op de doorgaande CLK draad zet komt op de CLK pin van de chip. Dus als je zegt: Met 220 Ohm in serie op de zendende kant werkt het ineens niet meer, dan denk ik dat we daar een hint te pakken hebben van dat er iets mis is. Dus... zoek het uit wat er mis is zou ik zo zeggen. Meet met een scope hoe signalen er uitzien...

Op 6 mei 2021 12:19:50 schreef rew:
Ter info: "zoals je "nr 6" getekend hebt, dat is waar ik naar vroeg.

Je hebt dus vanaf de doorgaande lijn een serie weerstand van 2k naar de pin van de chip opgenomen. Dat houdt bij iets meer "ongein" de chip heel, maar eigenlijk zijn het dingen die je zowiezo niet wil.

Omdat daar toch geen stroom loopt, is de spanningsval over die 2k weerstand als het goed is ongeveer nul. (bij een AVR of PIC staat er iets van "max 1 µA" dus dan hebben we het over "max 2mV" aan spanningsval. Alles wat je op de doorgaande CLK draad zet komt op de CLK pin van de chip. Dus als je zegt: Met 220 Ohm in serie op de zendende kant werkt het ineens niet meer, dan denk ik dat we daar een hint te pakken hebben van dat er iets mis is. Dus... zoek het uit wat er mis is zou ik zo zeggen. Meet met een scope hoe signalen er uitzien...

Dat had ik dus al gedaan, zie

https://www.circuitsonline.net/forum/view/message/2262754#2262754

Die 2K weerstanden had ik van een ander Forum (ik weet niet meer precies waar). Dat was iemand die vrijwel hetzelfde probleem had als ik, en had de oplosing gevonden in de 2K weerstanden in serie met SCK en Data. Samen met de parasitaire capciteit van de chip vormde dat een soort 'RC-netwerkje'.

Het hielp mij ook toen; ik had rare verschijnselen maar toen nog met slechte bedrading. Die heb ik later verbeterd met de UTP kabel en degelijke connectors.

Het signaal ziet er volgens mij wel redelijk uit. Toch?

Ik heb de clockfrequentie inmiddels nog verder teruggedraaid tot 15.625 Khz.
Wellicht kan ik het nóg verder verlagen, ik heb nl geen belang bij hoge snelheid. Het wisselpatroon tussen de sterren ligt ergens tussen de 3 en 5 seconden.

Thuis krijg ik het spul niet aan het 'hangen' en werkt het continu goed.
Zelfs met een heel lange kabel.

Op de bestemming liep het deze nacht deze keer helemaal door.

Ik ben toch ook nog met de voeding bezig. Dat vertrouw ik ook nog niet helemaal.

Een van de functies is dat alle sterren langzaam uit gaan. Tot de Counter op nul staat. Maar het gebeurde onlangs dat er na afloop toch weer een paar ledjes aansprongen.
Iets dergelijks kan ik hier nabootsen door mijn oude scoop, die in de buurt staat, eens flink aan-en uit te zetten. De schakeling reageert daar direct op.

Ook deze symptomen kan ik in het programma bestrijden. Na afloop van het uitzetten van alle leds worden in een loop doorlopend alle leds uitgezet.

Dus mocht er nog eentje branden, wel, dan wordt-ie alsnog uitgezet.
Dat werkt wel.

Wat dus volgens mij in de probleemzone blijft:

- De voeding
- De Max-printjes op de panelen zijn niet allemaal gelijk en komen van tante Alie.

Ik ben nog wat aan het puzzelen met de PIC16F1847 maar kom er niet helemaal uit.

Hewt ding heeft een aantal timers. Timer2 gebruikte ik voor de interrupt.
Die verhuis ik naar Timer4.

Want dan heb ik Timer2 'vrij', je kunt de SPI clock laten afhangen van de output TMR/2 volgens de Datasheet.

Ik dacht dat te doen door:

T4CON      = %00011100                                      'Pre: 4 - Post:1
PR4        = 99
GIE_bit    = 1                                              'Enable timer4 irq
PEIE_bit   = 1
TMR4IE_bit = 1                                              'Enable Timer4 overflow interrupt
TMR4If_bit = 0                                              'Clear Timer4  overflow interrupt flag bit

Dit werkt wel, de interrupt loopt keurig, maar het vervolg:

T2CON      = %00011100                                      'Pre: 4 - Post:1
PR2        = 99                                              'Period Timer 2
SSP2CON1   = %001000110                                      'Clock by Timer 2

Werkt niet. Het vreemde is dat met deze statements het programma ook niet meer loopt.

Update: Het SSP2CON1 Statement verstoort de boel. Die heeft blijkbaar ook invloed op de delays, etc.
Wat gaat hier nu fout?

(NB en wat is precies Output Tmr2 / 2? Moet ik daar ook een aparte interrupt afvraging voor doen?

Er zat een foutje in bovenstaande post.

Maar het probleem met TMR2 heb ik nog:

SSP2CON1 = %00110011

Dat zou inhouden: SPI2 clock = TMR2 Output / 2

fOsc =16.000.000 Mhz

Met:

T2CON      = %01111111                                       'Pre: 64 - Post:16
  PR2        = 249                                             'Period Timer 2
  SSP2CON1   = %00100011

Dat zou dan moeten betekenen dat de frequentie wordt:
16.000.000 / ((4 * 16 * 64 * 250) / 2) = 31, 25 Hz. Heel laag dus.

Dit werkt chter niet.

Wat is hier nu de denkfout?

Ik ben er uit!

Zo werkt het:

  OSCCON     = %01111000                                      '16 MHz internal
  T4CON      = %00011100                                      'Pre: 4 - Post:1
  PR4        = 99
  GIE_bit    = 1                                              'Enable timer irq
  PEIE_bit   = 1
  TMR4IE_bit = 1                                              'Enable Timer1 overflow interrupt
  TMR4If_bit = 0                                              'Clear Timer1 overflow interrupt flag bit

  WDTCON = %00011011                                          'WatchDog 8 Sec Timer

  SPI2_Init()
  Delay_ms(10)
  
  T2CON      = %00001100                                      'Pre: 2 - Post:1
  PR2        = 249                                            'Period Timer 2
  SSP2CON1   = %00100011                                      'Timer 2 for SPI Clock

Met Timer4 stel ik de interrupt in, door het 'spelen' met Timer 2 (post- en prescale + PR2) kan ik de SPI clockfrequentie los daarvan instellen.

In het voorbeeld is de Clock ca 6 Khz.

Nu vroeg ik me af:

Is een lage SPI altijd goed als je de snelheid niet nodig hebt? Het lijkt me dat hoe lager, hoe minder gevoelig voor storingen, etc.

Is die veronderstelling juist?

Het hangt er een beetje vanaf waar de storingen vandaan komen.

Als jij 1000 bits per seconde MOET versturen en je doet dat op 6kHz, ben je 1/6e van de tijd aan het zenden. Doe je het op 1Mhz, dan ben je maar 1/1000e van de tijd aan het zenden.

Nu is SPI niet echt afhankelijk van hoeveel tijd je neemt: Op iedere CLK flank moet een slave het databit inlezen. Als op dat moment een storing het databit omgooit, dan heb je een bitfout. Het window waarbinnen dit kan gebeuren is vrij klein, zeg 100ns. Dus hoe je die 1000bitjes ook verstuurd er is 1000 * 100ns = 100 microseconden per seconde aan "gevoelige tijd". Dan denk je: Dat is heel weinig, dat is maar 1/10000e van de tijd. Maar als er 50x per seconde een storing is, die een bitje omgooit, dan heb je na gemiddeld 200s je eerste bitfout te pakken.

Wat wel uitmaakt is of de boel tijd heeft om te stabiliseren. Als je op 1MHz probeert de boel uit te sturen, maar je signaal heeft 0.6 microseconde nodig om netjes op het juiste spanningsniveau te komen, dan is dat voor het klok signaal net te weinig.

Langzamer dan zeg 100kHz heeft dan denk ik weinig zin. 5 microseconde is voor moderne elektronica een zee van tijd.

Je moet ook de lengte van de kabels en de latency van alle 7219 printjes meerekenen.
Er zit een delay tussen het inkomende signaal en het uitgaande signaal (naar de volgende 7219).

Als je veel printjes aan elkaar knoopt, gaat bij ieder volgend printje de data meer 'uit de pas' lopen met de clock.
Dan wil je liefst geen supersnelle SPI clock...