avr veel variabelen opslaan ?

dus je hoeft van te voren niet te vertellen hoe lang de array gaat zijn ?

mijn probleem van bij 0 beginnen is ook meteen opgelost.

zie nu in mijn code dat ik de "column_counter" ook 1x te vaak ophoog: nl. in "start_scan == 1"

Jawel, de lengte van de array ligt vast. Anders kun je die niet gebruiken.

uint8_t Columns[900];

Op een "groter" platform dan de arduino/AVR kan je later opgeven wat de grootte van de array is.

C doet geen "boundschecking".... Dus ook als je de array als 100 bytes declareert kan je het 1000e element van de array adresseren.

Dat "later opgeven" werkt dat met malloc:

uint8_t *Columns;

...
Columns = malloc (900);

Wederom niet omdat het van toepassing is op jou situatie maar gewoon om van te leren.

Over je code: De declaratie staat nu in een blok waar ook statements in staan. Dat betekent dat het binnen een functie is. Dat zou betekenen dat ie "op de stack" zou komen te staan. Enerzijds is ie dan weg (waarde niet behouden) als je returned uit die functie, anderzijds, moet je zeker niet meer dan 10% van je beschikbare geheugen aan automatische variabelen op de stack zetten. Geen wet van meden en perzen, maar gewoon een richtlijn.

Hij moet dus:

static uint8_t Columns[900]; 

zijn om hem als statische variabele te declareren. Dan kan je er alleen bij binnen de functie (als je het binnen een functie doet) waarin ie staat, of als ie buiten functies staat alleen in dat c-file waarin je hem declareert. Anderzijds kan je hem zonder "static" declareren en dan kan je hem bij alle functies in dat file gebruiken (en evt daarbuiten als je dat wilt).

Je array begint altijd bij nul. Je kan niet een array maken die bij 1 begint. (nouja, vandaag geen zin om uit te leggen hoe dat wel kan). Dus als je 900 elementen wil hebben zijn die altijd genummerd van 0 tot 899. Wil je echt 1 tot 900 gebruiken, dan is het makkelijkste om 901 elementen te declareren.

en ik heb nog veel te leren
zeker met arrays en pointers. ik heb straks een c.a. 12 kB aan data opgeslagen in een 23LC1024 (1Mb externe RAM met SPI) waarmee ik moet gaan rekenen, schuiven, groeperen. ik denk dat dit dan veel aan bod komt.

Even een andere invalshoek:

In plaats van telkens de 288 statussen door te zenden, op te slaan, te scannen etc etc... Kan je natuurlijk ook een verzameling maken:

Bijvoorbeeld:

blocked_sensors = { 23, 44, 200, 201 };

Stel dat je moet reageren als er af en toe iets over je raster schuift dan kan je 99% heel snel alleen de lege array even inspecteren.

Zelfs bij volle bedekking is het niet meer ruimte dan je huidige structuur.

Verder, ik weet niet of C voor avr multi dimensionale arrays doet:

Dat is natuurlijk de mooiste structuur voor jouw systeem.

ja C kent 2 dimensionale array.

der zijn inderdaad wel trucjes om tijd/snelheid te winnen, maar daar wil ik me op dit moment nog niet al te veel mee bezighouden, het is zo al lastig genoeg.

zoals al vermeld ga ik uiteindelijk uit de scanner ong. 12 kB aan data krijgen. die ga ik opslaan in een 23LC1024 (1Mb externe RAM met SPI).
in welke "structuur" ik het daar ga opslaan ben ik nog niet over uit, mischien een 2 dimensionale array.
als ik het daar heb op geslagen moet ik er nog bewerkingen mee kunnen doen, onder andere bepalen waar het werkstuk is, en dit "vertalen" naar coordinaten (waar zit de O met puntjes ?) voor de stepper drivers.

ik denk dat een 2D array een beetje lastig is, omdat ik daarmee gebruik moet maken van de adressen in de 23LC1024.

dank voor de reactie.

Op 19 april 2020 09:22:16 schreef trix:
en ik heb nog veel te leren
zeker met arrays en pointers. ik heb straks een c.a. 12 kB aan data opgeslagen in een 23LC1024 (1Mb externe RAM met SPI) waarmee ik moet gaan rekenen, schuiven, groeperen. ik denk dat dit dan veel aan bod komt.

Zoals al eerder gezegd... Jij bent niet goed in de "architectuur" fase van het project. Deels is dat omdat je als architect moet weten wat de bouwstenen zijn en welke er beschikbaar zijn.

Componenten als een megabit extern RAM zijn "handig" voor bedrijven die een product hebben wat al jaaaaren prima werkt, maar nu ineens een paar kilobyte aan geheugen extra nodig hebben. Die hebben dan geen zin om hun ouderwetse 8051 code te gaan porten naar ARM of iets dergelijks dus dan maar zo houden.

