Pat

А где и как заказывали?

Там больше человечесий фактор присуствовал. Какие бы защиты не делали их всегда можно обойти. (Прогресс придумал безопасные розетки для детей, погибают самые талантливые).

А что из Киева поезда в Россию не ходят? Или жалко проводнику денег дать?

Это та платформа, что в дЯревне "Бычий рай"?

Там тоже перепробовал все что можно. Самое интересное что Инструмент типа Link почему то не подсвечен его можно выбрать и добавить, если внизу установить CheckBox (извиняюсь сейчас нахоусь на работе и точно сказать не могу как он называется). Но ничего не меняется. Вообще где находятся сами настройки путей для текущего Tool Chain. Другими словами как Эклипс узнает о подключенных инструментах. Я так понимаю что эти инструменты (находятся) появляются при установеке ARM plugin.

Поскажите пожалуйста по настройке среды Eclipse. Установлены CDT и ARM plugin, CodeSourcery и Yagarto. В Tools Settings нет вкладки Link. Соответсвенно все не собирается. Что только не делал. И разные версии Eclipse брал и переустанавливал все и с настройками игрался. Не выходит.... Так же пусто во вкладке Additional Tools. Все это под Win7 Может кто знает волшебное слово.

Спасибо. Поиском, не нашел почему то. Будем знать.

В фале iostm8s103f3.h определена структура /* Flash control register 2 */ #ifdef __IAR_SYSTEMS_ICC__ typedef struct { unsigned char PRG : 1; unsigned char : 3; unsigned char FPRG : 1; unsigned char ERASE : 1; unsigned char WPRG : 1; unsigned char OPT : 1; } __BITS_FLASH_CR2; #endif __IO_REG8_BIT(FLASH_CR2, 0x505B, __READ_WRITE, __BITS_FLASH_CR2); Компилятор выдает ошибку От ошибки можно избавится если переименовать OPT например unsigned char OPTION : 1; уже ошибки нет. Вроде на глобальном уровне не нашел похожего имени OPT. Оно то не мешает, но интересно, что бы это могло быть. Причем оно везде и в EWSTM8 1.30 было и в 1.40 есть.

Здравствуйте Уважаемые Коллеги. Есть указанная выше связка. Портирую на нее LwIP взял за основу пример lwIP_Demo_Rowley_ARM7 из FreeRTOS. Работаю в Keil. После плясок с бубном запустил приемную часть. Принимаю входящие пакеты, LwIP в своей части прекрасно отрабатывает. Пока рассматриваю только запросы ARP. Запросы ARP прекрасно видны, принимаю свой запрос, LwIP формирует ответ (формат ответ проверял все соответствует) и посылает в передатчик. А дальше тишина до Wireshark ничего не доходит. Тут вот еще что меня напрягает, не могу вообще ничего отследить осциллографом по выводам MII даже в части приема. Приемная часть работает пакеты принимаются а на выводах RX ничего не вижу. Осцилограф C1-114/1, тактовую частоту на выводе RXC KS8721 вижу, а на выводах RXD0 - RXD3 никакой активности. Точно так же ничего не вижу на выходах передатчика только задающую частоту TXC\REFCLK. Плату подключил к древнему хабу и к нему же подключен вход ПК, если из платы передавать пакеты то светодиод LINK мигает как на плате так и в хабе. Значит что то передается вот только что и почему ничего не могу отследить Wireshark. А отследить наверное не могу из за "поломатого" пакета, то что находится в буфере для передачи я проверял там все хорошо, поэтому либо-либо. 1) EMAC не передает пакет полностью. 2) Либо передает но проблема с CRC Чем или как посмотреть что реально передается? Понятно, что если пакет бракованный то его откинут на уровне физики, но есть ли возможность увидеть на ПК сам факт что приходят плохие пакеты. Прошу помочь тема для меня совсем новая, еще нет необходимых знаний. Что касается настроек EMAC и KS8721 то что только не делал и не по разу. Может у кого будет рабочий пример в части драйвера EMAC AT91RM9200 и KS8721. С уважением Вадим.

