adnega

Пример, конечно, надуманный, но все же: что будет, если на ножку кнопки подать сигнал частотой под мегагерц? в случае работы по прерыванию и в случае работы по опросу? ;) По-моему в случае периодического опроса - ничего страшного, а в случае прерываний - ничего хорошего.

RCC_APB2ENR бит AFIOEN установлен? RCC->APB2ENR = (1 << RCC_APB2ENR_IOPAEN) | (1 << RCC_APB2ENR_IOPBEN) | (1 << RCC_APB2ENR_IOPCEN) | (1 << RCC_APB2ENR_IOPDEN) | (1 << RCC_APB2ENR_AFIOEN); AFIO->MAPR = (SW_DP << AFIO_MAPR_SWJ_CFG);

//----------------------------------------------------------------------------- // DWORD int_to_time(DWORD x, DWORD *hh, DWORD *mm, DWORD *ss) //----------------------------------------------------------------------------- DWORD int_to_time(DWORD x, DWORD *hh, DWORD *mm, DWORD *ss) { *ss = x % 60; x /= 60; *mm = x % 60; x /= 60; *hh = x % 24; x /= 24; return x; } //----------------------------------------------------------------------------- // DWORD date_to_int(DWORD y, DWORD m, DWORD d) //----------------------------------------------------------------------------- DWORD date_to_int(DWORD y, DWORD m, DWORD d) { if(m < 3) { m += 12; y -= 1; } return ((y * 1461) >> 2) + ((m * 306 + 7) / 10) + d - 730533; } //----------------------------------------------------------------------------- // void int_to_date(DWORD jd, DWORD *y, DWORD *m, DWORD *d) //----------------------------------------------------------------------------- void int_to_date(DWORD jd, DWORD *y, DWORD *m, DWORD *d) { int aa, bb, cc, dd, ee, mm, xx; aa = jd + 2483589; bb = (aa * 4 + 3) / 146097; cc = aa - ((146097 * bb) >> 2); dd = (4 * cc + 3) / 1461; ee = cc - ((1461 * dd) >> 2); mm = ((5 * ee + 2) * 13707) >> 21; *d = ee - ((16043274 * mm + 209716) >> 19) + 1; *m = mm + 3 - 12 * ((mm * 27) >> 8); *y = 100 * bb + dd - 4800 + ((mm * 27) >> 8); } Корректно работает от 2000 до 2099 годов включительно. Начало эпохи 01.01.2000 00:00:00. Примеры // установка rtc_set_datetime(((date_to_int(dt->YYYY, dt->MM, dt->DD) * 24 + dt->hh) * 60 + dt->mm) * 60 + dt->ss); // считывание if(rtc_get_datetime(&datetime)) { datetime = int_to_time(datetime, &hh, &mm, &ss); int_to_date(datetime, &y, &m, &d); }

Если АЦП реально более 8 бит, то можно применить компандирование для расширения динамического диапазона.

Задам вопрос иначе: может, у меня просто нет библиотеки, в которой математические функции реализуют hard по-максимому?

1. В моем городе я знаю по крайне мере два магазина, где пленочный фоторезист в наличии. 2. В рулоне достаточно материала, чтобы пользоваться им полгода-год. В крайнем случае можно месяц и подождать. 3. Про бумагу для факсов лично для меня открытие, всегда выискивали "правильный" журнал для этих целей))

Дык, реализация библиотечного корня судя по листингу два экрана строк. Может это проблема библиотеки? Но зачем компилятор использует функцию, а не инструкцию. По поводу размера: он уменьшился лишь в комплексе, конкретный кусок при этом стал больше.

Не-не-не. Это какая-такая религия запрещает компилятору использовать инструкцию, которая входит в реализацию fpv4-sp-d16. Можно подумать, что в отличии от "обычных" арифметических действий, которые всегда дадут результат (даже при делении на ноль), извлечение квадратного корня несколько расширяет диапазон результата (особенно для отрицательных аргументов), поэтому должно быть функцией. Или ход мыслей неверный?

Так не пойдет. Это все равно, что на асме писать; vsqrt ведь не библиотечная функция. Не понятно почему при оптимизации Os вызывается библиотечная функция, а при O2 подставляется инструкция FPU.

