Пишу прогу для СС3200 - у этого проца всего 256 Кбайт памяти,
из которой 64 кБайт используется как память для хранения констант и прочего
остается ~192 кБайтпод код стек и др.
Я изменил скрипт линкера, так как мне нужна очень большая куча -
под нее я выделил 128 кБайт - это место для RTOS, буферов
для скидывания на SD и прочего 2048 под стек, осталное на код.
Пока работал с портом, все хватало - начал дописывать функции
для работы с WiFi и сокетами - выскакивает ошибка, что мол не лезет в flash
Я компилирую при отключеной оптимизации,
если включаю ее - начинает влезать.
но мне это не очень нравится, так как эта оптимизация может отключить
некоторые куски кода, которые я неверно или в чем то неправильно написал
ошибки конечно исправляются, но как сделать с отключенной оптимизацией
и вообще, почему такая ошибка возникает ведь суммарно объем кода
получается меньше чем место под код в моем СС3200?

Из вашего сообщения ничего не понятно. Вы не могли бы написать нормально? Приложить скрипт линкера и текст ошибки.
Линкер IAR вполне конкретно говорит, сколько именно места не хватило и в какой секции.
Если у Вас действительно не хватило памяти (а похоже на то, раз Вы говорите про оптимизацию), то что тут поделаешь? Жмите код, юзайте оптимизацию по размеру.

Увы, это жизнь. Большинство моих проектов тоже не помещаются без оптимизации, и это неудобно.
Вариантов много - учиться писать код с меньшим количеством ошибок, исключать одни куски кода/функциональности на время отладки других.
Но в целом это предупреждение, что ресурсов выбранной платформы может не хватить для реализации желаемой функциональности, поэтому следует все внимательно взвесить.

Да, конечно, размер выделенных областей памяти удивляет.
Какое-то обоснование существует?

Из написанного совершенно ясно следует, что нималейших обоснований не существует.
А из того, что на какой-то неведомо для чего нужный стек, при одновременном поминании RTOS, выделяется 2K и того, что хипу отдается не вся остающаяся память, а тоже чего-то там "выделяется", совершенно ясно, что и не будет никаких обоснований . "Не лезет во Flash" это вообще прикол для устройства без пользовательского Flash на борту.
Про отключение оптимизации вообще помолчу.

Вариант ОДИН - учиться писать и перед тем, как начинать писать, думать, что и в какой последовательности. Это фундамент.

Для сбрасывания на SD карту нужны большие блоки.
увы..опытным путем установлено : какие бы SD карты не были,
какого класса - чем реже на них происходит запись,
тем меньше сбоев.
у меня 4-8 АЦП с частотой дискретизации 1 кГц накапливаются
буферы, которые я поочередно сбрасываю на SD карту.

1кГц 12 байт/пакете 3 сек на 1 буфер: 3000 отсч. и 36000 байт в пинге или понге
сответсвенно для разных частот (до 4 кГц) размер буфера может меняться

что таракан с оторваными ногами, если постучать по столу, никуда не побежит. Вывод - таракан слышит ногами.

, если работа с SD картой написана так, что Автор боится даже включать опимизацию , очевидно, не говоря уже об аккуратной работе с буферами карты, обработке ошибок и состояний карты. Цикл работы SD карты привязан к размерам ее внутрених блоков и от того, что Вы что-то у себя будете накапливать, ей ни холодно ни жарко.

вот только для карты
большая разница писать в нее 10 раз в секунду и 1 раз за 10 секунд.
и без разницы на
ее внутренние цыклы и блоки

Читайте по буквам - никакой. Забрасывается в карточку, типично, 512 байт и записываются. Всякие перекуры по 10 секунд, создаваемые Вами, ей по барабану.

нет не по барабану.
у нее есть параметр связанный с поиском клевого сектора взамен сбойного
и время этого поиска будет больше чем время записи 512 байтного сектора

1) Это время будет по любому и совершенно без разницы, получите эту задержку при попытке записать многокилобайтный буфер или нет. Таймауты записи, кроме всего прочего, тактируются SPI/SDIO и совершенно детерминированы и если Вы можете позволить себе еще и дикие многосекундные паузы, то времени ДЛЯ ЗАПИСИ у Вас просто неменяно.
2) Пы пытаетесь морочить голову ТЕПЕРЬ задержками, хотя разговор начали с:

На что и получили мои возражения.

ага..и при подходе следущего буфера предыдущий просто потеряется

