cnc-club.ru

MX_Master писал(а):Работа с МК напрямую немного отличается от работы программ в операционной системе.

Причем в лучшую сторону. В плане реалтайма.

Сергей Саныч писал(а):

MX_Master писал(а):Работа с МК напрямую немного отличается от работы программ в операционной системе.

Причем в лучшую сторону. В плане реалтайма.

для МК есть мини ОС реального времени, но для двух-трёх задач их использовать - только ресурс потратить

Сергей Саныч писал(а):А если есть огромное желание, можно попробовать разобраться в коде планировщика LinuxCNC (код открытый) и попытаться сделать что-то подобное на ваших МК.

Желание есть большое. Сразу понял, что LinuxCNC мощная система. Но делал несколько подходов разобраться в исходниках - только больше запутываюсь. Надо собраться основательно.

MX_Master писал(а):В идеале gcode файл должен быть на SD карте и, до начала работы УП, этот файл нужно переварить в другой файл с компактным байт кодом.

Байт код - дело хорошее, к сожалению с оперативкой у контролеров туго. Тоже думал 4 шага вперед маловато, но как увидел скорость в два раза быстрее, пока оставил как есть.))

aftaev писал(а):Называется это Look ahead во всех нормальных ЧПУ есть, некоторые умеют "просматривать" код на заданное кол-во.

Спасибо возьму на вооружение понятие. Но гордость взяла, что китайская "кляча" так не может.)))

MX_Master писал(а):Работа с МК напрямую немного отличается от работы программ в операционной системе.

Работа планировщика чем именно будет отличаться?..

UAVpilot писал(а):

MX_Master писал(а):Работа с МК напрямую немного отличается от работы программ в операционной системе.

Работа планировщика чем именно будет отличаться?..

его работа будет прерываться реже

MX_Master писал(а):его работа будет прерываться реже

Ну и что? Он-же не в RT работает...
Да и как правило в МК одно ядро, а там, где есть ОС сейчас уже несколько ядер.

UAVpilot писал(а):

MX_Master писал(а):его работа будет прерываться реже

Ну и что? Он-же не в RT работает...
Да и как правило в МК одно ядро, а там, где есть ОС сейчас уже несколько ядер.

и в одном МК бывают сопроцессоры, товарищи из проекта Smoothieware все-таки решили пересесть с кортекса М3 на М4 с сопроцессором М0. Но, если подводить итог, у нас дискуссия на бесполезную тему. Если б можно было на настольных ОС с RT извернуться и как-нибудь сделать стабильный высокочастотный вывод шагов, я бы с генераторами на медленном одноядерном STM32 не заморачивался.

slavik писал(а):И вот я так и не придумал как это можно реализовать, если разделить задачи на несколько контролеров. (только если вводить дополнительные команды G кода

Я думаю, что ваш STM32F407VET6 вполне справится и один, но если разбивать задачи на несколько МК, то можно их объединить по SPI

MX_Master писал(а):Если б можно было на настольных ОС с RT извернуться и как-нибудь сделать стабильный высокочастотный вывод шагов, я бы с генераторами на медленном одноядерном STM32 не заморачивался.

Тут уже назывались в качестве примера платы Mesa и макетки за 15$.

Весь комплект в сборе
Пора опробовать Ethernet соединение, TCP и HTTP. А также проверить одновременную работу с SD картой и работу по сети..

MX_Master писал(а):Я думаю, что ваш STM32F407VET6 вполне справится и один, но если разбивать задачи на несколько МК, то можно их объединить по SPI

Пока что справляется замечательно. )) Буду перенимать опыт ускорения и торможения по S кривой, там видно будет.
По поводу SPI вроде понимаю, вопрос в том какими блоками данных обмениваться:
- если передавать большие блоки, то нужно много оперативки да процессорное время будет теряться на обработку, тут есть смысл работать одному контролеру;
- если маленькими блоками, то нужны методы высчитывания с хирургической точностью эти порции байт кода, что бы время импульсов на мотор не терять. Так как код неоднородный будет.

MX_Master писал(а):Пора опробовать Ethernet соединение, TCP и HTTP. А также проверить одновременную работу с SD картой и работу по сети..

Надо веб камеру с веб интерфейсом, что бы мы форумом тоже погоняли его.))))

