tronix286

Каждый эмбедер хоть раз в жизни, но обязан попробовать ШИМить с помощью реле

Здрям, Достался по случаю пучек сабжев. Полистал даташит, но что-то не понял насчет программирования. Понял только то, что он не как Atmel 89C51 шьется параллельно и при VPP 12V. А как он шьется? Допустим, я его переведу в F04KBOOT (Boot From LDROM), но дальше не понятно для меня - куда чего подключать-то? По UART или как? Описан некий регистр SFRCN, но как мне его по UART изменить или не по UART, какие команды подавать? Ничего не понимаю. Не так, чтобы уж очень нужно, но мало-ли, чего-то пятивольтовое подергать...

Чем дело то кончилось?

Благодарю, будем что-то придумывать...

Подскажите, есть ли у сабжа AutoBaud . Дело в том, что по некоторым соображениям UART на устройстве жестко настроен на 115200. Новый SIM68M стартует на 9600. Можно как-то на скорости 115200 ему послать $PSIMIPR,W,115200*1C , или все-таки надо переводить UART на 9600 и только тогда слать команду, а потом переводить обратно на 115200? И, еще вопрос, какая команда установки скорости правильная? $PSIMIPR,W,115200*1C или $PMTK251,115200*1F? Спасибо.

smk, а попробуйте прикола ради вот этот файл зашить.... kolib.hex

Пришлите на почту монтажку. tronix286( собачга) rabmler.ru .

Чтоб не изобретать велосипед, может быть уже кто-то делал такое? Например нужна имитация фиговой проводки бортовой сети автомобиля 24В. Что значит фиговой? Ну, например, это может быть окисленная скрутка, недожатый соединитель, отпадающий при хорошей кочке и тому подобное. Может быть вообще мат модель какая-нибудь данных процессов есть? ) Собственно, интересно протестировать устройство в условиях плохой проводки (по питанию), не устанавливая его на реальный авто.

1-3 дня??? Первую плату 10 штук с ее 0603 я соберу за час максимум, с перекурами. Вторую - 10 штук за чуть больше, чем пол дня рабочих, остальные полдня - написание тестовой прошивки и отладка. Платы то ни о чем вообще.

Хоспаде. Задача решается на одном STM23F030, который стоит меньше атмеги и меньше пика, особенно если штук 500 хотя-бы взять, за вечер под певко. Просто ужас что школьникам преподают.

А что за SMT компоненты такие?

А какие части исходников то? Ну есть таски парсинга GPS, общение с мопедом, запись точек сначала в очередь, потов во флешку, отслеживание аналоговых кнопок, измерение ADC напряжения питания и просто других, управление открытими коллекторами для блокировки и тд, общение по омникому на 485 со всякими датчиками топливными. Что присылать? Да и присылать стыдно - потому что не дают времени и говнокод. Работает конечно, но причесать некогда.

Ну стм, ну фриртос. Что программировать будем? Трекеры, или что? Не всякая работа по душею. Подтвержден проектами, многими. Мне нужна белая зарплата, и тыщ 70 минимум. Можно и не трекеры, можно закладки, температуруные датчики и так далее. Но главное по трудовой.

Вот и я говорю. А вместо таблицы, у меня в начале памяти приемо-передающие буфера (то есть я там вижу данные свои которые шлю в контроллер). Вот те и CubeMX на пару с HAL. Короче замес был в том, что изначально в Cube я создал HID Class, а не Custom HID Class. Код сгенерился для одной ендпоинт входяшей. В частности, в функции USBD_LL_Init нужно правильно настраивать буфера. Было: HAL_PCDEx_PMAConfig(pdev->pData , 0x00 , PCD_SNG_BUF, 0x18); HAL_PCDEx_PMAConfig(pdev->pData , 0x80 , PCD_SNG_BUF, 0x58); HAL_PCDEx_PMAConfig(pdev->pData , 0x81 , PCD_SNG_BUF, 0x100); Стало: HAL_PCDEx_PMAConfig(pdev->pData , 0x00 , PCD_SNG_BUF, 0x18); HAL_PCDEx_PMAConfig(pdev->pData , 0x80 , PCD_SNG_BUF, 0x58); //HAL_PCDEx_PMAConfig(pdev->pData , 0x81 , PCD_SNG_BUF, 0x100); HAL_PCDEx_PMAConfig(pdev->pData , HID_EPIN_ADDR , PCD_SNG_BUF, 0x98); HAL_PCDEx_PMAConfig(pdev->pData , HID_EPOUT_ADDR , PCD_SNG_BUF, 0xD8); Так что да, "читайте доки - они рулез". Всем спасибо за участие, отбой тревоги.

