Средства и методы разработки

Попробую пояснить так. Итог нескольких лет моих размышлений. http://caxapa.ru/779072.html
Пусть у нас будет мега-хост, модулек, из которого выходит несколько линий следующего типа. 2 диф пары, RS-422, кодирование с переменной длительностью бита ->. 1 = 1/10мгц, 0 = 1/20 мгц. ICE40LP384-SG32 FPGA 21 I/O 32QFN 100 1.37870 - это наш "контроллер интерфейса". ISL3176EIUZ-T RS422/485 20MBPS 10MSOP $0.79650 - 2,500 - это наш "физический уровень". Оно полнодуплексное. SIT2001BI-S3-33E-50.000000E OSC MEMS 50.0000MHZ LVCMOS SMD 50MHz MEMS (Silicon) LVCMOS Oscillator 3.3V Enable/Disable 4-SMD, No Lead 1,000 $0.47736 -40°C ~ 85°C ±50ppm - это наша опора. Тут скорее получится 25 МГц и 12.5 МГц - но это сейчас пофиг, просто попалось под руку. Итого стоимость нашего "контроллера интерфейса" = 1.37870+0.79650+0.47736 = $2,65256 В линии есть Хемминг, который кодируется/декодируется указанной плиской. Пусть будет Hamming (15, 11) как один из совершенных кодов. Поскольку кодер-декодер модуляции тривиальны, то, надеюсь, хемминг влезет. (7, 4) точно влезет :) В начале каждой посылки стоит адрес 8 бит, затем само тело. Хемминг идет на низком уровне, т.е. формируется посылка, потом в линию она сразу с хеммингом идет, при приеме собирается в обратную сторону. Периферийный контроллер знает, что у протокола есть максимальня длина посылки - 128 байт, например. Он программирует SPI slave, DMA и ждет прихода. Еще есть квитирование линиями с контроллером - почти как в UART - запрос приема - готов к приему и т.д. Для "стека протокола" нужно 512 байт -- текущий обмен - 128b TX, 128b RX -- будущий обмен - 128b TX, 128b RX Остальных 512 байт STM8L хватит при экономном кодинге. Когда контроллер интерфейса декодировал широковещательный адрес или индивидуальный адрес, он выплюнул по SPI очищенные данные посылки, как раз 8 мбит получилось. STM8L051F3P6 8Мбит макс мастер и слейв. И одновременно контроллер интерфейса принял пакет, захемминговал его и кинул в линию по второй паре. Это был ответ периферийного контроллера на предыдущий запрос хоста. Пусть у нас 8 мбит/сек "чистой" скорости в линии. 128 байт = 1 килобит = 8к пакетов в секунду. Важно - ответ слейва может не иметь адреса, т.е. понятно, кто отвечает сейчас в дуплексной системе. Считаем, что обратный пакет передастся за время прямого пакета. Зазоры не нужны, пусть у нас будет 8к пакетов в секунду. Указанные драйверы RS-422 имеют 1/8 нагрузки на прием, т.е. их может быть 256 на одной линии. Итого получаем 256 устройств, каждое их которых сможет принять и передать 32 пакета 128 байт в секунду. 4к байта в секунду. Дальше объединяем тайм-слоты как нам надо. Ради упрощения кодирования и декодирования можно считать, что передача бита всегда идет на 12.5 Мбит/сек, и на остаток времени просто забить. На короткие расстояния (до 10м) спектральная эффективность использования кабеля нас не особо парит. Простота превыше всего. Периферийный контроллер делает все, что нам надо. Как видим, 8 мбит SPI и DMA являются ключевыми для успеха. Контроллер может быть 3.3В или 5В с транслятором уровня на 4 линии (1 gate логика рулит). Вводим специальные форматы кадра - типа 32 нуля подряд (как идея) - по ней FPGA сбрасывает контроллер. Также видно, что одна FPGA сможет быть контроллером обмена для кучки MCU, на худой конец можно снаружи дискретный мультиплексор прикрутить. И дешифратор для nCS Т.е. накладные расходы на организацию такого контроллера обмена - менее $2,7 На фоне таких затрат простейший STM8L, который можно даже на асме закодить, но с ценой $0.5, у которого есть DMA 8 mbit SPI, являются ключевым элементом. Система обмена является строго синхронной, и синхронизацию времени до 1 мкс сделать умеренно сложно. В начале каждой посылки от мастера идет тайм-код, и слейв подстраивает свой таймер. Предложенный интерфейс весьма параноидален в части борьбы с ошибками, и в пределах 19 дюймовой стойки его можно считать идеальным. В силу дешевизны можно даже задублировать - это если надо ядерным реактором управлять :) Теперь главное. Главное - на хосте создать удобный стек протокола, чтобы он мог удобно для программирования обрабатывать все типы сообщений от периферийных MCU. Именно поэтому я представил себе, что периферийный MCU - это microPLC. Вот. Таки сложилась у меня в голове идеология распределенной (в пределах шкафа) системы. Все, что выходит за пределы шкафа - строго гальванически изолированное! Но в пределах нормально собранного шкафа - не обязательно.