esaulenka

Кстати, поддержу вопрос. LPC1768 (или любой другой LPC, отличий в USB мне обнаружить не удалось). сигнал VBUS заведен на ногу VBUS, которая сконфигурирована как VBUS. Чтением ЧЕГО я могу определить уровень на VBUS ? Где-то внутри оно явно определяется (при ошибке, когда на пин всегда приходил ноль, энумерация идти никак не хотела), но через какой регистр это можно увидеть, я не нашёл. GPIO не предлагать :-)

Значение USER_CODE будет +1 или +0 в зависимости от того, ARM-код это, или THUMB. В моей реализации большими буквами написано "SWI и xxx_Handler не используется, надо инициализировать только пользовательский стек". Но вообще-то для универсального бута странно. Это я знаю, что буду грузить своим загрузчиком.

Прошёл всего лишь месяц, и у меня дошли руки проверить. LPC1778 (уж что было под рукой, с припаяным лог.анализатором). Один таймер с NVIC_SetPriority(4), другой таймер с NVIC_SetPriority(0). В первом - длительная задержка (в половину его периода) и дрыганье ножкой на входе и выходе. Во втором - также дрыганье ножкой. Кроме EnableIRQ и SetPriority, в проекте больше нет никаких обращений к NVIC'у. Компилятор - кейл. В итоге - дрыг ножкой второго таймера от первого никак не зависит, находится ли тот в прерывании, или нет. Собственно, что и требовалось доказать - NXP люди вменяемые и делают контроллеры, которые работают согласно документации :-)

Очередной подземный стук... Как вариант - "неправильные" ноги сконфигурированы не как GPIO, а какая-то периферия (для P1.28 P1.29 - выходы таймера, например). Методика лечения - прочитать раздел даташита про переназначение ног и внимательно проверить код примера на предмет лишних переназначений (внимательно! там один регистр сразу переназначает 16 выводов).

Ну, не на себя (в этом действительно смысла немного), а на следующий такой же объект. Подробности здесь: http://ru.wikipedia.org/wiki/%D0%A1%D0%B2%...%81%D0%BE%D0%BA В оригинале, кстати, оно выглядит так: /** Generic data structure used for all lwIP network interfaces. * The following fields should be filled in by the initialization * function for the device driver: hwaddr_len, hwaddr[], mtu, flags */ struct netif { /** pointer to next in linked list */ struct netif *next;

Вы, наверное, в курсе, что USB-host и USB-device - разные вещи? И USB-host, на мой взгляд, это довольно "интересный" курсовик :-)

А где задача "измерить" ? Я вижу задачу "сравнить с порогом". Может, стоит продумать вариант с 4 компараторами, нагруженными на оптопары?

Это, пардон, где такое написано?

kovigor, спасибо. Извиняюсь, не указал - сейчас размер пакетов от 1 байта до полутора сотен. Планов "а давайте увеличим размер на порядок" пока нет, тьфу-тьфу. Так что фрагментирование не должно потребоваться. Как я вычитал в даташите на LPC17xx, есть и MAC, и DMA. Всё это добро самостоятельно принимает пакеты и раскладывает их по порядку в памяти. Аналогично с отправкой. Выглядит просто замечательно, ничего низкоуровнего делать не надо.

1) (общетеоретический). Посоветуйте, где достаточно подробно почитать про низкоуровневые (TCP/UDP и "ниже") вещи ? То, что я нарыл, это пяток страничек на каждый уровень, а потом "перейдём к настройке web-сервера". По-русски читаю чуть лучше, чем по-английски :-) 2) (более практический) какой протокол мне выбрать? сейчас железка общается с ПК по своему собственному протоколу через UART и USB (через эмуляцию UART). Есть желание добавить ethernet, а поверх него пустить тот же протокол. Вопрос - что бы такое пустить по ethernet? "Чистый" IP не хочется по избежание геморроя со стороны ПК (сейчас - всевозможные windows, в планах linux, вероятны android/ios). Контроль доставки, который даёт TCP, не очень актуален - сейчас этим занимается наш протокол (не очень оптимально, т.к. задумывалось это под медленные uart'ы, ну да фиг с ним). Сделать UDP ?.. Или для простоты понимания программерами ПК сделать TCP, а с контролем доставки всё-таки разобраться (см. пункт 1) ? 3) (совсем уж практический) в текущем софте RTOS нет, и желания её туда прикручивать у меня немного. Стек TCP(UDP) хорошо бы запихать в обработчик прерывания (с учётом вложенных прерываний это не так страшно, холивар прошу не разводить). Посмотрел uIP и lwIP, они заточены под супер-луп или отдельную задачу в RTOS. Кто-нибудь стек посоветует? Самому писать без опыта (опять см. пункт 1) будет очень долго, подкладывать костыли под тот же uIP - больно некрасиво... Совсем уж идеально - чтоб автор знал о модуле MAC в контроллерах LPC и не очень пытался затачиваться под что-то совсем другое :-)

Может, нам theBMV расскажет, что у него за компилятор? И даже стартапы все покажет? :-) Кейл по умолчанию делает только инициализацию стеков, включает питание на периферию и настраивает PLL. Тут, кажется, IAR, и там, может, есть настройки NVIC ?

