perpelov: ЦАП/АЦП по идее тупо вместо циферок дают аналоговый сигнал какой-то величины/измеряют величину аналого сигнала. Само оно за вас ничего делать не будет.
Можно в целом то все, даже возьмите тот же UART и реализуйте софтово все. Но правда зачем? В микроконтроллере есть довольно стандартный интерфейс UART, к компу он подключается замечательно. Почему бы не воспользоваться им, а не выдумывать свой велосипед?
perpelov: Идите по пути наименьшего сопротивления. COM/USB в компе есть? Их можно использовать? В микроконтроллере вашем есть UART. так что можно им передавать без гемороя. Довольно популярный способ.
perpelov: Я видел, что используете этот микроконтроллер, он интел 51 архитектуры. Раз вы задаете такие вопросы, то я делаю вывод, что вы новичок. Ну и смысла не вижу сейчас брать такое.
По поводу вашего выбора ничего не могу сказать, может у вас звуковая карта - это единственный интерфейс ввода вывода. Ну и так да, можно просто использовать кодирование одним уровнем сигнала, тогда можно чисто читать состояние порта ну и дрыгать ножкой. Если что-то сложное, то там уже хитрее.
А так, если есть возможность, лучше не изобретать велосипед. Хоть UART возьмите строенный.
Mirn: perpelov: Я видел, что используете этот микроконтроллер, он интел 51 архитектуры. Раз вы задаете такие вопросы, то я делаю вывод, что вы новичок. Ну и смысла не вижу сейчас брать такое.
По поводу вашего выбора ничего не могу сказать, может у вас звуковая карта - это единственный интерфейс ввода вывода. Ну и так да, можно просто использовать кодирование одним уровнем сигнала, тогда можно чисто читать состояние порта ну и дрыгать ножкой. Если что-то сложное, то там уже хитрее.
А так, если есть возможность, лучше не изобретать велосипед. Хоть UART возьмите встроенный.
Mirn: Да мне больше кажется, что автор от незнания мается. Драйверы какие-то хочет, хотя просто работай себе из проги со звуком и драйверы то зачем... Извиняюсь, если это не так и требуется именно передача все через звуковую карту.
А вы не думали над тем, чтобы парсер этим занимался? Есть casperJS, есть всякие компоненты WebView. Пусть парсер сам открывает сайт и выдирает ключ. Ну или JS код в браузере (расширение?) пусть выдирает его и отправляет. Опять же не ясно автоматический ли парсер, одноразовый, для дебилов, для умных. Для каждого из этих направлений - свои подходы. Но выдирать из файлов данных браузера - это пахнет зловредами и хардкод какой-то.
lega: от алхимии не хотелось бы отказываться. Модели имеют взаимосвязи, условия выборки сложные (тут даже просто SQLAlchemy.Core просто сахар, но хотелось бы ORM). Та же Peeewee слишком ограниченная. И хоть пока работаю с MySQL, то хотелось бы возможность использовать в будущем и PostgreSQL. Так же есть нюанс: часть используемых баз созданы другими приложениями и я там просто буду гостем. Так что я думаю, что SQLAlchemy - это хороший выбор и лидер среди тулкитов для БД в Python.
Разделение и так будет. В целом то все общие слова и на Flask я действительно не встречал примеров таких проектов. Обычно все ограничивается пачкой типовых расширений и использованием Blueprint'ов с регистрацией один раз. Все они по сути монолитные приложения.
Были мысли, может еще раз ее посмотрю. Но Джанга не идеальна, ее русскому языку надо учить (выражается на ломанном), пагинатор надо свой делать или подыскивать (Flask-SQLAlchemy предоставляет толковый), Jinja2 в плане возможностей покруче (да, прикручивается, но зачем, если есть готовое), так же ORM не очень в плане нагруженных проектов.
Мне Джанга нравится в том плане, что на ней можно быстро накидать: шмяк модель, шмяк вьюха, шмяк админка - магазин готов. В случае больших проектов там небось тоже вопросы будут всплывать. И мне больше нравится брать минимализм и необходимое, чем тащить комбайн, где не все нужно и не все подходит для задачи.
alex99505: Не зная что за приложение, ответить конкретно трудно. Если использовать чистый HTTP, то можно хоть скрытое поле в форме использовать для передачи данных. Так же "вариант AJAX" - это отсылка через iframe.
Но вся суть ситуации в том, что бэкенду без разница на фронтенд. Фроентенд делает запросы - сервер отвечает. А что будет дальше - не его забота. Так же и с фронтом: он отослал запрос, как и откуда он получит ответ - ему не важно, он ответа хочет. Так что ваш JS код должен взять данные из local storage, затем как-то отправить серверу (путей, как я сказал, много). А сервер должен принять запрос с этими данными.
Можно в целом то все, даже возьмите тот же UART и реализуйте софтово все. Но правда зачем? В микроконтроллере есть довольно стандартный интерфейс UART, к компу он подключается замечательно. Почему бы не воспользоваться им, а не выдумывать свой велосипед?