Sterrenhemel

In eerste instantie heb ik de settings.ini weggedaan. Die bouwt hij dan opnieuw op.

Hielp niet.

Daarom maar MB opnieuw geinstalleerd. Het probleem is nu over.

Ik sleep wel altijd na installatie direct het compiler output window ('messages') naar rechts, da's veel handiger.
Onder de sourcecode neemt 't veel te veel ruimte in beslag en heb je maar weinig ruimte over op het scherm voor code.
(16:9 schermen zijn sowieso niet erg optimaal voor tekstweergave... )

Dat deed ik ook zelf...opschuiven van de message window.
Want als hij onderin staat, laat het inderdaad weinig ruimte over voor de code...

Nou, alles doet het...

Sterrenhemelprogramma, nu mét Watchdog. Deze ga ik binnenkort installeren op de 'echte' sterrenhemel en kijken hoe het gaat.

MikroBasic ook in het gareel..en geen gekke schermen meer.

Dus op naar het volgende experiment!

Mbt Great Cow Basic: Dat schijnt open source te zijn. Is dat een redelijk alternatief voor MB?
(en in het bijzonder de doorontwikkeling daarvan)?

Volgens mij is Great Cow basic iets tussen picbasic en mikrobasic in...
(het heeft nog steeds de vreemde namen van picbasic zoals hSerin en out, en lijkt ook in de verte op Mikrobasic)
Ik denk dat Mikrobasic een wat beter ontwikkeld product is...

Nu ik de sterrenhemel aan het plafond heb gemonteerd en eerdaags de software versie met 'watchdog' als een 'zelfhersteller' installeer, is het alvast een moment voor een eerste evaluatie.
Achteraf had ik - zoals sommigen al aangaven - niet met lange kabels en SPI moeten werken.
Dat is daar gewoon niet voor bedoeld.
Wel had ik één print kunnen maken en draden naar de LED's waar geen protocol overheen hoeft. Had 108 draden betekend.
Of een heel andere techniek, met LEDstrips en WS2812 o.i.d.
Of zelfs met een projector met glasvezels... Heel wat anders.

Maar om nu helemaal opnieuw te beginnen is eigenlijk niet te doen. Maar wellicht met wat modificaties kan ik het toch gewoon in de lucht houden.
Zo bracht ik al serieweerstanden aan in de MAX7219 moduultjes naar de SCK en SDO (Uit een andere post).

In het zoeken kwam ik de 74LS244 tegen, een line driver.

Omdat het eerste paneel wél kort op de print zit (ca 20cm), zou het nog zin hebben om de line driver 74LS244 op het printje met PIC te monteren en vanuit dit ding de 'lijn' op te gaan?
Of heeft dat helemaal geen zin? (de andere 7 panelen zijn voor invoer / uitvoer 'doorgelust', maar de SCK van alle panelem komt rechtstreeks vanuit de uC)

Maar om nu helemaal opnieuw te beginnen is eigenlijk niet te doen. Maar wellicht met wat modificaties kan ik het toch gewoon in de lucht houden.
Zo bracht ik al serieweerstanden aan in de MAX7219 moduultjes naar de SCK en SDO (Uit een andere post).

Noem mij eigenwijs , een "Drammert" maar geef gewoon iedere MAX7219 een eigen processor , en laat ze via RS485 met elkaar babbelen. Dan hoef je geen 108 draden te maken, en je kunt het zelfs nog parallel aan het huidige systeem opbouwen. Je kunt het per paneel aanpassen (toevoegen).

Op 24 april 2021 19:49:10 schreef bprosman:
[...]
Noem mij eigenwijs , een "Drammert" maar geef gewoon iedere MAX7219 een eigen processor , en laat ze via RS485 met elkaar babbelen. Dan hoef je geen 108 draden te maken, en je kunt het zelfs nog parallel aan het huidige systeem opbouwen. Je kunt het per paneel aanpassen (toevoegen).

Nee hoor, zeker geen 'Drammert'...
Ieder idee is altijd welkom! Dankzij de inbreng van anderen ben ik zo ver gekomen!

Het 'praten' met elkaar zou dan via een commando kunnen via een Poort (Aan of uit). Als dat niet snel hoeft (5 sec wijziging) zou dat zelfs met een gewone draad kunnen lijkt me. Er hoeft immers geen verkeer over, althans geen echte snelheid.
Hangt een beetje af welke functionaliteit ik dan nog wil (De RTC had ik er al afgehaald).

Het is alleen wel zo dat de panelen er dan weer afmoeten...Dan mag ik de boormachine wel opladen..8 * 9 = 72 lange houtschroeven...Groot bed dat er onder staat helemaal uit elkaar, anders kan je er niet bij...
Tja..