Что-то теряться может только из-за кривизны Вашего ПО.
Ни SD-карта ни малый объём ОЗУ тут не помеха.
12 байт с частотой 4кГц это всего == 48000 Б/сек - это просто ни о чём, при размере блока SD ==512байт, это частота записи блоков меньше 100Гц - ни о чём.
Для записи на SD-карту достаточно буфера в 512 байт. Если боитесь каких-то мифических задержек поиска, создайте очередь из неск. блоков, максимум - десятка. Это будет никак не 128кБ.
В моём текущем проекте я пишу поток данных с АЦП во флешь (правда не SD, а 2шт. SPI-Flash) со скоростью минимум 114000 б/сек (и выше), при этом по этому SPI-каналу этот поток проходит трижды:
запись во FRAM, чтение из FRAM, запись в 2-е FLASH с чередованием. При этом в SPI-канале ещё остаётся время для фоновых транзакций других процессов с FRAM и FLASH.
Пишущий этот поток процесс обходится буфером размером 256 байт (одна страница SPI-flash) + ещё 2-3 десятка байт на накопление.
Загрузка процессора (Tiva CM4 120МГц) процессом записи потока - менее 10%.
Естественно - никаких переполнений/потерь и т.п. ни в каком случае не случается - ни с оптимизацией ни без.

Если Ваш код перестаёт работать при включении оптимизации, совет один - ищите баги! А не замазывайте их отключением оптимизации. Включение оптимизации и проверка с ней - это кстати хороший тест на наличие багов.

ЗЫ: И кстати - отлаживаю этот свой проект я сейчас в ОЗУ (флешь МК не использую, код и данные в ОЗУ) размер которого как раз ==256кБ. И ещё много его свободного осталось.

Максимальное время задержки операции записи детерминировано, вот исходя из него размер буфера и СЧИТАЕТСЯ.
Считается, а не берется с потолка, "подкрепляется" "аргументом", что чем реже писать, тем меньше глюков, и после этого спрашивается на форуме куда подевалась память.

херня. ничем не подкрепленая
SD карты затыкались на время до секунды.
и если нет буфера на это время и больше - будет потеря.
все остальное на уровне болтовни

У Вас порядок предложений перепунан. Правильно так:

"SD карты затыкались на время до секунды.
херня. ничем не подкрепленая"

"Успехов" в стучании головой в стену да еще и находящуюся в противоположном направлении движения.
Счастливо оставаться!

"Херня" - это то, что у Вас в исходниках.
А у меня с SD-картой всё работало на 512 байт без каких-либо потерь.

Знаете, а мне приходилось сталкиваться с большими задержками при записи на SD/SDHC карты.
Если писать секторы строго последовательно, то в самом начале записи ~600 мс задержка - карта выдает неготовность, а затем сплошным потоком.
Если запись в произвольные секторы, то такие задержки постоянно.
Поэтому я делаю сперва запись данных, сплошным потоком, а потом пишу FAT.
На чтение никаких задержек.
Где-то говорилось, что задержки обусловлены внутренним алгоритмом "перемешивания" карты.

Вы сейчас помянули еще одну сущность, которая к собственно к процедуре записи никакого отношения не имеет - это файловая система Что, как и кем там реализовано, и как надо делать для исключения отвлечений на запись файловой сисемы, если она вообще нужна, это отдельный разговор. И она вообще не поминалась в этой теме.
А что касается собственно записи, то Вы же сами и написали, что при секвенальной записи никаких проблем. Все остальное к собственно записи потока даных не имеет - все пишется в нормальном темпе без задержек.

Да я собственно только хотел уточнить причину возникновения задержек при записи и как их избежать.
Наверное все, начинающие работать с SDcard, наступают на эти грабли.
А тут все пишут, что задержек в принципе не существует, что неверно.
Прошу прощения за оффтопик.

Задержки на запись блока - существуют, их максимум определен, но он никак не приближается ни к секундам ни к сотням миллисекунд. Все вопросы о сотнемиллисекундных задержках следует переадресовывать к тому, кто написал такой софт в котором лезут такие задержки.

Тут такое никто не утверждал. Более того - из сообщения ТС совсем не явствует, что он использует ФС (хотя из его сообщения вообще мало что явствует).
Задержки внутри middleware ФС предугадать сложно, в то время как задержки SD-карты прописаны в её блоке данных, считываемом на этапе инициализации.

вот в этой теме неск, лет назад уже разбирали
http://electronix.ru/forum/index.php?showt...=89678&st=0

Вот не соглашусь с Вами.
Специально открыл документ

