pacman2ebawer: ну так выше советовали миниатюрную штукенцию.
А вообще, если гонятся за размером, то сами обычно изготавливают платы. Ставьте на свою печатку А20 и будет счастье.
Neuroware: элементарно сделать: обрабатывать только строками. Т.е. все данные до символа \n (либо до символа \0) накапливаются в буфере, а как только получаем этот символ, устанавливаем флаг готовности.
Ну и по таймауту можно буфер опустошать, если есть желание. Только я не понимаю, как может что-то "потеряться", если прием-передача сделаны правильно, а не через одно место.
Можно, кстати, и линейным буфером обойтись: заполнять буфер посредством DMA, а в прерывании DMA проверять, что за байт пришел. И если нужный, то генерировать флаг и отрубать DMA (чтобы не забить буфер, пока он не обработан).
А можно и действительно таймаутами. У меня, например, буфер приема обрабатывается посимвольно, но конечными автоматами. И если нужно ждать какие-то данные, фиксируется текущее время, а в цикле периодически проверяется, сколько уже прошло. Если больше, скажем, 10с, то считается, что данные "куда-то исчезли" (куда?) и операция обрывается - конечный автомат переводится в изначальное состояние.
Neuroware: насчет интерфейсов ничего мудрить не надо. Все там элементарно: если буфер переполнился, выкидываем нафиг все содержимое буфера и не паримся! Все равно битые пакеты нам не нужны.
Но если правильно выбран микроконтроллер, то ничего там переполняться не будет!
Прием-передачу по SPI вообще проще реализовать через DMA, и ни на что отвлекаться не надо будет!
Да и в принципе, везде, где только это возможно, следует использовать DMA.
Neuroware: C++ для микроконтроллеров - это дичайшая дикость! Там вообще обычно 0 оптимизации!
Скажем, если STM32 программировать на С, но с использованием SPL, у вас будут вылезать "непонятные баги", а также кое-какие вещи (скажем, оптимизированное скоростное выполнение задач, работа с шустрыми интерфейсами, да и просто оптимизация по размеру кода - не у всех на борту 10МБ флеша) вы выполнить вообще не сможете!
Neuroware: А что там может быть проблематичным? Пишем в кольцевой буфер, в основном цикле постоянно проверяем на наличие данных, если данные есть, обрабатываем. Везде так работает. И никаких проблем.
Ну и, понятное дело, писать нужно хоть и не на ассемблере, но хотя бы на сях, а не мышкой в каком-то ынтырфейсе тыкать. Мышкой вы ничего путного не натыкаете.
тяжело, наверное, вспомнить то, что не знал ;)
Армянское Радио: ну, я скорость не замерял, но терминал у меня всегда на 150кбит/с работает, проблем не видел. Да и что значит "теоретический максимум в 128 тысяч"? Если это FS, то максимум - мегабита полтора. А если это HS, то вообще чуть ли не тактовая частота!
Армянское Радио: да я сам поначалу ею пользовался и удивлялся, чего это ее ругают. Пока не познакомился с этим быдлокодом поближе: то один косяк появился, то другой... Патчил-патчил, потом плюнул и стал пользоваться opencm3. Правда, проблему с USB еще не решил (хочу на STM32F407 наладить одновременную работу обоих интерфейсов — и FS, и HS).
Ну, а задачи, требующие максимального приближения к realtime, вообще никаких библиотек не допускают - только регистры.
Армянское Радио: Нет, потому как всякие культи и т.п. используют классы. Здесь C не пройдет.
Мне пару раз для использования готовых библиотек приходилось писать прослойку, предоставляющую сишные интерфейсы, т.к. авторы на кой-то черт запилили "железячную" библиотеку на С++! Благо, таких извращенцев немного.
Ну, а эти культевые обертки я считаю коровьим седлом, которое так и просит бритвы Оккама!
Пакеты, кстати, не ворует микроконтроллер (сам недавно на подобное грешил, а потом разобрался): если поток слишком шустрый, то просто буфер переполняется со всякими неприятными последствиями.
Да, USB-библиотека от STM (которая в состав SPL входит) - жутчайший быдлокод, из того, что я видел. Советую opencm3, если вы ее еще не используете.
А SPL надо выкинуть подальше.
Армянское Радио: QSerialPort - очень надежный способ себе ногу отстрелить. ЕМНИП, пару-тройку раз натыкался на ЛОРе на проблемы с этой дрянью у любителей культей.
Есть нормальный open/read/write. Зачем эти культеизвраты?
А еще у культей есть другой гигантский недостаток: эта дрянь только с С++ работает. А С++ в 99.9% - лютый оверхед. Лично у меня нет ни одной задачи, где этот ЯП понадобился бы!
Дмитрий: "переустановить"? Какой-то мастдаечный подход.
В случае, если хочется актуальные версии всегда иметь возможность поставить, лучше уж тогда на сервер генту воткнуть. И периодически обновлять по-минимуму.
tushev: ядро в случае критических уязвимостей и вручную можно скомпилировать. Это несложно. Все-таки, сервер - не десктоп. На сервере ПО нужно обновлять лишь когда сам сервер помрет, и все равно на новую платформу переезжаешь.
А вот десктоп - другое дело. У меня, например, на работе арчик как помер (в смысле - дистрибутив помер, арчик на работе еще живой), так и 2 года уже без обновления. Все никак не найду время генту туда воткнуть вместо этого старья. Софт-то нужен постоянно, в итоге уже в свалку систему превратил: все, что нужно обновить, обновляется вручную. В обход pacman (т.к. он хочет всю систему уничтожить).
Dorsal: если не веб-интерфейс, то нужно готовиться к заполнению памяти тонной совершенно ненужных знаний. Ну и помучиться с совершенно идиотскими методиками рисования GUI (если будет выбран Qt или GTK). Можно motif или Tk использовать, тогда будет легче.
Армянское Радио: ну, не сказал бы. У меня только проблема была на бажной версии огнелиса, когда я пытался вместо ненужных кук использовать более приличный localstorage. Пришлось патчить жабкоскрипт: добавлять куки, если localstorage не может отработать.
В остальном все без проблем. И 3D-графику через webGL делал, и псевдо-3D через SVG, и просто менюшки-кнопочки, видео, графики и т.п.
К Qt я однозначно отношусь: лучше бы этой дряни вообще не было. Она - как ардуйня. Портит мозг.
Армянское Радио: ну, не такая уж и морока с сегментником: двоично-десятичный дешифратор для уменьшения количества ног на аноды + по какому-нибудь копеечному полевику на катоды.
Армянское Радио: я все-таки хочу, чтобы люди развивались, а не оставались обезьянками вроде бубунтофилов или ардуинщиков!
Нужно учиться думать головой, а не копировать бездумно мантры, смысла которых не понимаешь.
Стандартная длина посылки у DS18 составляет 60мкс, т.е. свет за это время проходит 18км, но длительность импульса 1/0 более чувствительна, там уже задержка в 10мкс может поломать весь протокол → теоретически где-то при длине проводов 1.5км 1-wire перестанет работать.
Однако, есть потери на проводах, и нужно будет внимательно выбирать сечение. Ну и, как я говорил, паразитного питания на таких длинных линиях сделать не получится (иначе нужно будет уж слишком толстую медь укладывать). Но можно взять недорогие импульсные преобразователи и запитать наиболее удаленный датчик отдельно (батарейка + импульсник == 3.3В вплоть до полного высасывания батарейки - где-то 0.6В).
KyIIpyM: www.ebay.com/itm/Digital-LCD-Car-Fridge-Incubator-... - вроде таких.
Передача данных там по 1-wire, так что вполне до ~15м можно удлинить провод, если питание сделать не паразитным.
Но при большом желании можно то же самое и самому воспроизвести. Однако, повторю: это будет уже значительно дороже.
Wizzy: коротим, затем запускаем хоть сессию screen, хоть com из пакета setserial.
Скажем, так: com /dev/ttyUSB0
И печатаем что-нибудь. Если переходник работает, должно быть эхо.
А вообще, если гонятся за размером, то сами обычно изготавливают платы. Ставьте на свою печатку А20 и будет счастье.