Согласен, у меня такое же впечатление сложилось от взгляда на слитые прошивки для FFU - что командный модуль это какое-то слабое процессорное ядро, работающее по прошивке, а данные обрабатываются именно что специализированными DMA между NAND и eMMC интерфейсом, которые настраиваются тем самым ядром. Все на это указывает.
Но там не обошлось без хитростей. Например, если обратить внимание на работу того многострадального open-ended read, спека задает тайминг между стоп битом команды остановки чтения, и собственно остановки чтения на шине данных. Тайминг этот Nst, и равен ровно 2 циклам (6.15.7 JESD84-B51.20). И это оставляет немой вопрос - а как этот процессор так точно выключает свои DMA с точностью до такта, когда он сам явно работает последовательно? Тут варианта три: 1) Либо все забивают на тайминг из спеки и прерывают читалку когда смогут (вероятнее всего) 2) Либо процессор заранее планирует стоп передачи, запуская таймер сразу по получению команды (не дожидаясь её завершения, для проверки CRC например) 3) Либо этот случай вообще не обрабатывается прошивкой и ядром, и обрабатывается как-то через логику в порядке исключения.
В общем нарисовать стейт машину для команд оказалось проще и надежнее, чем реализовывать такое же софт ядро (не было риска откатиться при попадании на нереализуемые требования). Хотя преимущества софта тоже понятны)
Ушло приблизительно 18 месяцев работы, от начала разработки до загрузки в ядро. Терпения и сил знакомому, если это SD с поддержкой UHS, там возможно задача еще сложнее)
Согласен, но в деле создания просто бесконтактных тростей я боюсь что ничего нового не достигну, такие решения уже есть в довольно большом количестве и качестве. У меня была именно центральная идея - освободить обе руки пользователю. Хотя бы в некотором наборе сценариев (скажем, при прогулке в известной, предсказуемой местности). Подвес на BLDC моторах я видел, щупал, но пришел к выводу что достать как движок, так и детали для разводки драйвера будет еще сложнее и дороже, чем то, что уже включено в устройство. Шаговики, мне кажется, не сильно им уступают, проигрывая только в крутящем моменте (который в данном применении не очень нужен).
В принципе инженеры-электронщики довольно консервативный народ, им сложно навязать какую-то новую технику :) Ярчайший пример - когда STM в 201X раздавала бесплатно нуклеи всем кто на презентации приходил, и еще долго занижала на них цены так, что они оказывались дешевле составляющих в их основе. Atmel/Microchip помнят за их 8-битные МК, потому мне кажется даже если этот атсам не обладал бы такой забористой документацией и непонятным функционалом, ему нужно еще десятилетие работать с целевой аудиторией, чтобы та подсела на эти линейки
И вот проблема - электромеханика при любых обстоятельствах не только на порядок больше потребляет, чем твердотельное решение, но и изнашивается буквально на глазах. Касательно лазерных датчиков - да, рассматривал, даже заказывал маленькую платку для отработки VL53L0X датчика (до сборки, правда, не дошло). Как-то по ходу мысли пришел к выводу, что мне нужен именно "конус" для обнаружения тех же, скажем, столбиков на дороге - лазерный датчик будет их попросту не замечать, вызывая столь же опасное столкновение, что и с широким препятствием. У моего датчика угол обзора был 15 градусов, как раз на тех же 170см полета звука это уже 42.5 см ширины обнаружения - величина немного меньшая, чем средняя ширина плеч.
Там какой-то ад творился в марте-апреле, если честно. Был бы посвободнее, наверное, разбирался и дальше, но так я по сути полмесяца ждал возврата денег после того, как они просрочили отправку и али сам отменил заказ. Сейчас правда понимаю, что это все равно лучше чем в России заказывать (цены совсем пробили потолок)
Согласен, у меня такое же впечатление сложилось от взгляда на слитые прошивки для FFU - что командный модуль это какое-то слабое процессорное ядро, работающее по прошивке, а данные обрабатываются именно что специализированными DMA между NAND и eMMC интерфейсом, которые настраиваются тем самым ядром. Все на это указывает.
Но там не обошлось без хитростей. Например, если обратить внимание на работу того многострадального open-ended read, спека задает тайминг между стоп битом команды остановки чтения, и собственно остановки чтения на шине данных. Тайминг этот Nst, и равен ровно 2 циклам (6.15.7 JESD84-B51.20). И это оставляет немой вопрос - а как этот процессор так точно выключает свои DMA с точностью до такта, когда он сам явно работает последовательно? Тут варианта три:
1) Либо все забивают на тайминг из спеки и прерывают читалку когда смогут (вероятнее всего)
2) Либо процессор заранее планирует стоп передачи, запуская таймер сразу по получению команды (не дожидаясь её завершения, для проверки CRC например)
3) Либо этот случай вообще не обрабатывается прошивкой и ядром, и обрабатывается как-то через логику в порядке исключения.
В общем нарисовать стейт машину для команд оказалось проще и надежнее, чем реализовывать такое же софт ядро (не было риска откатиться при попадании на нереализуемые требования). Хотя преимущества софта тоже понятны)
Ушло приблизительно 18 месяцев работы, от начала разработки до загрузки в ядро. Терпения и сил знакомому, если это SD с поддержкой UHS, там возможно задача еще сложнее)
Согласен, но в деле создания просто бесконтактных тростей я боюсь что ничего нового не достигну, такие решения уже есть в довольно большом количестве и качестве. У меня была именно центральная идея - освободить обе руки пользователю. Хотя бы в некотором наборе сценариев (скажем, при прогулке в известной, предсказуемой местности). Подвес на BLDC моторах я видел, щупал, но пришел к выводу что достать как движок, так и детали для разводки драйвера будет еще сложнее и дороже, чем то, что уже включено в устройство. Шаговики, мне кажется, не сильно им уступают, проигрывая только в крутящем моменте (который в данном применении не очень нужен).
В принципе инженеры-электронщики довольно консервативный народ, им сложно навязать какую-то новую технику :) Ярчайший пример - когда STM в 201X раздавала бесплатно нуклеи всем кто на презентации приходил, и еще долго занижала на них цены так, что они оказывались дешевле составляющих в их основе. Atmel/Microchip помнят за их 8-битные МК, потому мне кажется даже если этот атсам не обладал бы такой забористой документацией и непонятным функционалом, ему нужно еще десятилетие работать с целевой аудиторией, чтобы та подсела на эти линейки
И вот проблема - электромеханика при любых обстоятельствах не только на порядок больше потребляет, чем твердотельное решение, но и изнашивается буквально на глазах. Касательно лазерных датчиков - да, рассматривал, даже заказывал маленькую платку для отработки VL53L0X датчика (до сборки, правда, не дошло). Как-то по ходу мысли пришел к выводу, что мне нужен именно "конус" для обнаружения тех же, скажем, столбиков на дороге - лазерный датчик будет их попросту не замечать, вызывая столь же опасное столкновение, что и с широким препятствием. У моего датчика угол обзора был 15 градусов, как раз на тех же 170см полета звука это уже 42.5 см ширины обнаружения - величина немного меньшая, чем средняя ширина плеч.
Там какой-то ад творился в марте-апреле, если честно. Был бы посвободнее, наверное, разбирался и дальше, но так я по сути полмесяца ждал возврата денег после того, как они просрочили отправку и али сам отменил заказ. Сейчас правда понимаю, что это все равно лучше чем в России заказывать (цены совсем пробили потолок)