Смотрю Ваши цены вот это не понятно Меньше нельзя заказывать. Другими словми могу ли я заказать плату в 0.45дм/кв c подготовкой производства под этот размер.

Друзья, Поздравляю Всех С Новым Годом. Здоровья, Любви, Счастья, Позитива, Креатива. Интересных проектов, после завершения которых появляется, гордость за себя.

Та же ерунда и с отладчиком JLink. Немного лучше получается если смотреть переменные не в окне Watch а в Memory.

А зачем запрос от хоста? Настраиваете канал передачи типа BULK и Хост будет сам ловить ваши данные и запихивать их в буфер потом только успевай их из буфера доставать и новый подсовывать. По крайней мере это так для реализации Хоста типа OHCI. Хост контроллер планирует транзакции в кадре (фрейме) и распределяет полосу. Полоса распределяется следующим образом. Вначале идут до определенного времени непереиодические передачи типа Controlи BULK. Затем передачи прерываний после них изохронные передачи и если еще осталось время в кадре то снова передаем BULK и Control. Другими словами если у вас на хосте висит одно устройство и оно передает только BULK то весь канал будет отдан ему и только ему. Поэтому вы получите Full Speed за минусом накладных расходов на заголовки пакетов и прочее.

Антон, Спасибо огромное.

Это я просил. Спасибо огромное. Думаю будет, Вам, общая благодарность, если найдете время допилить порт под F4. Еще раз Спасибо.

Может получится так, что на одном источнике упадет все напряжение которое на выходе. Это как диоды которые можно устанавить последовательно и они будут работать при повышенном обратном напряжении, но их надо зашунтировать кило-мегомными резисторами.

Программу пока не смотрел. Вы что хотите получить от HID. Эмулировть мыш, клавиатуру или сделать кастом HID. Предпологаю, что нужно разобратся с дескрипторами особенно интерфейса и отчета.

Обычно это решаться правильным выбором реле, которое должно выдерживать перегрузки в том числе и от преходных процессов. Есть специальные реле которые конструктивно имеют систему искрогашения. Схемотехнические искрогасящие цепи, устанавливаемые параллельно контактам реле или параллельно нагрузке. Например тут (думаю что легко найдете еще ссылки) http://www.meandr.ru/texts/RC.html http://www.atof.ru/pea/relay/rl_045.shtml Но мое ИМХО схемотехнические решения (по крайней мере те что я видел) не идеальны. При установке их параллельно контактам реле не будет полной развязки. Параллельно нагрузке будет отбор мошности с нагревом этих цепей. Поэтому лучше правильно подобрать реле, или если все очень плохо то найти реле с системой искрогашения.

А зачем, от чего и что Вы хотите защищать?