Есть подозрение на косяки в HAL, в частности регистр BTABLE = 0, соответственно приемный и передающий массивы лежат по адресу 0x4000 6000. Есть подозрение что один накладывается на другой. То есть при инициализации нифига не инициализируется. Буду сегодня детально смотреть регистры :(

Приветствую, Пытаюсь реализовать "эхо" обмена контроллер-комп по 32-байта. Сначала я заполняю массив числами от 0 до 31 и шлю его раз в пять секунд. while (1) { HAL_Delay(5000); USBD_HID_SendReport(&hUsbDeviceFS, OutBuffer, HID_EPIN_SIZE); } Принимаю на компе нормально. Затем я передаю контроллеру массив из всех нулей. В программе приемный массив должен скопироваться в тот, что я отсылаю и по-идее я должен увидеть в обратку массив нулей. static uint8_t USBD_HID_DataOut (USBD_HandleTypeDef *pdev, uint8_t epnum) { if (epnum != (HID_EPOUT_ADDR & 0x0F)) return USBD_FAIL; int8_t i = 0; while (i < HID_EPOUT_SIZE) { OutBuffer[i] = usb_rx_buffer[i]; i++; } USBD_LL_PrepareReceive(pdev, HID_EPOUT_ADDR, usb_rx_buffer, HID_EPOUT_SIZE); return USBD_OK; } Но у меня появляются откуда-то числа 0x20 и 0x40 Дескриптор репорта: { //................................. 0x06, 0xFF, 0xFF, // 04|2 , Usage Page (vendor defined?) 0x09, 0x01, // 08|1 , Usage (vendor defined 0xA1, 0x01, // A0|1 , Collection (Application) //.................................. // IN report 0x09, 0x02, // 08|1 , Usage (vendor defined) 0x09, 0x03, // 08|1 , Usage (vendor defined) 0x15, 0x00, // 14|1 , Logical Minimum(0 for signed byte?) 0x26, 0xFF, 0x00, // 24|1 , Logical Maximum(255 for signed byte?) 0x75, 0x08, // 74|1 , Report Size(8) = field size in bits = 1 byte // 94|1 , ReportCount(size) = repeat count of previous item 0x95,HID_EPIN_SIZE, 0x81, 0x02, // 80|1 , IN report (Data,Variable, Absolute) //.................................... // OUT report 0x09, 0x04, // 08|1 , Usage (vendor defined) 0x09, 0x05, // 08|1 , Usage (vendor defined) 0x15, 0x00, // 14|1 , Logical Minimum(0 for signed byte?) 0x26, 0xFF, 0x00, // 24|1 , Logical Maximum(255 for signed byte?) 0x75, 0x08, // 74|1 , Report Size(8) = field size in bits = 1 byte // 94|1 , ReportCount(size) = repeat count of previous item 0x95, HID_EPOUT_SIZE, 0x91, 0x02, // 90|1 , OUT report (Data,Variable, Absolute) // Feature report 0x09, 0x06, // 08|1 , Usage (vendor defined) 0x09, 0x07, // 08|1 , Usage (vendor defined) 0x15, 0x00, // 14|1 , LogicalMinimum(0 for signed byte) 0x26, 0xFF, 0x00, // 24|1 , Logical Maximum(255 for signed byte) 0x75, 0x08, // 74|1 , Report Size(8) =field size in bits = 1 byte 0x95, HID_EPOUT_SIZE, // 94|x , ReportCount in byte 0xB1, 0x02, // B0|1 , Feature report 0xC0 // C0|0 , End Collection Ставил бряк на функцию USBD_HID_DataOut. Странное дело, но тогда в массиве usb_rx_buffer то же есть эти числа 0x20 и 0x40, но они идут подряд под 22 и 23 номером в массиве. Почему их разносит друг от друга в разные стороны при отправке, и откуда они там вообще берутся? Помогите нубу, плиз

Сия поделка на яве писана, поэтому и тормозит вся, как и все что на яве. Чему удивляться?

Сабж. Как отключить все то, что пытается ёклипсъ делать за меня. Скобки закрывать, скобки в циклах открывать и тд. Бесит люто бешено. Формальное издевательство! Как можно такой продукт выпускать вообще?

Ну как проще.... Для стм - проще, а для шины данных все равно защелку ставить.

Шину адреса не нужно. С этим пусть аппаратный дешифратор справляется. Имхо никакой микроконтроллер с дешифрацией не справится, если он только не на паре гигагерц работает. Навязывание значит... Ну не просто оно так, навязывание-то, а из-за более - менее вменяемого USB OTG у STM'ов. Вот и хотелось красиво обойтись одним МК, а не россыпью мелко-логики из защелок и триггеров, что-бы лишь параллельную шину обслужить. Не то. Оно типа как ведущее, то есть STM32 может чем-то управлять по этой шине (памятью, дисплеем или чем еще). А им управлять не могут. Ага, порвет, хостовую систему, когда случится коллизия на шине данных. BTW, ISA 8 Mhz

Меня даже больше волнует не переслать содержимое по событию в память (запись /WR), а чтение, то есть переслать из памяти в порт, при этом успев сменить направление порта туда-обратно... Так то где-то на хабре была статейка, как STM цепляли к ISA для снифа данных между контроллером HDD и мамкой. Но там все просто - порт все время в режиме input, и как только ext int, то сохраняем содержимое порта в буфер. Плюс, настроить DMA то можно GPIO <-> memory, но как настроить чтоб он еще при этом менял направление порта - вот это вопрос... В общем склоняюсь, что надо вешать внешний регистр-защелку типа 555ИР23, потому что по другому в лоб не решается. А казалось бы, мегагерцы, DMA и вообще пальцы \w/

Ясный пионер, что может. Любой микроконтроллер, который умеет дергать ногами, может прикинуться 8085. Вопрос встает не тогда, когда нужно кого то там дергать, а когда тебя (микроконтроллер) дергают. А именно, когда пришел сигнал чтения /RD, перевести восемь ног из hi z в output, выдать на них байт и уйти по спаду /RD быстренько опять в hi-z. Желательно за детерминированное время, а не как получится. Потому что пару раз может получится, а третий - нет.

Доброго, Вопрос у меня такой - возможно ли на STM32 реализовать ведомый параллельный 8-битный порт? Например подключить STM32 к шине ISA-8bit? У PIC'ов есть классная штука под названием Parallel Slave Port (PSP) - если включить этот режим некоторые ноги становятся сигналами /WR, /RD,/CS и 8-битный PORTD сам в зависимости от состояния этих ног переходит из высокоимпедального состояния в режимы input или output или опять в hi-z. На порту есть встроенная защелка, поэтому особо не важно в какой момент времени произойдет чтение из порта, так как если до этого что-то туда (в порт) было положено - оно и прочитается из защелки. Ну и по прерыванию конечно можно обрабатывать события (запись/чтение). Так вот, возвращаясь к STM32 - есть что-то подобное? Если дергать софтварно, успею ли я за пару наносекунд перевести порт из одного состояния в другой по событию? По грубым прикидкам, на 72Мгц не успею. Да и ARM - он же фиг его знает какие там префечи, кеши и вообще не понятно, за сколько исполнится какая инструкция. Закладываться на большую частоту, > 100 Мгц? А если не софтварно, то как? Вот DCMI в принципе, но... Это ж не совсем то. А может просто кто-то уже реализовывал?

Да, было бы не плохо освободить контроллер от этой задачи, ибо проклятый 1-wire виноват во всех бедах всех контроллеров мира, начиная от таких малышей как PIC12 и заканчивая ARM'ами. В армах то понятно, это все знают, и через костыли с парой транзисторов и UART - уже "стандартное решение", а тут казалось - бы ничего не мешает. Обычная ногодрыжка. Но, есть "нюанс". 400Гц дрыгается нога по таймеру. А в основной программе идет обмен по 1-wire. И ессно нужные интервалы не выдерживаются, ибо успевает сваливаться в прерывание пару-тройку раз, и все времянки летят в тра-тарары. Обошел запрещением прерываний на время обмена по 1-wire. Но и 400Гц уже не 400Гц получается из-за переодического останова. Благо, останов маленький и почти не заметен, но все равно... Не люблю 1-wire, у меня с ним давно вражда. :-E А генератор то сделать отдельный можно, но уже лень. Дык у нашего КР293КП7В, которые я применил, тоже два МОП-реле в одном корпусе. Поэтому у него 8 ног, а не 6, как у большинства. И именно поэтому у меня 7 корпусов на плате, а не 14, как могло бы быть... Спасибо. Финальный вариант термометра: видео http://www.youtube.com/watch?v=EijLOoaUI6A PS: Вообще, спасибо всем участникам, хоть и много комментариев типа "выкинь этот хлам, изучи сначала закон ома", но я еще раз убедился, что есть люди, готовые помочь новичку, с его дурацкими и глупыми вопросами. Программисты мы по профессии, не электронщики, так вот получилось. Но электроника - это гораздо интереснее -)) PSS: Полет нормальный уже около двух недель 24h/7d. Яркость прежняя. Стоят на работе, просто показывают температуру.

До 31-ого были еще советские клоны i8035(ВE35). Это MSC-48 (i8048), тоже без ПЗУ, с 32 байтами ОЗУ. На мой взгляд, контроллер как контроллер, ногами умеет шевелить и ладно. Если есть случайно в гараже вагон таких - можно и ныне заюзать для небольшой поделки.