А АЦП у них кто-нибудь проверял, как оно работает и соответствует ли документации (Throughput Rate fADC = 25 MHz 1400 ksps)

АЦП мне понравился. Работает надежно.
Разгонял STR912FW44 до 133 Мгц, делал предделитель у АЦП = 1 т.е. подавал все 133 Мгц, а он продолжал работать как ни в чем не бывало. Только показания ушли где-то на пол бита по сравнению с показаниями на 25 МГц. Измерял среднее и среднеквадратическое на 1000 отсчетов.
Линейность АЦП я не проверял, но оверсамплингом легко можно добиться 4-х стоячих десятичных разрядов на середине шкалы (1.5 В).
Среднеквадратическое на 1000 отсчетов на всем диапазоне входных напряжения не превышало 0.25 бита
Проверял на переменном резисторе 10К на eval плате от ST. Ревизия кристалла - D

Ulink нормально работает на 96MHz, единствунный ньюанс, при первом включении компютера не находит его и приходится каждый раз передёргивать USB разьём. Тайминги все стоят по умолчанию я их не трогал. KEIL версии 3.02, с 3.00 будет виснуть.

Ещё вопрос, вернее проясните ситуацию с таймерами.

To AlexandrY: Вы пишите таймеры сбрасываются не в 0, а в 0xFFFC, т.е. имеется в виду вот это - Writing in the TIM_CNTR register resets the free running counter to the FFFCh value (STR91xF reference manual, стр. 126). Судя по тому, что регистр TIM_CNTR доступен только на чтение, запись в него любого значения приводит к сбросу регистра счёта в состояние 0xFFFC. Я правильно понял?

To SGP: Что Вы имели ввиду - Таймер убогий нет даже автоперезагрузки?

Да именно так, записываю туда че нить, а он сбрасывается в 0xFFFC. Немного неудобно.
В фирменной библиотеке туда пишут 0x1234 почему-то. Я писал 0 - тот же эффект.

Отсутствие автоперегрузки (наверно произвольным значением имелось в виду) счетчика таймера не такой уж и сильный недостаток, compare логика и четыре блока таймеров вполне позволяет его приодолеть для формирования произвольных временных интервалов.
Но счетчики 16-и разрядные, вот это неудобство.
Зато есть источник тактирования от RTC независимый от тактовой ядра с периодом тиков очень удобным при портировании RTOS.
Еще ценное свойство - остановка периферии и счетчиков в том числе при захвате ядра JTAG-ом. Такого ни у кого из uC на ARM-ах еще не видел.
Вообщем, по периферии, по моему, паритет с конкурентами.

Netsilicon NS9xxx тоже это умеет.

Да, с таймерами они немного перемудрили , ну да бог с ними. Короче созрел я, буду брать STR91X-SK/KEI и штук 5 камней на попробовать. Посмотрю, может не всё так страшно

Собрался применить 911. КонстантинТ посоветовал. Отказался от LPC2138 - нужно хранящееся от батарейки SRAM, хотя USB, CAN и Ethernet не нужны. Жалко только, что таймеры кривоваты, чуть некрасивше потребление и отсутсвует встроенный стабилизатор напряжения ядра.

LPC23xx уже в прайслистах появились, скоро и живьем появятся - это к вопросу о SRAM с батарейкой.

Спасибо, смотрел уже. Там только 2К от батарейки можно держать. Неплохо, конечно, но мне нужно больше 32К. Как вариант делал "мюнхаузеновскую схему" горячей отключаемой подпитки LPC2138 от батарейки и на один из SPI вешал FRAM для перегрузки содержимого ОЗУ перед отключением. В принципе могло бы и устроить, но аккуратности с программой требуется побольше, чем у наших программистов;(

Проблема с прерываниями Имеется контроллер STR912FW44X6 ревизия D код 610. Одновременно работают таймер TIM3, АЦП и UART1. Таймер и ацп заведены на VIC0, UART1 подключён к VIC1.Обработчики прерываний написаны на С Кеil_3.02. При интенсивном обмене по UART1, на скорости 115200 выкачивается содержимое ОЗУ, происходит вылет программы на нулевой адрес в режиме IRQ. По отдельности всё работает. Перенос UART1 на FIQ нечего не дал. Иследования показали что дело скорее всего в арбитраже между VIC0 и VIC1. Чтото похожее описывается в ерате: "2.1 VIC interrupt controller wrong vector fetch."Хотелось бы услышать мнение общества: кто нибудь сталкивался с подобной проблемой или первопричина в кривизне моей программы.

Та же ерунда и у меня! Когда использую прерывания одного контроллера - всё нормально, если задействую оба - вылетает. Эта проблема уже почти год обсуждается в форуме ST (английский). Одни говорят, что в новых ревизиях этой проблемы уже нет. Другие снова обнаруживают... Может проблема уже решена?

Меня както просвещал AlexandrY: