Есть устройство подключаемое к компьютеру через USB, периферии мизер (несколько входов/выходов). Сейчас реализовано на AT90USB128. И всё бы хорошо, да производительности маловато, SRAM бы побольше (сейчас 8KБ), и цена у чипа не мала.
По сему стал задумываться о переходе на другую платформу. Опыта работы с ARM нет, но чувствую пора начинать.
Посоветуйте на какой чип лучше перейти, в свете вышеуказанных требований. Хорошо бы в минимальнопиновом корпусе.

PS
Забыл совсем, ещё EEPROM нужна, не менее 4КБ.

А USB FullSpeed устраивает, или нужен HighSpeed.

Да, 12 Mbit/s вполне.

А много-ли сейчас дешёвых армов с таким кол-вом eeprom? Если вообще есть...
Почему-бы не попользовать внешнюю eeprom в so8? Тогда выбор будет пошире

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

Вот как ... жаль ...


Это лишний корпус, интерфейс, место на плате, цена, ...
Но самое важное, там хранятся переменные, доступа к которым из вне не должно быть.


Да ресурса в 100000 перезаписей за глаза.
Возможно удастся ужаться в 2КБ.

У LPC много обычной флэш со 100К перезаписями. Страницами от 4К. Нет восможности побайтового программирования, но можно копировать во внутреннюю раму, исправлять байты и перезаписывать обратно. Благо и рамы много.

У LPC программная flash имеет ресурс 100000, поэтому необходимости в EEPROM, особой не видно.

А сколько времени занимает запись страницы?
И я сказал 100000 перезаписей достаточно с учётом того, что используется кольцевой буфер, т.е. на самом деле каждая переменная имеет ресурс перезаписей на несколько порядков больше.

Если очень-очень захотеть, то в LPC можно взять 32К страницу флэша и сделать в нём кольцевой буфер с элементами по 16 байт. Меньше нельзя, т.к. флэш там организована по 128 бит, для которых присутствуют дополнительные биты ECC (инфа для восстановления, типа Хэмминга)

Внешняя еепром, криптование и ключ во внутренней флеши не подойдет? Места 8 ногий soic занимает не так и много. Стоит совсем дешево. При частых изменениях можно поставить FRAM, заодно скорость записи сильно подрастет.

Сделать то можно, но городить такой огород вместо простого чтения/записи ... да и крипт/декрипт данных туда-сюда займёт не мало времени.
Оставлю этот вариант на крайний случай.

Что-то я не понял как это. В описании написано: копирование из RAM во flash блоками по 256 | 512 | 1024 | 4096 байт.
Ткните носом пожалуйста.

Честно скажу, сам не проверял, но в User Manual на LPC213x (стр 222 из 270) написано

Щас проверю. Может и мне потом пригодится.
Принцип простой. В раме держится минимальный буфер (окно) 256 байт. В нём непрограммирующиеся байты запоняются 0xff, а нужные как надо. Это похоже на маску. Потом вызывается IAP для программирования. Эта маска во флэше объединяется с уже прошитыми данными. Так друг за другом можно "прошивать" группы по 16 байт.

Все именно так, только "непрограмирующиеся" можно и считать из Flash.

У меня была такая же мысль. Но! А кстати, этот алгоритм проверенный? Точно работает?

Но. Мне кажется, что многоразовое туннелирование заряда в уже прошитые затворы может снизить срок их службы. Честно скажу, не владею информацией о влиянии многоразового программирования на долговечнойсть ячейки флэш. Только ли стирание ячейки сокращает срок её службы? В то же время программирование ячеек значением 0xff не разрушает их с вероятностью 100%. С другой стороны, многократное перепрограммирование ячейки повышает долговечность хранимой информации. Но в данном случае этого не требуется.

Лучше 0xFF. Тогда не будет жарить уже прожаренные ячейки. Вот только где я на это натыкался, уже не вспомню

Да, тут на форуме проблемы с 16 байтовостью как-то обсуждали и я писал тест. Работает.

Как я понял, наличие "0xff" (GetSmart) или "аналогичное" (zltigo) означает для IAP, что эту ячейку не следует перепрограммировать во флэш (как я понимаю: перезапись - это стирание + запись нового значения)?
Где это указано? В мануале никакого намёка нет.

Не. Стирание - это отдельная операция. После того, как заполните весь сектор (32К допустим), потом стираете его целиком и пишете заново с начала.
А перезапись - это запись нулей поверх едениц.

Т.е. запись в ячейку флеш "0xff" эквивалентна не записи, и счётчик перезаписей ячейки 100000 - 1 = 100000?


Это плохо, придётся стирать весь буфер, а у меня реализован алгоритм восстановления предыдущего значения в случае сбоя при записи текущего. На два буфера переходить чтоли ...

Ага. Примерно так.


Берите два буфера (сегмента). Стирать можно только сектор целиком. В начале флэш там есть 7 свободных сегментов по 4К, не считая нулевой, в котором таблица исключений. А в 128К, 256К и 512К процах много сегментов по 32К.

А в серии LPC23xx об этом не упоминается, выходит нет этого ограничения.

Проверил программирование по 16 байт 0xFF. Работает как надо. Проблема могла быть в том, что для 16-ти байт 0xFF контрольные биты ECC могли быть не все еденичные. Но, как говорится, пронесло.


Не может быть. В юзер мануале не нашёл, но возможно забыли упомянуть. А вообще, лучше проверить на кристалле. У меня под рукой его нет.

то есть пишем только изменения ? если можем записать... иначе сттираем страницу и перезаписываем...
так ?


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

Ясно.
Но если мы можем писать блок 256 байт, в котором все "0xff" (не изменяется ничего) и нет проблем с ECC, то записывая блок 256 байт, в котором первый "0x00" и далее все "0xff" (пишем первый байт только) будут проблемы?

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

Я не корректно выразил свою мысль, имелось ввиду следующее:
во флеш имеем группу из 16-ти байт: 00,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff
пишем поверх: ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff , без проблем с ECC
но если пишем поверх: ff,00,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff , то получаем ошибку, почему? Если ECC формируется по результату записи, то проблем не должно быть, а если по записываемым данным, то проблемы должны быть и со всеми ff.

Дело в том, что после первой записи ECC сбросит некоторые из своих бит в 0. Даже если во второй раз записать в следующий байт группы не затронув предыдущий первый байт, то ECC изменится и с большой вероятностью некоторые биты ECC изменятся с "0" на "1", а так как флэш это не допускает делать без стирания байта (в LPC только сектор целиком), то ECC приобретёт совершенно некорректное значение. После этого читая эти 16 байт в них будут случайные биты (немного, возможно 1, 2 или 3) искажены алгоритмом ECC. Хотя большая часть бит в 16-ти байтах будет похожа на записанные значения.

Дошло.

Раз физически минимальновозможный размер записываемых данных = 16 байт, почему бы производителю и не сделать возможность записи от 16 байт, и было бы всем хорошо.

А что будет, если во время записи страницы отключится питание?

Вероятно, некоторые биты могут записаться не до конца. В таком случае при чтении ошибка скорее всего отловится при помощи ECC. Причём проблемы могут начаться не сразу, а через некоторое время.

Как вообще происходит запись на низком уровне, побайтно, ...? Сколько байт может испортится?
Нужна диагностика этой ситуации.
Когда пишешь сам и побайтно, известно где и сколько писал, обработать бракованные ячейки весьма просто, а когда пишешь сразу сотни байт ... (точнее в данном контексте реально пишутся 16 байт, остальные ff)