avr veel variabelen opslaan ?

Op 3 mei 2020 11:32:16 schreef trix:
..
die 3 databytes worden in de tsops opgeslagen (worden er 900 tot.)
en naar de master gestuurd als die daar om vraagt.
[...]

Ja, omdat de scantijd zo hoog is ben je bijna verplicht om het zo te doen.

3 bytes per TSOP PCB (1x atmega 16)
12x TSOP PCB
300 x scannen
3x12x300 = 10800 bytes

dus uiteindelijk zitten er straks 10800 bytes in de ext. RAM. die vertegenwoordigen een raster (matrix) van 3x3 mtr. waarin het werkstuk met allemaal "1"-en.
aan de hand van die data wil ik dus de steppers sturen om het werkstuk na te tekenen.

ik verwacht geen cheksum o.i.d. dergelijks nodig te hebben, omdat ik weet dat bepaalde bit combinaties onmogelijk zijn. dus ergens 1,2 of 3 losse "1"-en negeer ik, ik heb dit al eens eerder filteren genoemd. mischien voldoet dit niet aan de verwachting, dan moet er een cheksum komen.
de data overdracht over de RS485 gaat relatief langzaam (9600 boud), de kabel is kort ( 5-10 mtr.) verwacht daar ook geen "corupte" bytes van.

wat ik al eerder heb gezegd: het project is redelijk groot, maar zeer goed in te delen in blokken die na elkaar moeten worden afgehandeld. bijna niets gaat tegelijk.
van een zo'n blok ben ik achter gekomen dat er wel meerdere dingen tegelijk moet gaan, is voor nu nog geen probleem, maar gaat het later denk ik wel worden. en dat zijn de steppers, gaan nu nog 1 voor 1 maar moeten met meerdere tegelijk kunnen, volgens mij heeft stijnos in een topic van mij ooit iets over gepost, hoe dit normaal gaat.

als je een machine wilt programeren kan je inderdaad het best vooraf volledig in kaart brengen hoe je dit gaat doen, maar dan moet je (dus ook vooraf) veel kennis van programeren hebben,...en die heb ik dus niet,....bij mij is het meer "trail & error". geluk is dat het allemaal blokken zijn zodat ik het overzicht nog wel kan houden. en omdat ik julie af en toe iets mag vragen, gaat het wel lukken
bovendien zal een goede programeur in sommige gevallen denken:....ja het werkt zo wel, maar ik kan het beter zo en zo doen want mischien willen ze nog ooit iets toevoegen.....is bij mij niet aan de orde. dus b.v. de ext. RAM schrijven van uit de UAST ISR,.....wat "quick & dirty" is voldoet voor mijn toepassing.

Op 3 mei 2020 12:54:38 schreef trix:
ik heb dit al eens eerder filteren genoemd. mischien voldoet dit niet aan de verwachting,

Dit heet "salt and pepper filtering".

is dat erg

Op 3 mei 2020 09:16:14 schreef henri62:
[...]
Het is ook de bedoeling dat trix er iets van leert, dus niet nu al met hele slechte dingen aankomen.

Die hoop heb ik stilletje een beetje opgegeven en probeer nu vooral met parktische oplossingen. Dan maar minder netjes. Er is niet de intentie om een volwaardig firmware engineer te worden begrijp ik

Anyway ik bedacht me gisteren nog iets, wat je zou kunnen helpen om het wat netter te maken Trix.
Ik gebruikte jaren geleden op de AVR een uart library van Peter Flury
https://github.com/damadmai/pfleury)
(je hebt enkel uart.c en uart.h nodig dacht ik)
Daarin zitten de ISR's die de uart data al automatisch in een ring buffer zetten.
In je mainloop kijk je continu met een

 uin8_t data = uart_getc();
if (data != UART_NO_DATA) {
 SPI_Transfer(data);
//of wat nog meer
}

Zo hou je het schrijven in de spi RAM toch netjes buiten de interrupt.