slavik писал(а):По поводу SPI вроде понимаю, вопрос в том какими блоками данных обмениваться:

Очень мелкими, желательно, без ответов. Имеет смысл только генератор вывести на отдельный МК, там пойдут и мелкие 8-ми битные команды, чисто приказы отдавать. Ну и DMA для передачи можно задействовать, чтобы чуток разгрузить проц.

Походу надо предусмотреть возможность подключения генератора к другим устройствам по SPI как ведомого устройства. Это позволит подрубить генератор к любым одноплатникам (типа Orange Pi) или другим МК. К той же ардуине.

Пока настраивал SPI, понял, что DMA каналов на всё не хватит. У мк STM32F103C8T6 их всего 7, а для полного счастья нужно 8, иначе придётся передачу по одному из SPI делать процем. Походу надо отделять генератор в отдельную платку (6-ти каналов DMA хватит), а какие-то мозги или вебморду делать на другой платке. Иными словами, чтобы сделать полноценный контроллер на базе этого генератора, надо перепрыгнуть на МК, где периферии количественно больше, например STM32F407VET6

MX_Master писал(а): Иными словами, чтобы сделать полноценный контроллер на базе этого генератора, надо перепрыгнуть на МК, где периферии количественно больше, например STM32F407VET6

У меня на этом мк камнем приткновения встало отображение информации. Подключил экран от нокии 3310 - отлично, ресурсы почти не ест, но мелковат он. Начал подключать серьезнее - 3.2 дюйма от ардуины. На этом мк нет встроенного LCD-TFT контролера, поэтому имеет большую нагрузку на процессор, что плохо. А вот в этой же линейке мк STM32F429xx/439xx есть такое устройство. Но цены на них кусаются. Или думаю вынести в отдельный контролер это все.

При подключении МК к TFT дисплеям есть смысл использовать спец. контроллеры типа http://schemov.com/tftcomp/

Если дисплей где-то и будет, то только на отдельной платке Orange Pi One, куда подключится и прочая периферия. Нагрузить стм'ку дисплеем, флэшкой, сетью, генератором и прочим кодом контроллера - это довольно смело. Даже с учетом повсеместного использования DMA.

MX_Master писал(а):Нагрузить стм'ку дисплеем

да не, по моей ссылке как раз разгрузка микроконтроллера - по SPI отправляются только макрокоманды отрисовки примитивов и вывода текста. DMA вообще не требуется.

MX_Master писал(а):Нагрузить стм'ку дисплеем, флэшкой, сетью, генератором и прочим кодом контроллера - это довольно смело.

Сети у меня нет, а так работает достаточно бодро все.)) Ну и пока парсер G-кода на минимально необходимый набор команд (только линейное передвижение). Арткамовские рельефы рисует отлично.

slavik писал(а):У меня на этом мк камнем приткновения встало отображение информации. Подключил экран от нокии 3310 - отлично, ресурсы почти не ест, но мелковат он. Начал подключать серьезнее - 3.2 дюйма от ардуины. На этом мк нет встроенного LCD-TFT контролера, поэтому имеет большую нагрузку на процессор, что плохо. А вот в этой же линейке мк STM32F429xx/439xx есть такое устройство. Но цены на них кусаются. Или думаю вынести в отдельный контролер это все.

Я думаю, надо сразу юзать нормальный дисплей. Пока искал данные по разной периферии к STM32F4, видел кучу статей по подключению LCD экранчиков с помощью контроллера внешней памяти - FSMC. По возможности, всегда надо юзать периферию, иначе проц начнёт загибаться еще до всякого контроллера.

MX_Master писал(а): видел кучу статей по подключению LCD экранчиков с помощью контроллера внешней памяти - FSMC

Тоже когда начинал разбираться теплилась надежда, что FSMC - панацея. FSMC в отличии от SPI позволяет работать с контролером экрана по 16 битной шине и дергать ножки управления. Команды же и данные по каждому пикселю приходится слать одиночно, что сильно уже грузит проц. При этом у большого цветного экрана поток данных в несколько больше.

MX_Master писал(а):Я думаю, надо сразу юзать нормальный дисплей.

Маленький LCD от нокии был на то время более понятен и прост в подключении, не отвлекал от основных задач. До сих пор достойно выполняет свои функции. Просто код писал так, что-бы можно было быстро адаптировать к другому экрану.