Решил проблему. Во время передачи данных должно выполнятся переключение триггера данных DATA TOGLE. В принципе этим занимается сам хост контроллер OHCI от нас (Драйвера Хост Контроллера) требуется только правильно начать процесс передачи данных, и дальше не мешать. Необходимо сохранять бит C (toggleCarry) поля HeadP дескриптора конечной точки ED при начале следующей транзакции. Алгоритм работы Хост Контроллера примерно такой (очень примерно). После выполнения транзакции (передача/прием) хост контроллер сохраняет значение последнего переключения данных в бите “C” поля HeadP дескриптора конечной точки. При этом в старшие биты ED->HeadP записывается адрес следующего дескриптора передачи (TD) и если в дескрипторе конечной точки (ED) значения старших бит поля HeadP равно TailP, то этот ED больше не будет обрабатываться хост контроллером. Можно считать что транзакция окончена. Так же обработанный дескриптор передачи (который до этого содержался в поле HeadP дескриптора конечной точки (ED) ) будет изъят из очереди (из этой ED) и помещен в HcDoneHead. Если нет ошибок, которые можно подсмотреть в битах CC поля DWord0 дескриптора передачи (TD). Об ошибке также говорит установленный бит H (Halted) в поле HeadP дескриптора конечной точки (ED). Другими словами если СС==0 и H == 0 можно считать, что транзакция закончена успешно. Хост контроллер больше не будет обрабатывать эту связку ED TD. Поэтому нужно сформировать новую транзакцию, для чего необходимо обновить поля дескрипторов передачи и конечной точки. Нужно восстановить значения в полях 1) дескриптора передачи (TD): CBP – здесь находится адрес приемного буфера BE – это адрес но конец буфера (обновляем если в CPB каждый раз записываем новое значение, например организовано FIFO) NextTD – здесь указатель на следующий дескриптор передач (в нашем случае это пустой TD) 2) дескриптора конечной точки (ED): В HeadP - необходимо прописать указатель на TD, в котором содержится адрес приемного буфера, причем необходимо сохранить бит Toggle Carry. Примерный алгоритм показан ниже. Обновить дескрипторы необходимо после срабатывания прерывания по изъятию TD из списка ED, с перемещением его в очередь HcDoneHead. AT91S_UHP_ED *pInIntED; AT91S_UHP_TD *pInIntTD[2]; // Равенство HeadP и TailP означает, что pInIntED обработан хост контроллером if((pInIntED->HeadP & 0xFFFFFFF0) == pInIntED->TailP) { // Запрещаем обрабатывать pInIntED pInIntED->Control |= (1 << 14); // Сюда помещаем начал адреса приемного буфера pInIntTD[0]->CBP = (unsigned int)fifo.get_next_inc(); // и адрес его окончания pInIntTD[0]->BE = pInIntTD[0]->CBP + (BuffLen) ? CurBufPtr + BuffLen - 1 : CurBufPtr; // Адрес нулевого TD pInIntTD[0]->NextTD = (unsigned int)pInIntTD[1]; // Присваиваем указатель на TD и сохраняем значение бита “C” pInIntED->HeadP = (unsigned int)pInIntTD[0] | (0x0000000E & pInIntED->HeadP); // Разрешаем обрабатывать pInIntED pInIntED->Control &= ~(1 << 14); flag = MOUSE_EVENT; } Предполагаю вопрос из первого поста должен решится правильным переключением DATA TOGLE. (Пока нет времени это проверить). Ниже привожу, как заполнить дескрипторы конечной точки и передачи для транзакций IN. //Create a default endpoint descriptor AT91F_CreateEd( (unsigned int) pInIntED, // ED Address m_nMaxPacketSize, // Max packet size 0, // TD format 0 - generic 1 - Isochronous 1, // Skip Запрешаем в будующем обрабатывать хост контроллеру этот дескриптор конечной точки speed, // Speed = ("0" <=> "Full", "1" <=> "Low") 0x02, // Direction IN enpN, // Номер Endpoint m_wDeviceAddress, // Адрес устройства Func Address (unsigned int) pInIntTD[1], // TDQTailPointer (unsigned int) pInIntTD[0], // TDQHeadPointer 0, // ToggleCarry 0); // NextED //Create transfer descriptor //Data IN AT91F_CreateGenTd( (unsigned int) pInIntTD[0], // TD Address 0, // Data Toggle (First data packet <=> "0") 0, // DelayInterrupt 0x2, // Direction ("2" <=> IN) 1, // Buffer Rounding (unsigned int) buffer, // Current Buffer Pointer (unsigned int) pInIntTD[1], // Next TD length); // Buffer Length // Пустой дескриптор передачи AT91F_CreateGenTd( (unsigned int) pInIntTD[1], // TD Address 0, // Data Toggle 0, // DelayInterrupt 0, // Direction 0, // Buffer Rounding 0, // Current Buffer Pointer 0, // Next TD 0); // Buffer Length // Размещаем ED в таблице прерываний // При таком размещении транзакции будут генерироваться с // периодом 8 mS HCCA.HccaInterruptTable[4] = (unsigned int)pInIntED; HCCA.HccaInterruptTable[12] = (unsigned int)pInIntED; HCCA.HccaInterruptTable[20] = (unsigned int)pInIntED; HCCA.HccaInterruptTable[28] = (unsigned int)pInIntED; ///Устанавливаем бит "PeriodicListEnable". Остальные биты не трогаем AT91C_BASE_UHP->UHP_HcControl |= 0x04; /* ************************************************ */ /* Generate traffic between UHP and UDP */ /* ************************************************ */ //Skip == 0, т.е. "запускаем" список TD в работу pInIntED[idx]->Control &= ~(1 << 14); Ну и до кучи typedef struct _AT91S_UHP_ED { volatile unsigned int Control; volatile unsigned int TailP; volatile unsigned int HeadP; volatile unsigned int NextEd; } AT91S_UHP_ED, *AT91PS_UHP_ED; typedef struct _AT91S_UHP_TD { volatile unsigned int Control; volatile unsigned int CBP; volatile unsigned int NextTD; volatile unsigned int BE; } AT91S_UHP_TD, *AT91PS_UHP_TD; typedef struct _AT91S_UHP_HCCA { volatile unsigned int HccaInterruptTable[32]; volatile unsigned short HccaFrameNumber; volatile unsigned short HccaPad1; volatile unsigned int HccaDoneHead; volatile unsigned char reserved[116]; } AT91S_UHP_HCCA, *AT91PS_UHP_HCCA; //*---------------------------------------------------------------------------- //* Init a pre-allocated endpoint descriptor. !!! //* ED must be aligned on a 16 bytes boundary //*---------------------------------------------------------------------------- __inline void AT91F_CreateEd( unsigned int EDAddr, unsigned int MaxPacket, unsigned int TDFormat, unsigned int Skip, unsigned int Speed, unsigned int Direction, unsigned int EndPt, unsigned int FuncAddress, unsigned int TDQTailPntr, unsigned int TDQHeadPntr, unsigned int ToggleCarry, unsigned int NextED) { AT91PS_UHP_ED pED = (AT91PS_UHP_ED) EDAddr; pED->Control = (MaxPacket << 16) | (TDFormat << 15) | (Skip << 14) | (Speed << 13) | (Direction << 11) | (EndPt << 7) | FuncAddress; pED->TailP = (TDQTailPntr & 0xFFFFFFF0); pED->HeadP = (TDQHeadPntr & 0xFFFFFFF0) | (ToggleCarry << 1); pED->NextEd = (NextED & 0xFFFFFFF0); } //*---------------------------------------------------------------------------- //* Init a pre-allocated transfer descriptor. !!! //* TD must be aligned on a 16 bytes boundary //*---------------------------------------------------------------------------- __inline void AT91F_CreateGenTd( unsigned int GenTdAddr, unsigned int DataToggle, unsigned int DelayInterrupt, unsigned int Direction, unsigned int BufRnding, unsigned int CurBufPtr, unsigned int NextTD, unsigned int BuffLen) { AT91PS_UHP_TD pTD = (AT91PS_UHP_TD) GenTdAddr; pTD->Control = (DataToggle << 24) | (DelayInterrupt << 21) | (Direction << 19) | (BufRnding << 18) | 0xF0000000; pTD->CBP = CurBufPtr; pTD->NextTD = (NextTD & 0xFFFFFFF0); pTD->BE = (BuffLen) ? CurBufPtr + BuffLen - 1 : CurBufPtr; } Перечитал написанное, одни ED и TD, нужно их в голове упорядочить, на что у меня ушло не мало времени. Из информации одни стандарты и примеры типа U_Boot где голову сломать можно. Отдельное спасибо автору сайта, где есть перевод стандарта правда не полный http://microcontrollerov.net/books/OpenHCI Ну и спасибо всем откликнувшимся ;)

