Комментарии 23
Я правильно понял, что у Вас свой асинхронный движок + еще RTIC? Возможно ли обойтись без RTIC?
Тепло, лампово. Чем-то напоминает как я начинал сборку своего самого-самого первого компьютера вычислительного устройства с отдельных логических элементов...
Вспомнил, как я делал программную реализацию этого манчестерского протокола на ассемблере i8080 просто слушая порт КР80ВВ55. На компьютерах Радио-86рк, Вектор06ц и на "Корвете", для записи на кассетный магнитофон.
Байт синхронизации там был E6. 30 лет прошло, а все помню!))
..а меня, наоборот, убивало то, что в РК все программно и из последних сил - и я подпатчил Монитор, убрав EI/DI как генератор звука, поставил контроллер шины, прерываний и ВВ51 с кодером/декодером Манчестера в синхронный последовательный код как раз подобным способом - для нормального обмена с магнитофоном без срыва ПДП и всех этих воркэраундов с регенерацией. Помню, качественный магнитофон позволял 9600 бит/с читать/писать запросто )
если данных приходит много, обычно кадры идут подряд с минимальным интервалом. Моя программа не успевает так быстро перенастроить DMA на новый буфер, поэтому часть кадров в таком случае теряется.
Включите кольцевой буфер — тогда ничего перенастраивать не надо. Если не упёрлись в лимит по ОЗУ.
Дабл плюс!
Эта последовательность состоит из семи байт 0x55 и восьмого байта 0xE5
А на картинке восьмой байт - D5 ?
Ну очень напомнило мне этот проект!
http://www.aholme.co.uk/Ethernet/EthernetRx.htm
Но вроде не плагиат..
– А я умею писать телеграм боты без фреймворков, на чистых http запросах.
– А я умею на транзисторах!
– ?
Респект)
Ах, какая же годнота.
По этим импульсам устройство на другой стороне узнает, что с нашей стороны что-то подключено
Я совсем не эксперт, но. По этим импульсам устройство на другой стороне синхронизирует часы через phase-locked loop. Если PLL не использовать, у вас часы не будут выравниваться на принимающей стороне, и вы прочитаете биты там, где их нет. Более быстрые сорта эзернета используют 8b/10b кодирование, чтобы отдельные битовые ошибки чинить (в том числе от несинхронизированных часов), а 10BASE-T на такой абьюз не рассчитан, и после проверки чексуммы теряется пакет целиком.
Кроме того, у вас magnetics какие-то странные, без common-mode choke.
UPD. Блин, там в оригинальной статье не только PLL есть, но ещё и параметры честно посчитаны через control theory. Это не "что-то слишком сложное", это обязательная часть!
pub struct ReadFuture<'socket, 'adapter, 'buf> where 'socket: 'adapter, 'socket: 'buf, { adapter: &'adapter mut TcpSocketAdapter<'socket>, buf: &'buf mut [u8], }
У меня есть пара вопросов к этому определению:
- Зачем накладывать ограничение
'socket: 'buf
, если они не используется на одном поле? - Зачем вводить отдельные времена жизни
'adapter
и'buf
? Borrow checker может унифицировать лайфтаймы двух разных ссылок.
Я не знаю, зачем это нужно в этом конкретном случае.
Но, в принципе, такое может быть нужно, чтобы иметь возможность вернуть ссылку на буфер, которая живёт дольше, чем адаптер. Если время унифицировать, то знание о том, что буфер, вообще говоря, может пережить адаптер потеряется.
'socket: 'adapter,
'socket: 'buf,
Вот этот кусок не понял. Время жизни сокета должно быть равно максимальному из буфера и адаптера или как читать это?
Ура - технопорно на сайте! Спасибо за труд, очень интересно!
Пишем телеграм-бота на Rust, предварительно спаяв сетевую карту