ig_z

Я точно не вспомню, но делал что то типа такого: Помещал "супер структуру" + массив байт в "супер-супер структуру" Размерность массива байт задавал как остаток от деления sizeof("супер структура") на 4. Единственное, что не могу вспомнить, как обходил ситуацию с нулевым размером массива байт.

В местной файлохранилке есть книга из которой выдран пример вашего фаулт обработчика. Там всего несколько страниц очень понятного объяснения. Настоятельно рекомендую прочесть. Здесь на форуме давали ссылку на пример использования фаулт обработчика для поиска места сбоя. В качестве подопытного примера использовалось деление на ноль. В вашем случае нужно смотреть окрестности 0x0000A74A.

У меня плата на 4337. Возможно у вас те же симптомы. Сразу предупреждаю - полегче с экспериментами! Палец на пролифик - обязательно! Яркость светодиода меняется от резкого увеличения потребляемого тока. Пришлось менять микросхему. Все пролифики из китая паленые. Внимательно смотрите на маркировку. Плюс кривая разводка платы.

Это всего 3072000 байт/сек получается. Не маловато ли для HS?

Я на сахаре поднимал тему и давал ссылки на хабр статью о хаке таких карт. Сейчас сходу не вспомню прямых ссылок. Но я думаю легко найти поиском.

Вы

