Jump to content

    

Intel4004

Участник
  • Content Count

    74
  • Joined

  • Last visited

Everything posted by Intel4004


  1. А хрен его знает. Но практика показывает, что оно работает. UART по кабелю пускал в однопроводном режиме (Rx с Tx закорочены). Условия точно такие-же как и здесь, с обоих сторон открытый коллектор и несколько метров провода. Подтяжки с обоих сторон позволяли поднять скорость в два раза.
  2. Фронты приличнее будут выглядеть. Подтяжки на обоих концах длинной линии немного компенсируют емкость линии.
  3. Да, не помню откуда я взял про внутриплатность. Сейчас там явно сказано, что можно: In general, the wiring must be chosen so that crosstalk and interference to/from the bus lines is minimized. The bus lines are most susceptible to crosstalk and interference at the HIGH level because of the relatively high impedance of the pull-up devices. If the length of the bus lines on a PCB or ribbon cable exceeds 10 cm and includes the VDD and VSS lines, the wiring pattern should be: SDA _______________________ VDD ________________________ VSS ________________________ SCL _______________________ Я не про согласование, тут не те частоты. SDA - двунаправленный (SCL теоретически тоже), т.ч. на стороне мастера хотя-бы кил 50 надо навесить.
  4. Если я правильно помню, то в спецификации от филипс явно сказано, что I2C - внутриплатный интерфейс и в цепях SCL/SDA не должно быть разъемов и проводов. Если сильно хочется - то во первых нужен кабель с минимальной емкостью(и желательно с экраном), а во вторых подтяжки на обоих концах кабеля.
  5. У меня снабженцы не смогли найти у нормальных поставщиков флешки типа AT49F и купили партию судя по всему в каком-то музее. 1998 год выпуска. Паяются, правда, хреново, но работают как новые.
  6. Недавно практически такую-же тему создавал. В результате пришел к тому, что написал обертку вокруг кейловских MDK USB и MDK FS. Работает так: если нужен доступ к флешке, которая в данный момент используется как USB MSC - то ждем 5 сек с последнего обращения по MSC (на самом деле винда сбрасывает флаг "смонтировано" через полторы секунды после последней записи, т.ч. 5 - для пущей надежности), ставим MSC в паузу (переключаем владельца на FS), читаем/пишем на флешку. После этого если только читали - переключаем владельца назад на MSC. Если писали - делаем USB Disconnect/Connect.
  7. Сделал. Стресстесты еще недельку погоняю, но вроде работает, винда больше не возмущается. Но если у кого-нибудь через сколь угодно долгое время возникнет идея как решить эту проблему красиво, без костылей - приму эту идею с благодарностью.
  8. Пока добавлю задержку перед дисконнектом, пока не пройдет секунда с последней записи по MSC. Тоже костыль, тоже второго уровня, но по крайней мере может спасти от воплей современной винды "устройство было извлечено некорректно, надо проверить". Только вот еще регулярно встречаются древние виндовс (2000, xp) в которых, ЕМНИП, флешка кешируется...
  9. В смысле после принудительного дисконнекта сбросить на диске флаг "не размонтировано" (или как он там называется)? Так ведь это тоже костыль. Причем второго уровня, поверх первого. Винда на этот флаг хотя-бы чекдиск запускает...
  10. Исходные данные: Есть устройство, имеющее на борту флешку и USB. Естессно эта флешка отдается наружу как USB mass storage. Все прекрасно работает, но только до тех пока пока устройству не захочется что-то записать на эту флешку в тот момент, когда оно(устройство) подключено к компьютеру по USB. Пока что я реализовал костыль: принудительно вырубаю USB перед записью во флешку. В результате регулярно при следующем подключении винда мне сообщает, что устройство было извлечено некорректно. Так вот, вопрос: есть ли какая-нибудь возможность со стороны USB устройства сообщить хосту, что устройство хочет отключиться? Чтобы винда сбросила кеш и корректно размонтировала диск? Я понимаю, что в рамках MSC это невозможно. Но может быть есть какие-нибудь другие способы? Если что - свободных эндпоинтов на устройстве хватает, реализовать еще один USB-класс - не проблема.
  11. Ну, можно в свойствах проекта, на вкладке Target отрезать от IRAM1 нужное количество памяти, вписать его в IRAM2, и поставить на IRAM2 галочку NoInit. Смысл этого действия тот-же, но не требует редактирования scatter.
  12. Буду думать. PS. 24 байта (непонятно(0), указатель на свободное место, указатель на heap, указатель на мутекс, непонятно(0), свободное место(0)).
  13. Тогда второй вопрос: а как к этому отнесется Keil RTX ?
  14. Я бы с удовольствием. Но сторонние библиотеки (JSON например) эту кучу пользуют со страшной силой. И компилять из одного комплекта исходников пару десятков разных бинарников? И иметь геморрой с производством, которое все перепутает и будет, как вы говорите, сношать мне мозги что ничего не работает? Лучше я отмучаюсь один раз, написав универсальную прошивку, чем пару раз в неделю заново объяснять что и в каком случае из этого зоопарка надо прошивать.
  15. Этот вариант я знаю. Проблема в том, что конфигурацию платы я могу прочитать только после запуска RTOS.
  16. Поясняю: на плате могут распаять SRAM разного размера, могут вообще не распаивать. Конфигурация платы будет прошита в EEPROMке. В зависимости от конфигурации настраиваю heap (адрес/размер), и в зависимости от размера блокирую некоторые функции программы, чтобы не выжрать весь heap.
  17. Проблема в том, что на этапе компиляции я еще не знаю какие именно микросхемы SRAM будут распаяны на плате. Достаточно ли для этого по новому адресу прописать пустую HEAP-структуру, и подменить указатель на heap по адресу __user_libspace()+8 ? Или ссылки на heap еще где-то присутствуют?
  18. Я же UDP отлаживал, соответственно у меня открыто окно с регистрами UDP (Peripherals->System Viewer->UDP). И галочка "periodic update" стоит. Вот он и портил FIFO. Достаточно убрать галочку или закрыть окошко с регистрами - все нормально.
  19. Такого в моей практике еще не было. Больше недели трахался с абсолютно рабочим исходником. Кстати, как оказалось бит DTGLE вполне можно использовать для определения какой банк сбрасывать (RX_DATA_BK0 или RX_DATA_BK1). status = UDP->UDP_CSR[ep_num]; ... if ((status & (UDP_CSR_RX_DATA_BK0 | UDP_CSR_RX_DATA_BK1)) != (UDP_CSR_RX_DATA_BK0 | UDP_CSR_RX_DATA_BK1)) status &= UDP_CSR_RX_DATA_BK0 | UDP_CSR_RX_DATA_BK1; else { if (status & UDP_CSR_DTGLE) status = UDP_CSR_RX_DATA_BK1; else status = UDP_CSR_RX_DATA_BK0; } UDP_CSR_CLEAR(ep_num, status); Интересно, почему во всех фреймворках используют не DTGLE, а программный флаг, полностью эмулирующий поведение DTGLE? Кстати, кейловский CMSIS MSC оказался не таким тормозным как я ожидал. С SD-флешкой 600Kb/s на запись, 750Kb/s на чтение.
  20. МамаМиа! Деру себя за волосы! Выдернул JLink, ребутнул железяку. ОНО РАБОТАЕТ!!! Поехал водку пить...
  21. Собрал по быстрому MSC пример в Atmel Studio. Оказалось достаточно просто... Он работает! С теми-же настройками PMC, на тех-же частотах. Железо в порядке. Прошелся по обоим проектам от начала и до прихода первого SETUP пакета. Ничем не отличаются (я на ASF и поглядывал, когда писал). Те-же самые записи, в те-же регистры, в том-же порядке. У них работает, у меня пакет регулярно приходит битым. Поставил брейкпоинт в обоих проектах на прерывание SETUP(когда все уже давно отконфигурировано) и сравнил настройки кеша, EFC, PMC. Привел в соответствие, теперь они идентичны. У прерывания UDP - самый высокий приоритет, но на всякий случай завернул все функции в запретить/восстановить. Даже понатыкал __DMB() где надо и где не надо. Пофигу. Ничего не помогает.
  22. А их нет. Когда атмел был еще атмелом - примеры были на каждый чих, как он стал микрочипом - примеры исчезли как класс. Есть Atmel Studio и Atmel Software Framework (ASF), на них можно собрать что-то вроде примера, с минимальным написанием собственного кода - но с ними еще разбираться надо...
  23. Пишу CMSIS UDBD драйвер для ATSAM4E. Не могу найти источник глюка. SETUP пакет регулярно приходит с потерей байт. Причем размер пакета (RXBYTECNT в UDP_CSR[0]) правильный, 8 байт, но сам пакет считанный из FIFO сдвинут на один/два байта и дополнен мусором до 8 байт. Например должно прийти: 80 06 00 01 00 00 40 00 приходит: -- 06 00 01 00 00 40 00 dd должно прийти: 00 05 01 00 00 00 00 00 приходит: -- 05 01 00 00 00 00 00 eb должно прийти: 02 01 00 00 84 00 00 00 приходит: -- 01 00 00 84 00 00 00 06 или: -- -- 00 00 84 00 00 00 06 1d Глюк проявляется случайным образом примерно на одном пакете из десяти. Исходник проверил, вылизал и практически уверен, что проблема не в нем. Железяка пока в единственном экземпляре, т.ч. проверить на другой возможности нет. Никто с подобным не сталкивался? В чем может быть источник проблемы? UPD. Причем проблема только с SETUP пакетами. Когда дело доходит до CBW - то OUT транзакции с CBW пакетами проблем не имеют... UPD2. Нет, это я поторопился. bulk транзакции так-же корежатся: INQUIRY H TX 55 53 42 43 d0 1b bc 0d 24 00 00 00 80 00 06 12 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 D RX 55 53 42 43 d0 1b bc 0d 24 00 00 00 80 00 06 12 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 D TX 00 80 00 02 1f 00 00 00 4b 65 69 6c 20 20 20 20 44 69 73 6b 20 30 20 20 20 20 20 20 20 20 20 20 31 2e 30 20 H RX 00 80 00 02 1f 00 00 00 4b 65 69 6c 20 20 20 20 44 69 73 6b 20 30 20 20 20 20 20 20 20 20 20 20 31 2e 30 20 D TX 55 53 42 53 d0 1b bc 0d 00 00 00 00 00 H RX 55 53 42 53 d0 1b bc 0d 00 00 00 00 00 READ FORMAT CAPACITIES H TX 55 53 42 43 d0 6b b1 0d fc 00 00 00 80 00 0a 23 00 00 00 00 00 00 00 fc 00 00 00 00 00 00 00 D RX 55 53 42 43 d0 6b b1 0d fc 00 00 00 80 00 0a 23 00 00 00 00 00 00 00 fc 00 00 00 00 00 00 00 D TX -- 00 00 00 08 00 ee 20 00 02 00 02 00 H RX 00 00 00 00 08 00 ee 20 00 02 00 02 00 D TX 55 53 42 53 d0 6b b1 0d f0 00 00 00 00 H RX 55 53 42 53 d0 6b b1 0d f0 00 00 00 00 INQUIRY H TX 55 53 42 43 d0 6b b1 0d ff 00 00 00 80 00 06 12 01 80 00 ff 00 00 00 00 00 00 00 00 00 00 00 D RX -- -- 42 43 d0 6b b1 0d ff 00 00 00 80 00 06 12 01 80 00 ff 00 00 00 00 00 00 00 00 00 00 00 62 f3
  24. Стоило сюда написать, как сразу все заработало. Хреново я из asf-master выдирал, невнимательно. Interface->TWI->TWI_PTCR = TWI_PTCR_RXTDIS | TWI_PTCR_TXTDIS; Interface->TWI->TWI_RNPR = (unsigned int)Buffer; Interface->TWI->TWI_RNCR = Size; Interface->TWI->TWI_PTCR = TWI_PTCR_RXTEN | TWI_PTCR_TXTEN; Interface->TWI->TWI_CR = TWI_CR_START; while ((Interface->TWI->TWI_SR & TWI_SR_ENDRX) == 0); Interface->TWI->TWI_PTCR = TWI_PTCR_RXTDIS | TWI_PTCR_TXTDIS; Interface->TWI->TWI_CR = TWI_CR_STOP; while ((Interface->TWI->TWI_SR & TWI_SR_TXCOMP) == 0);