Еще как шагнули вперед, 1-2 такта и 100Мгц. http://www.silabs.com/products/mcu/Pages/8...ontrollers.aspx http://we.easyelectronics.ru/MCS51/start-s-silabom.html

Наметился прогресс. Только странно это как то. В спецификации сказано что ED и TD должны быть выровнены по границе 16 бит, что и делаю. Должен ли быть выровнен приемный буфер (который указываем в регистре CBP дескриптора передачи TD) ничего не сказано (или не нашел где указано). Выровнял приемный буфер по границе диапазона и начал принимать данные, но через раз. В данный момент у меня настроена только одна конечная точка прерываний, другими словами читаю данные один раз в 32 мсек. В дескрипторе конечной точки мыши читаем, что значение интервала опроса должно быть 10 мсек. получается надо настраивать опрос конечной точки один раз в 8 мсек. Думаю, что в этом заключается проблема потери данных или…. (см. ниже) Не понятно, что делать с DATA TOGLE (DT). 1 Переключение (DT) происходит в процессе передачи пакетов данных, которые больше чем максимальный пакет, разрешенный для устройства? (В пределах одной транзакции) 2 Данные должны переключаются каждый раз при приеме очередного пакета? (В каждой отдельной транзакции). Сейчас, я читаю данные каждый раз с DT=1 предполагая, что процесс проходит по типу вопроса 1. Вечером буду проверять.