"Copyright 2001-2006 SD Group (Panasonic, SanDisk, Toshiba) and SD Card Association
Physical Layer Simplified Specification Version 2.00"

там написано:
A High Capacity SD Memory Card indicates R2W_FACTOR as a fixed value.
Maximum length of busy is defined as 250 ms for all write operations. The host should use 250 ms
timeout (minimum) for single and multiple write operations rather than using R2W_FACTOR.

R2W_FACTOR - это поле CSD (card specific descriptor)
Могут быть такие задержки.

PS
Опередили.
Ну в общем я тоже самое хотел сказать.
Тут даже на обсуждение ссылка есть.

Итого: 48000/512*.25 = ~24 блока по 512байт, но никак не 128кБ

хм, тогда не ~24 блока а ~24 секунды
то есть при максимальных задержках получается что запись одной секунды звуковых данных может растянутся в 24 раза
И сколько буфер не бери, все равно труба вытекающая меньше втекающей =)

P.S. Хотя я такого реально не наблюдал, тоже пишу на SD но в два потока и c использованием FatFS

Я на этом спор прекращаю, т.к. не вижу смысла.
Я специально выделил жирным в копипасте документа.
Хост должен быть готов к таймауту 250 мс.
Дальнейшее можем обсудить по ссылке inventor'а, если есть желание.

Не понял, какие 24 секунды????
48000 б/сек - скорость потока записываемых данных, делим на размер блока 512, получаем кол-во блоков записываемых в секунду, умножаем на длительность задержки 0.25 секунд.
Получаем кол-во блоков, которые могут накопиться за время задержки. В реале надо взять с небольшим запасом - 1-2 блока.


И что? Я уже посчитал какой размер буфера нужен для устойчивости к такой задержке.
У ТС в 10 раз больше. и при этом у него ещё и потери.....

первоначально не указана размерность, поэтому вполне справедливо можно и так посчитать: 48000 байт / 512 байт * 0,25сек = 24 сек