Normaal gesproken lijkt me het laden van de SPI in de UART interrupt toch de beste manier. (op een meer geschikte processor na dan... )

De snelheid staat of valt met hoe efficient die compiler je code omzet naar assembly.
Ik zou voor SPI geen library gebruiken en die paar regels direct inkloppen; ik schat dat dat 4x zo snel (of meer) is...
Dat scheelt je in ieder geval een call en return bij iedere interrupt.

mischien dat ik het begrip ringbuffer niet goed begrijp, maar volgens mij heb ik daar niks aan. ik moet gewoon in 1x 10800 bytes v/d atmega16 (TSOP) over de UART naar de atmega 2560 en dan in de ext. RAM, liefst zo snel mogelijk.

Op 4 mei 2020 07:47:44 schreef Stijnos:
[...]
Er is niet de intentie om een volwaardig firmware engineer te worden begrijp ik

ik ga inderdaad geen cariere switch doen, heb ik de leeftijd ook niet meer voor

mag ik dit nog een keer onder de aandacht brengen:

ik heb nu op een vrije poort 8x een LED geplaatst om de geheugen plaatsen in de ext. RAM binair te kunnen uit lezen, met 2 drukknoppen kan ik het adres verhogen en verlagen (met de code stuur ik een begin waarde mee nu dus 1000)
nou valt mij op dat de niet beschreven adressen een random waarde bevatten. ik had hier overal 0xFF verwacht ?

Een ringbuffer is wel de beste (netste) oplossing maar geeft overhead.
Zoals ik in mijn vorige post vermeldde is het laden van de SPI in de UART-rx interrupt het snelste. (lieftst zonder libraries)

Op 4 mei 2020 10:16:18 schreef Arco:
(op een meer geschikte processor na dan... )

Precies. Er worden problemen gecreerd door domme keuzes aan het begin. Voor een tientje heb je een "master" controller met genoeg geheugen voor 13000 plaatjes van 19kb. En dan moet er hier het schrijven naar SPI ram in een interrupt geprutst worden omdat iemand data van interrupt naar main doorgeven niet aan de praat krijgt....

Daar gaat het niet om: doorgeven van interrupt naar main en vandaar weer naar spi geeft veel onnodige overhead...
Direct alles in de interrupt afhandelen is veel sneller. (zeker bij hogere baudrates als bijv. 115k2)

Je moet met een kleine controller nu eenmaal roeien met de riemen die je hebt...

[Bericht gewijzigd door Arco op 4 mei 2020 18:48:49 (17%)

RAM geheugen is niet gedefinieerd na opstarten. Daar staat meestal random data totdat er iets wordt geschreven.

ok, ik dacht ergens gelezen te hebben dat er overal 0xFF staat
kan ook eigenlijk niet, nu ik er over nadenk.

keuze v/d proccesor is natuurlijk in het begin gemaakt, gebaseerd op hetgeen wat ik kende, en dat was niet veel
maar het voldoet aan alles eisen die ik had, behalve te weinig RAM. en die is eenvoudig uit te breiden.
er zullen wel proccesors zijn die sneller en beter zijn, met ik weet wel niet hoeveel RAM. maar ik heb dat niet nodig, 13000 plaatjes opslaan ? totaal nutteloos voor deze toepassing. alsof je met een ferrari boodschappen gaat doen.

ik vind natuurlijk ook wel, dat je voor het moderne snelle spul moet kiezen. maar ik kende het gewoon niet, en wat ik wel kende voldeed, en nu is er geen echte noodzaak om over te stappen.

[Bericht gewijzigd door trix op 4 mei 2020 20:12:57 (74%)

Op 4 mei 2020 19:59:59 schreef trix:
ok, ik dacht ergens gelezen te hebben dat er overal 0xFF staat

Dat is flash. Lege flash begint met 0xff.

dan was ik daar mee in de war, tnx