Doka

Еще такой нюанс с этим есть: если интерфейс не имеет сигнала MCLK (Master Clock) и он по какой-то причине нужен (тому же DAC), то такие вот "пустые биты" попытка повысить SCK (в отсутствии MCLK)

судя по упоминанию длл-ек сборка в винде. там не пробовал. в линуксе всё по стоковой инструкции из коробки собирается - что икарус, что верилятор. единственное, об ред-хатовский gcc версии 4.8 может споткнуться, ну так это не беда - есть devtoolset с любой версией gcc up to 11

использование DMA не решает проблемы?

а что верилятор такое нормально переварит? сомнения берут меня.. :-/ теже авторы из Цюриха и Болоньи в других репо наоборот ментор нахваливают, да не простой, а с доп.фичами: https://github.com/pulp-platform/pulpissimo#requirements

ох, давно это было... в принципе в ISO-стандарте такие ситуации расписаны чётко (но я сейчас по памяти): Передающая нода всегда "слушает" что передаёт, как только несовпадение RX & TX: выставление кадра ошибки на шину Представим ситутацию, что пп.1 не реализован (в отдельной имплементации контроллера шины кан), тогда две ноды продолжат передачу и как минимум на CRC произойдёт вероятное несовпадение целостности, этот факт будет обнаружен всеми нодами, принявшими фрейм на шине, после чего все эти ноды обязаны выставить кадр ошибки на шину PS: система, в которой хотя бы раз повторяются идентичные CAN ID у разных нод считается неработоспособной системой (ни индастрил, ни аутомотиф, ни аэроспейс сертификацию она не пройдёт) .

а откуда информация что ESP32 так не умеет? По крайней мере для BT вроде как есть возможность подцепляться к VHCI (software-implemented virtual HCI interface): https://github.com/espressif/esp-idf/tree/master/examples/bluetooth/hci https://docs.espressif.com/projects/esp-idf/en/v4.2.3/esp32/api-reference/bluetooth/controller_vhci.html https://s3-sa-east-1.amazonaws.com/robocore-lojavirtual/1205/ESP32_Bluetooth.Architecture.pdf

так это может не от рекурсии как таковой, а от "раздутой" иерархии. Интересно как рантайм изменится, если сделать ungroup иерархии внутри топ-левел компонента этой рекурсии.

+1 когда на винде сидел именно этим пользовался) еще что-то на Tk пробовал ваять

посмотрите у Эдди, может что-то подберёте, например: https://github.com/eddyem/STM8_samples/tree/master/led

LIN+LDO: серия АТА6, например ATA6625 (но там много есть всяких).

@Losik , привет) Не знаю насколько можно считать за референсы, но на Sky130 вроде как есть какое-то портфолио аналоговых айпи UPD: Сейчас нашёл в хистори https://efabless.com/design_catalog/ip_block/ но что-то этот УРЛ уже недоступен - куда-то перенесли (либо у меня айпишник "неправильный") - там раньше был каталог аналоговых блоков (какие-то фри какие-то за деньги), только уже не могу посмотреть полноту поставки фришных айпи (((

пример скрипта tcl: https://github.com/ciniml/atom_display_fpga/blob/main/eda/project.tcl пример мейка: https://github.com/ciniml/atom_display_fpga/blob/main/eda/build_gowin.mk ЗЫЖ в этом же проекте еще есть самодельные утилиты для конвертации форматов битстримов https://github.com/ciniml/atom_display_fpga/tree/main/script

для похожих задач (FPGA & SDIO) в своё время использовали TXS0108|TXB0108 (не помню какой именно - помню только что с одним из этих "наелись" мы знатно, а со вторым проблем не было).

не помню какой именно партнамбер FX3 стоит на BladeRF, но если уж совсем туго будет - попробуйте рассмотреть такой вариант.

