Михась

Кстати задача уже и с программной частью не так проста. Написать все на асме, скомпилить и прошить в УФПЗУ будет почти невыполнимой задачей с текущим пониманием схемотехники. Не стоит такие задания давать. Сейчас собрать схему на 80 или 85 - уже серьезный уровень. Реально доступный для студентов - Ардуинка. Там будут хоть простые знания, но зато реальные. А тут один ботан будет за всю группу отдуваться.

Какие позиции?

Осталось: 1 крейт на 12 позиций, без БП - 1шт UNIO48-5 - 2шт UNIO96-1 (DIC111) - 4шт

О чем поют в станицах по поводу перспектив в поставке STM32 в общем и STM32F0 в частности?

С тупым остановом ядра не должно быть проблем. А вот периодический останов клока периферии может привести к эффектам (я сталкивался с АЦП у STM32G0, когда после останова клока биты остались на месте, но АЦП не работало после enable). И там уже нужно будет произвести переинициализацию со сбросом настроек, а потом настройку с контролем установления битов, что вызовет накладные расходы по времени. Так что не исключено что такую периферию на малое время усыплять нет смысла.

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

Так сообщите данные по трафику в цифрах - размер пакета, количество пакетов в секунду и допустимое время задержки на ответ (если система запросответная). В общем виде свич вообще ничего не знает, как PHY подключена к МАК.

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

50 на 50. Может оградит, может нет. Никаких чисел или опытов же не привели. Просто предупреждаем, что эффект имеет место быть. Занижение в 5 раз может и быть разумно, если вы исходите например от датчиков на 3000 калибровочных точек, а вас устроит 600. В 10 раз уж точно черезчур. Ну и подумайте на берегу - как будете сдаваться, как определять что у вас например весоизмерительный блок не уплыл. Есть еще фактор абсолютной грузоподъемности системы - одно дело емкость с жидкостью на 100 тонн - понятно что там случайного деформирующего воздействия не будет. А может у вас лабораторные весы на 100 грамм и на них кот прыгнет, а вы потом будите удивляться - что случилось?

Потом датчик гнется. Алюминиевый - у них с дрейфом сильно плохо. У стальных - получше, но дрейф все равно есть. По опыту - не надо грузоподъемность датчика использовать впритык для длительных статических нагрузок. Ни один мне известный производитель тензодатчиков ничего вам в этом плане не гарантирует, как и не гарантирует температурный дрейф. Все придется исследовать самому и искать приемлемые решения.

Знаю случай, когда одна очень известная фирма, будем ее называть ШЭ, купила у малоизвестной итальянской фирмы разработку. Итальянцы передали, ШЭ начали выпускать и потом вылез баг. Но оказалось что ШЭ сорцы пролюбил, а итальянцы уже все удалили. Девайс по тихому перестали поставлять. Бигбиз тоже плачет.

А мне надо 24х вольтовый МК - в нашей промке все на 24В. Потом уже и трехфазный МК на 380В захочу. Стильно, модно, молодежно. А серьезно, какие причины дальше не снижать питание? У кого есть опыт рационального опускания напряжения до 2.5 вольт в обычных схемах? С батарейным нестабилизированным и так понятно.

Можно Интел вспомнить 251. У меня знакомые хорошо так в свое время налетели. Да мало ли их было.

Питон уже?

