Выбор микроконтроллера Опции

[Visor]

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

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

[vvvv]

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

[Visor]

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

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

[sonycman]

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

[zltigo]

Почему-бы не попользовать внешнюю eeprom в so8?

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

[Visor]

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

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

Почему-бы не попользовать внешнюю eeprom в so8? Тогда выбор будет пошире

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

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

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

[GetSmart]

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

[Diman_]

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

[Visor]

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

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

[GetSmart]

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

[Qwertty]

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

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

[Visor]

Внешняя еепром, криптование и ключ во внутренней флеши не подойдет?

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

[Visor]

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

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

[GetSmart]

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

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

When a sector of user’s Flash memory is erased, corresponding ECC bytes are also
erased. Once an ECC byte is written, it can not be updated unless it is erased first.
Therefore, for the implemented ECC mechanism to perform properly, data must be written
into the Flash memory in groups of 4 bytes (or multiples of 4), aligned as described above.

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

[zltigo]

Принцип простой.

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

[GetSmart]

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

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

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

Сообщение отредактировал GetSmart - Jan 20 2009, 12:45

[Rst7]

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

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

[zltigo]

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

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

[Visor]

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

[GetSmart]

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

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

[Visor]

А перезапись - это запись нулей поверх едениц.

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

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

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

[GetSmart]

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

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

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

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

[Visor]

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

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

[GetSmart]

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

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

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

Сообщение отредактировал GetSmart - Jan 20 2009, 14:38

[singlskv]

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

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

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

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

[Visor]

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

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

[GetSmart]

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

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

[Visor]

Какие проблемы? ...

Я не корректно выразил свою мысль, имелось ввиду следующее:
во флеш имеем группу из 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.

[GetSmart]

но если пишем поверх: 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-ти байтах будет похожа на записанные значения.

Сообщение отредактировал GetSmart - Jan 21 2009, 09:36

[Visor]

... а так как флэш это не допускает делать без стирания байта ...

Дошло.

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

[Visor]

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

[scifi]

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

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

[Visor]

Вероятно, некоторые биты могут записаться не до конца.

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