esaulenka

Ну так вы уже половину сделали. Мне кажется, уже пора скрестить пальцы и попробовать самому кидать эти пакеты в шину. Синхронизацию с "тишиной" в шине на коленке не сделаешь, высока вероятность коллизий, но для первого опыта пойдёт. Последний байт неинтересен, это контрольная сумма (алгоритм - в гугле, по слову 1-wire). Возможно, нажатая кнопка кодируется половинкой предпоследнего байта, вторая половинка значит что-то другое. Кстати, может быть полезным посмотреть обмен в этот момент.

Имхо, исходя из рассматривания единственного лога. На шине общаются несколько устройств: - постоянно бегает пакет 0x80 0x30 0x6F 0x00 0x45 - также постоянно бегает пакет 0x80 0x30 0x8F 0x00 0x30 - и некое третье устройство (пульт?) изредка отправляет пакеты вида 0x80 0x30 0x9F 0x40 0x00 0x15 0x86 0x80 0x30 0x9F 0x40 0x00 0x15 0x86 0x80 0x30 0x9F 0x40 0x00 0x35 0xA5 0x80 0x30 0x9F 0x40 0x00 0xF5 0x6F 0x80 0x30 0x9F 0x40 0x00 0xD5 0x4C 0x80 0x30 0x9F 0x40 0x00 0x55 0xC0 0x80 0x30 0x9F 0x40 0x00 0x25 0x38 0x80 0x30 0x9F 0x40 0x00 0xA5 0xB4 0x80 0x30 0x9F 0x40 0x00 0x65 0x7E Ждём выяснений, соответствует ли это нажатию одной кнопки, или это "нажал всё что было".

@MiD, у вас есть возможность подпаяться к драйверу и переснять логи? Анализатор уарта у салеае туповат (настоящий уарт такие помехи игнорирует). Рассматривать лог с кучей "левых" 0xFF не очень удобно.

В saleae они не вставляются. Для "чистого" сигнала надо просто подпаяться к RO/DI (а заодно и DE) драйвера 485.

Вы не могли бы привести какую-то ссылку на первоисточник? Хотя бы схему подключения блоков. Ну или крупную фотку какого-нибудь ЭБУ, утыканного оптопарами. Мне кажется, докУмент врёт, и в реальной железке защит больше. Но для понимания, как оно себя ведёт, пока помех нет, сойдёт.

ЭБУ - электронный блок управления. Калька с ECU - electronic control unit.

Не подскажите закрома, где всё это можно найти? Я даже доку на банальный GMLan найти не смог (правда, не очень пытался - представление о параметрах можно получить из даташитов на трансиверы). Да. Но для исключения земляных петель питание и земля датчика подключаются через ЭБУ.

Любой штатный блок авто покажите.

Создайте тему, например, здесь: https://electronix.ru/forum/index.php?app=forums&module=forums&controller=forums&id=194 И прилепите туда несколько capture анализатора. Что-нибудь типа "включил", "три раза нажал кнопку быстрее" и т.д.

class EcgReader: def __init__(self, settings_name: str, data_name: str): with open(settings_name, 'rb') as f: d = f.read() params = d[50:53] self.channels = params[0] self.accel_present = (params[1] != 0) self.block_size = params[2] self.data_file = open(data_name, 'rb') self.idx = 0 def read(self): res = [] for _ in range(self.channels): d = self.data_file.read(3) if len(d) != 3: return None # eof # данные согласно файлу "описалово" # num = (d[0] * 0x10000) + (d[1] * 0x100) + d[2] # данные согласно примеру num = (d[2] * 0x10000) + (d[1] * 0x100) + d[0] if num >= 0x800000: num -= 0x1000000 res.append(num) # skip accelerometer data self.idx += 1 if self.idx == self.block_size: if self.accel_present: self.data_file.read(4) self.idx = 0 return res # some tests if __name__ == '__main__': reader = EcgReader('000_ecg.crd', '000_ecg.bin') print('settings:', reader.channels, reader.accel_present, reader.block_size) for _ in range(10): # while True: d = reader.read() if d is None: break print(d) Деньги перечислите, пожалуйста, куда-нибудь в благотворительный фонд.

Да, UART поверх BLE - это чисто нордиковское нестандартное изобретение. Почитайте их инфоцентр, там, насколько я помню, есть пример терминала для андроида. Под винду придётся самому что-то писать...

