AVR GCC (ATMega128) Как да организирам оптимална опашка от масиви?
Правя измервания на нещо, примерно, 100 пъти в секунда получавам по 4 байта.
Целите измервания са по разни прекъсвания (таймери и АЦП).
Резултати трябва да ги записвам на SD карта, което е сравнително бавно и го правя в главна програма.
Сещам се за два начина (благодарности за други предложения):
1. един кръгов буфер, например с 100х4 байта, пълнещ се при измерване, а всеки път, когато главната програма се натутка - записва новополучената част от буфера на SD.
2. опашка, която да се пълни по прекъсване и, след запис на SD, да се празни от главната програма.
Вторият начин е по-професионален щото не държи 400 байта винаги заети, а и организационните конфликти са по-малко.
Обаче (2) изисква непрекъснато заделяне и освобождаване на памет и не зная какво ще стане след фрагментирането на паметта.
И не съм уверен, че в (2) ще успея да се оправя с указателите , поне не без ваша помощ.

Така, че очаквам преложения, идеи и коментари . Вероятно има много подобни примери и описания на подобни неща, но не ги намирам.

Зависи от файловата ти система...
Обикновено такива като fatfs си имат кеширане поне на ниво сектор (512 байта). Демек може много начесто да пишеш по малко байтове, а то ще ги кешира в РАМ докато не се напълни сектора и чак тогава ще почне трансфер към картата. В случая най-добрата стратегия е при първа възможност да викаш write_file() ако ще и за 1 байт.
Но ако ползваш файлова система без никакъв кеш ще трябва да внимаваш на колко големи парчета пишеш, т.е. ще е добре повече да буферираш отвън.

Зависи също и от мениджера на паметта. По-масовите имат стратегия при заделяне, т.е. не ти връщат първия свободен блок, ами преравят за най-подходящия. При подобна стратегия вероятността някога фрагментирането да ти прави проблеми клони към нула...

В случая обаче аз не виждам нужда от динамична памет. Един кръгов буфер си е ОК.

Ползвам това: http://www.roland-riegel.de/sd-reader/index.html
Има едно "#define USE_DYNAMIC_MEMORY 0", но и да е включено, не виждам да се ползва при запис на файлове (ползва се при заемане на дялове и директории).
(за мен все още стила на C не е много обозрим, тоя драйвер има пет H файла и няколко C файла - има много да ровя )
ОК, вероятно за сега ще го направя така. По нататък ще му мисля.

Не знам... това жувотно има само 4К нали?

Ще имаш ядове с паметта... само дето не мога да разбера що се мъчите. Като гледам цените на Атмел между куртексите и мегите няма голяма разлика...

Само дето куРтексите са значително по сложни. Къде къде по лесна е работата с мега.. на 2 кратки реда съм установил даден извод като изход и съответно стойност.
Това на куртекса (м3) не можах да постигна (само на 2 реда). Да не говорим , че всеки производител слагал негова си библиотека. Имената на регистрите - и те различни от производител до производите (за периферията). В примерите за куртекс рядко някой се сеща да напише аджеба, защо в даден регистър записва например 0х0055AC00, еместо да го напише разбираемо като (1<<REG_BLA) | (1<<REG_BLABLA2) и т.н. После викай ти - учи куртекс..
Ей, и без да се засягате

по принцип си прав - има проблеми.... и няма пълно щастие

Но конкретно преходът от мега към атмелски куртекс би трябвало да е по-лек щото периферията е много близка да не казвам една и съща... А и специално Атмел имат доста прилично АПИ за хардуера, константи, макроси и т.н.