Предложение - забить на обновление FAT'а (сделать его ридонли, в памяти контроллера), и обновлять только данные. Пользователю разрешить только перезаписывать единственный имеющийся файл. Нечто похожее есть в примерах NXP "USB bootloader".

Что-то я не понимаю... По умолчанию в AIRCR поле "Interrupt priority grouping field" равно нулю. По моим соображениям, это означает, что приоритеты прерываний - это именно priority, а не subpriority. Т.е. количество вложенных прерываний может быть максимальным. Ссылку на infocenter.arm.com дать не могу - никак не найду, где её там взять :-) На железе, правда, все свои соображения проверить поленился: у меня критичное к времени старта прерывание ровно одно, оно же - самое длительное. Остальные прерывания быстрые, и особо не влияют. Пока, во всяком случае...

Это взаимоисключающие понятия, на мой взгляд. Человек, который считает себя продвинутым программером, ДОЛЖЕН хотя бы читать ассемблер. Странные дела творятся... Я кроме кейла и не знаю ничего (мои поделки на вижуал си дальше соседнего кабинета не уходят, AVR в конторе не в почёте уже года три (когда их купить нельзя было)), но выкинуть неиспользуемую переменную - это довольно простая оптимизация, было б очень странно, что другие компиляторы ей не пользуются. Да ради бога. НО: а) с вероятностью 99.99% там будет именно то, о чём я уже написал - функция MPU6050_read_reg() что-то там считывает и возвращает, а main() это игнорирует б) лично я буду это анализировать недельки через две. Интернет в отпуске - зло :-)

Предлагаю заглянуть в словарь. "variable was set but never used" означает, что в переменную записывается значение, которое потом никто никогда не считывает (это очевидно из кода main() ). У компилятора логика простая: раз эту переменную никто не считывает, её можно безболезненно выкинуть. Варианты решения: 1) правильный: дописать код, который будет использовать это значение. Хотя бы на экранчик выводить. 2) тоже правильный: посмотреть по дизассемблеру (!) MPU6050_read_reg(), что "return не выполняется!!" - это неправда, и возвращается верное значение. 3) неправильный: прочитать про volatile и/или отключить оптимизацию.

Ищите галку "обновлять значения переменных" где-то в дебрях меню дебага. Должно помочь.

1) предлагаю прочитать раздел user manual "flash memory programming" 2) сейчас камень можно оживить, прижав P2.10 к земле в момент старта, и очистив всю память через flash magic (uart0 наружу есть?). 3) дальнейшие эксперименты предлагаю выполнять с кодом unsigned int const CRP2 __attribute__((at(0x1FC))) = 0; - при левых значениях этой константы JTAG не отключается. Убедившись, что всё работает, можно включить запрет штатного загрузчика (и JTAG'а).

Вот ведь китайцы... По-хорошему (см. ответ Руслана), там выход 150 мА. Каждое реле - это 150 мА и есть (если оно живое, и ничего дополнительно не замкнулось), так что перегрузка изрядная. Massi, ну прочитайте ж текст, наконец, перед написанием ответов!

поиск по arm.com "cortex-m3 unaligned access" Так что контроллер работает согласно спецификации :-) К кейлу тоже никаких претензий - он же не знает, что этот указатель не выравнивается. PS. Вот так должно работать.

Кстати да. На LPC1768 я аналогичное поведение наблюдал. Поэкспериментировать с подтяжками в разные стороны всё никак руки не дойдут...

Конкретнее, чем здесь, не знаю :-) http://www.nxp.com/products/microcontrolle...8.html#ordering (смотреть Orderable part number)

Я перегоняю в массив, включаю файл в проект, а далее - как обычно. Если файл один, можно сконвертировать каким-нибудь хекс-редактором, там часто есть "export C/Pascal/ASM". Могу порекомендовать HxD - ничего лишнего и совершенно бесплатно. Если файлов много, или они регулярно меняются, лучше написать скриптик для srecord.

Проверять лень, но, может быть, к проекту подцеплены два стартапа?..

Повторюсь. У этих микросхем есть параметр SCR rise (fall) time, равный 0.1 V/ns min. Для 3 вольт питания это означает максимальное время фронта 30 наносекунд. По опыту, при превышении этих параметров будет работать именно так, как описано - читается всякая фигня, вне зависимости от самой частоты клока. При этом форма сигнала довольно хорошая...

Предлагаю пользоваться более свежей версией библиотек. Заголовок lpc17xx.h 1.1 (или что-то похожее) содержал вообще немеряное количество опечаток. В более новых system_lpc17xx.c эту проверку убрали. Да, ноги растут отсюда: