Size: a a a

2021 February 04

LZ

Leonid Zaliubovskii in Embedded Group
Как по мне, SLIP отличный вариант, если объемы данных не сильно большие
источник

A

Alexander in Embedded Group
Leonid Zaliubovskii
Как по мне, SLIP отличный вариант, если объемы данных не сильно большие
Будет небольшой overhead.
Но так да, норм.
Мы использловали.
источник

ED

Electronics Designer in Embedded Group
Alexander
Protobuf?
С ним одна проблема - Google не озаботился сделать нормальный генератор кода на ANSI C.
источник

r

romanetz in Embedded Group
Leonid Zaliubovskii
Как по мне, SLIP отличный вариант, если объемы данных не сильно большие
Так постепенно до PPP дойдём )
источник

LZ

Leonid Zaliubovskii in Embedded Group
romanetz
Так постепенно до PPP дойдём )
Как будто что-то плохое 😁
источник

r

romanetz in Embedded Group
Не, чтобы не колхозить самому - сразу lwip в проект закинуть?
источник

АБ

Александр Баракин... in Embedded Group
Всем привет! Народ, кто-нибудь работал с boost::beast::http ? Есть большой проект, обмен с веб-сервисами построено на нем и хотелось бы использовать именно его и в этом  случае, но проблема - похоже он не умеет разбирать HTTP ответы с версией HTTP 1.0. Это действительно так? Гуглил, много, но именно версию в ответе сервера не нашел ничего
источник

ED

Egor Dolgalev in Embedded Group
protobuf нормальный протокол, есть хорошие библиотеки для C, не сказал бы что оверхед есть
источник

ED

Egor Dolgalev in Embedded Group
достаточно платформо независим, есть под разные языки поддержка
источник

LZ

Leonid Zaliubovskii in Embedded Group
Egor Dolgalev
protobuf нормальный протокол, есть хорошие библиотеки для C, не сказал бы что оверхед есть
На си, но под МК нормальных и свежих имплементаций я не видел, правда трогал в 18 последний раз.

С радостью послушаю аргументы за
источник

ED

Egor Dolgalev in Embedded Group
jon pedro
у меня вот такой вопросец есть. Сейчас хочу сделать протокол обмена сообщениями, вот подумал о том, как его можно реализовать полностью платформонезависимым и подумал о следующем. Норм ли будет идея, чтобы были указатели на функции для основных операций (отправка, проверка буфера и т.д). А при инициализации своего класса я бы просто присваивал указатель на нужные мне функции и дальше это уже бы работало с необходимой периферией. Или тут могут возникнуть проблемы? (вопрос возможной работы с указателем в никуда отметается, рассматривается, что происходит контроль инициализации указателей на функции)
раз уж тут С++, то делать лучше интерфейсный класс и в его наследниках менять поведение
источник

ED

Egor Dolgalev in Embedded Group
Leonid Zaliubovskii
На си, но под МК нормальных и свежих имплементаций я не видел, правда трогал в 18 последний раз.

С радостью послушаю аргументы за
nanopb использую
источник

ED

Egor Dolgalev in Embedded Group
есть репа на гитхабе, там много чего, но по большому счету нужно из нее только три файла
источник

jp

jon pedro in Embedded Group
Egor Dolgalev
раз уж тут С++, то делать лучше интерфейсный класс и в его наследниках менять поведение
Епрст, это же гениально. Я просто только осваиваю си, и пока до конца его не про чувствовал)
источник

LZ

Leonid Zaliubovskii in Embedded Group
Egor Dolgalev
есть репа на гитхабе, там много чего, но по большому счету нужно из нее только три файла
Почитаю, спасибо
источник

AK

Andrej Kostrov in Embedded Group
Egor Dolgalev
раз уж тут С++, то делать лучше интерфейсный класс и в его наследниках менять поведение
👍
источник

AM

Aleksander Mironov in Embedded Group
ID:0
Переслано от Ksenia Gorkova
Вакансия: Senior C developer
Город: Санкт-Петербург
Зарплата: до 250 т.р.
Формат: офис/ частично удаленная на выбор

О компании и проекте:                                                                                                                                                                                    В ведущую российскую компанию в сфере заказной разработки ПО ищем C developer. Среди заказчиков - крупные международные компании. Проект связан с низкоуровневой разработкой светового оборудования для фотографов для шведской компании, которая занимается разработкой и выпуском светооборудования для фотографов (фотовспышки, световое окружение). Необходимо будет программировать микроконтроллеры для того, чтобы фотовспышка взаимодействовала с ПО на камерах и мобильных устройствах.
                                                                                                                                                                                                                                                                       О вас:
- опыт embedded разработки от 3 лет,
- опыт работы с STM (32). На проекте: STM32F4,
- опыт работы с UART, I2C, SPI, BLE, RF,
- разговорный английский

Условия:
- Белая з/п - до 230 т.р.,
- Офис в Санкт-Петербурге,
- Частично удаленная работа или офис,
- Обучение, занятия по английскому, ДМС со стоматологией

Контакт: @kseniaithr
Хз норм, зп, не понимаю че все разнылись ТАКИЕ ДЕНЬГИ. Такие деньги получают люди за знание HTTP + пары библиотечек, без всяких upper intermediate.
А то что в всяком низком уровне требуют ВО + 65 лет опыта + знать "Всю херню" за 17к это просто рабство.
источник

Х

Х in Embedded Group
Aleksander Mironov
Хз норм, зп, не понимаю че все разнылись ТАКИЕ ДЕНЬГИ. Такие деньги получают люди за знание HTTP + пары библиотечек, без всяких upper intermediate.
А то что в всяком низком уровне требуют ВО + 65 лет опыта + знать "Всю херню" за 17к это просто рабство.
Или в вебе зажрались...
источник

AM

Aleksander Mironov in Embedded Group
Х
Или в вебе зажрались...
Нет это просто обычные человеческие з\п.
источник

s

shadowsoul in Embedded Group
а дрочение сотрудника за <50к - сельская дискотека под видом завода с понтами стариков
источник