richie

В таких ситуациях чаще всего виновны обе стороны. 1. Работодатели не хотят оформлять договорные отношения с предоставлением достаточно подробного ТЗ. 2. В "честь" п.1 наёмники не до конца осознают объём работ и понимают в определенный момент, что сильно продешевили. Чтобы не кричать на весь интренет, что "памагите! кинули!" работодателю нужно потратить время на задание, затем его детализацию и согласование с наёмником, договориться об вознаграждении, его последовательности и способах выплаты, и обязательно оформлять отношения договором, в котором оговорить как можно больше аспектов отношений. Тогда конфликтов гораздо меньше будет. По завершению работ (определение завершения также прописано должно быть в договоре) договор можно уничтожить. Из личного опыта, примечательно, что часть работодателей отказывается от услуг, как только завожу речь о договоре.

LUA перспективнее, есть и русскоязычные сайты поддержки фанатов. Синтаксис, конечно не C, документация по синтаксису читается за полчаса, а далее только от гибкости (извращения) ума зависит. :) Мой сотрудник говорит, что на предыдущей работе чел использовал его в контроллере.

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

На ефайнд есть форум, на форуме есть раздел для таких случаев. :) Сам иногда пользуюсь.

;) Батенька, я же говорил выше:

На всякий случай сделай копию после установки С51. Потом в эту же папку накати для ARM. Раньше точно инсталлятор добавлял записи в этот файл. Если не добавит, то можно это сделать вручную. Вот мой tools.ini: [uV2] ORGANIZATION="SweetCompany" NAME="Alex", "Alex" EMAIL="[email protected]" BOOK0=UV3\RELEASE_NOTES.HTM("uVision Release Notes",GEN) DEVICE_BOOKS= ARMSEL=1 SOCKETPORT=835792213 [C51] PATH="C:\Wrk\Keil\C51\" VERSION=V9.01 BOOK0=HLP\Release_Notes.htm("Release Notes",GEN) BOOK1=HLP\C51TOOLS.chm("Complete User's Guide Selection",C) TDRV0=BIN\MON51.DLL ("Keil Monitor-51 Driver") TDRV1=BIN\ISD51.DLL ("Keil ISD51 In-System Debugger") TDRV2=BIN\MON390.DLL ("MON390: Dallas Contiguous Mode") TDRV3=BIN\LPC2EMP.DLL ("LPC900 EPM Emulator/Programmer") TDRV4=BIN\UL2UPSD.DLL ("ST-uPSD ULINK Driver") TDRV5=BIN\UL2XC800.DLL ("Infineon XC800 ULINK Driver") TDRV6=BIN\MONADI.DLL ("ADI Monitor Driver") TDRV7=BIN\DAS2XC800.DLL ("Infineon DAS Client for XC800") TDRV8=BIN\UL2LPC9.DLL ("NXP LPC95x ULINK Driver") TDRV9=BIN\SiC8051F.dll ("SilLabs C8051Fxxx uV Driver") RTOS0=Dummy.DLL("Dummy") RTOS1=RTXTINY.DLL ("RTX-51 Tiny") RTOS2=RTX51.DLL ("RTX-51 Full") LIC0=... [C251] PATH="C:\Wrk\Keil\C251\" BOOK0=HLP\RELEASE_NOTES.HTM("Release Notes",GEN) BOOK1=HLP\GS51.PDF("uVision2 Getting Started",GEN) BOOK2=HLP\C251.PDF("C251 User's Guide",GEN) BOOK3=HLP\C251LIB.CHM("C251 Library Functions",C) BOOK4=HLP\A51.PDF("Assembler/Utilities",GEN) BOOK5=HLP\DBG251.CHM("uVision2 Debug Commands",GEN) BOOK6=HLP\RELEASE_NOTES.HTM("Release Notes",GEN) BOOK7=HLP\GS51.PDF("uVision2 Getting Started",GEN) BOOK8=HLP\C251.PDF("C251 User's Guide",GEN) BOOK9=HLP\A51.PDF("Assembler/Utilities",GEN) TDRV0=BIN\MON251.DLL ("Keil Monitor-251 Driver") VERSION=V3.5 SN=... LIC0=... [ARM] PATH="C:\Wrk\Keil\ARM\" VERSION=3.50 PATH1="C:\Program Files\CodeSourcery\Sourcery G++ Lite\" BOOK0=HLP\RELEASE_NOTES.HTM("Release Notes",GEN) BOOK1=HLP\ARMTOOLS.chm("Complete User's Guide Selection",C) BOOK2=HLP\RL_RELEASE_NOTES.HTM("RTL-ARM Release Notes",GEN) BOOK3=HLP\RVI.chm("RV Compiler Introduction",GEN) TDRV0=BIN\UL2ARM.DLL("ULINK ARM Debugger") TDRV1=BIN\UL2CM3.DLL("ULINK Cortex Debugger") TDRV2=BIN\AGDIRDI.DLL("RDI Interface Driver") TDRV3=BIN\ABLSTCM.dll("Altera Blaster Cortex Debugger") TDRV4=BIN\lmidk-agdi.dll("Luminary Eval Board") TDRV5=Signum\SigUV3Arm.dll("Signum Systems JTAGjet") TDRV6=Segger\JLTAgdi.dll("J-LINK / J-TRACE") TDRV7=Segger\JL2CM3.dll("Cortex-M3 J-LINK") TDRV8=STLink\ST-LINKIII-KEIL.dll ("ST-Link Debugger") LIC0=... [ARMADS] PATH="C:\Wrk\Keil\ARM\" PATH1="BIN40\" BOOK0=HLP\RELEASE_NOTES.HTM("Release Notes",GEN) BOOK1=HLP\ARMTOOLS.chm("Complete User's Guide Selection",C) BOOK2=HLP\RL_RELEASE_NOTES.HTM("RTL-ARM Release Notes",GEN) BOOK3=HLP\RVI.chm("RV Compiler Introduction",GEN) TDRV0=BIN\UL2ARM.DLL("ULINK ARM Debugger") TDRV1=BIN\UL2CM3.DLL("ULINK Cortex Debugger") TDRV2=BIN\AGDIRDI.DLL("RDI Interface Driver") TDRV3=BIN\ABLSTCM.dll("Altera Blaster Cortex Debugger") TDRV4=BIN\lmidk-agdi.dll("Luminary Eval Board") TDRV5=Signum\SigUV3Arm.dll("Signum Systems JTAGjet") TDRV6=Segger\JLTAgdi.dll("J-LINK / J-TRACE") TDRV7=Segger\JL2CM3.dll("Cortex-M3 J-LINK") TDRV8=STLink\ST-LINKIII-KEIL.dll ("ST-Link Debugger") RTOS0=Dummy.DLL("Dummy") RTOS1=ARTXARM.DLL ("RTX Kernel") [KARM] PATH="C:\Wrk\Keil\ARM\" BOOK0=HLP\RELEASE_NOTES.HTM("Release Notes",GEN) BOOK1=HLP\RL_RELEASE_NOTES.HTM("RTL-ARM Release Notes",GEN) BOOK2=HLP\ARMTOOLS.chm("Complete User's Guide Selection",C) BOOK3=HLP\RVI.chm("RV Compiler Introduction",GEN) TDRV0=BIN\UL2ARM.DLL("ULINK ARM Debugger") TDRV1=BIN\UL2CM3.DLL("ULINK Cortex Debugger") TDRV2=BIN\AGDIRDI.DLL("RDI Interface Driver") TDRV3=BIN\ABLSTCM.dll("Altera Blaster Cortex Debugger") TDRV4=BIN\lmidk-agdi.dll("Luminary Eval Board") TDRV5=Signum\SigUV3Arm.dll("Signum Systems JTAGjet") TDRV6=Segger\JLTAgdi.dll("J-LINK / J-TRACE") TDRV7=Segger\JL2CM3.dll("Cortex-M3 J-LINK") TDRV8=STLink\ST-LINKIII-KEIL.dll ("ST-Link Debugger") RTOS0=Dummy.DLL("Dummy") RTOS1=ARTXARM.DLL ("RTX Kernel") [C166] PATH="C:\Wrk\Keil\C166\" BOOK0=HLP\Release_Notes.htm("Release Notes",GEN) BOOK1=HLP\GS166.PDF("uVision2 Getting Started (PDF)",GEN) BOOK2=HLP\C166.PDF("C166 User's Guide (PDF)",GEN) BOOK3=HLP\C166LIB.CHM("C166 Library Functions",C) BOOK4=HLP\EC166.CHM("EC166 Embedded C++",GEN) BOOK5=HLP\A166.PDF("A166 & Utilities User's Guide (PDF)",GEN) BOOK6=HLP\DBG166.CHM("uVision2 Debug Commands",GEN) BOOK7=HLP\OCDS.CHM("OCDS Debugging",GEN) BOOK8=HLP\License.htm("Enter License ID",GEN) BOOK9=HLP\C166TOOLS.chm("Complete User's Guide Selection",C) BOOK10=HLP\UV3.chm("uVision3 User's Guide",GEN) TDRV0=MONITOR\MON166.DLL ("Keil Monitor-166 Driver") TDRV1=OCDS\CBC166.DLL ("OCDS Driver for C16xU/H/UTAH") TDRV2=OCDS\OCDSXC.DLL ("OCDS Driver for XC16x") RTOS1=RTXTINY.DLL ("RTX-166 Tiny") RTOS2=RTXFULL.DLL ("RTX-166 Full") RTOS3=ARTX166.DLL ("Advanced RTX-166") VERSION=V4.2 LIC0=... SN=... Удалил только номера серийников и лицензий. P.S. В файле куча записей для различных версий компиляторов ARM, которые поставлялись ранее с кейлом. Выбор конкретного компилятора делает чудная строчка "ARMSEL=1". Сейчас используется realview MDK-ARM 3.50. Сложилось так, что для ARMов кейл давно не использую, использую IAR. P.P.S. Для проверки какой компилятор использует среда для открытого в ней проекта достаточно при открытом проекте открыть About среды, там будет указан toolchain (используемый компилятор)

