- Аналогичные камни на M3 появятся не раньше, чем через год.
- Если нужен MII - пожалуйста LPC24xx.
- IAP функции не "как бы" скрывают, а просто не распространяют. Для увеличения производительности встроенного flash используется патентованный модуль, особенности работы которого компании раскрывать особо нет нужды. Плюс для совместимости кода при изменениях в контроллере flash код программы не изменяется.

Честно говоря более преспективными видятся кристаллы 2387 2388. Скорее всего прям с них и начнем.

Вопрос к shashr
Будут ли такие же только на кортексе?



А в чем, собственно, минус? Нельзя выделить массив больше чем 32К?



Побайтно, Вы имеете ввиду. В принципе не использовал, так как там довольно хитрая прцедура, я так понял все равно прееписывается вся страничка.

Меня больше волнует проблема написания собственного загрузчика. Я так понял что в nxp это будет посложнее реализовать, так как надо использовать возможности встроенного.


Для меня это плюс - не надо тратить кучу драгоценных лап. А вот у X он не работает по еррате

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

Какой PHY посоветуют использующие??



Интересная подробность. Правда сравнить с X не получится.


долбанные индусы [censored]

Будут. LPC1770 уже заявлены в roadmap.
http://www.standardics.nxp.com/products/lpc2000/lpc23xx/ На этой страничке чуть ниже указаны мкросхемы PHY, с которыми гарантированно работает LPC23xx/24xx/17xx

Никакой сложности, фактически встроенный IAP имеет фиксированную точку входа для обращения. Не нее мапится функция, и все делается на С

В остальном читайте документацию на IAP.

Простите меня Александр!!

И спасибо за ответы.



Дык я имел ввиду, что это сложнее чем просто написать свой код.

Это проще - низкоуровневые процедуры работы с Flash уже за вас написали, вам осталось только правильно их вызвать.

Собственно да, почему бы и нет, смотря какой стиль программирования используешь, например обьявить массив для расперделения памяти между пользовательскими процессами в операционках и псевдооперационках
Есть и другой минус - у тебя только одна область (сегмент - сектор, смотря кто какую IDE использует ) DATA, в которую по умолчанию кидаются все глобальные переменные.
Остальные которые не влезли придется распределять средствами компилятора. Что снижает читабельность, портируемость проекта, и возможно источником ошибок.



Нет именно побитно, на Sam7 есть возможность например сбросить какой нибудь Флаг на константно залитой структуре на флэшке. В Lpc для такого флага надо выделить соответственно регион в 16 байт 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF.
Т.е в Sam7 можно на избранный байт 0x55 записать 0x51 и получить 0x51 (естественно вся остальная часть записываемой странички в 256 байт должна быть идентичной той которой лежит).



Кстати щас юзаю тут sam7x512 никто не знает реанимировали ли у него RMII, в роде как в еррате на него я знаменитого Not Functional не нашел ?
И ещё у него 2 флэш контроллера, можно ли одновременно писать в один контроллер и при этом паралельно исполнялся бы код из другого (прерывания к примеру)???



Стоимость важна? если нет тогда бери те что рекомендует NXP и ставит на свои киты.
А так можешь пошношаться с каким нибудь Lan8700 или более неизвестными китайскими образцами (тут кто то мне кидал ссылку на работающий от резонатора и стоимостью в бакс, но использующих его я ещё не встречал).



Там DMA вообще работает только с USB памятью (из той которая на борту)

Так используйте "нормальный"

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

Не нужно ничего "распределять средствами" - линкер прекрасно все и сам распределит, если ему указать ВСЕ ресурсы RAM имеющиеся в его распоряжении.

Я и использую нормальный.

Ну начались теологические беседы
Далее я бы должен спросить какой линкер вы используете, какую модель распределения кучи и какой планировщик задач и т д и т п
Но мне не интересен флуд, я лишь проинформировал человека о возможных (далеко не всех) use cases.

Судя по поднятым проблемам - не совсем

Отвечаю - любой линкер.

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

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

Увы, это больше похоже на ДЕЗинформацию . По этой причине и не смог пройти мимо.

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

Это и называется распределять средствами. Вы распределяете средствами линкера для чего пишите соответсвующий файл типа xcl, icf, xml, sct и т д и т п. Для этого вы вынуждены изучать документацию на линкер при переходе на другой и тратить на это время.
Стандартные методы это ANSI C/C++.

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