Приветствую! Начал осваивать СС1101 и столкнулся с некоторыми "особенностями". По порядку: надо научиться принимать сигнал скоростью 9600бит/с, модуляция FSK, на которого наложен манчестер (длительность сигнала порядка 10мс). Сигнал был записан на SDR и изучен, после чего сделал сперва имитатор сигнала на СС1101 (передатчик) Для работы с СС1101 использую библиотеку https://github.com/LSatan/SmartRC-CC1101-Driver-Lib 1) Передатчик на СС1101: код ELECHOUSE_cc1101.Init(); // must be set to initialize the cc1101! ELECHOUSE_cc1101.setCCMode(1); // set config for internal transmission mode. ELECHOUSE_cc1101.setModulation(0); // set modulation mode. 0 = 2-FSK, 1 = GFSK, 2 = ASK/OOK, 3 = 4-FSK, 4 = MSK. ELECHOUSE_cc1101.setMHZ(433.92); // Here you can set your basic frequency. The lib calculates the frequency automatically (default = 433.92). ELECHOUSE_cc1101.setDeviation(38.0); // Set the Frequency deviation in kHz. Value from 1.58 to 380.85. Default is 47.60 kHz. ELECHOUSE_cc1101.setManchester(1); // Enables Manchester encoding/decoding. 0 = Disable. 1 = Enable. ELECHOUSE_cc1101.setDRate(19.2); // Set the Data Rate in kBaud. Value from 0.02 to 1621.83. Default is 99.97 kBaud! ELECHOUSE_cc1101.setSyncMode(0); // Combined sync-word qualifier mode. 0 = No preamble/sync. 1 = 16 sync word bits detected. 2 = 16/16 sync word bits detected. 3 = 30/32 sync word bits detected. 4 = No preamble/sync, carrier-sense above threshold. 5 = 15/16 + carrier-sense above threshold. 6 = 16/16 + carrier-sense above threshold. 7 = 30/32 + carrier-sense above threshold. ELECHOUSE_cc1101.setWhiteData(0); // Turn data whitening on / off. 0 = Whitening off. 1 = Whitening on. ELECHOUSE_cc1101.setPktFormat(0); // Format of RX and TX data. 0 = Normal mode, use FIFOs for RX and TX. 1 = Synchronous serial mode, Data in on GDO0 and data out on either of the GDOx pins. 2 = Random TX mode; sends random data using PN9 generator. Used for test. Works as normal mode, setting 0 (00), in RX. 3 = Asynchronous serial mode, Data in on GDO0 and data out on either of the GDOx pins. ELECHOUSE_cc1101.setLengthConfig(1); // 0 = Fixed packet length mode. 1 = Variable packet length mode. 2 = Infinite packet length mode. 3 = Reserved ELECHOUSE_cc1101.setPacketLength(0); // Indicates the packet length when fixed packet length mode is enabled. If variable packet length mode is used, this value indicates the maximum packet length allowed. ELECHOUSE_cc1101.setCrc(0); // 1 = CRC calculation in TX and CRC check in RX enabled. 0 = CRC disabled for TX and RX. ELECHOUSE_cc1101.setFEC(0); // Enable Forward Error Correction (FEC) with interleaving for packet payload (Only supported for fixed packet length mode. 0 = Disable. 1 = Enable. ELECHOUSE_cc1101.setPRE(0); // Sets the minimum number of preamble bytes to be transmitted. Values: 0 : 2, 1 : 3, 2 : 4, 3 : 6, 4 : 8, 5 : 12, 6 : 16, 7 : 24 ELECHOUSE_cc1101.setPQT(0); // Preamble quality estimator threshold. The preamble quality estimator increases an internal counter by one each time a bit is received that is different from the previous bit, and decreases the counter by 8 each time a bit is received that is the same as the last bit. A threshold of 4∙PQT for this counter is used to gate sync word detection. When PQT=0 a sync word is always accepted. ELECHOUSE_cc1101.setAppendStatus(0); // When enabled, two status bytes will be appended to the payload of the packet. The status bytes contain RSSI and LQI values, as well as CRC OK. ELECHOUSE_cc1101.setPA(-10); // set TxPower. The following settings are possible depending on the frequency band. (-30 -20 -15 -10 -6 0 5 7 10 11 12) Default is max! Отключены все автоматические вставки длин, адресов и проч. преамбула 16 бит её кладу в пейлоад пакета (в начало): 0х00, 0х01 Тут всё хорошо за исключением одного нюанса: откуда-то всё равно пролезает байт 0х0С, которые передаются _перед_ моим пейлоадом передаю пакет: byte transmit_byte[PACKET_LEN] = {0x00, 0x01, 0x0f, 0x3c, 0x35, 0xdb, 0x66, 0xbb, 0x42, 0x1b, 0x59, 0xA4}; оригинал: имитация на СС1101: какой настройкой это задаётся? это вообще отключается? ================================================================================ 2) приём на СС1101 ELECHOUSE_cc1101.Init(); // must be set to initialize the cc1101! ELECHOUSE_cc1101.setCCMode(1); // set config for internal transmission mode. ELECHOUSE_cc1101.setModulation(0); // set modulation mode. 0 = 2-FSK, 1 = GFSK, 2 = ASK/OOK, 3 = 4-FSK, 4 = MSK. ELECHOUSE_cc1101.setMHZ(433.92); // Here you can set your basic frequency. The lib calculates the frequency automatically (default = 433.92). ELECHOUSE_cc1101.setDeviation(38.0); // Set the Frequency deviation in kHz. Value from 1.58 to 380.85. Default is 47.60 kHz. ELECHOUSE_cc1101.setManchester(1); // Enables Manchester encoding/decoding. 0 = Disable. 1 = Enable. ELECHOUSE_cc1101.setDRate(19.2); // Set the Data Rate in kBaud. Value from 0.02 to 1621.83. Default is 99.97 kBaud! ELECHOUSE_cc1101.setRxBW(200.0); // Set the Receive Bandwidth in kHz. Value from 58.03 to 812.50. Default is 812.50 kHz. ELECHOUSE_cc1101.setSyncMode(2); // Combined sync-word qualifier mode. 0 = No preamble/sync. 1 = 16 sync word bits detected. 2 = 16/16 sync word bits detected. 3 = 30/32 sync word bits detected. 4 = No preamble/sync, carrier-sense above threshold. 5 = 15/16 + carrier-sense above threshold. 6 = 16/16 + carrier-sense above threshold. 7 = 30/32 + carrier-sense above threshold. ELECHOUSE_cc1101.setSyncWord(0, 1); // Set sync word. Must be the same for the transmitter and receiver. (Syncword high, Syncword low) ELECHOUSE_cc1101.setAdrChk(0); // Controls address check configuration of received packages. 0 = No address check. 1 = Address check, no broadcast. 2 = Address check and 0 (0x00) broadcast. 3 = Address check and 0 (0x00) and 255 (0xFF) broadcast. ELECHOUSE_cc1101.setAddr(0); // Address used for packet filtration. Optional broadcast addresses are 0 (0x00) and 255 (0xFF). ELECHOUSE_cc1101.setWhiteData(0); // Turn data whitening on / off. 0 = Whitening off. 1 = Whitening on. ELECHOUSE_cc1101.setPktFormat(0); // Format of RX and TX data. 0 = Normal mode, use FIFOs for RX and TX. 1 = Synchronous serial mode, Data in on GDO0 and data out on either of the GDOx pins. 2 = Random TX mode; sends random data using PN9 generator. Used for test. Works as normal mode, setting 0 (00), in RX. 3 = Asynchronous serial mode, Data in on GDO0 and data out on either of the GDOx pins. // page 39 of SWRS061I ELECHOUSE_cc1101.setLengthConfig(2); // 0 = Fixed packet length mode. 1 = Variable packet length mode. 2 = Infinite packet length mode. 3 = Reserved ELECHOUSE_cc1101.setPacketLength(PACKET_LEN); // Indicates the packet length when fixed packet length mode is enabled. If variable packet length mode is used, this value indicates the maximum packet length allowed. ELECHOUSE_cc1101.setCrc(0); // 1 = CRC calculation in TX and CRC check in RX enabled. 0 = CRC disabled for TX and RX. ELECHOUSE_cc1101.setDcFilterOff(0); // Disable digital DC blocking filter before demodulator. Only for data rates ≤ 250 kBaud The recommended IF frequency changes when the DC blocking is disabled. 1 = Disable (current optimized). 0 = Enable (better sensitivity). ELECHOUSE_cc1101.setFEC(0); // Enable Forward Error Correction (FEC) with interleaving for packet payload (Only supported for fixed packet length mode. 0 = Disable. 1 = Enable. ELECHOUSE_cc1101.setPRE(0); // Sets the minimum number of preamble bytes to be transmitted. Values: 0 : 2, 1 : 3, 2 : 4, 3 : 6, 4 : 8, 5 : 12, 6 : 16, 7 : 24 ELECHOUSE_cc1101.setPQT(0); // Preamble quality estimator threshold. The preamble quality estimator increases an internal counter by one each time a bit is received that is different from the previous bit, and decreases the counter by 8 each time a bit is received that is the same as the last bit. A threshold of 4∙PQT for this counter is used to gate sync word detection. When PQT=0 a sync word is always accepted. ELECHOUSE_cc1101.setAppendStatus(0); // When enabled, two status bytes will be appended to the payload of the packet. The status bytes contain RSSI and LQI values, as well as CRC OK. Тут задаю 16битное синхрослово setSyncWord(0, 1) по которому из эфира ловится пакет, и пакеты сгенерированные на СС1101 действительно ловятся (вероятно из-за доп.байта - он помогает отработать схемам АРУ + захват тактовой/несущей?), а оригинальный пакет не принимается. Тут проблема: на СС1101 нельзя задать синхрослово менее 16 бит (наверное 12..13 бит хватило бы), а после прембулы 0х00 0х01 идёт динамический пейлоад и хвататься за него нельзя (точнее неизвестно за что "хвататься"). Как быть в этой ситуации? Гипотетически есть еще режимы: 0 = No preamble/sync. 4 = No preamble/sync, carrier-sense above threshold. но опасение, что байты могут быть приняты с произвольной сдвижкой, а 0х0001 не самая надёжная последовательность чтобы на мк пытаться найти правильный офсет байтов. Или есть еще какая-то возможность настройки, которую я не вижу? ================================================================================ 3) "таймаут" приёма на СС1101 самая загадочная часть сс1101 с которой столкнулся, делаю прийм пакета опросом в цикле: void loop() { //Checks whether something has been received. rxfifo_len = ELECHOUSE_cc1101.CheckRXFIFO(); if (rxfifo_len >= RX_PACKET_LEN){ delay(50); int size = ELECHOUSE_cc1101.ReceiveData(buffer, RX_PACKET_LEN); //Print received in bytes format for (int i = 0; i<size; i++){ Serial.print(buffer[i], HEX); Serial.print(" "); } Serial.println(); } else if (rxfifo_len) { // rxfifo_len > 0 delay(DURATION_PACKET/2); // waiting to receive remaining frame } else { delay(DURATION_PACKET); // no data received. just wait: 10ms == duration of packet } } сами библиотечные процедуры модифицированы (библиотечные версии подразумевали первым байтом длины пакета): byte ELECHOUSE_CC1101::CheckRXFIFO(void){ if(trxstate!=2){ SetRx(); } return (SpiReadStatus(CC1101_RXBYTES) & BYTES_IN_RXFIFO); } byte ELECHOUSE_CC1101::ReceiveData(byte *rxBuffer, byte limit){ SpiReadBurstReg(CC1101_RXFIFO,rxBuffer,limit); SpiStrobe(CC1101_SFRX); SpiStrobe(CC1101_SRX); return limit; } Так вот delay(50); был подобран экспериментально ( и содержится внутри CheckRXFIFO() в оригинальной авторской библиотеке - т.е. он также знал об этой "странности"), 50мс - минимальная задержка при которой проект стабильно принимает пакеты, если ставить менее, то принимается 1й пакет, после чего поллинг SpiReadStatus(CC1101_RXBYTES) всегда возвращает 0 ). Т.е. по факту эта задержка между SpiReadStatus(CC1101_RXBYTES) и последующим SpiReadBurstReg(CC1101_RXFIFO,rxBuffer,limit) и она должна присутствовать. Зачем? В errata по этому поводу информации не содержится https://www.ti.com/lit/er/swrz020e/swrz020e.pdf