Будут, при запуске из среды ОС файла проекта будет стартовать последний установленный кейл. Делай-делай как я! (С)

Как они могут мешать друг другу работать? У меня стоят кейлы: - ARM, - C51, - C251, - C166. А также оболочки: - uv2, - uv3, - uv4. Содержимое папки C:\Wrk\Keil: 24/11/10 15:29 <DIR> ARM 05/10/06 12:03 <DIR> C166 05/10/06 12:03 <DIR> C251 21/10/09 18:09 <DIR> C51 16/02/11 13:56 <DIR> UV2 16/02/11 13:56 <DIR> UV3 16/02/11 13:56 <DIR> UV4 18/02/09 17:47 UVSetup.ini 02/03/11 18:35 TOOLS.INI 24/11/10 15:53 TOOLS.INI.BKUP Оболочкой UV2 не пользуюсь давно, оставлена на всякий случай для старых проектов. Использую UV3 и UV4, они отличаются файлами проектов, uv4 может открывать файлы проектов .uv2 (.opt), но при закрытии предлагает сохранить в своём формате .uvproj (.uvopt). Старый формат по структуре - ini-файлы, удобные для редактирования вручную, новый формат файлов проекта пос структуре - xml. В фале проекта хранится тип используемого компилятора (для поддержки нужно правильно выбирать используемый "камень"). В файле "tools.ini" прописаны настройки для каждого компилятора (пути, файлы помощи, dll-ки и т.д.) и ключики (не выяснял нужны ли сейчас, но пусть будут). Файл "UVSetup.ini" хранит тоже самое что и "tools.ini", плюс ещё настройки. Добавлял эти файлы вручную. Для каждого компилятора добавлена лицензия. Инсталлировал компиляторы по очереди в одну и туже папку, сохраняя после каждой установки копию папки, потом сравнивал отличия. Также теперь выполняю обновления версий.