@one_eight_seven, а вы для контроллеров на каком языке пишете? Я по большей части - на плюсах, и как-то так получается, что без синглтонов никуда. Можно использовать подход "как у больших" с динамическим созданием всего-всего и динамическими же связями, но для мелкоконтроллеров это перебор, на мой взгляд.

Разговор про отладку начал я в соседней теме, когда автор сломал что-то в кишках flatbuffer'а. Что именно сломал, коллективный разум не понял (впрочем, никто из присутствующих не знаком близко с flatbuffer). Вот там без гуляний по шагам с пристальным просмотром всех переменных некомфортно. В комплекте из двух указателей - на экземпляр класса и на сам метод - можно и передать, и использовать. Тут даже где-то была тема про делегаты в с++, где мы это обсуждали. Но один указатель на "голую" функцию проще этой магии на порядок.

Я с чем-то подобным сталкивался на STM32F105. Почему-то при использовании sleep'а консолька стала вести себя неадекватно. К сожалению, так и не дошли руки разобраться - в отладочной версии просто не использую __WFI(). FAQ от сеггера также не рекомендует использовать энергосбережение.

Слегка не в тему. Вы под линуксом работаете, или под виндой? Не могу сказать, что я ОЧЕНЬ пытался, но собрать openocd под винду у меня не получилось... init не вызывается?.. По идее, при первом же RTT_printf должен вызваться.

Ну вроде б очевидно, что вместе с чтением постов надо смотреть в хрустальный шар и гуглить по ключевым словам. Код из первого сообщения похож на официальный пример: https://github.com/espressif/arduino-esp32/blob/master/libraries/WiFi/examples/WiFiClientEvents/WiFiClientEvents.ino Можно предположить, что он работает. Какой магией при подключении wifi.h подтягивается соотв. кусок BSP - я не знаю. Изучение ESP в планах есть, но всё никак руки не дойдут...

Подскажите пожалуйста, в какой книжке это описано? https://godbolt.org/z/PyKfGc

В данном случае c_str() это из гугловского flatbuffer::String::c_str. И любая перегрузка operator= - это для синтаксиса наподобие ла_ла_ла.c_str() = "ла-ла-ла", которого нет ни в стандартной библиотеке, ни (насколько мне известно) в велосипедах "по образу и подобию". Ну а автору я б посоветовал читать книжки (уже пора) и изучить слово GDB.

Перегрузки "operator=" у "const char *" ? Удивительно просто.

Вы первоисточник читали? http://www.keil.com/dd/docs/datashts/infineon/c167cr_um.pdf раздел bootstrap loader. Или только чиптюнеров всяких? Я вот только сходу не понял: общение по uart надо начинать сразу же после отпускания ресета, или не раньше, чем сколько-то там микросекунд после отпускания. Но не проще будет найти где-нибудь программатор для параллельных ROM и паяльник?

Нет, я к тому, что по какой-то причине у дисплея CS всегда активен, он не только будет выставлять данные по RD, как мы наблюдаем, но и сохранять (куда-то) данные, записываемые в ОЗУ.

Это всё здорово, но палочки-кружочки могут рисоваться в т.ч. и при всегда активном CSX (во всяком случае, в описании 9341 есть такая сноска). У вас там при записи в RAM никакие артефакты на дисплее не лезут?

Чуток не так. ACK - это не подтверждение приёма тем узлом, которому сообщение предназначено. ACK одновременно выставляют все узлы, которые приняли это сообщение. Соответственно, если на шине больше одного корректно работающего узла, все сообщения получат свои ack'и. Но, с другой стороны, если вам нужно знать, что сообщение принял именно ваш приёмник, а не какой-то другой, придётся делать какой-то протокол поверх этого.

Сразу предупрежу, что слово "ксайлинкс" я не знаю, зато имею кой-какой опыт общения с CAN в МК. Да, именно так. Да, так всё и работает. Параллельно должны расти счётчики ошибок, и устройство затыкается. Есть, правда, вариант, что после таймаута оно подключается обратно. Реализован ли механизм в вашем примере, я не знаю (см. начало сообщения). ... то оно сидит себе тихо, и никак не мешает обмену всех остальных устройств. Единственная серьезная пакость - это рассогласование скоростей. Вот там действительно на шине что-то непотребное творится...

Очень неохота перечитывать мануал на FSMC, а по памяти в этой портянке я ничего не скажу. Параллельный интерфейс у 9481 и 9486 одинаковый, насколько я вижу в даташите. Вы вот лучше скажите: CS на вашем дисплее есть? Он корректно дёргается? Если оторвать RD от дисплея (раз уж всё равно проводами всё) память перестаёт портиться?