Я использую такой обработчик Hard_Fault_Handler для вывода в уарт. void Hard_Fault_Handler(uint32_t stacked_reg[]) { DBGS_STR("In HardFault_Handler:"); DBGS_MSG("SCB->HFSR = 0x%08X", SCB->HFSR); if ((SCB->HFSR & (1 << 30)) != 0) { DBGS_STR(" Forced Hard Fault"); DBGS_MSG(" SCB->CFSR= 0x%08X", SCB->CFSR ); if((SCB->CFSR & 0xFFFF0000) != 0) { uint32_t CFSRValue = SCB->CFSR >> 16; // right shift to lsb DBGS_STR(" Usage fault:"); if((CFSRValue & (1 << 9)) != 0) { DBGS_STR(" Divide by zero"); } if((CFSRValue & (1 << 8)) != 0) { DBGS_STR(" Unaligned"); } if((CFSRValue & (1 << 3)) != 0) { DBGS_STR(" NOCP"); } if((CFSRValue & (1 << 2)) != 0) { DBGS_STR(" INVPC"); } if((CFSRValue & (1 << 1)) != 0) { DBGS_STR(" INVSTATE"); } if((CFSRValue & (1 << 0)) != 0) { DBGS_STR(" UNDEFINSTR"); } } } DBGS_MSG("R0 = 0x%08X", stacked_reg[0]); DBGS_MSG("R1 = 0x%08X", stacked_reg[1]); DBGS_MSG("R2 = 0x%08X", stacked_reg[2]); DBGS_MSG("R3 = 0x%08X", stacked_reg[3]); DBGS_MSG("R12= 0x%08X", stacked_reg[4]); DBGS_MSG("LR = 0x%08X", stacked_reg[5]); DBGS_MSG("PC = 0x%08X", stacked_reg[6]); DBGS_MSG("PSR= 0x%08X", stacked_reg[7]); for(;;) { UART0_Put(); } } __asm void HardFault_Handler(void) { TST lr, #4 // Test for MSP or PSP ITE EQ MRSEQ r0, MSP MRSNE r0, PSP B __cpp(Hard_Fault_Handler) }

Ну что вы так близко принимаете к сердцу! Здесь приоткрылся портал в вегалаб. Нужно просто запастись попкорном и наблюдать как парочка вегалоботомов развлекает народ

Спасибо, понятно. У меня тоже опен4337-с в полной комплектации. А что такого предполагается в LPCOpen 2, по сравнению с текущей версией? А как это выглядит с технической точки зрения? Стабильнее, меньше грузят систему, проще в настройке или еще что то?

Вот ей богу, странный вы человек. Вам SNGNL с самого начала говорил Должны быть опоры (втулки скольжения), обеспечивающие свободный ход трубы в осевом направлении и исключающие её смещение в радиальном направлении. Естественно без касания трубой зубцов статора. Иначе, получится просто заклинивший асинхронник И как это понять зазор 1 мм и труба прилипала? Был зазор или труба прилипала? Был зазор и труба изгибалась и прилипала?

А Вы могли бы более подробно описать свой проект? Т.е. какой юсб стек используете, планируете аудио входы, интересна ли мнимизация задержки, сколько каналов и т.д.? У меня в данный момент есть лпс1768, стм32ф407 и лпс4337. На сегодняшний день у меня работает лпс1768 как юсб лупбек. Режим синхронизации - асинхронный, пробовал и експлисит и имплисит. В принципе я сейчас принимаю решение, переходить на 4337 или все же закончить с 1768. Сейчас я работаю с Кейловским юсб стеком. Пробовал изохронную передачу на LPCUSB. В будущем планирую перебраться на NXP USB стек. Особо интересует минимизация задержки по входу и выходу. Возможно вы помните, я как то обращался к вам по почте, интересовался вашим дайвером для UAC2. В финале было бы интересно сравнить коммерческие драйвера для вин, ваш драйвер и встроенные в мак и линукс. ПС может вы знаете/подскажете более активные форумы по теме разаработки юсб аудио.

Да вроде там все просто, как угол дома. ЮСБ стек стандартный кейловский. void USB_SOF_Event(void) { //STORE_DMA_SAMPLES(); STORE_DD_OUT_STATUS(); STORE_DD(); if ((USB_DeviceAddress != 0)&&(USB_Configuration != 0)) { uint32_t numOutEP, numFBackEP, numInEP; numOutEP = ProcessOutEP(); numFBackEP = ProcessFeedbackEP(); numInEP = ProcessInEP(numOutEP); STORE_NUM_SAMPLES(numOutEP); if ((iso_in_size == 44*4)||(iso_in_size == 48*4)) { numFBackEP *=4; } else if ((iso_in_size == 44*6)||(iso_in_size == 48*6)) { numFBackEP *=6; } else { //should never happen } STORE_NUM_FB_SAMPLES(numFBackEP / (1<<14)); STORE_NUM_IN_SAMPLES(numInEP); } SOF_EV(); } uint32_t ProcessFeedbackEP() { int32_t fb = getFeedbackValue(); if (fb == 0) { DBG_INFO_MSG("ProcessFeedbackEP ERROR!!!! FeedbackRate = 0x%X =========================",FeedbackRate); } #if (USB_ADC_SYNC_MODE == USB_ADC_SYNC_MODE_EXPLISIT_FB) IsoFBBuff = fb; #if (USB_DMA_FB == 0) // sw copy for FEEDBACK EP USB_WriteEP(ADC_F_BACK_EP_LOG, (uint8_t*)&IsoFBBuff, 3); #else // (USB_DMA_FB == 0) DMA copy for FEEDBACK EP //DD_ISO_FB_Mem[0] = 0; //DD_ISO_FB_Mem[1] = (1<<16) | (1<<4); //isoc packet, length = 1 packet DD_ISO_FB_Mem[0] = (uint32_t)DD_ISO_FB_Mem; DD_ISO_FB_Mem[1] = (1<<16) | (1<<4) | (1<<2); //isoc packet, length = 1 packet DD_ISO_FB_Mem[2] = (uint32_t)&IsoFBBuff; DD_ISO_FB_Mem[3] = 0; DD_ISO_FB_Mem[4] = (uint32_t)&InfoFBBuf; InfoFBBuf = 3|0x10000; #endif //(USB_DMA_FB == 0) SW/DMA copy for FEEDBACK EP #endif //(USB_ADC_SYNC_MODE == USB_ADC_SYNC_MODE_EXPLISIT_FB) return fb; } USB_SOF_Event() обработчик софа. Макросы в USB_SOF_Event() отладочные. Три байта передаются в юсб модуль в ProcessFeedbackEP(). Ничего необычного, за исключением того, что юсб модуль ЛПЦ не в состоянии продетектить изохронный запрос с хоста. Объяснить это трудно. Это больше выглядит как инициализация FB_rate. В обработчике FB_rate должна накапливать значения (что то типа FB_rate +/- дельта). Давно не смотрел сдр-виджет, он уже может работать на стм32?

У меня ЛПЦ. Отправляет/принимает юсб модуль. Я только подготавливаю необходимые данные. Т.е. вы говорите драйверу хоста, что у вас изохронный асинхронный експлисит девайс. Хост будет слать аудио данные на каждый соф и запрашивать фидбек данные через заданное вами кол-во соф-ов. Если вы правильно настроили фидбековскую конечную точку и там есть данные, то юсб модуль отправит данные хосту. Как это сделано в стм32 я не в курсе. Стараюсь как можно подальше отложить необходимость работы с ними :)

Вот часть моего дескриптора. Я вижу разницу в поле bRefresh. /* Endpoint, EP3 ISO OUT - Standard Descriptor */\ AUDIO_STANDARD_ENDPOINT_DESC_SIZE, /* bLength */\ USB_ENDPOINT_DESCRIPTOR_TYPE, /* bDescriptorType */\ ADC_DATA_O_EP_LOG, /* bEndpointAddress */\ EP_ISO_OUT_ATTRIB, /* bmAttributes */\ WBVAL(SAMPL_PER_FRAME_48 * SubFrameSize * 2), /* wMaxPacketSize */\ 0x01, /* bInterval */\ 0x00, /* bRefresh */\ ADC_DATA_OUT_EP_SYNC_ADDR, /* bSynchAddress */\ Тестил под вин7 только.

Маладец! Герой! Аплодирую стоя, один прет против всех! Прям как макаревич в своих нетленках. Теперь нужно срочно наставить на путь истинный девелоперов линукс ядра, lwip, contiki и т.д. Залезть в их репозитории и поубивать ненавистные дувайлы :)

s3c4530 догадливый вы наш

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

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

Попробую побыть телепатом :) Похоже, что вы прошли стадию с PCM27-29 и теперь хотите добавить один байт, несколько частот и асинхронный режим. Все три задачи можно решать независимо одна от другой. И для этого не нужен кристалл с хайспид. Можете смело брать плату с LPC176х в любом ларьке и начинать работать. Во всяком случае я делаю именно так. У меня в работе LPC1766, а вейвшаровский LPC43 ждет своей очереди. Что касается LPC17xx то эти кристаллы имеют 2 фичи: модуль USB не сигналит о закончившейся изохронной передаче. модуль I2S работает с 4 байтами.

В качестве офтопа. Вариант купить готовое, повторить готовое не рассматриваете? Сделать такое с нуля непростая задача. Если же охота пуще неволи, то быстрее всего стартануть с LPC18-LPC43. Там есть встроенный хай спид фи. Платы от кетайцев приезжают за неделю - две. Широко известный в узких кругах юсб стек от кейла позволит сделать процентов 70 работы одним махом. Имеется также LPCUSB и стек от NXP. Ну а недостаток - большие корпуса. Возможно в будущем появится что то малоногое, но филипки такие кристаллы меньше чем на 80 ног не делают. В идеале было бы неплохо дождаться кортексов с хайспид юсб от нувотона. Там и цена и малые корпуса и I2S трехбайтный присутствует.

Там должна быть каскодная схема. Лично я поставил бы первый полевик усилителем, второй полевик каскодом для уменьшения входной емкости. Это на стороне датчика. На другом конце кабеля обычный биполярный тр-р тоже каскодом. Выбрав оптимальные значения истокового резистора первого полевика и его тока (ну тип полевика), можно получить оптимальные значения линейности, широкополосности и отношения с/ш для данного датчика.

http://dmilvdv.narod.ru/AT91SAM9260/index.html

Ну да, п.5 д.б. самым первым. :) В области аудио я сам зачастую не вижу логики. Один из примеров данная тема. Я не вижу рационального объяснения почему идеальные цифровые кроссоверы не применяются в аудио. А самым правоверным признан линквитц. Единственное логичное объяснение (с моей точки зрения), что аудиофилы предпочитают фазово-исковерканный звук но с апериодической ИХ звуку с идеальной (прямоугольной) АЧХ и идеальной(длинной) ИХ, которая не может быть правильно просуммирована реальными звуковыми излучателями.

Топикстартер не указал предметную область, но как телепат попробую угадать, что речь идет об аудио. В этом случае я не представляю как: 1. в реальном помещении 2. на реальных "динамиках" 3. установленных в конкретный корпус на некотором расстоянии друг от друга 4. корпус в свою очередь ориентирован относительно слушателя "как попало" 5 ... произойдет суммирование ИХ в задержанный дельта импульс.

А с ИХ как быть?