Хм, а зачем такой гемморой изобретать? В одной void функции returna нет, а в другой зачем-то понадобился. Чем простая запись не подходит: .... if(Command.Data[i++] >= ZOND_SIZE) { ErrOptions(); return; } Лаконично и понятно будет другому человеку, и самому себе даже через несколько месяцев. ИХМО. Если есть неопределенность в спецификации изобретаемой функции, то всегда делай её с кодом возврата.

О_о! Не у меня одного такая проблема! В 2004 году когда первый раз столкнулся с силабсами при слетании отладки были советы одного типа: схема плохая, плохая земля, плохое питание. По-разному соединял земли, по-разному давал питание, от различных источников, витые пары использовал, для EC-3 менял различные USB-кабеля, к различным портам USB подключал, в общем исполнял много и долго шаманских обрядов. Причём всё-равно на нашей плате или силабсовском КИТе с 310-м камнем. С того времени несколько видов приборов разработано, на разных камнях: 311, 411, 344, 345, 064, а сейчас на 581. При переходе с EC-2 на EC-3 скептически лучше стало. Но всё-равно практически никогда не завершаю отладку в keil'е кнопкой "Start/Stop Debug Session". Пришедшие на работу новые сотрудники провели "свежим" взглядом ревизию соединения заземлений. Снова скептически стало лучше. Но всё-равно редко вспомню где в меню находится выход из отладки. В 2004-м ситуация осложнялась тем что UV2 иногда при "Программа выполнила недопустимую операцию..." херила исходный код, открытого в ней файла или файла проекта, за UV3 такого не замечено, UV4 пока с сентября по март не испортила ни одного файла, однако при зависании отладки падает с "недопустимой операцией", в UV3 это было в половине случаев. Это всё верно для всех плат с интерфейсом C2. На изделии с 064, где соединение с камнем по JTAG проблем с отладкой нет, причём используются те же отладчики EC-2 и EC-3, меняется только кабель. Замечено, что 100% вероятность слетания отладки происходит при открытых окнах просмотра SFR'ов, если окошки SFR'ов не открыты, то есть шанс поковыряться в отладке подольше. Также замечено, что чтобы гарантированно срабатывали точки останова нужно выполнить следующую последовательность: 1. Командой из меню убить все точки останова (в keil: Меню_>Debug->Kill All breakpoints); 2. Сделать Reset (в keil: Меню_>Debug->Reset CPU); 3. Запустить программу (в keil: Меню_>Debug->Run); 4. Сразу же остановить программу (в keil: Меню_>Debug->Stop); 5. Вот теперь можно запускать программу до срабатывания точки останова (в keil: Меню_>Debug->Run). Ещё было несколько раз замечено: выполняя пошаговую отладку кнопками на клавиатуре, только коснулся "мыши" (она USBшная) -всё зависло и погодя несколько секунд слетело. Ещё сильно раздражает что при слетании очень долго не вываливается окно "Программа выполнила недопустимую операцию..." чтобы выполнить закрытие программы.