и по примеру Копейкин`а, не указано, что хост получит только одну задержку, значит задержка может проявлятся и постоянно. Или нет ?

...производится со скоростью 2K в секунду и это предел в 24 раза МЕНЬШЕ желаемого.

Если такая задержка появляется постоянно, значит это карта с ну очень мееееееееееееееееееееееееееееедленной потоковой скоростью записи.
Настолько медленная, что таких не существет
Нет сейчас в продаже карт со скоростью записи менее неск. МБ/сек.
Такая большая задержка как я понимаю, появляется в момент стирания блока (возможно 64кБ (или большего) блока), далее этот блок пишется, задержки записи на порядки меньше, и след. задержка стирания будет по достижении границы след. блока стирания. Размеры блоков стирания - см. уже упомянутый CSD.

короч че спорить - все что делается - нужно делать с избытком.
у меня буферы с запасом минимум на 2 секунды - сбоев пока не было.
если сокрашаю время до полусекнды - начинает сбоить

Да.

Причем, напомню, что ТС начал разговор не задержек и не с потерь, а с дивного утверждения, что ему буфера нужны вообще для того, что-бы РЕЖЕ ПИСАТЬ, типа каких-то "сбоев" меньше.

Просто чуть выше была ссылка на некий документ, который регламентирует макс. длительность операции записи. Прочитали и возрадовались, но вроде бы этот документ не говорит, как часто происходит вот эта аномально долгая операция.
Кстати, потоковая скорость записи - она же усредняется по некоторому достаточно большому промежутку времени. И высокая скорость записи не противоречит возможности появления двух подряд операций записи по 250 мс, к примеру. А почему бы и нет? Мы же не знаем, какой именно алгоритм они туда заложили.
Выходит, официальный документ не гарантирует спокойной жизни. Приходится полагаться на свидетельства бывалых товарищей и прочие вести с полей.

Как я понимаю - никаких поисков блоков контроллер карты не производит. Если имеется в виду обычная запись на карту без ФС в непрерывную последовательную цепочку секторов,
то длительные задержки (операции стирания) будут появляться среди коротких задержек (операций записи) с периодичностью равной отношению размера блока стирания к размеру блока записи (см. CSD).
Все эти счётчики износа - это что-то из более высокоуровневнего ПО (либо из SSD), контроллеры SD-карты, имхо, такое не реализуют.

Да, ещё насколько помню, карты умеют делать групповую запись, накапливая некоторое кол-во секторов во внутреннем буфере и потом записывая скопом. Здесь тоже может быть некоторая неравномерность задержек.
Но всё равно - потоковая скорость записи при непрерывной линейной записи секторов, должна быть константой на некотором интервале усреднения.

Вроде всё с точностью до наоборот.
Современные карты (SDXC) требуют extFAT, потому как "wear leveling" не производят.

Приведите соответствующий раздел спецификации SD, где указано что она это делает.

Вот здесь привести документ или цитату не могу.
Честно скажу, информация косвенная.
Основана на предупреждении с упаковки новой карточки SDXC, где было сказано
использовать FAT32 недопустимо, только extFAT.
extFAT создана для FLASH носителей требующих выранивание износа и т.п.
Тогда как SDSC/SDHC прекрасно обходились FAT16/32.

The controller in Delkin’s Industrial SLC microSD cards implements an
efficient bad block management algorithm to detect the factory-produced bad blocks and manage
any bad blocks that appear with use.

http://delkinoem.com/oem-engineering-specs...icroSD-Spec.pdf

я не понимаю к чему спор, мы выпускали сейсмооборудование -
предыдущий разработчик делал 2-е резервирование
в случае сбоя. т.е. ставил 2 SD карты
что там пишут прооизводители - это все реклама
практика - критерий истыны: чем реже пищешь тем надежнее

Мы пишем на карточки разнообразные звук и видео в очень больших объемах. Эффекты наблюдаются при этом самые потрясающие. В том числе и задержки записи (карточка уходит в Busy) до 3 секунд. На девственно чистой карте этих задержек нет. Там есть максимум специфицированные 250 мс или около того. После того, как карта будет записана полностью, часть файлов стерта и записана снова, и так еще пару раз - начинаются большие задержки. Некоторые новые карточки сделаны аккуратно и не имеют этого эффекта. Увеличение размеров буферов помогает, но не сильно. Для борьбы с ним найден единственный разумный способ - при стирании файлов карточке нужно сказать, что место этого файла свободно. (Команда Erase на карту) Свежие версии файловых систем под Linux (fat и ext4) это поддерживают, и в сочетании с правильным указанием параметров при создании разделов и монтировании (выравнивание разделов и элементов файловой системы на 16 МБ) это приводит к отсутствию больших задержек при записи даже при большой скорости.

Спасибо, весьма полезная информация.
А про выравнивание по 16Мб - это откуда?

А чего было "искать"? Естественно, что нужно flash стирать перед использованием, тогда не придется делать этого в процессе записи. Естественно, что при использовании классических файловых систем и сооответсвенно "форматировании" это не делается, ибо либо ничего не делается, либо при полном форматировании заполняется тестовым паттерном.

Групповая запись экономит время, но ещё лучше перед командой групповой записи выдать команду с информацией о размере планируемой записи. Цитату не приведу, у себя пока блочную запись не использую. При записи на карту потока 48 кГц-моно-16 бит заметные задержки (выражающиеся в росте количества буферов, ожидающих записи на карту) иногда происходят, как и у других участников, на время до секунды-полутора, при использовании 96 килобайт буферов потерь данных из-за пропусков практически не происходит (но бывает). Карты на малые объёмы (2/4 GB) меньше страдают задержками.
Интерфейс (4 бит или MMC/SPI) не влияет.

Вот сколько не пробовал на SD и SDHC, не попадались мне карты, которые этой информацией пользовались бы.
То есть разницы просто не наблюдается, увы

Значит, я не много потерял, не внедряя это в свой код.

Кстати, да.
С этим эффектом я тоже столкнулся в своё время.

Все это конечно интересно, но чем докажете?

По моему опыту никаких задержек нет. Максимум 160 мс.
Но вот плохой выбор файловой системы вполне может увеличить их в два раза.
В два раза ухудшает скорость работы с картами и форматирование карт на FAT16 и уменьшение AU до 512 байт.

Карты из магазина, не перформатирую.
Пишется WAV файл, начало данных выровнено на 512 байт, пишется по четыре сектора (четырьмя записями).
Для доказательства могу пригласить показать "в натуре"...

А почему FAT16 должно ухудшать?
Запись в последовательные сектора, блоками по 512, обновление FAT по окончании записи.
Реализация записи своя, без библиотек, простая, как гвоздь.
Просто карточки 4Гб и более должны быть FAT32, меньше FAT16. Чтобы были совместимы.

Я хотел сказать где исходники, где методика тестирования, где статистика и файлы результатов?
Потому как нет худшей дезы чем собственные воспоминания о прошлом опыте.