выделить чуть больше страниц и сделать аналог выравнивания износа
Конечно, почему бы и нет. Всё зависит от того, на сколько толстый FLASH и сколько объема можно пожертвовать.
Я не стал усложнять текущий пример, хотел сделать его максимально простым. Выравнивание износа можно прикрутить как надстройку для текущего драйвера. Сделать это достаточно просто.
Самый сок в том, что я только сейчас о нем узнал :) В целом подходы похожи (а есть ли другие?). Мне нужно больше времени разобраться в нем, возможно получится улучшить мой вариант
Но что-то мне подсказывает, что 3 состояний будет недостаточно. Я пытался уложиться в меньшее количество и в некоторых моментах возникали неоднозначности -- поэтому у меня их больше
Нет. Проверено экспериментально и в Reference Manual об этом сказано.
The Flash memory interface preliminarily reads the value at the addressed main Flash memory location and checks that it has been erased. If not, the program operation is skipped and a warning is issued by the PGERR bit in FLASH_SR register. The only exception to this is when 0x0000 is programmed. In this case, the location is correctly programmed to 0x0000 and the PGERR bit is not set.
Изначально я так и хотел -- обойтись словом. Я вот прям помню, что встречал где-то FLASH с возможностью сбросов отдельных битов, но не в этом случае
Согласен. Внешняя микросхема всегда предпочтительнее в этом случае. Но всё же бывают случаи, когда нет места для нее. Я сталкивался с подобной ситуацией, когда делал миниатюрное устройство, там каждый мм был на счету. Решал задачу логгирования данных.
Да и к тому же использование 2 страниц увеличивает количество циклов, но в итоге приведет к смерти сразу 2х страниц. Перспективы печальны.
Наверное стоит написать почему я пришел с этим убеждениям. Раньше я использовал HAL, но в новом проекте у меня перестал работать USART. Я потратил много времени на отладку и оказалось, что в HAL не правильно вычислялся baudrate (подробностей не помню, было давно).
Я кайфую с этого :) Причем это отличный способ разобраться в деталях как все работает. Не люблю HAL и прочие нагромождения. LL разве только, но это просто обертки.
Микроконтроллеры программирую только в своих хобби проектах и их не нужно портировать на другие процы.
Это лично мои убеждения. В больших проектах писать драйвера на регистрах излишне, но тут можно и развлечься :)
Как старый еврей старому еврею - а что вы хотели за 30 рублей?
То, что написано после "ЧТО МЫ ПРЕДЛАГАЕМ? (за 30 рублей)". Меня как клиента не должно волновать сколько там кВт нагорает. Так же там есть "На тарифе присутствует ряд технических ограничений." и там только лимит на диск установлен, не на CPU.
Хе-хе, а Вы в России хоть раз видели честную рекламу без обещаний, текстов мелким шрифтом и так далее?
Очень хотелось бы без этого всего, но реально такова...
Ну не знаю, зависит от производительности процессора, который выбрать. Да и я бы не стал делать гексапод на DSP или FPGA -- излишняя сложность, там не нужна такая производительность.
Операционка и тем более ПК тут избыточны. Операционки хорошо подходят для реализации высокоуровневой логики (той же навигации). Думать о том, как там работает I2C или DMA процессора во время реализации алгоритма построения маршрута...мне бы не очень хотелось :)
Микроконтроллер на 72МГц спокойно вытаскивает весь текущий функционал с запасом. У меня есть знакомый, который решил реализовать гексапода на FPGA, вот наблюдаю что из этого получится.
Я надеюсь, что не потерял нить беседы, возможно я о чем-то другом написал, не о том что Вы имели ввиду
По сути это не полноценный робот. Сейчас это просто шестиногая платформа, которая выполняет команды с более высокого уровня. А в качестве этого высокого уровня может выступать все что угодно.
AIWM -- сейчас реализуется только WM часть, AI часть потом :)
Я пока не думал в этом плане, для этого нужно математический движок подготовить.
Первое что приходит в голову -- лидар. В рамках помещения отлично подойдет. Для открытой местности...а нужно ли это? Там АКБ на 20 минут, далеко все равно не уйдет.
Для определения препятствий можно использовать камеру, которая уже в нем есть. 20 FPS должно хватить с запасом
Я даже не знаю нужна ли навигация в нем. В целом это реализуемо. Нечего не мешает поставить в него RPI с какой-нибудь нейронной сетью и так же по WIFI управлять им, как я сейчас с телефона.
Это получится бутерброд из плат. К тому же АЦП к тензодатчикам лучше ставить как можно ближе, там микровольты и падение на проводах может оказаться критичным, тем более тут клеммы.
Я разметил по одному АЦП в ноге (там в статье есть фото) и уже по цифровому интерфейсу снимаю с них показания.
В целом проблема не в датчиках и коммуникации с ними, а в обработке данных с них и механики. Тут очень долго рассказывать и об этом наверное будет отдельная статья когда я решу эту проблему, очень много нюансов.
Конечно, почему бы и нет. Всё зависит от того, на сколько толстый FLASH и сколько объема можно пожертвовать.
Я не стал усложнять текущий пример, хотел сделать его максимально простым. Выравнивание износа можно прикрутить как надстройку для текущего драйвера. Сделать это достаточно просто.
Самый сок в том, что я только сейчас о нем узнал :) В целом подходы похожи (а есть ли другие?). Мне нужно больше времени разобраться в нем, возможно получится улучшить мой вариант
Но что-то мне подсказывает, что 3 состояний будет недостаточно. Я пытался уложиться в меньшее количество и в некоторых моментах возникали неоднозначности -- поэтому у меня их больше
Нет. Проверено экспериментально и в Reference Manual об этом сказано.
Изначально я так и хотел -- обойтись словом. Я вот прям помню, что встречал где-то FLASH с возможностью сбросов отдельных битов, но не в этом случае
Согласен. Внешняя микросхема всегда предпочтительнее в этом случае. Но всё же бывают случаи, когда нет места для нее. Я сталкивался с подобной ситуацией, когда делал миниатюрное устройство, там каждый мм был на счету. Решал задачу логгирования данных.
Да и к тому же использование 2 страниц увеличивает количество циклов, но в итоге приведет к смерти сразу 2х страниц. Перспективы печальны.
Я физически выдернул провод во время ввода команды, куда УП посылать? Соответственно сервер об этом не узнает
Наверное стоит написать почему я пришел с этим убеждениям. Раньше я использовал HAL, но в новом проекте у меня перестал работать USART. Я потратил много времени на отладку и оказалось, что в HAL не правильно вычислялся baudrate (подробностей не помню, было давно).
После этого я соскочил с него.
Я кайфую с этого :) Причем это отличный способ разобраться в деталях как все работает. Не люблю HAL и прочие нагромождения. LL разве только, но это просто обертки.
Микроконтроллеры программирую только в своих хобби проектах и их не нужно портировать на другие процы.
Это лично мои убеждения. В больших проектах писать драйвера на регистрах излишне, но тут можно и развлечься :)
Ух, большое спасибо за ссылки, не попадались мне при поиске. Отличный источник хороших идей
То, что написано после "ЧТО МЫ ПРЕДЛАГАЕМ? (за 30 рублей)". Меня как клиента не должно волновать сколько там кВт нагорает. Так же там есть "На тарифе присутствует ряд технических ограничений." и там только лимит на диск установлен, не на CPU.
Очень хотелось бы без этого всего, но реально такова...
Попробуйте сделать свой без 18 приводов, посмотрим на его мобильность :)
Это который в main? Внутри ОС такой же цикл.
С этим нет проблем
Чтобы подрыгать сервоприводами? Для светодиодов тоже ОС ставить?
Он там был изначально -- сначала SAM3X8E, сейчас STM32F373.
Под слоеным пирогом я понимаю вот это
это ужасно. Для первого прототипа сойдет, но не для последующих и тем более для конечного продукта.
Мой прототип вообще был ужасен в плане эргономики и технологичности :)
Ну не знаю, зависит от производительности процессора, который выбрать. Да и я бы не стал делать гексапод на DSP или FPGA -- излишняя сложность, там не нужна такая производительность.
Операционка и тем более ПК тут избыточны. Операционки хорошо подходят для реализации высокоуровневой логики (той же навигации). Думать о том, как там работает I2C или DMA процессора во время реализации алгоритма построения маршрута...мне бы не очень хотелось :)
Микроконтроллер на 72МГц спокойно вытаскивает весь текущий функционал с запасом. У меня есть знакомый, который решил реализовать гексапода на FPGA, вот наблюдаю что из этого получится.
Я надеюсь, что не потерял нить беседы, возможно я о чем-то другом написал, не о том что Вы имели ввиду
По сути это не полноценный робот. Сейчас это просто шестиногая платформа, которая выполняет команды с более высокого уровня. А в качестве этого высокого уровня может выступать все что угодно.
AIWM -- сейчас реализуется только WM часть, AI часть потом :)
Я пока не думал в этом плане, для этого нужно математический движок подготовить.
Первое что приходит в голову -- лидар. В рамках помещения отлично подойдет. Для открытой местности...а нужно ли это? Там АКБ на 20 минут, далеко все равно не уйдет.
Для определения препятствий можно использовать камеру, которая уже в нем есть. 20 FPS должно хватить с запасом
Я даже не знаю нужна ли навигация в нем. В целом это реализуемо. Нечего не мешает поставить в него RPI с какой-нибудь нейронной сетью и так же по WIFI управлять им, как я сейчас с телефона.
Да можно тут, тот раздел похож на мамонта -- устарел и вымер. Электроника сейчас совсем другая.
Порты:
- 18 под приводы
- 3 под передние RGB светодиоды
- 1 для управления питанием сервоприводов
- Аналоговый вход для мониторинга напряжения АКБ
- 8 для датчиков касания (6 DI, 1 SCL, 1 master clock)
- 1 для пищалки
- 3 для FTDI (USART)
- 2 для MPU6050 (I2C)
- 2 для дисплея (I2C)
- 2 для SWD
- 2 для WIFI (USART)
Итог: 43 пина
Это если при условии принять плату управления как черный ящик с выводами.
Не, ну на дискретных элементах я собирать это не буду конечно. Готовые микросхемы в приоритете -- это дешевле и проще, они для этого и были созданы :)
Это получится бутерброд из плат. К тому же АЦП к тензодатчикам лучше ставить как можно ближе, там микровольты и падение на проводах может оказаться критичным, тем более тут клеммы.
Я разметил по одному АЦП в ноге (там в статье есть фото) и уже по цифровому интерфейсу снимаю с них показания.
В целом проблема не в датчиках и коммуникации с ними, а в обработке данных с них и механики. Тут очень долго рассказывать и об этом наверное будет отдельная статья когда я решу эту проблему, очень много нюансов.
У меня явно не хватает знаний в этой области, отличный повод почитать пару книг :)