Сделано... В процессе добавил отслеживание ещё одной ноги, которая на том же PCA0 генерирует частоту наружу. Диаграмма такая: Нулевой канал логического анализатора показывает ресеты, первый канал - тоглы пина при сбросе ватч-дога, третий канал - генерируемая процессором частота (~1,2 МГц). Временной интервал между последним дёрганьем ватч-дога и ресетом - примерно 100 мкс. Ресет это дёрганье ногой второй командой после джампа по вектору прерывания по ресету. Реально прекращением работы программы на процессоре можно считать время прекращение генерации частоты, которая перестала генерироваться через ~50 мкс после последнего сброса ватч-дога. Источником ресета (по значению RSTSRC) снова является ватч-дог...

Может быть, как-нибудь проверю и эту идею. С другой стороны VDD-монитор включен, источником ресета он никогда не был.

Игорь, спасибо за ответ! Проявляется и в нормальном режиме и под отладчиком, что казалось сперва плюсом, думал отловлю быстро. Проблема проявляется не сразу, для её вызова нужно непрерывно вызывать запись во флэш с указанной частотой в течении времени от 10 до 120 секунд. Чтобы вызвать функцию записи флэш с интерфейса нужно сперва войти в режим записи "заводских настроек", разрешить команды запись, записать новые значения, запретить команды записи, выйти из режима записи "заводских настроек". Сама запись выглядит классически для этих процессоров: копирование страницы в ОЗУ, замена в ОЗУ значений параметров, с контролем того что действительно что-то меняется, если были изменения, то стирание страницы флэш и запись всей страницы из ОЗУ. По пути всякие контрольные суммы считаются, счётчики инкрементируются и т.д. Время стирания флэш на 344 эти же 15 мс, прерывания на время стирания и сам вотч-дог запрещены, согласно рекомендациям SiLabs. Отличия, конечно, от последовательности записи/стирания от апнотовских имеются: раздельная запись ключей, первая часть ключа пишется в специально выделенном для этих целей прерывании, разрешение которого делается отдельной функцией, вторая часть ключа пишется в самих функциях, но с обязательными проверками залочивания флэш и проверкой что первая часть ключа записалась. Сделано так для избежания самопроизвольного стирания флэш при различных внешних условиях. С утра появилась идея параллельно с ватч-догом дёргать дискретными выходами, коих есть две штуки, одним делать тогл при сбросе вотч-дога, другим индицировать ресет. Этим выясню что, бывают ли действительно, при работе с вотч-догом, задержки большие 3 мс, приводящие к ресету процессора.

