clawham, у вас опыт , и кто вас заставил юзать г.либы?
Это тупиковый путь.

ЗЫ . "Проблема" pashka решена.

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

А по другим моим вопросам/проблемам кто что скажет?
1) 18 микрух впаралель входами. микрухи на 5 вольт, арм на 3.6 48 мегагерц(уже умерил аппетит - итак легко укладывается) и шлейфики длинные(относительно - 10 см макс) как оно себя чувствовать будет?

2) ФатФС спи 48 мегагерц проц /4 спи, флешка 8 гиг. - читаем в пустоту - 200 мсек 60 килобайт данных а запись на флешку - 7 секунд! иногда..а иногда тоже 200 мвек! я хочу всегда 200 мсек

П.С. нашел почему надо было первую ногу моей рамки держать на земле - а она не SRAM! Она псевдосрам - тоесть внутри она драма + декодер ROW COL и если первая нога в единице - самообновление не работает! она и забывала все что я в неё писал
она такаяже как и http://www.datasheet.hk/search.php?part ... stype=part вот эта

Стесняюсь спросить, а что делает функция malloc(), как вы думаете?

И еще просто очаровало вот это


Сами придумали, или скопировали где-то?

а что тут не то? мне надо положить в буффер часть порта а. у меня а0-а7 это шина данных оперативки. указатель буффера я инкрементирую вконце а это - ну читаю из входного регистра и накладываю маску чтоб попадало в фуффер только то что надо. Что в этом такого?



это были попытки оптимизации по скорости работы. кроме того это сейчас оно такой вид имеет а потом там будет битмаска покруче чем просто 8 единиц. просто на макетке разводка не важна а вот в реальной плате для удобства разводки без переходных - прийдется переназначать и не факт что получится поподряд выбрать биты на порту - армы эти по-идиотически сделаны в плане распиновки.

По поводу маллок и мемсет я знаю что они делают но вопервых не я заремил маллок а во вторых какова хрена мемсет мне стек портит? ведь если есть буффер и есть его размер - почему налазит на стек? Эти либы не я писал - это в CubeMX FatFS и ведь у многих она ж работает без проблем..ну да нету sdio у f100 ну дак и что? spi режим запрещен?

В функции Ram_Read задан тип указателя char* buf, т.е. он и без всяких эндов скопирует только младшие 8 бит за проход.




Идея, конечно, гениальная. Да, два байта справа занулятся. Второй байт проэндится с 0xFF. А байт слева?


А работать через указатели с портами не пробовали? Хотя кодвижн, да...


Сложно сказать, судя по отрывкам вашего кода, что конкретно там не так. Надо смотреть переменные, которые вы передаете в функцию, в частности uint16_t BlockSize. Как вариант, поскольку память заранее выделена не была, memset, возможно, затирает действительные переменные. С другой стороны, учитывая сам стиль кодинга в местах работы с периферией прямо из while(), довольно неочевидные приемы обращения к памяти, уже как-то не сильно удивляет, что дивайс ваш глючит, имхо конечно.

ненене вы не поняли!
ClrA = 0xFF << 16; это маска для атомарного сброса битов портов! Там где единички - там будет сброшено в ноль. ClrA это битовая маска для регистра BSRR.

с указателями конечно же можно и сразу я так и сделал - набрал пинов попдоряд абы каких глдавное чтоб шиной шли и поназначал им алиасы а дальше уже как с одним лонг интом с ним работал а то что оно таам разворачивается в 3 порта и 100500 сдвигов то меня не интересовало. с таким подходом на 48 мегагерцах я смог с внешней памяти качать только 0,3-0,4 мегабайт в секунду! когда полностью перешел на один порт для данных а второй для адреса - стало 3 мегабайта в секунду. Дальше больше - когда перестал использовать функции HAL и прочее - стало 3.4 мегабайта в секунду, потом убрал расчет масок для BSRR и получил 4.2 мегабайта в секунду! мне очень важна скорость работы с памятью. тем более что эта память просто sram подключенная к произвольным пинам проца. я согласен что возьми F103 и не парься но есть этих 5 штук и они справляются.

Ну а по char*buf ну дак до этого он был не чар остатки оптимизаций по хорошему надо будет открыть новый проект и переписать с нуля все это неподобство.

в плане глючит не глючит - ну я не могу точно сказать но я в те бибилиотеки и не лазил - они автоматом создаются. Ну да предназначены для SDIO но я нашел реализацию SPI драйвера нижнего уровня. а этот кусок с очисткой буфера - это бибилиотечкая штатная функция она общая и для SDIO и для моего варианта и идет из CUbeMX а он походу из елм чана. может эта очистка и лишняя я хз. но почемуто через дма если делать передачу - становится совсем тухло по скорости. нене я понимаю что по спи 800 килов в секунду получать это круто. но вот записть сильно печальная. иногда. как затык.

И да...я использую кеил ювижн 5,24,1 и причем тут кодевижн? это ж аврки

а вы уверены, что у вас есть block?)
в исходном варианте не зря проверяется результат malloc-а - для большого куска непрерывной памяти может не найтись места в куче. Вы же хотите выделить ее на стеке. Там достаточно места на этот момент?

конечно недостаточно у меня всего 8 кил оперативки и 3кила заняты буферами моими а не фатовыми. в том то и вопрос - почему так получается? и как минимизировать пожирание оперативы этой либой?

не страдать фигней и использовать кучу, как оно и было.

и этсамое. Я смотрел исходник из архива, там закомменчены оба memset-а. Вчитался в первое сообщение - а ничо, что вот тут

вы сначала пытаетесь сделать memset на NULL, а уже потом инициализируете ptr адресом массива block?
можно обойтись вообще без ptr


ЗЫ туплю, sizeof там не сработает