А почему не LPC2146, ведь у нее и пинов меньше и МАС-а нет, дешевле будет? Может есть другие соображения?

Нормально, просто Вы как-то перевели речь на свежие 80pin . LPC213x/4x у меня на данный момент самые массовые в применении. звестные баги на данный момент пофиксены практически все. Уточните только о SPI - они имееют ограниченя по скорости разные по функционалу.

На один канал SPI ,будут подключены две флешки AT45DB, а на второй периферийное slave устрйство с потоком до 1мб. В прототипе устройства они вешались все на один канал AT91SAM7X, но от сети отказались и она более не нужна. Встал вопрос, спускаться на SAM7S или брать нечто другое.

Сообщение отредактировал Мусатов Константин - Dec 20 2008, 16:15

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

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

Сообщение отредактировал Sanek_spb - Dec 21 2008, 15:29

Те, кого не смущает наличие неразумно большое количество документированых и не документированных багов и, повторяю, устраивает минималистичное использование ресурсов через "библиотеки" могут пользовать. Остальным рекомендую крепко подумать, даже если формально есть в нем нечно очень привлекательное. Я например, в свое время из-за HDLC возился с их-же STR711. В результате количество хоть и несмертельных багов, неудобств, кривостей для меня перевесило все прочее. Традичия такая у ST нехорошая продолжилась и на STR9 (в конце концов плюнул на производительность и ужался на ARM7 от NXP), и на STM , хотя от STM еще не отказался окончательно

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

Проблем с ИАРом у меня нету, а если вы используете в С++ библиотеки наисанные на Си и у вас возникают проблемы, то вы скорее всего не умеете работать с кодом содержащим и С и С++ код.

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

с этим у меня нет проблем уже как лет двадцать с гаком

Насчет библиотеки абсолютно верно.
По стилю тех библиотек видно, что писались они зелеными студентами.
Либы совершенно в диссонансе с такими культовыми вещами как ARTX и FS у Keil-а, uCOS , FreeRTOS и т.д. и по стилю именований и по стилю передачи параметров.
В либах совершенно обходятся стороной реализации асинхронных обменов с периферией через буферы , очереди и прерывания.
А такой стиль обменов только и возможен в RTOS.
Например в STM32 сделать мультимастера по I2C эти либы нисколько не помогают.
Такая же фигня с UART-ами.
Та же история с USB. Там вообще дикий гемор. Ребята решили сделать добрую часть либы такой абстрактной чтоб она без изменений шла и под STR91 и под STM32 и под STR7.
Поэтому где обычно хватает одного файла у них нужно десять и концов не найдешь в бесконечных косвенных вызовах. А это уже прямые убытки на отладку.

Ну ладно. Тема пройденная.
Меня волнует другое.
Какого х. внутренний термометр в STM32 никогда не показывает температуру ниже 70 C?
Все считаю по формуле. Все остальные напруги его ADC измеряет достаточно прецизионно, правда кроме референсного напряжения которое тоже оказывается завышено.

Что интересно в предыдущей партии температура тоже была завышена, но не выше 30 С
Или реально там кристал такой горячий?

Если действительно кристалл нагрет до 70, то это легко должно чувствоваться на ощупь - как очень горячий!