Так, мысли. Написать на Си, то что надо - задача простая, сконпелять в XC8 для пика12 и avr tiny, сделать отчет. Я сделал простой тест для XC8 и GCC на tiny13 и был несколько в недоумении от оптимизации: //xc8 C volatile uint8_t a, b, c; int main(void) { a = 1; b = 2; while(1) { c=a+b; c = c*3; c++; c=c/21; } } // результат Disassembly of section .text: 00000000 <__vectors>: 0: 0c c0 rjmp .+24 ; 0x1a <__ctors_end> 2: 5e c0 rjmp .+188 ; 0xc0 <__bad_interrupt> 4: 5d c0 rjmp .+186 ; 0xc0 <__bad_interrupt> 6: 5c c0 rjmp .+184 ; 0xc0 <__bad_interrupt> 8: 5b c0 rjmp .+182 ; 0xc0 <__bad_interrupt> a: 5a c0 rjmp .+180 ; 0xc0 <__bad_interrupt> c: 59 c0 rjmp .+178 ; 0xc0 <__bad_interrupt> e: 58 c0 rjmp .+176 ; 0xc0 <__bad_interrupt> 10: 57 c0 rjmp .+174 ; 0xc0 <__bad_interrupt> 12: 56 c0 rjmp .+172 ; 0xc0 <__bad_interrupt> 00000014 <.dinit>: 14: 00 60 ori r16, 0x00 ; 0 16: 00 63 ori r16, 0x30 ; 48 18: 80 00 .word 0x0080 ; ???? 0000001a <__ctors_end>: 1a: 11 24 eor r1, r1 1c: 1f be out 0x3f, r1 ; 63 1e: cf e9 ldi r28, 0x9F ; 159 20: cd bf out 0x3d, r28 ; 61 00000022 <__do_copy_data>: 22: e4 e1 ldi r30, 0x14 ; 20 24: f0 e0 ldi r31, 0x00 ; 0 26: 40 e0 ldi r20, 0x00 ; 0 28: 17 c0 rjmp .+46 ; 0x58 <__do_clear_bss+0x8> 2a: b5 91 lpm r27, Z+ 2c: a5 91 lpm r26, Z+ 2e: 35 91 lpm r19, Z+ 30: 25 91 lpm r18, Z+ 32: 05 91 lpm r16, Z+ 34: 07 fd sbrc r16, 7 36: 0c c0 rjmp .+24 ; 0x50 <__do_clear_bss> 38: 95 91 lpm r25, Z+ 3a: 85 91 lpm r24, Z+ 3c: ef 01 movw r28, r30 3e: f9 2f mov r31, r25 40: e8 2f mov r30, r24 42: 05 90 lpm r0, Z+ 44: 0d 92 st X+, r0 46: a2 17 cp r26, r18 48: b3 07 cpc r27, r19 4a: d9 f7 brne .-10 ; 0x42 <__DATA_REGION_LENGTH__+0x2> 4c: fe 01 movw r30, r28 4e: 04 c0 rjmp .+8 ; 0x58 <__do_clear_bss+0x8> 00000050 <__do_clear_bss>: 50: 1d 92 st X+, r1 52: a2 17 cp r26, r18 54: b3 07 cpc r27, r19 56: e1 f7 brne .-8 ; 0x50 <__do_clear_bss> 58: e9 31 cpi r30, 0x19 ; 25 5a: f4 07 cpc r31, r20 5c: 31 f7 brne .-52 ; 0x2a <__do_copy_data+0x8> 5e: 03 d0 rcall .+6 ; 0x66 <_etext> 60: 00 c0 rjmp .+0 ; 0x62 <_exit> 00000062 <_exit>: 62: f8 94 cli 00000064 <__stop_program>: 64: ff cf rjmp .-2 ; 0x64 <__stop_program> Disassembly of section .text: 000000c0 <__bad_interrupt>: c0: 9f cf rjmp .-194 ; 0x0 <__TEXT_REGION_ORIGIN__> Disassembly of section .text.startup: 00000066 <main>: volatile uint8_t a, b, c; int main(void) { a = 1; 66: 81 e0 ldi r24, 0x01 ; 1 68: 80 93 62 00 sts 0x0062, r24 ; 0x800062 <a> b = 2; 6c: 82 e0 ldi r24, 0x02 ; 2 6e: 80 93 60 00 sts 0x0060, r24 ; 0x800060 <__DATA_REGION_ORIGIN__> { c=a+b; c = c*3; c++; c=c/21; 72: 25 e1 ldi r18, 0x15 ; 21 while(1) { c=a+b; 74: 90 91 62 00 lds r25, 0x0062 ; 0x800062 <a> 78: 80 91 60 00 lds r24, 0x0060 ; 0x800060 <__DATA_REGION_ORIGIN__> 7c: 89 0f add r24, r25 7e: 80 93 61 00 sts 0x0061, r24 ; 0x800061 <c> c = c*3; 82: 80 91 61 00 lds r24, 0x0061 ; 0x800061 <c> 86: 98 2f mov r25, r24 88: 99 0f add r25, r25 8a: 89 0f add r24, r25 8c: 80 93 61 00 sts 0x0061, r24 ; 0x800061 <c> c++; 90: 80 91 61 00 lds r24, 0x0061 ; 0x800061 <c> 94: 8f 5f subi r24, 0xFF ; 255 96: 80 93 61 00 sts 0x0061, r24 ; 0x800061 <c> c=c/21; 9a: 80 91 61 00 lds r24, 0x0061 ; 0x800061 <c> 9e: 62 2f mov r22, r18 a0: 03 d0 rcall .+6 ; 0xa8 <__udivmodqi4> a2: 80 93 61 00 sts 0x0061, r24 ; 0x800061 <c> a6: e6 cf rjmp .-52 ; 0x74 <main+0xe> Disassembly of section .text.libgcc.div: 000000a8 <__udivmodqi4>: a8: 99 1b sub r25, r25 aa: 79 e0 ldi r23, 0x09 ; 9 ac: 04 c0 rjmp .+8 ; 0xb6 <__udivmodqi4_ep> 000000ae <__udivmodqi4_loop>: ae: 99 1f adc r25, r25 b0: 96 17 cp r25, r22 b2: 08 f0 brcs .+2 ; 0xb6 <__udivmodqi4_ep> b4: 96 1b sub r25, r22 000000b6 <__udivmodqi4_ep>: b6: 88 1f adc r24, r24 b8: 7a 95 dec r23 ba: c9 f7 brne .-14 ; 0xae <__udivmodqi4_loop> bc: 80 95 com r24 be: 08 95 ret Оптимизация максимальная, больше только в ПРО. Чего он постоянно сует переменные в рам а потом их высовывает оттуда?

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