8 losse processoren voor zo'n simpel klusje is ook een knoeiboel.
Er zit gewoon wat niet goed en dat moet je oplossen. (alles eraf slopen wat niet werkt kan ook, maar da's niet echt het probleem oplossen.)

Op 24 april 2021 22:54:13 schreef Arco:
8 losse processoren voor zo'n simpel klusje is ook een knoeiboel.
Er zit gewoon wat niet goed en dat moet je oplossen. (alles eraf slopen wat niet werkt kan ook, maar da's niet echt het probleem oplossen.)

Ja ok... mee eens.

Maar als de lange bedrading de hoofdoorzaak blijkt (m.a.w. een ontwerpfout) dan valt er weinig op te lossen, en kom je in de sfeer van de boel dusdanig modificeren dat het werkbaar is.

De Watchdog met zijn reset, met behoud van waarden is al heel wat vind ik
Zachtjes reset de boel zonder dat je het in de gaten hebt omdat de waarden behouden blijven. Behoudens als de processor zelf hangt en Watchdog ook niet meer werkt.

Vandaar dat ik zocht naar een error-handling van de SPI. Dat wanneer daar iets stokt, ik de boel ook kan resetten. Ik las iets over WCOL maar ben daar nog niet verder mee.

8 losse processoren voor zo'n simpel klusje is ook een knoeiboel.

Het is wat overkill maar RS485 gekoppelde processoren die ieder "hun eigen ding doen" , centraal aangestuurd is wel retestabiel.

Als harde tweede maatregel zou het wellicht ook denkbaar zijn dat er een 'power reset' komt als de zaak écht vast zit.
Dan zou ik een schakeling moeten hebben die dat doet. Wellicht een andere processor die met Watchdog wacht op de andere processor en dan Power off-on doet?

Of is dat heel gek gedacht?

Dat is het echt Nederlandse poldermodel...

Als iets niet werkt dan bouwen we een constructie om toezicht daarop te houden, in plaats van de zaak in orde te maken.
Werkt 't dan nog niet, dan bouwen we iets daaromheen wat daar weer toezicht op houdt...

Niets zegt ook dat het met 8 losse processoren wel goed gaat (je weet immers niet wat er aan de hand is?)
Als de resetknop niet meer werkt, is er wat heel, heel erg mis toch...

Je denkt nu dat het aan de SPI verbindingen ligt, maar daar is totaal geen bewijs voor. (ik geloof dat ook niet)
Ik gok toch op te dunne voedingsdraden van de processor naar de max7219's, waardoor ontoelaatbare spanningsverschillen ontstaan.

Juiste methode is debug code in te bakken zodat je kunt zien wat er mis gaat.
Extra watchdog processor heb ik pas 1 keer ooit toegepast bij aansturing van heel zware solenoids (2kW per stuk)
Als extra veiligheid: als de processor vast zou lopen met aangetrokken solenoids, dan verbranden ze binnen een paar minuten, daar zijn ze niet voor gemaakt.

Op 24 april 2021 23:27:54 schreef Arco:
Dat is het echt Nederlandse poldermodel...

Grappig dat je dit aanhaalt. Maar het is een feit, we leven hier in het 'Polderland'. Maar onze samenleving is er van doordrengt.
Als je bv meer zou investeren in betere wegen (Oplossing) dan voorkom je nóg meer investering in ziekenhuizen (symptoombestrijding)...

Maar dat is politiek.
Gelukkig houdt electronica zich daar niet mee bezig. Alhoewel die ook niet altijd doet wat voor ogen stond...

Ik ben zelf niet zo overtuigd dat de voedingsdraden te dun zijn. Als ik die UTP kabel-aders zo bekijk, zit er toch best wel een stevige harde kern in. Het geheel trekt weinig stroom, getuige het feit dat de sterrenhemel na uitschakeling nog heel kort op de voedings-elco van 1000 uF doordraait.

Daar komt bij dat de schakeling akelig lang draait als ik de voeding verlaag: pas bij 2,7 Volt begint hij raar te doen.
De 'maan' als 'grootverbruiker' met zijn 68 ledjes heeft zijn eigen voedingsdraden, net als de Marsledjes. Die zijn dus niet doorgelust met de UTP kabel en onafhankelijk van de MAX7219 moduultjes.

Waarom ik zelf de SPI wantrouw, is gebaseerd op mijn eerste opstelling op een breadboard en de panelen met Dupont verbindingen en draden. Daar vlogen de panelen (toen nog niet aan het plafond) in de stress. Er hoefde maar even een stekkertje te rammelen (gebeurt al snel met dat Dupont spul) en voilá, de boel stond op tilt.
De RJ45 connectoren en UTP bekabeling bracht daar een aanzienlijke verbetering in. Ook de serieweerstanden van 2K op de MAX7219 moduultjes naar de SCK en SDO gaven stabilisatie.

Ik schrok ook even van een Post dat lange draden vaak een 'antenne' vormen. Nooit bij stilgestaan.

Maar goed, het spul zit aan het plafond bij een vriendin. Met een groot bed eronder dat al een uur kost om het uit elkaar te halen en opzij te zetten. Anders kun je er niet bij.
Dat maakt het 'troubleshooten' een stuk lastiger.

Het wijzigen van de panelen om ze ieder van een processor te voorzien kan, maar dan moet het hele spul er af. Plus dat ze de sterrenbeelden (Orion, Grote beer) met elkaar moet afstemmen. Dat vraagt wel een en ander van het programma.

Terwijl het nu op zich wel redelijk draait, op een hangsessie af en toe na.
Dat brengt me terug naar het begin: inderdaad niet de beste oplossing, maar de gaten in de weg dichten met een beetje teer ipv een nieuwe weg aanleggen.

De Watchdog zoals Arco al aangaf werkt heel goed. Bij een timeout volgt een reset en het programma gaat verder waar-ie was gebleven.
Het enige issue dat nu in feite rest, is dat soms de processor zélf niks meer doet, dus ook niet 'Watch-dogged', waarvan Arco al zegt dat er dan iets wel héél erg mis is.
Maar zoals al gezegd, rammel maar eens vanuit een breadboard aan de SPI draadjes naar een MAX7219-LedMatrix en je moet toch echt de voedingsspanning er af halen, 10 seconden wachten tot de elco's leeg zijn etc, en daarna weer aandoen. Dan wil-ie wel resetten.

Vandaar mijn idee om een laatste 'noodverband' aan te leggen en een - weliswaar niet ideaal- maar werkend iets te hebben zonder fysieke brekerij.

Ik heb al een beetje gezocht, en het lijkt dat de oplosing naar een schakeling met Power MOS FET (IRF9110?) kan liggen.

Ik heb nog nooit met MOSFET's gewerkt.
Maar wellicht heeft iemand nog een leuke schakeling waarmee de Power vanuit een uC kan worden aangestuurd?

NB sorry voor het lange verhaal...

NB sorry voor het lange verhaal...

Maakt het alleen maar leuk en geeft inzicht waarom je bepaalde keuzes maakt.

Ik vond dit moduultje nog in mijn 'voorraadje'

Daarmee kan je spanningen in-en uitschakelen. Werkt met een relais, maar is geen punt (je kunt er zelfs 250 V mee schakelen).

Zo'n ding is er denk ik makkelijk tussen te monteren...

Ik heb meteen wel weer een uitdaginkje:
Op de PIC16F1847 had ik nog 1 poort vrij: B.2
Dacht ik tenminste.

Maar deze poort is geassocieerd met o.a. SDA2, SDI2 en SDO1.

Omdat ik SPI2 gebruik, wordt deze poort door SPI2_INIT() gezet en is B.2 niet meer bruikbaar. (vanwege SDI2 denk ik).

Ik lees wel in de datasheet dat ik in het SSpxCon1 de poorten kan loskoppelen van I2C en SPI. Maar dan kan ik SPI2 weer niet gebruiken...

Is de conclusie dan deze poort dan 'verloren' gaat vanwege het gebruik van SPI2?

Ik denk het wel. Een SPI poort bestaat nu eenmaal uit een data in, data out, en clock... (en bij een slave ook nog een slave select)

Wat ik (en denk anderen met me) nog steeds mis is een schema. Teken eens op papier uit hoe je alle componenten en bedrading hebt aangesloten. Dan kunnen we allenmaal mee kijken. Misschien is het iets simpels wat je over het hoofd hebt gezien.
Op je foto van je print zie ik bijvoorbeeld maar 1 ontkoppelcondensator bij je PIC, maar niet bij het andere IC. Zie er enkel nog 1 bij je voedingsconnector. Dat is te weinig. En misschien heb je nog een aantal foutjes gemaakt?

Je bent nu symptoom bestrijding aan het doen. Je lost de oorzaak niet op, maar probeert het gevolg op te bestrijden. Gevolg is dat de oorzaak van je probleem blijft bestaan en steeds andere gevolgen kent.

De SDO1 kan met APFCON worden verplaatst. De SDA2 is niet spannend, dat is I2C en gebruik ik niet.
De SDI2 bederft het feestje...

Werkt het dan niet als je SDI2 ook als input gebruikt? (dat de SDI eraan blijft hangen hoeft niet erg te zijn)

Op 25 april 2021 16:18:47 schreef Arco:
Werkt het dan niet als je SDI2 ook als input gebruikt? (dat de SDI eraan blijft hangen hoeft niet erg te zijn)

Hmm. Vat ik even niet..Ik wil Poort B.2 (of liever: LATB.2) gebruiken als output.

Zo heb ik hem ook gedefiniëerd in de TRIS. Maar na de SPI2_Init() is die poort niet meer beschikbaar als Output...

TRISB  =     %00000000                                      
LATB.2 = 1    ' <---Dit werkt.  
SPI2_Init()

Maar:

SPI2_Init()
LATB.2 = 1    '<---Dit werkt niet.  

[Bericht gewijzigd door Bavelt op 25 april 2021 22:40:34 (20%)]

Gebruik hem als input, dat zal wellicht werken (output werkt zeker niet...)

Tja, dan zou ik poorten moeten omruilen.

Ik heb maar één input poort: voor de IR-sensor. De rest is output.
Het werkt inderdaad als ik B.2 definieer als Input en daar de sensor aan hang.
Dan heeft-ie dus geen last van de SPI2-Init()

Deze wordt wat aan de lange kant, ik heb hem even opgeknipt, deel 2 staat hier:

https://www.circuitsonline.net/forum/view/154294