igor_pskov

Если не сложно подскажите по аудио кодеку v3s. Я не могу понять каким образом задается количество семплов запроса к дма. Я вижу fifo, его размер это и есть максимальный линенный запрос? Но где говорится о его размере? В описании упоминаются некие пакеты. Пакет это что такое? Это и есть запрос на заполнение fifo? Если устанавливать размер семпла в 24 бита, то DMA Destination Data Width устанавливать на 8 бит? Откуда Вы вообще черпаете информацию по железу? ПДФ явно расчитаннан на тех, кто уже в теме. Я к сожалению нет. я пробовал программировать через алсу, но столкнулся с тем, что размер буфера нет возможности установить более чем в 32 раз больше чем размер пакета. Так и не смог понять это ограничения железа, алсы, или драйвера. Хотелось бы поменьше накладных расходов. Я ожидал, что можно будет сделать как на stm. задать размер буфера и запустить связку дма цап в цикле.

Спасибо!

в v13. в pcb добавил 3d модель корпуса, чтоб не мешала скрыл. уже не помню как, или прозрачностью или hide. теперь когда она понадобилась не могу ее выбрать, чтобы сделать видимой. когда делаю экспорт в step, в конечном файле она есть. не представляю, как ее выбрать в альтиуме.

Если делать запуск преобразований от внешнего тригера (таймер 1), то работает согласно даташиту. Ухх... У меня таймер 1 задействован. Черт. Как вывернуться...