Нашел два файла, где есть пример чтения репортов мыши через канал прерывания. Правда у меня вызывает сомнение реализация функции заполнения дескриптора конечной точки. void OHCI_Create_ed (tED **ed, tTD **td, u32 FA, u32 EN, u32 D, u32 S, u32 K, u32 F, u32 MPS) { if (((*ed) != NULL) || ((*td) != NULL)) rExit("OHCI_Create_ed failed."); (*ed) = rmalloc16B ("HC_ENDPOINT_DESCRIPTOR"); (*ed)->Control = 0; (*ed)->Control |= (FA << 0); //7-bit (*ed)->Control |= (EN << 7); //2-bit (*ed)->Control |= (D << 9); //2-bit (*ed)->Control |= (S << 11); //1-bit (*ed)->Control |= (K << 12); //1-bit (*ed)->Control |= (F << 13); //1-bit (*ed)->Control |= (MPS<< 14); (*td) = rmalloc16B ("HC_TRANSFER_DESCRIPTOR"); (*td)->Control = 0; (*td)->CBP = NULL; (*td)->NextTD = NULL; (*td)->BE = NULL; (*ed)->TailP = (*td); (*ed)->HeadP = (*td); (*ed)->NextED = NULL; } Не сходятся со стандартом биты которые устанавливаются в Control (D << 9),(S << 11),(K << 12),(F << 13),(MPS<< 14); Должно быть так (D << 11),(S << 13),(K << 14),(F << 15),(MPS<< 16); В исходниках по тексту видно, что при, заполнении ED программист подбирал значения, но не везде. Поэтому не понятно работоспособен ли данный пример. Сделал ED, TD как в примере. // Формируем структуру дескриптора конечной точки ED AT91F_CreateEd( (unsigned int) &pED, // ED Address 8, // Max packet size 0, // TD format 1, // Skip 1, // Speed = "Low" ("0" <=> "Full", "1" <=> "Low") 0x0, // Direction (брать из поля PID Td) 0x1, // Endpoint Address FuncAddress, // Func Address (unsigned int) &pTD[1], // TDQTailPointer (unsigned int) &pTD[0], // TDQHeadPointer 0, // ToggleCarry 0x0); // NextED // Формируем структуры дескрипторов передачи ТD //Data IN AT91F_CreateGenTd( (unsigned int) &pTD[0], // TD Address 3, // Data Toggle (First data packet <=> всегда DATA1) 0x00, // DelayInterrupt 0x2, // Direction ("2" <=> In) 1, // Buffer Rounding (unsigned int) buffer, // Current Buffer Pointer (сюда принимаем данные) (unsigned int) &pTD[1], // Next TD 4); // Buffer Length // Этот TD хостом не должен обрабатывается AT91F_CreateGenTd( (unsigned int) &pTD[1], // TD Address 0, // Data Toggle 0, // DelayInterrupt 0, // Direction ("1" <=> Out) 0, // Buffer Rounding 0, // Current Buffer Pointer (unsigned int) 0, // Next TD 0); // Buffer Length Пропали ошибки. Стал отлавливать события от мыши. Вот только в приемном буфере одни нули. Ладно будем разбираться дальше. Файлы примера прикладываю. ohci_example.rar

Не получается ни так ни этак. Что-то совсем запутался, уже не знаю, что и делать. Пытаюсь организовать канал прерывания для чтения репорта мыши. Подскажите, как правильно сформировать список TD для запроса данных IN прерывания? Один из моих вариантов. // |Формируем структуру дескриптора конечной точки ED AT91F_CreateEd( (unsigned int) &pCtrlED, // ED Address 8, // Max packet size 0, // TD format 1, // Skip 1, // Speed = "Low" ("0" <=> "Full", "1" <=> "Low") 0x0, // Direction (брать из поля PID Td) 0x1, // Endpoint Address FuncAddress, // Func Address (unsigned int) &pCtrlTD[2], // TDQTailPointer (unsigned int) &pCtrlTD[0], // TDQHeadPointer 0, // ToggleCarry 0x0); // NextED //Data IN AT91F_CreateGenTd( (unsigned int) &pCtrlTD[0], // TD Address 3, // Data Toggle (First data packet <=> всегда DATA1) 0x00, // DelayInterrupt 0x2, // Direction ("2" <=> In) 1, // Buffer Rounding (unsigned int) buffer, // Current Buffer Pointer (сюда принимаем данные) (unsigned int) &pCtrlTD[1], // Next TD 5); // Buffer Length //Status OUT AT91F_CreateGenTd( (unsigned int) &pCtrlTD[1], // TD Address 3, // Data Toggle (Status packet <=> всегда DATA1) 0x00, // DelayInterrupt 0x01, // Direction ("1" <=> Out) 1, // Buffer Rounding 0x0, // Current Buffer Pointer (unsigned int) &pCtrlTD[2], // Next TD 0x0); // Buffer Length // Этот TD хостом никогда не обрабатывается AT91F_CreateGenTd( (unsigned int) &pCtrlTD[2], // TD Address 3, // Data Toggle 0x00, // DelayInterrupt 0x01, // Direction ("1" <=> Out) 1, // Buffer Rounding 0x0, // Current Buffer Pointer (unsigned int) 0, // Next TD 0x0); // Buffer Length После я подсоединяю ED к HCCA. HccaInterrruptTable[0] и установив бит PLE в HcControl. Ждем события мыши, так как предварительно было установлено Idle = 0. Нажав на кнопку мыши, я принимаю первый пакет данных, в buffer записываются прочитанные данные и они вроде правильные. Но в pCtrlTD[1].control в поле CC = 5 ошибка DEVICENOTRESPONDING Device did not respond to token (IN) or did not provide a handshake (OUT) И все от мыши больше ничего принять нельзя. Перечитал кучу литературы с нулевым результатов. Передача прерывания состоит из трех пакетов Token Packet Data Packet H/S Packet pCtrlTD[0] – это Data Packet pCtrlTD[1] – должен быть H/S Packet (но он передается с ошибкой) Кто формирует Token Packet. Думаю, что его формирует OHCI из ED, но может его нужно указывать явно через дополнительный TD (так тоже пробовал, но ничего не получилось). Подскажите хотя бы правильное направление, а то три недели стою на месте уже не знаю что и делать.

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