Из-за этого: " This section includes experimental options that may produce broken code."?

Отличнейшая опция! Странно, при -Os итерация порядка 1700 тактов и листинг: dist = 2.0f * asinf(sqrtf(sdlat * sdlat + cosf(clat) * cosf(lat) * sdlon * sdlon)) * 6367444.6571225f; 80015c4: ed9d 0a07 vldr s0, [sp, #28] 80015c8: f000 f856 bl 8001678 <cosf> 80015cc: eef0 aa40 vmov.f32 s21, s0 80015d0: ed9d 0a06 vldr s0, [sp, #24] 80015d4: f000 f850 bl 8001678 <cosf> 80015d8: ee2a 0a80 vmul.f32 s0, s21, s0 80015dc: ee20 0a09 vmul.f32 s0, s0, s18 80015e0: ee20 0a09 vmul.f32 s0, s0, s18 80015e4: eea8 0aa8 vfma.f32 s0, s17, s17 80015e8: f000 f920 bl 800182c <sqrtf> 80015ec: f000 f8c6 bl 800177c <asinf> А при -O2 итерация 1048 тактов и задействуется vsqrt dist = 2.0f * asinf(sqrtf(sdlat * sdlat + cosf(clat) * cosf(lat) * sdlon * sdlon)) * 6367444.6571225f; 8001bae: ed9d 0a07 vldr s0, [sp, #28] 8001bb2: f000 f85f bl 8001c74 <cosf> 8001bb6: eeb0 aa40 vmov.f32 s20, s0 8001bba: ed9d 0a06 vldr s0, [sp, #24] 8001bbe: f000 f859 bl 8001c74 <cosf> 8001bc2: ee2a 0a00 vmul.f32 s0, s20, s0 8001bc6: ee60 7a28 vmul.f32 s15, s0, s17 8001bca: ee67 7aa8 vmul.f32 s15, s15, s17 8001bce: eee8 7a08 vfma.f32 s15, s16, s16 8001bd2: eeb1 0ae7 vsqrt.f32 s0, s15 8001bd6: eeb4 0a40 vcmp.f32 s0, s0 8001bda: eef1 fa10 vmrs APSR_nzcv, fpscr 8001bde: d13f bne.n 8001c60 <main+0x1cc> 8001be0: f000 f8ca bl 8001d78 <asinf> При этом размер кода отличается всего на 32 байта, а производительность более чем на 38%

Конечно. Вроде все заработало. Указал все типы float, все константы с суффксом f (кроме M_PI). Код теперь генерится красивый (с vmul, vadd). Скорость возросла в долгожданные 11 раз. Но может чуть-чуть волнует вызов "80015b8: f000 f916 bl 80017e8 <sqrtf>" при живом "VSQRT{cond}.F32 Sd, Sm"

Нихт арбайтн: clat += 0.000001f; 8001150: a313 add r3, pc, #76; (adr r3, 80011a0 <main+0xc8>) 8001152: e9d3 2300 ldrd r2, r3, [r3] 8001156: 4620 mov r0, r4 8001158: 4629 mov r1, r5 800115a: f7ff fdbb bl 8000cd4 <__adddf3>

Поменял эффекта ноль. Стало еще хуже)) float lat, clat, lon, clon; clat += 0.000001; 8001154: ee18 0a10 vmov r0, s16 8001158: f7ff ff1a bl 8000f90 <__aeabi_f2d> 800115c: a314 add r3, pc, #80; (adr r3, 80011b0 <main+0xd8>) 800115e: e9d3 2300 ldrd r2, r3, [r3] 8001162: f7ff fdb7 bl 8000cd4 <__adddf3> 8001166: f7ff ff67 bl 8001038 <__aeabi_d2f> Тут согласен.