Первое. Согласно даташиту цикл измерения состоит из 14 тактов, по моим подсчетам получается 15 тактов. Второе. Если я правильно понимаю возможен режим работы АЦП когда оно складывает результаты измерения в буфер в непрерывном режиме (AN2658 Figure 5 (Multiple channel Continuous and Scan conversion (buffered)). В этом режиме тоже есть загадочное, но беда в том, что не получается его запустить. Биты ADC1_CR1_CONT, ADC1_CR2_SCAN, ADC1_CR3_DBUF устанавливаю. Прерывания возникают после каждого измерения, т.е. похоже режим скан не работает. Без бита ADC1_CR2_SCAN прерывания, как и поположено, возникают после заполения буфера. Иницилизация: CLK->PCKENR2 |= 0x08; ADC1->CR1 = (uint8_t)(ADC1_PRESSEL_FCPU_D12 | ADC1_CR1_CONT); // 126мкс (252 такта) ADC1->CR2 = (uint8_t)(ADC1_CR2_ALIGN | ADC1_CR2_SCAN); ADC1->CR3 = (uint8_t)(ADC1_CR3_DBUF); // DBUF ADC1->CSR = (uint8_t)(ADC1_CSR_EOCIE | 0x05); ADC1->TDRH = 0; ADC1->TDRL = 0x28; ADC1->HTRH = 0x02; // 539 0x21B (3.3A) ADC1->HTRL = 0x1B; ADC1->LTRH = 0; ADC1->LTRL = 0; ADC1->AWCRH = 0; ADC1->AWCRL = 0x08; ADC1->CR1 |= ADC1_CR1_ADON; enableInterrupts(); ADC1->CR1 |= ADC1_CR1_ADON;

static void (*const block_erase)(uint8_t *dst) = (void (*)(uint8_t *dst))block_erase_code; ух.... Спасибо. Работает. Красивое решение.

Для удаления блока в eeprom функцию удаления необходиом расположить в озу. Не получается. Делаю вроде согласно инструкции в stm8s_flash.c. - For Cosmic Compiler: 1- Define a segment FLASH_CODE by the mean of " #pragma section (FLASH_CODE)". This segment is defined in the stm8s_flash.c file. 2- Uncomment the "#define RAM_EXECUTION (1)" line in the stm8s.h file, or define it in Cosmic compiler preprocessor to enable the FLASH_CODE segment definition. 3- In STVD Select Project\Settings\Linker\Category "input" and in the RAM section add the FLASH_CODE segment with "-ic" options. 4- In main.c file call the _fctcpy() function with first segment character as parameter "_fctcpy('F');" to load the declared moveable code segment (FLASH_CODE) in RAM before execution. 5- By default the _fctcpy function is packaged in the Cosmic machine library, so the function prototype "int _fctcopy(char name);" must be added in main.c file. в первую страницу флеш записываю последовательность 0-32. потом пытаюсь стереть эту страницу. main.c _fctcpy('f'); adr=(u8 *)0x4000; FLASH->DUKR = FLASH_RASS_KEY2; FLASH->DUKR = FLASH_RASS_KEY1; for (i=0;i<32;i++){ *(adr++)=i; while ((FLASH->IAPSR & FLASH_IAPSR_EOP)==0); } eeErase((u8*)0x4000); while ((FLASH->IAPSR & FLASH_IAPSR_EOP)==0); FLASH->IAPSR &= (uint8_t)(~FLASH_IAPSR_DUL); функция eeErase #pragma section (flash_code) IN_RAM(void eeErase(u8 *adr)){ FLASH->CR2 |= FLASH_CR2_ERASE; FLASH->NCR2 &= (uint8_t)(~FLASH_NCR2_NERASE); *adr++ = 0; *adr++ = 0; *adr++ = 0; *adr++ = 0; } #pragma section () в файле stm8s003k3.lsf добавляю сегмент flash_code +seg .data -b 0x100 -m 0x100 -n .data +seg .in_ram -a .data -n .in_ram -ic +seg .bss -a .in_ram -n .bss +seg .flash_code -a .bss -n .flash_code #define RAM_EXECUTION (1) в файле stm8s.h раскоментил. в итоге в выходном hex файле функция располагается по адресам ОЗУ, на что STVP_CmdLine.exe ругается: >>> Loading file out/project.hex in PROGRAM MEMORY image in computer (API) WARNING : FILE : line 42: Address 0x12C is out of range and is ignored! По сути вроде правильно ругается. Только тогда я не понимаю, как расположить код функции во флеш, чтобы потом функция _fctcpy('f') скопировала его в секцию flash_code и обращение было именно к функции расположенной в ОЗУ?

Спасибо большое за работу. Не знал, что альтиум умеет открывать такие файлы. Попробовал, да, открылся. Спасибо за помощь.

Первый раз делаю проект со слотовыми падами. При проверке в Gerbv или онлайн вьюверах, например - http://www.gerber-viewer.com/default.aspx отверстия выглядят как обычные круглые. Хочу понять это проблемы просмотрщиков или проблемы установок или альтиума. Вот содержимое файла SlotHoles-Plated.тхт: M48 ;Layer_Color=9474304 ;FILE_FORMAT=4:4 METRIC,TZ ;TYPE=PLATED T6F00S00C1.1000 % G90 G05 T06 X2628998Y1396500G85Y1436500 X2700998Y1396500G85Y1436500 X2700998Y1487500G85Y1527500 X2628998Y1487500G85Y1527500 X1590998Y1487500G85Y1527500 X1590998Y1396500G85Y1436500 X1518998Y1396500G85Y1436500 X1518998Y1487500G85Y1527500 X1518998Y1926500G85Y1966500 X1590998Y1926500G85Y1966500 X2628998Y1926500G85Y1966500 X2700998Y1926500G85Y1966500 X2700998Y2017500G85Y2057500 X2628998Y2017500G85Y2057500 X1590998Y2017500G85Y2057500 X1518998Y2017500G85Y2057500 X1518998Y2456500G85Y2496500 X1518998Y2547500G85Y2587500 X1590998Y2547500G85Y2587500 X1590998Y2456500G85Y2496500 X2628998Y2456500G85Y2496500 X2700998Y2456500G85Y2496500 X2700998Y2547500G85Y2587500 X2628998Y2547500G85Y2587500 M30

Читал, не единожды. Видимо голова небольшого объема. Я собственно оветил, чтобы отметить, что с компилятором как всегда все ок.

Да. Вы правы. Проверил, преобразовывает именно так. Тогда вообще ничего не понимаю. Может быть кроме преобразования отрицательного в целое безнаковое еще и переполнение было? Да. если происходит переполнение, то результат не предсказуем.

Глюк мой. Плохое понимание преобразования типов. Ожидал, что преобразование из плавающего в целое беззнаковое будет осуществляться как в знаковое, оказывается знак просто откидывается. Т.е. значение 21521, на самом деле было -21521.0. Поэтому и было переполнение. Всем спасибо за внимание и помощь.

Криво.

Я могу посмотреть только целые, поэтому и вижу 9. Умножаю результат на 1000, вижу для х=12866, logf(x)*1000=9462, это вот прямо сейчас на диcплее. Т.е. если в функцию кладу целое, то считается нормально, если флоат, как требует объявление функции то результат - переполнение. Я понимаю, что какие-то траблы с преобразованием целое-флоат. Но в каком месте и почему не понимаю. варнингов нет. толчайн брал здесь - https://launchpad.net/gcc-arm-embedded gnu math: Function: float logf (float x) сейчас посмотрю исходники тулчайна если найду, но я думаю, что траблы где-то в другом месте. Тулчайн оказывается стоит Sourcery. А по ссылке, которую приводил, стоит дома. Но с обоими тулчайнами результат одинаков. в math.h extern float logf _PARAMS((float));

Спасибо про суффикс попробую запомнить, float использую да, для скорости. Все таки полное непонимание. Значит вчера я усомнился, что в функцию попадают корректные данные. Сегодня стал проверять и оказалось, что не понимаю в чем эти данные некорректные. Я могу вывести на дисплей данные, которые находятся в массиве send_base. Массив uint16_t. Выводить на дисплея я умею только uint16_t. Если код такой: float r=((adc_ext_result[i]*(20000.0f/5.0f))/(65535.0f-adc_ext_result[i]/5.0f)); send_base[adc_index[0]]=r; send_base[adc_ext_index[i]]=logf(r); то, значение r плавает около 12570 (это результат измерения ацп) значение logf® всегда 65535. Меняю код на следущий: float r=((adc_ext_result[i]*(20000.0f/5.0f))/(65535.0f-adc_ext_result[i]/5.0f)); uint16_t x=(uint16_t)r; send_base[adc_index[0]]=x; send_base[adc_ext_index[i]]=logf(x); значение x такое же, а вот значение функции logf(x) становится правильным =9. Не понимаю, что происходит. Так тоже работает: send_base[adc_ext_index]=logf((uint16_t)r); Наверно самое главное забыл сказать. У меня контроллер stm32f051. Т.е. cortex-m0. Может какие-то специальные ключи нужны для компилятора? Я ставлю ключи: -mcpu=cortex-m0 -mthumb