Использую процессоры от Silabs: 581, 344, 411, а ранее были 311 и 064. Так что опыт есть. Нареканий на процессоры, компилятор keil (успешно мигрирую на поздние версии) нет, за исключением регулярного слетания отладчика с громким падением Keil'а. Эта проблемка лезет из dll'ки отладчика EC-3. Пристальное вглядывание в землю отладчика выявило короткие и редкие всплески при двигании мышкой, подключенной тоже по USB. Но с этим как-то привык уже жить. Неделю назад столкнулся с другой проблемой на 344 процессоре и до сих пор её решаю: При интенсивной записи (10 раз в секунду) в страницу встроенного FLASH процессор ресетится, в регистре источника ресета (RSTSRC) торчит бит-3 - источником ресета был watch-dog. Такая частая запись флэша в работе устройства применяться не будет, просто шла отладка драйвера на ПК и тут вылезла описанная выше проблема в устройстве. Вотч-дог взведён на 3 мс - максимально возможное время для используемой конфигурации процессора. 1. Отключил вотч-дог - проблема пропала. 2. Вернул вотч-дог и наставил его доп. сбросов - не помогло. 3. Проанализировал код на наличие опасных мест связанных с запрещением прерываний. Ничего не нашёл. 4. Отключил запись во FLASH, оставив только запись во внешний EEPROM - проблема не проявляется. 5. Сделать эмуляцию ватч-дога для отлавливания места и состояния когда происходит истечение таймаута вотч-дога: отключил настоящий ватч-дог и вместо него задействовал свободный таймер, сконфигурировал его на аналогичный ватч-догу интервал, а на его прерывание по переполнению поставил точку останова. Запустил тестовую утилитку на ПК и ... ничего не произошло, всё работает, прерывание по переполнению таймера не возникает в течении 4 минут. Уменьшал время таймера-эмулятора ватч-дога, до тех пор пока прерывание не начало появляться. Это начало происходить при времени < 0.2 мс. Т.е. таймаута штатного вотч-дога гарантированно хватает. Получив этот результат, мысли "куда копать" иссякли.

Разумеется тип wchar_t определён typedef'ом. Более того, вполне может понадобиться добавить какой-нибудь #define, в виндусе это #define UNICODE, для правильной ветки условной компиляции. P.S. Откройте справку по компилятору и поищи wchar_t, например, в кейле для 51-х для типа wchar_t нужно цеплять файл stdlib.h. P.P.S. А в иаре для АВР нужно включить в проект DLIB.

Хай! :) Сейчас кейла под арм не стоит на машине, но попробуй прицепить в проект файл wchar.h P.S. Может всё-таки в одной теме вести "расследование"?

Если wchar_t это юникод, то расскажите в какой группе (диапазоне) юникода создана строка "АБВГ"? Сделав объявление wchar_t u[] вы объявили строку типа вайд-чар и всё. В большинстве случаев для хранения юникода 16 бит достаточно, но это не означает что инициализация строкой L"АБВГ" автоматически сделана правильной юникод-строкой, правильно интерпретируемой любой системой. Коды символов "0x00c0, 0x00c1, 0x00c2, 0x00c3", автоматически сгенерерированные компилятором на L"АБВГ" на самом соответствуют диапазону "Latin-1" (коды с 128 по 255). И отображаемые символы с этими кодами будут совсем не те, которые подразумевались. Так то вот.

Это не юникод, это вайд-чар. Причём тут компилятор? Что объявил, то и получил.

Датчики - конструктивно законченное изделие и полностью готовое к применению. Внутри у них наклеены тензорезисторы соединённые по мостовой схеме, схема соединения тензорезисторов обеспечивает термокомпенсацию. Из какого материала сделаны тензорезисторы нам мало интересно. Датчик имеет два провода питания (вольтовый диапазон) и два сигнальных (милливольтовый диапазон). Иногда встречаются датчики с 6-ти проводной схемой, два доп. провода подключены параллельно проводам питания, используются для контроля целостности аналоговой линии, и может использоваться как опорное напряжение для АЦП. Вопрос стоимости заказчика мало волнует, волнуют сроки, точность и возможность в будущем увеличения количества аналогичных стендов.