Интересно, почему компилятор сам так не делает?

Совершенно верно. И кстати я тестировал софтовые флоаты - они не очень тяжелые за счет 32х битности платформы. А вот даблы софтовые куда как тяжелее. Грубо говоря на платформе M3 софтовые даблы считаются в три раза дольше чем софтовые флоаты. А аппаратные флоаты в десять раз быстрее чем софтварные флоаты. На такой синтетической формуле = add(result[0], result[1]); = mul(result[0], result[2]); = div(result[1], result[2]);

Полуофф конечно, но для общего развития. ELECTRICAL GROUNDING ARCHITECTURE FOR UNMANNED SPACECRAFT NASA TECHNICAL grounding_nasa_hdbk_4001.pdf

Можете еще до кучи map файл выложить. Там все эти софтовые dmul и ddiv и всплывут. В общем, в любом случае есть смысл добиться чтобы все математика работала с float FPU. Просто надо внимательно весь код просмотреть и полностью убрать использование даблов.

6N136 использовали. На 115200 полет отличный.

Используем для заделки металлорукава в ПВХ оболочке такие муфты МВ20 (есть разные) https://www.zkabel.ru/catalog/fitingi-mufty/mufty-dlya-soedineniya-metallorukav-shchit/rezbovoy-krepezhnyy-element-rkn/rkn-20-u2-ip54-mv-20-m-up-50-250-sht-zeta-k/?keyword=%2Bмуфта %2Bмв %2B20&matchtype=b&utm_content=473021028369&device=c&utm_source=google&utm_medium=cpc&utm_campaign=Fitingi-POISK-vse_regiony_Rossia_Litva_Estonia&gclid=CjwKCAiAt9z-BRBCEiwA_bWv-A9zc5fh4BZ8kJ__FeQ1vFgYNtKGDoydYowx9IBlWwMWZvdkCy5w0hoCuxoQAvD_BwE Герметичность не обеспечивают, мехзащита удовлетворительная, внешний вид на момент сдачи шкафов очень достойный. Проблема металлорукава в ПВХ - нельзя шевелить на морозе - ломается и облазит. Вы бы фото конструкции кабельной сборки выложили.

Нет, но есть http://www.winfilter.20m.com/

---------------------------------------------------------------------- Code (inc. data) RO Data RW Data ZI Data Debug Library Name 1070 66 64 0 0 416 m_ps.l 2696 64 64 4 0 1520 mc_p.l 1236 34 0 0 0 808 mf_p.l ---------------------------------------------------------------------- 5016 164 128 4 0 2744 Library Totals ---------------------------------------------------------------------- Для чего нужны эти файлы?