Als jij in de master met 12k aan data moet gaan manipuleren, dan is een AVR met 2k intern RAM gewoon een foute keuze. Je kan 1 stapje omhoog gaan naar bijvoorbeeld een STM32. De STM32F405 heeft bijvoorbeeld 192 kilobyte RAM. Genoeg om een 12kb dataset in te manipuleren.

Maar tegenwoordig kost het helemaal niet veel om "over the top" te gaan..... Als je een orange-pi-zero koopt voor ongeveer een tientje, dan heb je 256Mb RAM (*). Dan kan je prima communiceren met de kleinere processoren die de 900 bytes data verzameld hebben, maar je programma op de 'zero kan tenminste makkelijk een paar keer die 12k aan data bevatten....

(*) Het zal wel 512Mb zijn of zelfs 1G. In ieder geval meer dan 1000x meer dan je nodig hebt.

Op 20 april 2020 06:51:03 schreef rew:
[...]Zoals al eerder gezegd... Jij bent niet goed in de "architectuur" fase van het project....

Dit project is volgens mij één grote leerschool en dat kan hem niet meer afgenomen worden, maar ik vrees dat het ganse project van de grond af opnieuw zal gemaakt moeten worden.

Hier zal de software bepalen hoe de hardware eruit mag zien, veel speling heb je niet dan meer, tenzij je herbegint

Mag ik vragen wat er aan data in die 900 bytes zit?
Heb je echt 3 volledige bytes nodig per kolom en zijn de data van alle kolommen relevant voor de andere kant?
ik vind 900 bytes best veel om zo continu te updaten. Dat kan ongetwijfeld efficiënter.

Stel je heb 2 variabelen die niet meer dan 0-15 kunnen bevatten, dan kun je die mooi samen in 1 byte stoppen. (2x 4 bits).
Je hoogt de kolom index steeds op, dus ik vermoed dat de array gewoon history bevat. die hoeft de andere kant natuurlijk niet elke keer opnieuw te krijgen lijkt me? Een slim sync mechanisme en enkel de laatste nieuwe waarde lijken me logischer.

Ik ben toch wel benieuwd wat voor machine/apparaat besturing je aan het maken bent en hoe dat straks gaat werken Leuk van je ondernemendheid en doorzetting vermogen, maar ik zie zoveel vragen omtrend die topic

opmerkingen als, ik doe het nu even zo, mooi en netjes doen we later, daar kun je vergif op innemen dat dat nooit meer gaat gebeuren. Eerlijk gezegd heb ik er een heel hard hoofd in dat het geheel gaat werken binnen de nu gekozen resources. Zoals rew al aangeeft loop je met deze manier van programmeren binnen no-time uit je stack / RAM