Постараюсь ответить на все вопросы сразу. В этом проекте мы являемся субподрядчиками. Параметры и ограничения на предложение по реализации накладывает подрядчик, причём излюбленным способом - устно. Одним из условий нашего подряда - никаких устройств не разрабатывать, использовать только готовое покупное оборудование. Изготавливаться будет только остастка, но уже другим субподрядчиком. Из постановки задачи для выполнения первичного преобразования (нагрузки в электрические сигналы) выбран ряд возможных для данного применения тензометрических датчиков производства Флинтек и Земик. Подрядчик выберет из предложенного списка наиболее удобные конструктивно для него датчики. Для нас критериями выбора моделей является значения максимально возможной нагрузки (до 10 кг) и габаритов датчика (интересует распределение нагрузки на измеряемом объекте с дискретностью 10 мм). Один датчик будет измерять один 10 мм отрезок. Сумма измеряемых участков объекта пока заявлена 1200 мм (500 + 700). Для исключения ожидания времени прогрева перед выполнением измерений датчики должны быть постоянно подключены к источнику питания. В списке выбранных датчиков имеются модели с выходным сопротивлением 350, 1000, 1100 ом. Для минимизации эффекта температурного ухода нуля от саморазогрева датчиков питание датчиков будет выбираться в диапазоне от 5 до 10 вольт. Желаемое напряжение питания - 5 вольт. Другой, известный способ термокомпенсации - питание датчиков переменным током, скорее всего будет избыточным для этой задачи. Естественным желанием было найти готовый многоканальный АЦП специализированный для тензодатчиков, с максимально возможным количеством входных каналов. Исходя из возможных вариантов АЦП, будет выбираться аппаратная платформа. Предложений 4-х канальных преобразователей для тензодатчиков очень много, но с большим кол-вом каналов пока удалось найти только один 8 канальный модуль.

Herz. Не все параметры для решения задачи выбираю я. Вариант с масштабированием в 0..5 вольта или 4..20 мА мной заказчикам уже предлагался. Был отвергнут.

Простите, что не указал уровень помех и расстояния. 1. Уровень электромагнитных помех не не является фактором, влияющим на систему. 2. Наибольшая длина кабеля чуть менее 10 м. 3. В помещении (цеху) заметный уровень полимерной достаточно крупной пыли. Для сбора и обработки информации предполагается использовать промышленный компьютер. Плата оцифровки в идеале должна входить в состав компьютера (т.е. модуль или плата расширения). Вариант с масштабирование милливольтового сигнала в другой диапазон не рассматривается как приемлемый. Тензодатчики, предполагаемые для использования, будут аналоговые, сопротивлением не менее 350 ом.

Добрый день, Друзья! Есть интересная задачка. Нужно измерять распределение нагрузки на протяжённом объекте. Не лабораторного применения, будет использоваться в промышленном производстве, т.е. где-то 1500 измерений в сутки. Есть идея использовать тензодатчики, которые могут обеспечить требуемую точность, выдержать максимально возможную нагрузку и достаточную надёжность. Из постановки задачи следует, что нужно использовать кол-во датчиков близкое к 120 штукам. Для обеспечения точности и скорострельности датчики должны быть всё время включены (не ожидать прогрева датчика для измерения). Напрашивается какая-то плата аналогового ввода, с числом входных каналов порядка 128. Для обеспечения требуемой точности достаточно 13 эффективных разрядов. Поиск в интернетах готовой такой платы пока не выявил. Или как-то не так искал. У кого есть предложения такой платы?

Странно, но почему-то напомнило вот это: http://www.institutrobotov.ru/

Если нужно что-то под винЦЕ что-то поотлаживать, то можно поставить программу PocketController на ПК и, с извратом из-за разбитого экрана, на устройство поставить ее вторую часть. Программка помимо всего прочего эмулирует экран КПК на экране ПК, позволяя использовать мышь для имитации тачскина КПК. Вообще программка полезна при отладке GUI на КПК и создании документации на написанную программу, потому что она делает скрин-шоты экранов. Просто покопаться в процессоре без BSP для этой платы будет сложно.