Sinds kort ben ik bezig met het programmeren in Embedded C voor AVR (atmels) met AVR-GCC als compiler.
De Uart heb ik al werkende, kan netjes terug sturen wat ik ontvang.
Nu kan het zo zijn dat ik voor een toepassing een onvoorspelbaar aantal karakters binnen krijg.
Moment A kunnen er 10 karakters binnenkomen, maar moment B kunnen er bijvoorbeeld 750 karakters binnenkomen.
Ik weet dat je een Array kunt maken die uit 750 entrypoints bestaat.
is er een methode waarbij je tijdens het ontvangen van een char de array doet redimmen zoals dit in visual basic gedaan word?
Een array van 750 karakters betekend wel een benodigde opslagruimte van 750 bytes (in geval van een uChar variabele), heeft je processor die wel ?. Moet je ze echt eerst opslaan voor je de karakters gaat bewerken ? Kun je niet de binnenkomende datastroom "wegwerken" ?
atmega2560, die heeft 8192 bytes RAM dus dat lijkt me voldoende.
"realtime" processing lijkt me ook niet handig. stel dat alles binnen sijpelt op 19200 baud, dan kun je niet ondertussen nog even de binnengekomen data in hapklare brokken gaan verwerken.
of toch wel?
stel dat de data (waar het uiteindelijk toch op gesplit moet worden) een | als tekenen heeft. dan kan ik natuurlijk wel splitten. maar ik moet nog steeds dat spul opslaan. Het moet uiteindelijk een variabele worden die ik ga gebruiken in de rest van het programma. als er nieuwe data beschikbaar is, dan word de oude overschreven.
[Bericht gewijzigd door Henry S. op (24%)]
Dan zou ik gewoon een (ring)buffer maken die groot genoeg is dat ie niet overloopt die onder interrupt gevuld word met binnenkomende data. Dan heb je de "rest van de tijd" over om met die data nuttige dingen te doen.
Als je dat wil doen zal je geheugen dynamisch op de heap moeten alloceren. Voor microcontrollers is dat niet echt aan te raden maar 8k maakt het toch al wel mogelijk als je voorzichtig bent. Deze pagina zou je opweg moeten kunnen helpen:
is dat niet echt aan te raden
Is mijn idee ook, voor je t weet loopt je stack "in" je variabelen space. Dan liever 2K "verkwisten" aan een grote buffer.
If external RAM is available, it is strongly recommended to move the heap into the external RAM, regardless of whether or not the variables from the .data and .bss sections are also going to be located there. The stack should always be kept in internal RAM. Some devices even require this, and in general, internal RAM can be accessed faster since no extra wait states are required. When using dynamic memory allocation and stack and heap are separated in distinct memory areas, this is the safest way to avoid a stack-heap collision.
dit lijkt me dan nog de beste oplossing.
Extern het spul op slaan. via i2c? een serieel eprom vol schieten? een 256 Kbyte type is al voldoende.
dan hoef je geen array te maken, je moet alleen een counter bijhouden die aangeeft waar je ergens in het externe ram zit.
External ram bedoelen ze SRAM chips mee. De grotere atmega modellen hebben externe data en address bussen die je daarvoor kan gebruiken.
Vraag me wel af wat je dan wil maken. Die UART zijn echt niet zo snel in vergelijking met de throughput van die controllers. Zoals bprosman al zei, waarom verwerk je de data niet direct ofwel gewoon direct een grote buffer maken als je ram genoeg hebt.
Met de mega op 16MHZ heb je 6500 cycles per byte bij 19200 baud. Als jij 6500 cycles nodig hebt om 1 byte te processen dan ben je wel heel iets raars aan het doen.
Gewoon een 256 bytes statische ringbuffer maken. Wel zorgen dat je datastroom enige syncrhonisatie mogelijkheden heeft, zodat je de processing kan resetten (B.v. door bepaalde byte sequence). Door dit interrupt driven te doen (ISR stufft de buffer), kun je in je main de ringbuffer uitlezen en verwerken.
Hier heb je echt geen "heap systeem" voor nodig hoor.