adnega

У меня есть четыре ослика. Однако, пользуюсь старым-добрым OWON SDS7102 (с батарейным паком). OWON XDS3102 - большой экран, но сам ослик глючный (не синхронизируется по триггерам зависящим от времени). RIGOL DS1104Z+ - слишком громоздкий. DHO924S - долго загружается, и нужно тыкать пальцем в экран, и софт сыроват.

Кста, у меня бага была на GD-проце. По идее, ядро после перезагрузки должно стек проинициализировать (первое слово) и управление передать (второе слово). У меня почему-то стек не инициализировался ядром - пришлось ручками задавать. Тоже вспотел - минимальнейший проект не работал)

Типа такого: Обработчик: HardFaultException: mov r0, sp push {lr} bl print_fault pop {pc} Си-функция: void print_fault(sFAULT *fault) { static int cnt = 0; if(cnt < 5) { con_str("FAULT:\n\r"); con_str("r0 = "); con_dword(fault->r0); con_str(", "); con_str("r1 = "); con_dword(fault->r1); con_str(", "); con_str("r2 = "); con_dword(fault->r2); con_str(", "); con_str("r3 = "); con_dword(fault->r3); con_str("\n\r"); con_str("r12 = "); con_dword(fault->r12); con_str(", "); con_str("lr = "); con_dword(fault->lr); con_str(", "); con_str("pc = "); con_dword(fault->pc); con_str(", "); con_str("xpsr = "); con_dword(fault->xpsr); con_str("\n\r"); con_start(); cnt++; } } typedef struct sFAULT { uint32_t r0; uint32_t r1; uint32_t r2; uint32_t r3; uint32_t r12; uint32_t lr; uint32_t pc; uint32_t xpsr; } sFAULT;

Там на стеке должны еще некоторые регистры лежать. Очень помогает сохраненные значения LR и PC.

Сделать-то можно, а вот запаять - не простая задача - маски очень не хватает.

ЛУТ с такой мелочью - без шансов на успех)

Сам ручками недавно собирал такое )) Главное, чтоб по бокам был доступ, и чтоб посадочное место было грамотно спроектировано.

ATtiny13.... ATtiny10-TSHR! UMD22N есть в ЧиД

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

Кста, я когда звук поверх CAN в низкоприоритетном потоке передавал сделал просто передачу четных и нечетных выборок в соседних пакетах. Т.е. при потере пакета просто полоса сигнала резалась. И, вроде, был у меня tog-бит в ID.. Но там можно было пакет потерять) И частота была небольшая, что несколько боксов с этим ID не забивались)

В жизни ни у всех есть аппаратный FIFO. У многих это просто три коробки. При приеме пакета выставляется флаг. Далее в обработчике смотришь какая коробка заполнена и помещаешь содержимое в программный FIFO. Бывает, что заполнено сразу несколько коробок - и вот это не гарантирует порядок пакетов.

Примет, разложит по mailbox`ам. Как узнать какой mailbox принят раньше?

Что гарантирует прием в нужном порядке? Отправить не проблема.

Лучше так не делать. Сам сталкиваюсь с тем, что при плотном потоке, даже если они все будут успешно отправлены в нормальном порядке, нет гарантий, что на приемной стороне этот порядок можно будет выстроить, т.к. они там тоже залетают в почтовые ящики) Можно часть ID выделить под счетчик (размером не менее числа mailbox на приемной стороне). Если протокол позволяет)

Нужно понимать, что между событием и DMA-транзакцией для этого события проходит время. Насколько я помню, порядка 12 тактов (для Cortex-M3).