Помогите расставить плавающие точки на i)) Собираю тестовый проект с плавающей точкой, и вроде все работает, но жутко медленно. Фактически не используются инструкции FPU, кроме vmov, vldr, vstr. Сложение двух переменных типа double выливается в код с вызовом __adddf3 (эмуляция плавучки?) 8001a0a: ed9f 1b21 vldr d1, [pc, #132]; 8001a90 <main+0x210> 8001a0e: ed9d 0b06 vldr d0, [sp, #24] 8001a12: f7ff fac1 bl 8000f98 <__adddf3> 8001a16: ed8d 0b06 vstr d0, [sp, #24] Писать ручками vadd.f64 d0, d1 не дает, ибо "Error: selected FPU does not support instruction". При использовании "простенькой" арифметики из math.h код разрастается на 10КБ. Тестю на этом: gcc version 4.8.0 20121121 (experimental) (Klen's GNU package (KGP) for ARM/elf platform) В последней сборке под linux_64 результат тот же. Кто виноват и что делать?

Тут и я переврал: bit-band есть в Cortex-M4, просто распространяется не на всю память, а на два отдельных региона (ОЗУ и периферия). В STM32F3 модули GPIO (и вроде только они) как раз ни в один этот регион не входят. По сути 6КБ адресного пространства зачем-то "выкинули" - глубинный смысл пытаюсь осознать (может какой-нить механизм маскирования для GPIO появился, как например в LPC11xx).

Наношу пленку на мокрую плату, чтоб не было пузырей. Экспонирование "черным светом" с 30 см через пластик от CD-диска около 8 минут. Смываю в холодной воде с одной чайной ложкой кальцинированной соды на глубокую тарелку. После проявки очень хорошо промываю плату пока она не перестанет быть скользкой. Все - после этого травлю в хлорном железе с подогревом и перемешиванием. По поводу ЛУТ не спорю - более того привести аргументы против сложно. Однако один "фанат ЛУТа" на днях признался, что будет переходить на пленочный фоторезист. Ему нужно макетить двухсторонние платы с металлизацией переходных отверстий, а там в технологии отверстия нужно перед травлением закрывать, что у ЛУТа по умолчанию не выполнено (ибо тонер не ляжет на дырку).

Работает? vsgui.zip

У многих так было... Сам больше года как для макетов перешел на фоторезист - руку набил. Мелкие платы получаются всегда и быстро (правда, пользуюсь ламинатором, который кстати хорошо заменяет и "утюг").

vsprog.exe -cstm32f1_md -ms -W0 -I test_f3.bin@0,0x08000000 -oe -owf ... Info: Chip-id read is 0x432. Warning:Chip-id unmatch, read=0x432, want=0x410 Info: erasing flash erasing flash ========================================%100| 0.03s used Info: flash erased Info: SWDID = 0x2BA01477 Info: AHB-AP_ID = 0x24770011 Info: ROM_ADDRESS = 0xE00FF003 Info: CFG = 0x00000000, Little-endian Info: CORTEX-M4 r0p1 processor detected Info: CPUID = 0x410FC241 Info: FLASH_OBR = 0xFFFFFF00 Info: FLASH_WRPR = 0xFFFFFFFF Info: programming flash writing flash ========%20 ========%40 ========%60 ========%80 ========%100| 0.13s used Info: flash programmed for 5120bytes(39.06KB/s) Info: erasing fuse erasing fuse ========================================%100| 0.03s used Info: fuse erased Info: programming fuse writing fuse ========================================%100| 0.00s used Info: fuse programmed for 8bytes(3.91KB/s) И даже работает)) Правда у "троек" сильно периферия отличается (RCC, USART) и вроде пропал bit-band, что особенно огорчает((

Советую обратить внимание на Versaloon. Тема была тут.

Кстати никто не запрещает НЕ смотреть "на даташиты к микрухам CAN", а придумать свою "физику". В этом плане CAN довольно демократичен, важно соблюсти два простых правила: 1. При наличии в шине хотя бы одного доминантного состояния при любом количестве рецессивных считаться должно доминантное. 2. В любой точке шины состояние должно быть одно и то же в один момент времени.

Обсуждаемый датчик на самом деле имеет плохую точность. Если нужно точнее, то у ST есть MEMS датчик давления. В разы дешевле и на порядки точнее)) ... Да, и не стоит путать точность и разрешающую способность. При давлении 750 мм.рт.ст получать 738.936 мм.рт.ст (с точностью до третьего знака после запятой) согласитесь не имеет смысла.

Отбой! Проблему решил, DMA тут ни при чем. Неудачно портировал с F1 в результате прерывания работали не с теми приоритетами.

А еще бывает, что тайминги "плывут" взависимости от температуры.