[Bericht gewijzigd door Stijnos op maandag 20 april 2020 13:30:39 (17%)

Op 20 april 2020 08:29:28 schreef MGP:
[...]
Dit project is volgens mij één grote leerschool en dat kan hem niet meer afgenomen worden, maar ik vrees dat het ganse project van de grond af opnieuw zal gemaakt moeten worden.
Hier zal de software bepalen hoe de hardware eruit mag zien, veel speling heb je niet dan meer, tenzij je herbegint

Dat heb ik ook al een paar keer gezegd... Beter met een schone lei beginnen, dan krijg je een veel beter en efficienter geheel.
Ik doe dat ook meestal. Als firmware niet makkelijk goed te krijgen is, simpel flowdiagram opstellen en daarvanuit beginnen.
Ik heb in het verleden ook wel doorgeborduurd op een eerste idee. Dat liep bijna altijd onbevredigend af. (ondoorzichtige of niet efficiente code)

Het poldermodel is (ook voor firmware) niet de beste oplossing...

Op 20 april 2020 09:22:00 schreef Stijnos:
Mag ik vragen wat er aan data in die 900 bytes zit?

Het zijn 900*8 bits van een 1-bit variabele die op een bepaald moment in de tijd bij een bepaalde binaire sensor gesampled is.... In theorie is er echt 7200 bits aan informatie....

ohja werd het niet eits van een 3d scanner? 24 bits in 300 posities dan dus eigenlijk.
Tsja hoe dan ook, ik ben benieuwd hoe en vooral wanneer het project eindigd
Mocht je nog iemand in willen huren Trix?

Zal wel geen 3d scanner zijn: daar zijn lichtsluisjes niet echt geschikt voor...

Ik begreep uit een recente post dat de afstand tussen de transmitter en ontvanger ongeveer 1cm is. Dat is veel minder dan wat ik me had voorgesteld vanuit eerdere omschrijvingen van het project...

Uit een eerdere post: (met tientallen topics duurt 't opgraven veel langer als het antwoorden... )

ze moeten ca. 50 cm. kunnen overbruggen.

Idd, zijdelings 1.5cm van elkaar en >=50 cm rechtover elkaar.

Deze morgen nog eens een test gedaan die dik tegenviel.

De TSOP keek door een 1.5mm gaatje in een 2cm dik blokje hout en de kijkbreedte was nog groter dan 10cm.

Toen werd er ook opgemerkt dat die TSOP van alle kanten te benaderen viel, zowel zijdelings, boven of achterzijde.
Zag zelfs de weerkaatsing aan de achterzijde op mijn voeding.

Er bestaan TSOP's in een metalen jasje maar die heb ik niet om te proberen.

Op 20 april 2020 06:51:03 schreef rew:
Deels is dat omdat je als architect moet weten wat de bouwstenen zijn en welke er beschikbaar zijn.

Als jij in de master met 12k aan data moet gaan manipuleren, dan is een AVR met 2k intern RAM gewoon een foute keuze. Je kan 1 stapje omhoog gaan naar bijvoorbeeld een STM32. De STM32F405 heeft bijvoorbeeld 192 kilobyte RAM. Genoeg om een 12kb dataset in te manipuleren.

vooral welke beschikbaar zijn, daar heb ik inderdaad niet genoeg kennis van.
ik heb een bepaald eisen pakket, en daar heb ik binnen de AVR's de meest geschikte gekozen: de atmega2560 (of mischien de minst slechte). eigenlijk was het enige waar de 2560 niet aan voldeed: onvoldoende RAM.
maar buiten de AVR's heb ik niet gekeken, niet dat ik dat niet wil, maar omdat ik die niet ken. maar ik wil graag hier mijn eisen pakket neer leggen, en hoop op een goede sugestie (eisen pakket slaat op de AVR,...dat je niet denkt dat ik van julie iets eis )

- los component (dus geen module).
- in C te programeren.
- lieftst met Atmel studio 7
- min. 60-70 I/O.
- min. 8 Mhz.
- min. 20 kB RAM
- eeprom (voor settings vast houden bij power off)
- UART
- I2C
- makkelijk verkrijgbaar en ook b.v. over 5 jaar nog.

als ik het zo terug lees, lijkt het mij niet zo veeleisend.

post dit alvast, probeer ik zo meteen nog te schetsen wat de bedoeling is v/h geheel.

Voor een paar euro heb je een pic met 16k of 32k (of meer) ram...

Even nog een schep ongevraagd en goed bedoeld advies:

Wil je niet eerst alles in software op de PC of laptop bouwen? De 288 sensoren al dan niet via AVRs naar USB en eerst in welke programmeertaal dan ook, of zelfs enkel met logging je concept toetsen.

- een "scanner" bestaande uit 288 lichtsluisen die 10 mm uit elkaar zitten (= 2.88 mtr.) verticaal geplaatst.
- die lichtsluisen noem ik vanaf nu TSAL & TSOP, dat is kort en "praat" makkelijk, maar word mischien nog een ander component.
- tussen de TSAL & de TSOP zit ca. 85 cm.
- in het midden daarvan paseert een werkstuk (werkstuk is nergens smaller dan 100 mm).
- bij elke 10 mm (passeren werkstuk) word er een "scan" gemaakt. maximaal 300 X (= ook 3mtr.)
dus.
- resultaat is dus: een matrix van 288 x 300, met een onderlinge afstand van 10 mm.
- uitgangspunt = de "scan" uit te voeren met 6 mtr./min. (kan meer of minder worden, afhankelijk v/d mogelijk heden).
- dat is per "scan" 100 mS.

de fysieke opbouw:
- 12x PCB TSAL en 12x PCB TSOP. (nu zo gemaakt dat het allemaal dezelfde zijn)
- is dus per PCB 288/12 = 24 TSAL of TSOP = 3 byte
- per PCB 1x atmega 16 (word waarschijnlijk atmega 32)

werking:
- idee is dat er maar 1 lichtsluis actief is, dan ben je zeker dat TSAL #30 niet TSOP #29 of #31 belicht.
- dus eigenlijk op TSAL & TSOP een "looplicht" die synchroon is.
- 1e idee is om die 288 TSAL/TSOP in een "beweging" te scannen. dat geeft 100 mS/288 = 350 uS per lichtsluis. lijkt mij niet realistisch dus:
- opdelen in blokken zodat er meerdere lichtsluisen tegelijk actief kunnen zijn.
- blokken van 24 lichtsluisen = dus 1x PCB en dus 1x atmega16 (voor TSAL & TSOP)
- probleem: dat TSAL #1 TSOP #25 belicht (beide de 1e van een PCB)
- word nog aan gewerkt om hier goede componenten voor te vinden, TSAL liefst kijken in een straal (i.p.v. kegel) TSOP liefst alleen "licht" uit 1 richting acepteren.
- mogelijkheid is grotere "blokken" maken maar geeft weer minder tijd (elk voordeel heeft zijn nadeel )

software:
- de main PCB (nu atmega 2560) stuurt elke keer dat het werkstuk 10 mm aflegt gelijktijdig aan TSAL & TSOP comando: start scan
- TSAL & TSOP starten hun "looplicht" zodanig dat ze synchroon blijven, (start moment is gelijk en de pulsduur ook)
- TSOP slaat elke keer (is dus elke 100mS) de data op, is dus 3 byte per atmega 16.
- dit doet hij 300 keer is dus 900 byte in de atmega 16
- 12 X TSOP PCB is dus 12x900 ca. 11 Kbyte.
- aan het einde v/d totale scan vraagt main PCB: TSOP #1 send me your data
TSOP #2 send me your data
TSOP #3 send me your data
- waar het verder word verwerkt in de nu nog atmega 2560.

Ik geef het maar op. Na al die topics begrijp ik nog steeds niks van de werking...
(als je 288 outputs hebt, hoef je maar 36 bytes te hebben, geen 900... )

AVR's met 20K ram zijn er niet.
Misschien wel in de XMEGA serie, al is die familie volgens mij nooit heel populair geworden.
Ik snap best je redenatie. Ik ken AVR goed dus dat is uitgangspunt voor mijn nieuwe project.
Ik heb ongeveer 9 jaar altijd alleen maar met AVR's gewerkt, omdat kostprijs technisch in ons bedrijf nu eenmaal de gunstigste controller was voor wat we nodig hadden.
Ik ken die dingen dromen. Daar kende ik ongeveer elk bitje van elk peripheral wel bij wijze van spreken.
En die moest je ook gebruiken zo in je code.

Echter zag ik ook wel de opkomst van de arm processoren, maar ik zat zo in die AVR dat het me een te stijle leer curve leek. De manier van coderen leek me zo anders dan ik gewend was en heb er daardoor hobby matig nooit de tijd voor gevonden om het te proberen/leren.

Ander half jaar geleden moest ik voor een freelance klus wel gebruik maken van een Arm, door een wifi implementatie en eisen van usb, encrypted firmware update etc. Het is een STM32F412 geworden. Ik zag op tegen de leer curve, maar gelukkig met wat opstart hulp snel de manier van werken ontdekt en ik ben om.
Qua documentatie vind ik persoonlijk ST erg goed, maar ook worden er bij de meeste gangbare ARM's goede HAL drivers bijgeleverd. Die lijken soms moeilijk, maar maken je het wel makkelijker om niet meer elk peripheral bitje te moeten weten. (Uiteraard moet je het nog steeds goed configureren, daar je veel meer opties hebt)
Maar om een lang verhaal kort te maken, het kost inderdaad wat investeren, maar nu pak ik net zo lief een Arm van NXP of STM. Dan heb ik voor hetzelfde geld wel een controller die met gemak op 100MHz draait, 512KB of 1MB flash heeft en 256K RAM. (En daarbij erg toekomst bestendig is)

Wat is het doel van je systeem? Je beschrijft wat hij functioneel doet, maar wat is de toepassing? Of kan je daar niks over zeggen?

Op 20 april 2020 21:39:59 schreef Arco:
Ik geef het maar op. Na al die topics begrijp ik nog steeds niks van de werking...
(als je 288 outputs hebt, hoef je maar 36 bytes te hebben, geen 900... )

die 288 outputs zijn verdeeld over 12 atmega's

je "denkt" verticaal, maar je moet eigenlijk horizontaal denken.

288 outputs =
36 bytes =
3 bytes per PCB =
3 byte per atmega
de atmega maakt 300x een scan
is dus 3x300 = 900 bytes

even uit mijn post gepikt:
- TSOP slaat elke keer (is dus elke 100mS) de data op, is dus 3 byte per atmega 16.
- dit doet hij 300 keer is dus 900 byte in de atmega 16

Op 20 april 2020 21:48:38 schreef Stijnos:
wat is de toepassing? Of kan je daar niks over zeggen?

de uiteindelijke toepassing wil ik nog even voor mezelf houden, voegt ook niks toe, hooguit voor de beeld vorming.

heb je voor zo'n ARM soms ergens een beginners artikel, om te kijken hoe dat werkt ?

Op 20 april 2020 20:39:51 schreef K7Jz:
Even nog een schep ongevraagd en goed bedoeld advies:

Wil je niet eerst alles in software op de PC of laptop bouwen? De 288 sensoren al dan niet via AVRs naar USB en eerst in welke programmeertaal dan ook, of zelfs enkel met logging je concept toetsen.

het concept werkt, dat is geen punt, is ook echt niet moeilijk. enige onzekere factor is nog: hoe de lichtsluisen in de scanner te maken, dat is iets fysieks, kan niet of moeilijk op de PC worden gedaan.