Вычисляемый переход - проблема

Поклонники продукции Microchip Technology Inc тусуются тут.
Аватара пользователя
Мурик
Друг Кота
Сообщения: 3383
Зарегистрирован: Пн окт 11, 2010 19:00:08

Re: Вычисляемый переход - проблема

Сообщение Мурик »

psw2.ru писал(а):А где там "простота" видна ? Кликать мышей в галки - просто ?
Я про первое сообщение, а не про второе. :)
psw2.ru писал(а):А лично я исходник просил инициализатора платформы (хотяб даже на Си), ну просто поглядеть/скомпилить из любопытства.
Выше я давал ссылку и упоминал про файл system_stm32fxxx.c. http://purebasic.mybb.ru/viewtopic.php?id=575
В первом сообщении есть ссылка на исходники. http://pure-basic.narod.ru/forum_files/stm32/Blink.zip
В архиве найдите файл "Blink\src\system_stm32f10x.c" в котором начальная инициализация. Еще можете посмотреть файл "Blink\src\startup_stm32f10x_md.S" в котором находится таблица прерываний и код выполняемый после сброса.
В system_stm32f10x.c несколько функий под разные частоты. Некоторые их них.
Начальная инициализация.
Спойлер

Код: Выделить всё

/**
  * @brief  Setup the microcontroller system
  *         Initialize the Embedded Flash Interface, the PLL and update the
  *         SystemCoreClock variable.
  * @note   This function should be used only after reset.
  * @param  None
  * @retval None
  */
void SystemInit (void)
{
  /* Reset the RCC clock configuration to the default reset state(for debug purpose) */
  /* Set HSION bit */
  RCC->CR |= (uint32_t)0x00000001;

  /* Reset SW, HPRE, PPRE1, PPRE2, ADCPRE and MCO bits */
#ifndef STM32F10X_CL
  RCC->CFGR &= (uint32_t)0xF8FF0000;
#else
  RCC->CFGR &= (uint32_t)0xF0FF0000;
#endif /* STM32F10X_CL */

  /* Reset HSEON, CSSON and PLLON bits */
  RCC->CR &= (uint32_t)0xFEF6FFFF;

  /* Reset HSEBYP bit */
  RCC->CR &= (uint32_t)0xFFFBFFFF;

  /* Reset PLLSRC, PLLXTPRE, PLLMUL and USBPRE/OTGFSPRE bits */
  RCC->CFGR &= (uint32_t)0xFF80FFFF;

#ifdef STM32F10X_CL
  /* Reset PLL2ON and PLL3ON bits */
  RCC->CR &= (uint32_t)0xEBFFFFFF;

  /* Disable all interrupts and clear pending bits  */
  RCC->CIR = 0x00FF0000;

  /* Reset CFGR2 register */
  RCC->CFGR2 = 0x00000000;
#elif defined (STM32F10X_LD_VL) || defined (STM32F10X_MD_VL) || (defined STM32F10X_HD_VL)
  /* Disable all interrupts and clear pending bits  */
  RCC->CIR = 0x009F0000;

  /* Reset CFGR2 register */
  RCC->CFGR2 = 0x00000000;
#else
  /* Disable all interrupts and clear pending bits  */
  RCC->CIR = 0x009F0000;
#endif /* STM32F10X_CL */

#if defined (STM32F10X_HD) || (defined STM32F10X_XL) || (defined STM32F10X_HD_VL)
  #ifdef DATA_IN_ExtSRAM
    SystemInit_ExtMemCtl();
  #endif /* DATA_IN_ExtSRAM */
#endif

  /* Configure the System clock frequency, HCLK, PCLK2 and PCLK1 prescalers */
  /* Configure the Flash Latency cycles and enable prefetch buffer */
  SetSysClock();

/* We disable the vector table mapping if we actively debug because we are doing this in our
** debugger script. By doing this in the debugger script, we can switch between flash or ram execution.
** For the release version, please enable the code below by undefining __DONT_INIT_VTABLE
*/

  /* Configure the Vector Table location add offset address ------------------*/
  /* If you work ith the STlink for debug, please don't use this.             */
#ifndef __DONT_INIT_VTABLE
    #ifdef VECT_TAB_SRAM
        SCB->VTOR = SRAM_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal SRAM */
    #else
        SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH */
    #endif
#else
#warning For release version do not use __DONT_INIT_VTABLE (see above).
#endif
}
Переключение с RC генератора (HSI) на кварц (HSE) и настройка умножителя частоты чтобы получить частоту 72 МГц при частоте кварца 8 МГц.
Спойлер

Код: Выделить всё

/**
  * @brief  Sets System clock frequency to 72MHz and configure HCLK, PCLK2
  *         and PCLK1 prescalers.
  * @note   This function should be used only after reset.
  * @param  None
  * @retval None
  */
static void SetSysClockTo72(void)
{
  __IO uint32_t StartUpCounter = 0, HSEStatus = 0;

  /* SYSCLK, HCLK, PCLK2 and PCLK1 configuration ---------------------------*/
  /* Enable HSE */
  RCC->CR |= ((uint32_t)RCC_CR_HSEON);

  /* Wait till HSE is ready and if Time out is reached exit */
  do
  {
    HSEStatus = RCC->CR & RCC_CR_HSERDY;
    StartUpCounter++;
  } while((HSEStatus == 0) && (StartUpCounter != HSE_STARTUP_TIMEOUT));

  if ((RCC->CR & RCC_CR_HSERDY) != RESET)
  {
    HSEStatus = (uint32_t)0x01;
  }
  else
  {
    HSEStatus = (uint32_t)0x00;
  }

  if (HSEStatus == (uint32_t)0x01)
  {
    /* Enable Prefetch Buffer */
    FLASH->ACR |= FLASH_ACR_PRFTBE;

    /* Flash 2 wait state */
    FLASH->ACR &= (uint32_t)((uint32_t)~FLASH_ACR_LATENCY);
    FLASH->ACR |= (uint32_t)FLASH_ACR_LATENCY_2;


    /* HCLK = SYSCLK */
    RCC->CFGR |= (uint32_t)RCC_CFGR_HPRE_DIV1;

    /* PCLK2 = HCLK */
    RCC->CFGR |= (uint32_t)RCC_CFGR_PPRE2_DIV1;

    /* PCLK1 = HCLK */
    RCC->CFGR |= (uint32_t)RCC_CFGR_PPRE1_DIV2;

#ifdef STM32F10X_CL
    /* Configure PLLs ------------------------------------------------------*/
    /* PLL2 configuration: PLL2CLK = (HSE / 5) * 8 = 40 MHz */
    /* PREDIV1 configuration: PREDIV1CLK = PLL2 / 5 = 8 MHz */

    RCC->CFGR2 &= (uint32_t)~(RCC_CFGR2_PREDIV2 | RCC_CFGR2_PLL2MUL |
                              RCC_CFGR2_PREDIV1 | RCC_CFGR2_PREDIV1SRC);
    RCC->CFGR2 |= (uint32_t)(RCC_CFGR2_PREDIV2_DIV5 | RCC_CFGR2_PLL2MUL8 |
                             RCC_CFGR2_PREDIV1SRC_PLL2 | RCC_CFGR2_PREDIV1_DIV5);

    /* Enable PLL2 */
    RCC->CR |= RCC_CR_PLL2ON;
    /* Wait till PLL2 is ready */
    while((RCC->CR & RCC_CR_PLL2RDY) == 0)
    {
    }


    /* PLL configuration: PLLCLK = PREDIV1 * 9 = 72 MHz */
    RCC->CFGR &= (uint32_t)~(RCC_CFGR_PLLXTPRE | RCC_CFGR_PLLSRC | RCC_CFGR_PLLMULL);
    RCC->CFGR |= (uint32_t)(RCC_CFGR_PLLXTPRE_PREDIV1 | RCC_CFGR_PLLSRC_PREDIV1 |
                            RCC_CFGR_PLLMULL9);
#else
    /*  PLL configuration: PLLCLK = HSE * 9 = 72 MHz */
    RCC->CFGR &= (uint32_t)((uint32_t)~(RCC_CFGR_PLLSRC | RCC_CFGR_PLLXTPRE |
                                        RCC_CFGR_PLLMULL));
    RCC->CFGR |= (uint32_t)(RCC_CFGR_PLLSRC_HSE | RCC_CFGR_PLLMULL9);
#endif /* STM32F10X_CL */

    /* Enable PLL */
    RCC->CR |= RCC_CR_PLLON;

    /* Wait till PLL is ready */
    while((RCC->CR & RCC_CR_PLLRDY) == 0)
    {
    }

    /* Select PLL as system clock source */
    RCC->CFGR &= (uint32_t)((uint32_t)~(RCC_CFGR_SW));
    RCC->CFGR |= (uint32_t)RCC_CFGR_SW_PLL;

    /* Wait till PLL is used as system clock source */
    while ((RCC->CFGR & (uint32_t)RCC_CFGR_SWS) != (uint32_t)0x08)
    {
    }
  }
  else
  { /* If HSE fails to start-up, the application will have wrong clock
         configuration. User can add here some code to deal with this error */
  }
}
Этот код самому писать не нужно. Он автоматически добавляется при создании проекта. Для упрощения подбора тактовой частоты в файле есть строки

Код: Выделить всё

/* #define SYSCLK_FREQ_HSE    HSE_VALUE */
/* #define SYSCLK_FREQ_24MHz  24000000 */
/* #define SYSCLK_FREQ_36MHz  36000000 */
/* #define SYSCLK_FREQ_48MHz  48000000 */
/* #define SYSCLK_FREQ_56MHz  56000000 */
#define SYSCLK_FREQ_72MHz  72000000
Какая будет раскомментирована, ту частоту и получим.
Чтобы было понятней, картинка с настройками тактирования. Читайте комментарии в коде и смотрите картинку.
СпойлерИзображение
STM32F103_Clock.png
(98.96 КБ) 85 скачиваний
Управлять тактированием можно во время работы МК. http://purebasic.mybb.ru/viewtopic.php?id=583

Код: Выделить всё

void Overclocking(void) // Разгон микроконтроллера.
{
  RCC_HSICmd(ENABLE); // Включаем внутренний RC генератор.
  RCC_SYSCLKConfig(RCC_SYSCLKSource_HSI); // Выбираем источником такторования внутренний RC генератор.
  RCC_PLLCmd(DISABLE); // Выключаем умножитель частоты.
  RCC_PLLConfig(RCC_PLLSource_HSE, RCC_CFGR_PLLMULL12); // На сколько будем умножать частоту.
  RCC_PLLCmd(ENABLE); // Включаем умножитель частоты.
  while ((RCC->CR & RCC_CR_PLLRDY) == 0);     // Ждем запуска умножителя частоты.
  RCC_SYSCLKConfig(RCC_SYSCLKSource_PLLCLK); // Выбираем источником такторования умножитель частоты.

  SystemCoreClockUpdate(); // Вычисление тактовой частоты ядра.
}
psw2.ru писал(а):Ибо все эти уровни привилегий/диспетчеры памяти - штука тёмная для лично меня.
STM32 это микроконтроллеры, а не микропроцессоры, т. е. ядро Cortex-M, а не Cortex-A. https://ru.wikipedia.org/wiki/ARM_(архи ... ессоры_ARM
В них нет таких сложностей. Самые обычные МК.
psw2.ru писал(а):АутоматишКодеКонфигуратор с галками такого не предлагает, нет такой иконки ?Но "простота" - манит ?
Код нужно писать, а не мышкотыкать!
psw2.ru писал(а):А фантастические заявления пенсионера типа "я разобрался с USB - там всё просто - втыкай и работает" - легко прерываются вопросом типа "а подскажите формат дескриптора для HID" например.И воспевание интеллекта обезъяны, которая самостоятельно разобралась что при нажатии картинки "банан" в лоток снизу падает реальный банан - ну, достойно простоты, согласен.
Это из собственного опыта?
psw2.ru писал(а):Какой смысл соблазнять лично меня ресурсами платформы, которую лично я не могу инициализировать ?
Начальную инициализацию производить не нужно. Код написал производителем МК. Разве что нужно подобрать коэффициенты умножителей и делителей, но это математика на уровне 5 класса. Настройка периферии тоже не сложная (например используя библиотеку SPL) и в сети можно найти примеры.
Нужно изучать платформу, ведь изначально мы даже ходить и говорить не умели не говоря о другом и всему приходилось учится.
psw2.ru писал(а):И что, прям все выводы 25/25 мА или только 8 штук ?
Все, но есть ограничение на общий ток потребления. Если не ошибаюсь 150 мА, но может быть больше в зависимости от модели МК.
psw2.ru писал(а):Ой, простите, оно бортовой аппаратный USART жрёт вместо чисто программной обработки.
Разве не знаете что программная работа не совсем совместима с прерываниями? Это можно обойти, но если задача простая и есть свободные USART, то почему его не использовать? Например в STM32F103C8T6 есть 3 USART. В STM32F103RET6 есть 3 USART и 2 UART.
Использование USART совместно с DMA также позволяет опрашивать датчики в одной из задач RTOS что позволяет минимизировать ресурсы затрачиваемые на опрос. Как вы будете программно опрашивать датчик в многозадачной среде, где выполнение задачи может быть прервано в любой момент?
psw2.ru писал(а):И парочка транзисторов/паек на макетке для объединения TX+RX в один провод - тоже стоит денег/места на платке.
В STM32 это не нужно. USART может работать в полудуплексном режиме используя один вывод и выход TXD можно настроить на работу с открытым коллектором.
Реклама
psw2.ru
Нашел транзистор. Понюхал.
Сообщения: 151
Зарегистрирован: Пт мар 02, 2018 13:47:57

Re: Вычисляемый переход - проблема

Сообщение psw2.ru »

[uquote="BOB51",url="/forum/viewtopic.php?p=3496355#p3496355"]Ну уж не такой и "абсолютист" - ассемблеру свое, ЯВУ - свое.
Просто до систем-на кристалле[/uquote]
Дочитал ту тему до искры и ПИК12Ф629.
Лично я лет 15 назад писал зажигу для 50 кубиков ДВС на 8 ног Пик12Ф683 с регулировкой базового угла и времени горения смеси 2 переменниками, датчиком от штатного 4 полюса гены и прямым управлением IGBT транзистором irgs14c40l ногой ПИКа.
Прожект до внедрения доведён не был, но хлопот с искрой на стенде я видал нормально.
Кроме глюков/сбросов - были защёлкивания внутри ПИКа с разогревом мелкопроца до синего каления.
Но в итоге искровые глюки были как-то побеждены, макетка той зажиги провалялась несколько лет, а теперь исправно поджигает отработку в самодельной печке знакомого уже пару годов в режиме автогенерации с управляемой частотой/скважностью импульсов.
Реклама
Аватара пользователя
КРАМ
Друг Кота
Сообщения: 25291
Зарегистрирован: Чт янв 10, 2008 22:01:02
Откуда: Московская область, Фрязино

Re: Вычисляемый переход - проблема

Сообщение КРАМ »

[uquote="psw2.ru",url="/forum/viewtopic.php?p=3496350#p3496350"]А фантастические заявления пенсионера типа "я разобрался с USB - там всё просто - втыкай и работает" - легко прерываются вопросом типа "а подскажите формат дескриптора для HID" например.
И воспевание интеллекта обезъяны, которая самостоятельно разобралась что при нажатии картинки "банан" в лоток снизу падает реальный банан - ну, достойно простоты, согласен.[/uquote]
Очень трудно комментировать этот бессмысленный набор слов.
Но рискну.
1. Я пенсионером стану только через 2 года.
2. "а подскажите формат дескриптора для HID" - говорит нам о том, что Вы не понимаете о чем говорите. Дескрипторы (а не дескриптор) класса входят в библиотечный исходник в виде части файла usb_descriptors.c
Спойлер/********************************************************************
FileName: usb_descriptors.c
Dependencies: See INCLUDES section
Processor: PIC18 or PIC24 USB Microcontrollers
Hardware: The code is natively intended to be used on the following
hardware platforms: PICDEM™ FS USB Demo Board,
PIC18F87J50 FS USB Plug-In Module, or
Explorer 16 + PIC24 USB PIM. The firmware may be
modified for use on other USB platforms by editing the
HardwareProfile.h file.
Complier: Microchip C18 (for PIC18) or C30 (for PIC24)
Company: Microchip Technology, Inc.

Software License Agreement:

The software supplied herewith by Microchip Technology Incorporated
(the “Company”) for its PIC® Microcontroller is intended and
supplied to you, the Company’s customer, for use solely and
exclusively on Microchip PIC Microcontroller products. The
software is owned by the Company and/or its supplier, and is
protected under applicable copyright laws. All rights are reserved.
Any use in violation of the foregoing restrictions may subject the
user to criminal sanctions under applicable laws, as well as to
civil liability for the breach of the terms and conditions of this
license.

THIS SOFTWARE IS PROVIDED IN AN “AS IS” CONDITION. NO WARRANTIES,
WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING, BUT NOT LIMITED
TO, IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE APPLY TO THIS SOFTWARE. THE COMPANY SHALL NOT,
IN ANY CIRCUMSTANCES, BE LIABLE FOR SPECIAL, INCIDENTAL OR
CONSEQUENTIAL DAMAGES, FOR ANY REASON WHATSOEVER.

*********************************************************************
-usb_descriptors.c-
-------------------------------------------------------------------
Filling in the descriptor values in the usb_descriptors.c file:
-------------------------------------------------------------------

[Device Descriptors]
The device descriptor is defined as a USB_DEVICE_DESCRIPTOR type.
This type is defined in usb_ch9.h Each entry into this structure
needs to be the correct length for the data type of the entry.

[Configuration Descriptors]
The configuration descriptor was changed in v2.x from a structure
to a BYTE array. Given that the configuration is now a byte array
each byte of multi-byte fields must be listed individually. This
means that for fields like the total size of the configuration where
the field is a 16-bit value "64,0," is the correct entry for a
configuration that is only 64 bytes long and not "64," which is one
too few bytes.

The configuration attribute must always have the _DEFAULT
definition at the minimum. Additional options can be ORed
to the _DEFAULT attribute. Available options are _SELF and _RWU.
These definitions are defined in the usb_device.h file. The
_SELF tells the USB host that this device is self-powered. The
_RWU tells the USB host that this device supports Remote Wakeup.

[Endpoint Descriptors]
Like the configuration descriptor, the endpoint descriptors were
changed in v2.x of the stack from a structure to a BYTE array. As
endpoint descriptors also has a field that are multi-byte entities,
please be sure to specify both bytes of the field. For example, for
the endpoint size an endpoint that is 64 bytes needs to have the size
defined as "64,0," instead of "64,"

Take the following example:
// Endpoint Descriptor //
0x07, //the size of this descriptor //
USB_DESCRIPTOR_ENDPOINT, //Endpoint Descriptor
_EP02_IN, //EndpointAddress
_INT, //Attributes
0x08,0x00, //size (note: 2 bytes)
0x02, //Interval

The first two parameters are self-explanatory. They specify the
length of this endpoint descriptor (7) and the descriptor type.
The next parameter identifies the endpoint, the definitions are
defined in usb_device.h and has the following naming
convention:
_EP<##>_<dir>
where ## is the endpoint number and dir is the direction of
transfer. The dir has the value of either 'OUT' or 'IN'.
The next parameter identifies the type of the endpoint. Available
options are _BULK, _INT, _ISO, and _CTRL. The _CTRL is not
typically used because the default control transfer endpoint is
not defined in the USB descriptors. When _ISO option is used,
addition options can be ORed to _ISO. Example:
_ISO|_AD|_FE
This describes the endpoint as an isochronous pipe with adaptive
and feedback attributes. See usb_device.h and the USB
specification for details. The next parameter defines the size of
the endpoint. The last parameter in the polling interval.

-------------------------------------------------------------------
Adding a USB String
-------------------------------------------------------------------
A string descriptor array should have the following format:

rom struct{byte bLength;byte bDscType;word string[size];}sdxxx={
sizeof(sdxxx),DSC_STR,<text>};

The above structure provides a means for the C compiler to
calculate the length of string descriptor sdxxx, where xxx is the
index number. The first two bytes of the descriptor are descriptor
length and type. The rest <text> are string texts which must be
in the unicode format. The unicode format is achieved by declaring
each character as a word type. The whole text string is declared
as a word array with the number of characters equals to <size>.
<size> has to be manually counted and entered into the array
declaration. Let's study this through an example:
if the string is "USB" , then the string descriptor should be:
(Using index 02)
rom struct{byte bLength;byte bDscType;word string[3];}sd002={
sizeof(sd002),DSC_STR,'U','S','B'};

A USB project may have multiple strings and the firmware supports
the management of multiple strings through a look-up table.
The look-up table is defined as:
rom const unsigned char *rom USB_SD_Ptr[]={&sd000,&sd001,&sd002};

The above declaration has 3 strings, sd000, sd001, and sd002.
Strings can be removed or added. sd000 is a specialized string
descriptor. It defines the language code, usually this is
US English (0x0409). The index of the string must match the index
position of the USB_SD_Ptr array, &sd000 must be in position
USB_SD_Ptr[0], &sd001 must be in position USB_SD_Ptr[1] and so on.
The look-up table USB_SD_Ptr is used by the get string handler
function.

-------------------------------------------------------------------

The look-up table scheme also applies to the configuration
descriptor. A USB device may have multiple configuration
descriptors, i.e. CFG01, CFG02, etc. To add a configuration
descriptor, user must implement a structure similar to CFG01.
The next step is to add the configuration descriptor name, i.e.
cfg01, cfg02,.., to the look-up table USB_CD_Ptr. USB_CD_Ptr[0]
is a dummy place holder since configuration 0 is the un-configured
state according to the definition in the USB specification.

********************************************************************/

/*********************************************************************
* Descriptor specific type definitions are defined in:
* usb_device.h
*
* Configuration options are defined in:
* usb_config.h
********************************************************************/
#ifndef __USB_DESCRIPTORS_C
#define __USB_DESCRIPTORS_C

/** INCLUDES *******************************************************/
#include "./USB/usb.h"
#include "./USB/usb_function_hid.h"

/** CONSTANTS ******************************************************/
#if defined(__18CXX)
#pragma romdata
#endif

/* Device Descriptor */
ROM USB_DEVICE_DESCRIPTOR device_dsc=
{
0x12, // Size of this descriptor in bytes
USB_DESCRIPTOR_DEVICE, // DEVICE descriptor type = 0x01
0x0200, // USB Spec Release Number in BCD format
0x00, // Class Code
0x00, // Subclass code
0x00, // Protocol code
USB_EP0_BUFF_SIZE, // Max packet size for EP0, see usb_config.h =0x08
0x04D8, // Vendor ID
0x003F, // Product ID: Custom HID device demo
0x0001, // Device release number in BCD format
0x01, // Manufacturer string index
0x02, // Product string index
0x00, // Device serial number string index
0x01 // Number of possible configurations
};

/* Configuration 1 Descriptor */
ROM BYTE configDescriptor1[]={
/* Configuration Descriptor */
0x09,//sizeof(USB_CFG_DSC), // Size of this descriptor in bytes
USB_DESCRIPTOR_CONFIGURATION, // CONFIGURATION descriptor type = 0x02
0x29,0x00, // Total length of data for this cfg
1, // Number of interfaces in this cfg
1, // Index value of this configuration
0, // Configuration string index
_DEFAULT | _SELF, // Attributes, see usb_device.h
50, // Max power consumption (2X mA)

/* Interface Descriptor */
0x09,//sizeof(USB_INTF_DSC), // Size of this descriptor in bytes
USB_DESCRIPTOR_INTERFACE, // INTERFACE descriptor type = 0x04
0, // Interface Number
0, // Alternate Setting Number
2, // Number of endpoints in this intf
HID_INTF, // Class code = 0x03
0, // Subclass code
0, // Protocol code
0, // Interface string index

/* HID Class-Specific Descriptor */
0x09,//sizeof(USB_HID_DSC)+3, // Size of this descriptor in bytes
DSC_HID, // HID descriptor type , #define DSC_HID 0x21
0x11,0x01, // HID Spec Release Number in BCD format (1.11)
0x00, // Country Code (0x00 for Not supported)
HID_NUM_OF_DSC, // Number of class descriptors, see usbcfg.h = 1
DSC_RPT, // Report descriptor type
HID_RPT01_SIZE,0x00,//sizeof(hid_rpt01), // Size of the report descriptor = 28

/* Endpoint Descriptor */
0x07,/*sizeof(USB_EP_DSC)*/
USB_DESCRIPTOR_ENDPOINT, //Endpoint Descriptor
HID_EP | _EP_IN, //EndpointAddress = 1|0x80 = 0x81
_INTERRUPT, //Attributes = 0x03
0x40,0x00, //size
0x01, //Interval 5ms

/* Endpoint Descriptor */
0x07,/*sizeof(USB_EP_DSC)*/
USB_DESCRIPTOR_ENDPOINT, //Endpoint Descriptor = 0x05
HID_EP | _EP_OUT, //EndpointAddress = 1|0x00=0x01
_INTERRUPT, //Attributes = 0x03
0x40,0x00, //size
0x01 //Interval 5ms
};

//Language code string descriptor
ROM struct{BYTE bLength;BYTE bDscType;WORD string[1];}sd000={
sizeof(sd000),USB_DESCRIPTOR_STRING,{0x0409
}};

//Manufacturer string descriptor
ROM struct{BYTE bLength;BYTE bDscType;WORD string[25];}sd001={
sizeof(sd001),USB_DESCRIPTOR_STRING,
{'M','i','c','r','o','c','h','i','p',' ',
'T','e','c','h','n','o','l','o','g','y',' ','I','n','c','.'
}};




//Product string descriptor
ROM struct{BYTE bLength;BYTE bDscType;WORD string[28];}sd002={
sizeof(sd002),USB_DESCRIPTOR_STRING,
{'H','I','D','-','U','S','B',' ',' ',' ',' ',
'D','e','v','i','c','e',' ','N','N','N','N','N','N','N',', ','1','4'
}};


//Class specific descriptor - HID
ROM struct{BYTE report[HID_RPT01_SIZE];}hid_rpt01={
{
0x06, 0x00, 0xFF, // Usage Page = 0xFF00 (Vendor Defined Page 1)
0x09, 0x01, // Usage (Vendor Usage 1)
0xA1, 0x01, // Collection (Application)
0x19, 0x01, // Usage Minimum
0x29, 0x40, // Usage Maximum //64 input usages total (0x01 to 0x40)
0x15, 0x01, // Logical Minimum (data bytes in the report may have minimum value = 0x00)
0x25, 0x40, // Logical Maximum (data bytes in the report may have maximum value = 0x00FF = unsigned 255)
0x75, 0x08, // Report Size: 8-bit field size
0x95, 0x40, // Report Count: Make sixty-four 8-bit fields (the next time the parser hits an "Input", "Output", or "Feature" item)
0x81, 0x00, // Input (Data, Array, Abs): Instantiates input packet fields based on the above report size, count, logical min/max, and usage.
0x19, 0x01, // Usage Minimum
0x29, 0x40, // Usage Maximum //64 output usages total (0x01 to 0x40)
0x91, 0x00, // Output (Data, Array, Abs): Instantiates output packet fields. Uses same report size and count as "Input" fields, since nothing new/different was specified to the parser since the "Input" item.
0xC0} // End Collection
};


//Array of configuration descriptors
ROM BYTE *ROM USB_CD_Ptr[]=
{
(ROM BYTE *ROM)&configDescriptor1
};

//Array of string descriptors
ROM BYTE *ROM USB_SD_Ptr[]=
{
(ROM BYTE *ROM)&sd000,
(ROM BYTE *ROM)&sd001,
(ROM BYTE *ROM)&sd002
};

/** EOF usb_descriptors.c ***************************************************/

#endif
3. Библиотека Микрочипа (MLA/MAL) никаких кнопок с бананами не содержит. Это просто систематизированный набор исходных файлов проекта и отдельно темплейты - примеры собранных проектов , которые можно править под себя, одновременно разбираясь в механизме работы стека.

Добавлено after 3 minutes 54 seconds:
[uquote="psw2.ru",url="/forum/viewtopic.php?p=3496391#p3496391"]Кроме глюков/сбросов - были защёлкивания внутри ПИКа с разогревом мелкопроца до синего каления.[/uquote]
Это к вопросу об опторазвязках и "схемотехнике" в которой пины управляют силой напрямую.... :wink: :tea: :)))
Последний раз редактировалось КРАМ Чт ноя 01, 2018 16:12:55, всего редактировалось 1 раз.
psw2.ru
Нашел транзистор. Понюхал.
Сообщения: 151
Зарегистрирован: Пт мар 02, 2018 13:47:57

Re: Вычисляемый переход - проблема

Сообщение psw2.ru »

[uquote="Мурик",url="/forum/viewtopic.php?p=3496388#p3496388"]В первом сообщении есть ссылка на исходники. http://pure-basic.narod.ru/forum_files/stm32/Blink.zip
В архиве найдите файл[/uquote]
Вот спасибо, с такими помошниками прям вот хочу-хочу купить тех платок STM32 на алишечке в коллекцию для морганий светодиодами и хотяб попытки переноса буратины на новую платформу.
Ибо такой перенос - времени возьмёт кучу, согласен.
[uquote="Мурик",url="/forum/viewtopic.php?p=3496388#p3496388"]
psw2.ru писал(а):Ибо все эти уровни привилегий/диспетчеры памяти - штука тёмная для лично меня.
STM32 это микроконтроллеры, а не микропроцессоры, т. е. ядро Cortex-M, а не Cortex-A.
В них нет таких сложностей. Самые обычные МК.[/uquote]
А лично мне читая доки на проц из платки - показалось что есть.
[uquote="Мурик",url="/forum/viewtopic.php?p=3496388#p3496388"]Как вы будете программно опрашивать датчик в многозадачной среде, где выполнение задачи может быть прервано в любой момент?[/uquote]
Какой "задачи" ? У лично меня критическим к времени является реакция на высоко приоритетное прерывание от таймера генерации задержек протокола 1-варе.
Согласен, если потребуется ещё высоко приоритетный обработчик - то будут столкновения прерываний, пробовал уже накопитель АЦП делать высоко приоритетным.
Но с контролем CRC это сводится лишь к не прочтению одного из датчиков иногда на Пик18, в котором лишь 2 уровня приоритетов прерываний.
Но в защиту чисто программного метода обмена по 1-варе (кажется четыре прерывания на бит инфы у лично меня в ПИК-18 с его устаревшими 12 МИПСами) - работают заявления "210 МИПС" и "это микроконтроллеры, а не микропроцессоры" - полноценной ОС с загружаемыми на ходу приложениями там не предвидится. Ну и приоритетов прерываний в СТМ32 поболее чем 2, кажется.
Но время реакции - дольше, ибо контекст спасается большой.
[uquote="КРАМ",url="/forum/viewtopic.php?p=3496395#p3496395"]2. "а подскажите формат дескриптора для HID" - говорит нам о том, что Вы не понимаете о чем говорите.[/uquote]
Так и есть, я же сразу сказал что "читаю Си со словарём".
А когда лично я переделал/добавил оси в USB-HID из mchpfsusb_setup.exe и опубликовал на РЦ-Дизайне джойстик кажется 8 осей году эдак в 2007 - вот именно тогда лично я как обезъяна в тот usbdsc.c и пялился, пытаясь понять как оно и модифицировать чутка для целей моделизма/авиасимуляторов.
[uquote="КРАМ",url="/forum/viewtopic.php?p=3496395#p3496395"]Это к вопросу об опторазвязках и "схемотехнике" в которой пины управляют силой напрямую....[/uquote]
То был опыт - сын ошибок трудных. И сегодня - работает, БЕЗ опторазвязок.
Ну пока что работает, а там - поглядим.
Реклама
Эиком - электронные компоненты и радиодетали
Аватара пользователя
Мурик
Друг Кота
Сообщения: 3383
Зарегистрирован: Пн окт 11, 2010 19:00:08

Re: Вычисляемый переход - проблема

Сообщение Мурик »

psw2.ru писал(а):А лично мне читая доки на проц из платки - показалось что есть.
Может неправильно поняли. Прочитайте для начала об устройстве МК. https://sunduk.radiokot.ru/loadfile/?load_id=1373389648
psw2.ru писал(а):Какой "задачи" ?
https://ru.wikipedia.org/wiki/Операцион ... ние_задачи
Речь про многозадачность (многопоточность) как в компе.
psw2.ru писал(а):пробовал уже накопитель АЦП делать высоко приоритетным.
Если нужно регулярно измерять аналоговый сигнал, в STM32 и других подобных МК настраивают таймер на нужный интервал опроса и по его переполнению автоматически запускается АЦП и по окончанию измерения результат копируется в массив с помощью DMA. По заполнению массива или его половины происходит прерывание от DMA. Таким образом можно уменьшить частоту прерываний и обработчик может быть низкоприоритетным.

psw2.ru писал(а):Но время реакции - дольше, ибо контекст спасается большой.
12 тактов если выполнялся основной код и 6 если произошло более приоритетное прерывание при обработке низкоприоритетного. При этом аппартано сохраняются регистры, а в PICе можно нужно делать программно, хотя там несколько помню только аккумулятор и все. В ARM регистров больше.
Реклама
psw2.ru
Нашел транзистор. Понюхал.
Сообщения: 151
Зарегистрирован: Пт мар 02, 2018 13:47:57

Re: Вычисляемый переход - проблема

Сообщение psw2.ru »

[uquote="Мурик",url="/forum/viewtopic.php?p=3496411#p3496411"]Если нужно регулярно измерять аналоговый сигнал, в STM32 и других подобных МК настраивают таймер на нужный интервал опроса и по его переполнению автоматически запускается АЦП и по окончанию измерения результат копируется в массив с помощью DMA. По заполнению массива или его половины происходит прерывание от DMA. Таким образом можно уменьшить частоту прерываний и обработчик может быть низкоприоритетным.[/uquote]
Ну вот именно в 18Ф4431 - и буфер ФИФО для АЦП микрочипы сделали, и автомат преобразование с указанным интервалом.
А в более продвинутых есть "преобразовать и прибавить", кажется. Ибо копить в ОЗУ все измерения индивидуально - смысл конечно есть если стат обработку делать какую-то.
Ладно, я понял что новое лучше старого, сегодня.
Но пока такие как лично я будут адаптировать собственные хотелки под новые веяния - команды яйцеголовых придумают ещё более новое, а сегодняшнее "новое" - станет старым.
И эта музыка будет вечной, ну если я заменю батарейки.
Так стоит ли гнаться за беличьим колесом в бесконечность ?
Ну если можно тихо и спокойно не спеша пилить Z80 например лет 40 кряду ?
Да, в тёплом ламповом ДИП-40 корпусе, припаянном проводками МГТФ к работающей буратине.
Повторяя для самоуспокоения слова "разумная достаточность" и "минимальное, но необходимое".
Реклама
psw2.ru
Нашел транзистор. Понюхал.
Сообщения: 151
Зарегистрирован: Пт мар 02, 2018 13:47:57

Re: Вычисляемый переход - проблема

Сообщение psw2.ru »

[uquote="BOB51",url="/forum/viewtopic.php?p=3496355#p3496355"]Жаль тренироваться не над чем... Все, чего интересно уже вроде соорудил, а местный народ даже "надурняк" участвовать в работах вида "детали/сборка/баблосики Ваши, схема прожка наши" не особо желает (или запросы не по имеющемуся уровню).
Да и ЛЕЕНЬ... - спешить/удивлять кого незачем, пенсия и так УЖЕ идет.[/uquote]
Дочитал ту тему до академических исследований искры на мозги. Похвальная глубина, согласен.
Лично я так глубоко даже и не думал копать, всё заработало чисто механически - макет был собран на радиаторе из металлолома, у которого тонкая пластина и навершие рёбер сверху.
Для борьбы с помехами кроме керамики везде - лично я использовал следующие меры:
1. тупо перенёс 12Ф683 на другую сторону радиатора, ноги сквозь дыры в пластине, высоты панельки аккурат хватило. Подальше от всяких источников ВЧ наводок.
В итоге на одной стороне была повышающая схема 12-200 вольт (автогенератор и транс от какого-то БП компа маломощного, и даже кажется были попытки ШИМ от 683 туда использовать) которая потом не использовалась, ибо волговская 2 рога катушка работала и от 12 вольт, был силовой ключ и прочая схема, а на второй - корпус ДИП-8 с ногами через люминь.
2. Взамен однорогой катушки от жыги, у которой ВВ объединена с первичкой одним концом и которая использовалась при испытаниях/отладке/подвисах/защёлкиваниях - взял двурогую от волги с полной гальваноразвязкой ВВ и первички. Запальные электроды котлов сплошь и рядом парные/симметричные - сами просятся на двурогую катушку.
3. Вместо КРЕН5 использовал маломощный стаб с током КЗ 200 мА для питания схемы - защёлкивания мозга с неконтролируемым дымом прекратились даже при искрении рядом с мозгами.
4. Свивка проводов к катушке и от катушки к искровому промежутку тоже использована была.
Как итог - "схема" (навесным монтажом) работала на тестах часами и после нескольких лет отлёжки в сырости и бардаке - до сих пор успешно поджигает отработку в самодельной горелке котла отопления.
И кстати - тот прожект зажиги хоть и не дорос до внедрения - но 50 кубиков двигло на нём всё-таки заводилось несколько раз для тестирования.
Да, были арифметические ошибки в вычислителе - борьба с переносом на ПИКах не так проста для лично меня. Но тем не менее - допилить тот прожект, тем более на ПИК18 с учётом прокачанного за годы скила - вполне реально.
Аватара пользователя
КРАМ
Друг Кота
Сообщения: 25291
Зарегистрирован: Чт янв 10, 2008 22:01:02
Откуда: Московская область, Фрязино

Re: Вычисляемый переход - проблема

Сообщение КРАМ »

[uquote="psw2.ru",url="/forum/viewtopic.php?p=3496847#p3496847"]3. Вместо КРЕН5 использовал маломощный стаб с током КЗ 200 мА для питания схемы - защёлкивания мозга с неконтролируемым дымом прекратились[/uquote]
Такое ощущение, что физику защелкивания Вы не понимаете от слова совсем.
Защелкивание происходит ТОЛЬКО от выхода ВХОДНЫХ напряжений за диапазон питания. То есть они выше питания и ниже земли. Точнее, более чем на 0,3 Вольта выходят за этот диапазон. Поэтому все что требовалось - на все входы повесить по последовательному резистору и на сами пины - ВНЕШНЮЮ диодную (Шоттки) растяжку. Протекание тока по внутренней диодной растяжке образованной паразитными диодами КМОП структур и вызывает то самое защелкивание. Ну и добавить супресор по питанию МК, чтобы защитить его от бросков напряжения связанных с импульсами тока через внешнюю диодную растяжку.
Остальные Ваши шаманства к проблеме не имеют никакого отношения.
psw2.ru
Нашел транзистор. Понюхал.
Сообщения: 151
Зарегистрирован: Пт мар 02, 2018 13:47:57

Re: Вычисляемый переход - проблема

Сообщение psw2.ru »

[uquote="КРАМ",url="/forum/viewtopic.php?p=3498392#p3498392"]Защелкивание происходит ... от выхода ВХОДНЫХ напряжений за диапазон питания.
... на все входы повесить по последовательному резистору и на сами пины - ВНЕШНЮЮ диодную (Шоттки) растяжку.
Протекание тока по внутренней диодной растяжке образованной паразитными диодами КМОП структур и вызывает то самое защелкивание.
Ну и добавить супресор по питанию МК, чтобы защитить его от бросков напряжения связанных с импульсами тока через внешнюю диодную растяжку.[/uquote]
Спасибо за разъяснения/возможные методы решения подобных проблем.
[uquote="КРАМ",url="/forum/viewtopic.php?p=3498392#p3498392"]на все входы повесить по последовательному резистору[/uquote]
Какого именно номинала резисторы надо повесить для защиты входа Pic от искры ?
И кстати, был у лично меня ещё казус с макеткой/искрой/ДВС.
В 2012 году лично я пытался сделать систему сбора данных с ДВС авто в реальном времени с посылкой на комп через USB-CDC эмулятор ком-порта на Pic18F27J53.
Ну там кроме GPS данных от внешнего приёмника с USART подмешивались ещё данные времени с захватчиков/и аналоговые АЦП каналы.
Хотелось длительность открытого состояния 6 штук форсунок знать доподлинно прямым измерением, ну и кое-какие аналоговые сигналы тоже иметь в компе для пост обработки.
Без присоединения к авто - оно работало, данные ГПС принимались в бэйсик-прогу, вычислялись ускорение и путь, остальное просто сохранялось для пост обработки.
Так вот оно висло намертво вместе с ноутбуком/виндой XP если только воткнуть кабель от подкапота авто в макетку (соединить земли ДВС авто и макетки, даже если ноут от батарей работал и макетка-Pic от USB ноута питалась).
Предполагаю что дело в помехонеустойчивости встроенного в Pic18F27J53 контролёра USB.
Та макетка и проект - валяются без разрушений, могу воткнуть опять.
Что именно туда надо припаять, чтоб не висло ?
Ну если всё так просто и заранее известно знатокам с многолетним опытом, проектирующим изделия с тиражом в сотни-тысячи экземпляров ?
Внешний USB приёмопередатчик с опторазвязкой - прошу не предлагать, ибо не смогу припаять.
Резисторы/конденсаторы/ограничители/прочие легкодоступные детальки - сколько угодно.
Фото макетки/каталог прожекта могу предоставить если надо для решения задачи.
[uquote="КРАМ",url="/forum/viewtopic.php?p=3498392#p3498392"]Такое ощущение, что физику защелкивания Вы не понимаете от слова совсем.
...
Остальные Ваши шаманства к проблеме не имеют никакого отношения.[/uquote]
Ну то есть если оно заработало надолго от перечисленных мною выше мер, без резисторов, без ограничителя на питании - то это "не считается" ?
Или "любое исключение опровергает правило/постулат/аксиому" - это не для здесь ?
А здесь - ну ровно как у юриспрудентов - "нельзя, но если очень хочется - то можно" и "закон что дышло" ?
Именно такой стогости здесь постулаты и утверждения ?
Аватара пользователя
КРАМ
Друг Кота
Сообщения: 25291
Зарегистрирован: Чт янв 10, 2008 22:01:02
Откуда: Московская область, Фрязино

Re: Вычисляемый переход - проблема

Сообщение КРАМ »

Можно потратить кучу времени на совершенно пустые мероприятия, но случайно и криво таки решить проблему.
Тиристорный эффект в паразитной диодной структуре КМОП драйвера ликвидируется путем ограничения тока протекающего ИЗ ПИНА в любой из паразитных диодов. Ток через сами транзисторы ничего не защелкивает.
Ток защелкивания зависит от нюансов технологии и составляет обычно от 5 до 25 мА. Обычно указывается в даташитах на контроллер в разделе электрических характеристик.
Я традиционно ставлю балласт в пин примерно в 470 Ом ... 1 кОм. Но МК в линию никогда непосредственно не включаю. Балласт стоит на внешней логике.
psw2.ru
Нашел транзистор. Понюхал.
Сообщения: 151
Зарегистрирован: Пт мар 02, 2018 13:47:57

Re: Вычисляемый переход - проблема

Сообщение psw2.ru »

[uquote="КРАМ",url="/forum/viewtopic.php?p=3499065#p3499065"]Тиристорный эффект в паразитной диодной структуре КМОП драйвера ликвидируется путем ограничения тока протекающего ИЗ ПИНА в любой из паразитных диодов.
...
Я традиционно ставлю балласт в пин примерно в 470 Ом ... 1 кОм.[/uquote]
Спасибо за полезную инфу/разъяснения.
[uquote="КРАМ",url="/forum/viewtopic.php?p=3499065#p3499065"]Ток через сами транзисторы ничего не защелкивает.[/uquote]
А неконтролируемый сквозняк от нагрева, распостраняющийся по кристаллу как круг по воде ?
Ну это если питание мелкопроца безграничное а не ограниченное внешним стабом на уровне максимального тока ног питания ПИКа.
А что произойдёт с защёлкнутой паразитной тиристорной структурой при снижении питания ниже напряжения удержания (полагаю что 1.5 - 2.0 вольта) ?
Лично я полагаю что тиристор - закроется. А далее линейный стаб снова поднимет питание до требуемых 5 вольт, мелкопроц ребутнётся по BOR.
В итоге - тиристор разрядит на себя лишь ёмкости фильтров по 5 вольтам (а ICD-4 открыто просит не делать их более 100 мкф) и быть могет останется жив.
[uquote="КРАМ",url="/forum/viewtopic.php?p=3499065#p3499065"]Ток защелкивания зависит от нюансов технологии и составляет обычно от 5 до 25 мА. Обычно указывается в даташитах на контроллер в разделе электрических характеристик.[/uquote]
Микрочипы открыто обещают защиту встроенными диодами на ток +25/-25 мА и прямо указывают напримеры прямого соединения мозга и питающей сети через токоограничительный резистор.
Куча брендов включая какой-то Бош производит миллионными тиражами бытовуху типа коллекторных шлиф машинок с поддержанием оборотов при изменении нагрузки,
где мозги без гальваноразвязки соединены с питающей 220 вольт сетью рядом с искрящим коллектором двигла.
Согласен что кнопы у Боша длиннее и заковыристее, но если на это закрыть глаза и принять что воздух/поверхностный разряд по пластику примерно киловольт/миллиметр - то разве 12 мм пластика кнопы до пальца - недостаточно без конденсации влаги ? А с конденсацией - входное УЗО не даст оператору частотника умереть случайно от тумана/росы ?
Ну и прикладывание пальца к кнопе и полный охват инструмента кистью - это весьма значимо разные при ударе током позиции руки оператора - палец он отдёрнет.
Но это лично я себя успокаиваю, согласен.
Надо было как все делать - оптику ставить туда, где каждая микросекунда (деградация оптики от времени наработки) на счету (между мозгами и силовыми ключами).
[uquote="КРАМ",url="/forum/viewtopic.php?p=3499065#p3499065"]Но МК в линию никогда непосредственно не включаю. Балласт стоит на внешней логике.[/uquote]
Что значит "в линию не включаю" ?
[uquote="КРАМ",url="/forum/viewtopic.php?p=3498392#p3498392"]Остальные Ваши шаманства к проблеме не имеют никакого отношения.[/uquote]
[uquote="КРАМ",url="/forum/viewtopic.php?p=3499065#p3499065"]Можно потратить кучу времени на совершенно пустые мероприятия, но случайно и криво таки решить проблему.[/uquote]
А если проблема решена, пусть даже и не так как это описано в учебниках - то почему "криво" ? Или это синоним "нетрадиционно" ?
И почему "пустые", если есть результат ?
И почему "случайно", если полноценной статистики - нет ? (ну кроме тестирование единственного экземпляра часы/годы).
Заранее обвинительный уклон на основании догматов из талмудов и веры в непогрешимость/абсолютность знаний преподов/авторитетов/гуру ?
А так-то согласен - у многих задач есть более одного решения.
Аватара пользователя
КРАМ
Друг Кота
Сообщения: 25291
Зарегистрирован: Чт янв 10, 2008 22:01:02
Откуда: Московская область, Фрязино

Re: Вычисляемый переход - проблема

Сообщение КРАМ »

[uquote="psw2.ru",url="/forum/viewtopic.php?p=3499736#p3499736"]А неконтролируемый сквозняк от нагрева, распостраняющийся по кристаллу как круг по воде ?[/uquote]
Такого эффекта не бывает. Из строя выходит только тот пин, который защелкнулся. Но он в состоянии загнуться в состоянии КЗ, что приводит к фактической неработоспособности всего МК с возможным повреждением внутренней шины питания.

[uquote="psw2.ru",url="/forum/viewtopic.php?p=3499736#p3499736"]В итоге.... быть могет останется жив.[/uquote]
Занятный критерий при разработке: "быть могет"... :facepalm: :))) :))) :)))
"Могет" стоит думать головой, а не расчитывать на "авось"?



[uquote="psw2.ru",url="/forum/viewtopic.php?p=3499736#p3499736"]Микрочипы открыто обещают защиту встроенными диодами на ток +25/-25 мА и прямо указывают напримеры прямого соединения мозга и питающей сети через токоограничительный резистор.[/uquote]
Балласт действительно в состоянии защитить вход от защелкивания. Я собственно и не отрицал этого. Вопрос только в том, что ВЕЛИЧИНА балласта иногда противоречит потребностям схемы в выходном токе пина, поскольку защита должна быть от напряжения на пине в разы больше питания, а ток защелкивания 25 мА. То есть я в эти же разы уменьшаю максимально возможный ток пина. И все это ради экономии двух диодов Шоттки. MBR0520 стоит менее 2 рублей. Экономия двух таких диодов на один внешний вход стоит риска потери всего МК или уменьшения нагрузочной способности пина? :tea:


[uquote="psw2.ru",url="/forum/viewtopic.php?p=3499736#p3499736"]Куча брендов включая какой-то Бош производит миллионными тиражами бытовуху типа[/uquote]
Причины этого лежат не в технической плоскости. Зато я, например, уже ДВАЖДЫ покупал блок управления стиральной машиной (разными машинами) по причине выгорания пина МК управляющего симистором. Зато бренду и АСЦ есть заработок... 8)
Сами понимаете, замена МК невозможна и нерентабельна по причине отсутствия прошивки и/или инструмента для прошивки. Я, например, не использую Мотороловские (Фрискейл) контроллеры, а именно их очень любят ОЕМ разработчики блоков управления для бытовой техники. Мне спецом держать программеры для всего подряд?
[uquote="psw2.ru",url="/forum/viewtopic.php?p=3499736#p3499736"]Что значит "в линию не включаю" ?[/uquote]
Значит между линией управления внешними силовыми цепями и самим МК всегда стоит некий буфер. Пусть и без опторазвязки.
Заменить транзистор или внешнюю логику гораздо проще, чем ковыряться с МК.

[uquote="psw2.ru",url="/forum/viewtopic.php?p=3499736#p3499736"]А если проблема решена, пусть даже и не так как это описано в учебниках - то почему "криво" ? Или это синоним "нетрадиционно" ?[/uquote]
Я не знаю что такое "нетрадиционно". Проблему можно решить грамотно или безграмотно. Безграмотное решение проблемы не является надежным, не является технически оптимальным, требует значительно числа проб и ошибок, значит экономически невыгодно.
Достаточно пару раз спалить МК за 5 долларов (например), чтобы наконец разобраться в проблеме и применить еще 3 доллара на обвес, чтобы проблема не возникла впредь из-за ВНЕШНИХ случайных событий. Испытания путем прогона не стоят ломаного гроша, поскольку сами по себе не подтверждают надежности. Любые испытания должны содержать возможные и допустимые в условиях эксплуатации ВНЕШНИЕ шоковые воздействия, а паче учитывать ресурс ряда компонентов, таких как, например, алюминиевые электролиты, у которых срок службы ограничен током через них и температурой их корпуса связанной с внешним нагревом и нагревом этим самым током (реактивным током пульсаций).
В общем, дилетантский метод тыка нигде не прокатывает. Слишком много степеней свободы даже у простой схемы.
psw2.ru
Нашел транзистор. Понюхал.
Сообщения: 151
Зарегистрирован: Пт мар 02, 2018 13:47:57

Re: Вычисляемый переход - проблема

Сообщение psw2.ru »

Спасибо КРАМ за дискусс.
Спойлер[uquote="КРАМ",url="/forum/viewtopic.php?p=3499878#p3499878"][uquote="psw2.ru",url="/forum/viewtopic.php?p=3499736#p3499736"]А неконтролируемый сквозняк от нагрева, распостраняющийся по кристаллу как круг по воде ?[/uquote]
Такого эффекта не бывает. Из строя выходит только тот пин, который защелкнулся.
Но он в состоянии загнуться в состоянии КЗ, что приводит к фактической неработоспособности всего МК с возможным повреждением внутренней шины питания.[/uquote]
Ну то есть например процессоры Атлон не взрывались до дыма и трещин кристалла на видеофиксацию при снятии радиатора БЕЗ внешних шоковых воздействий на выводы искрой и с учётом обещанной производителем "термозащиты" ? Интелы с голым кристаллом тоже взрывались, но пореже, видеофиксации на трубе не видел, но в СЦ и интелы приходили разогретые с трещинами.
Или там не такой КМОП и это "не считается" ? Или как ещё разрешить это противоречие сделанного утверждения с наблюдаемой реальностью ?
[uquote="КРАМ",url="/forum/viewtopic.php?p=3499878#p3499878"][uquote="psw2.ru",url="/forum/viewtopic.php?p=3499736#p3499736"]В итоге.... быть могет останется жив.[/uquote]
Занятный критерий при разработке: "быть могет"...
"Могет" стоит думать головой, а не расчитывать на "авось"?[/uquote]
Проблема данного утверждения в том - что гарантии только в сбербанке, да и то лишь когда кризиса нет.
А в реальном мире - вероятностные допущения. Ну так уж устроен мир по лично мне.
В итоге - "думать головой" от слова "гарантия" и "я знаю что будет" - это выглядит например как богохульство через самовознесение до уровня всезнающего.
Но есть ли объективно существующие причины так полагать ?
[uquote="КРАМ",url="/forum/viewtopic.php?p=3499878#p3499878"][uquote="psw2.ru",url="/forum/viewtopic.php?p=3499736#p3499736"]Микрочипы открыто обещают защиту встроенными диодами на ток +25/-25 мА и прямо указывают напримеры прямого соединения мозга и питающей сети через токоограничительный резистор.[/uquote]
Балласт действительно в состоянии защитить вход от защелкивания. Я собственно и не отрицал этого.
Вопрос только в том, что ВЕЛИЧИНА балласта иногда противоречит потребностям схемы в выходном токе пина, поскольку защита должна быть от напряжения на пине в разы больше питания, а ток защелкивания 25 мА. То есть я в эти же разы уменьшаю максимально возможный ток пина.[/uquote]
Воооот, приходим к вероятностям. А какое напряжение например помехи от искры взять для расчёта величины резистора ?
И какое время нужно для открытия паразитному тиристору ? И как на это время повлияет например ёмкость около ноги мелкопроца ?
Перенося мелкопроц по другую сторону радиатора в той зажиге - лично я руками создал проходные ёмкости вокруг ног на радиатор и конструктивно облегчил электростатическое экранирование мелкопроца, но оно не понадобилось.
Именно это действие было обозвано "шаманством" ?
[uquote="КРАМ",url="/forum/viewtopic.php?p=3499878#p3499878"]И все это ради экономии двух диодов Шоттки. MBR0520 стоит менее 2 рублей. Экономия двух таких диодов на один внешний вход стоит риска потери всего МК или уменьшения нагрузочной способности пина?[/uquote]
У 40 ног ПИК в ДИП корпусе примерно 35 выводов, нуждающихся в такой защите ? Итого 70 диодов по 2 рубля при стоимости мелкопроца 200-500 рублей ? С учётом площади платы и сложности пайки ?
Быть могет проще (проще для самодельщика, конвеер и роботы плести витуху пока не умеют, "руки" грубоваты) всё-таки подавить помеху в момент излучения и приёма чем паять резисторы и диоды ? Или использовать оба два метода, ну для увеличения шансов на "авось проскочит и не проскочит" ?
[uquote="КРАМ",url="/forum/viewtopic.php?p=3499878#p3499878"]я, например, уже ДВАЖДЫ покупал блок управления стиральной машиной (разными машинами) по причине выгорания пина МК управляющего симистором. Зато бренду и АСЦ есть заработок...[/uquote]
Как-то необычно программеру мелкопроцов и разработчику мелкосерийных изделий покупать мозги для стиралок вместо написания таковых самому в качестве хобби.
Или на основной работе столь хорошо платят, что "проще купить и не париццо", а "выходные потратить на отдых", не взирая на разъяснения товарища Ленина смысла слова "отдых" как такового ?
А вот лично меня со студенческой скамьи посещают мыслишки написать мозги для микроволновки/стиралки/котла отопления. Пока ничего не написал правда, но и жысь ещё не кончилась, согласен.
[uquote="КРАМ",url="/forum/viewtopic.php?p=3499878#p3499878"]Сами понимаете, замена МК невозможна и нерентабельна по причине отсутствия прошивки и/или инструмента для прошивки.[/uquote]
Это понимаю, согласен.
Наличие защищённых не контролируемых внешних библиотек, наличие "аппаратных" битов конфигурации защиты (обходные режимы которых известны автору кристалла но не известны широкой публике) - это привязка потребителя к себе, защита авторских прав и попытка Архимеда вместо "перевернуть" Землю - хотя-бы её "подоить".
На игле, согласен.
[uquote="КРАМ",url="/forum/viewtopic.php?p=3499878#p3499878"][uquote="psw2.ru",url="/forum/viewtopic.php?p=3499736#p3499736"]Что значит "в линию не включаю" ?[/uquote]
Значит между линией управления внешними силовыми цепями и самим МК всегда стоит некий буфер. Пусть и без опторазвязки.
Заменить транзистор или внешнюю логику гораздо проще, чем ковыряться с МК.[/uquote]
Если прожект открытый, а проц на кровати - то в чём проблема перекинуть МК в конструёвине для радиолюбителей ?
Но тем не менее - согласен, лично я неоднократно видел как внутри устроена обвязка мелкопроца в ЭБУ авто например - резисторы/диоды/конденсаторы в изобилии стоят, на каждом вводе.
Профи-разработчики не скупясь закидали вероятностную проблему чужим баблом, без долгих раздумий/исследований "оптимальности" и "экономической эффективности".
И возвращаясь к тому самодельному прямому сборщику данных с ДВС авто в реальном движении - согласен, надо подкапот разместить 18F27J13, с которого по USART через 4 провода и опторазвязку гнать данные в салон, где поставить 18F27J53 с конвертором USB-CDC и использовать его 2 USART для прихода данных от GPS и подкапота. Быть могет и заработает в такой конфигурации, согласен.
[uquote="КРАМ",url="/forum/viewtopic.php?p=3499878#p3499878"]Я не знаю что такое "нетрадиционно". Проблему можно решить грамотно или безграмотно. Безграмотное решение проблемы не является надежным,
не является технически оптимальным, требует значительно числа проб и ошибок, значит экономически невыгодно.[/uquote]
Как много утверждений без обоснования, согласен.
А кто решает "грамотно или безграмотно" и по каким критериям ?
А кто определяет "оптимальность" и по каким критериям и почему именно по ним ?
Ну и прочий остальной туман, согласен.
[uquote="КРАМ",url="/forum/viewtopic.php?p=3499878#p3499878"]наконец разобраться в проблеме и применить еще 3 доллара на обвес, чтобы проблема не возникла впредь из-за ВНЕШНИХ случайных событий.[/uquote]
А как можно ГАРАНТИРОВАННО предсказать случайность, если без "на авось" вероятностного подхода к оценке надёжности ?
[uquote="КРАМ",url="/forum/viewtopic.php?p=3499878#p3499878"]Испытания путем прогона не стоят ломаного гроша, поскольку сами по себе не подтверждают надежности.[/uquote]
А что они тогда подтверждают, тем более в контексте применения МК с самописанной прогой ?
Надёжность алгоритмов программы, надёжность проца, надёжность сопряжений проца и внешних искрящих например элементов - не подтверждается длительным прогоном ?
Именно по этой причине например производители накопителей на жёстких дисках открыто обещают MTBF 500К-2М часов сразу после выхода новой модели, но при этом эти накопители ломаются примерно 15 из 20 за 7+ лет непрерывной работы ?
[uquote="КРАМ",url="/forum/viewtopic.php?p=3499878#p3499878"]Любые испытания должны содержать возможные и допустимые в условиях эксплуатации ВНЕШНИЕ шоковые воздействия, а паче учитывать ресурс ряда компонентов[/uquote]
Именно потому харды и летят, ну вопреки рекламным обещалкам ? Именно потому, что обещать - не значит жениться, а на "авось проскочит" ?
[uquote="КРАМ",url="/forum/viewtopic.php?p=3499878#p3499878"]таких как, например, алюминиевые электролиты, у которых срок службы ограничен током через них и температурой их корпуса связанной с внешним нагревом и нагревом этим самым током (реактивным током пульсаций).[/uquote]
Инфа известная, согласен.
[uquote="КРАМ",url="/forum/viewtopic.php?p=3499878#p3499878"]В общем, дилетантский метод тыка нигде не прокатывает. Слишком много степеней свободы даже у простой схемы.[/uquote]
А где лично я применял "метод тыка" ? Хоть какой-либо выбор варианта был без обдумывания обозримой лично мне конкретики применения ?
Ну и про "много степеней свободы" - это было косвенное признание неизбежности некоторого "авось" при выборе вариантов ?
Согласен тогда.
"Учись сам - уча другого" в действии.
Последний раз редактировалось psw2.ru Ср ноя 07, 2018 08:20:27, всего редактировалось 4 раза.
Аватара пользователя
ARV
Ум, честь и совесть. И скромность.
Сообщения: 18590
Зарегистрирован: Чт дек 28, 2006 08:19:56
Откуда: Новочеркасск
Контактная информация:

Re: Вычисляемый переход - проблема

Сообщение ARV »

psw2.ru писал(а):Ну то есть например процессоры Атлон не взрывались до дыма и трещин кристалла на видеофиксацию при снятии радиатора БЕЗ внешних шоковых воздействий на выводы искрой и с учётом обещанной производителем "термозащиты" ? Интелы с голым кристаллом тоже взрывались, но пореже, видеофиксации на трубе не видел, но в СЦ и интелы приходили разогретые с трещинами.
Или там не такой КМОП и это "не считается" ? Или как ещё разрешить это противоречие сделанного утверждения с наблюдаемой реальностью ?
ну я так подозреваю, что трещины там возникали не из-за защелнутых КМОП-структур, а из-за деформации подложки/корпуса из-за невозможности отвода тепла от греющихся "естественным" образом разогнанных кристаллов. думаю, и отключенный от питания процессор лопнет, если его локально в центре греть инфракрасным лазером, например. лопнет по той же причине термической деформации.
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...

Мой уютный бложик... заходите!
psw2.ru
Нашел транзистор. Понюхал.
Сообщения: 151
Зарегистрирован: Пт мар 02, 2018 13:47:57

Re: Вычисляемый переход - проблема

Сообщение psw2.ru »

[uquote="ARV",url="/forum/viewtopic.php?p=3499911#p3499911"]
psw2.ru писал(а):Ну то есть например процессоры Атлон не взрывались до дыма и трещин кристалла на видеофиксацию при снятии радиатора БЕЗ внешних шоковых воздействий на выводы искрой и с учётом обещанной производителем "термозащиты" ? Интелы с голым кристаллом тоже взрывались, но пореже, видеофиксации на трубе не видел, но в СЦ и интелы приходили разогретые с трещинами.
Или там не такой КМОП и это "не считается" ? Или как ещё разрешить это противоречие сделанного утверждения с наблюдаемой реальностью ?
ну я так подозреваю, что трещины там возникали не из-за защелнутых КМОП-структур, а из-за деформации подложки/корпуса из-за невозможности отвода тепла от греющихся "естественным" образом разогнанных кристаллов. думаю, и отключенный от питания процессор лопнет, если его локально в центре греть инфракрасным лазером, например. лопнет по той же причине термической деформации.[/uquote]
На трубе есть видос (возможно более одного) именно как лопает кристалл работающего проца на метери в процессе работы игрухи при съёме радиатора с проца на ходу.
Найти и дать сцыль ?
Тема неоднократно обсуждалась на IXBT.
Механические повреждения от термических вполне различаются на глаз.
Аватара пользователя
ARV
Ум, честь и совесть. И скромность.
Сообщения: 18590
Зарегистрирован: Чт дек 28, 2006 08:19:56
Откуда: Новочеркасск
Контактная информация:

Re: Вычисляемый переход - проблема

Сообщение ARV »

не понимаю, как видео может пролить свет на проблему?
на видео видно, как защелкиваются КМОП-структуры? или что?
я продолжаю пребывать в уверенности, что из-за того, что работающие вентили процессора выделяют тепло, которое не может отвестись от них из-за снятия охладителя, происходит температурная деформация (локальная) самого кристалла, подложки и корпуса, из-за чего они и лопаются.
это не так?
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...

Мой уютный бложик... заходите!
Аватара пользователя
КРАМ
Друг Кота
Сообщения: 25291
Зарегистрирован: Чт янв 10, 2008 22:01:02
Откуда: Московская область, Фрязино

Re: Вычисляемый переход - проблема

Сообщение КРАМ »

[uquote="psw2.ru",url="/forum/viewtopic.php?p=3499909#p3499909"]Или как ещё разрешить это противоречие сделанного утверждения с наблюдаемой реальностью ?[/uquote]
Из той же оперы, когда пытаются безграмотные домыслы выдать за репрезентативный случай. Причин для выхода из строя чипа может быть очень много. И защелкивание там может быть совершенно не причем.
[uquote="psw2.ru",url="/forum/viewtopic.php?p=3499909#p3499909"]А в реальном мире - вероятностные допущения. Ну так уж устроен мир по лично мне.
В итоге - "думать головой" от слова "гарантия" и "я знаю что будет" - это выглядит например как богохульство через самовознесение до уровня всезнающего.[/uquote]
Пустой базар. Когда изделие регулярно выходит из строя по единственной причине, то причем тут надежность? Это тупо безграмотная разработка. Учите матчасть.
[uquote="psw2.ru",url="/forum/viewtopic.php?p=3499909#p3499909"]А какое напряжение например помехи от искры взять для расчёта величины резистора ?[/uquote]
Существует нормативная документация (стандарты устойчивости к внешним электромагнитным воздействиям) Которая содержит требования к величинам и методики испытаний . Она отражает ЧУЖОЙ ОПЫТ в этой области. Желаете наступать на грабли самостоятельно - Ваше дело. Изучить целесообразность этой нормативной документации не составляет труда.

[uquote="psw2.ru",url="/forum/viewtopic.php?p=3499909#p3499909"]конструктивно облегчил электростатическое экранирование мелкопроца, но оно не понадобилось.
Именно это действие было обозвано "шаманством" ?[/uquote]
И оно в том числе. Вы совершенно не знаете электродинамику. Электростатическое экранирование МК бессмысленно. Сам МК слишком мал для емкостных связей. Впрочем, для индуктивных тоже. Я практически уверен, что Вы бездарно развели плату с точки зрения разделения земель.

[uquote="psw2.ru",url="/forum/viewtopic.php?p=3499909#p3499909"]У 40 ног ПИК в ДИП корпусе примерно 35 выводов, нуждающихся в такой защите ?[/uquote]
Вы несете отчаянный бред. В подобной защите нуждаются только те пины, которые управляют силовыми цепями непосредственно. В промконтроллерах ВСЕ ВНЕШНИЕ ЦЕПИ имеют гальваноразвязку по входу и ключи по выходу.
Чтобы не было мучительно больно....

[uquote="psw2.ru",url="/forum/viewtopic.php?p=3499909#p3499909"]Как-то необычно программеру мелкопроцов и разработчику мелкосерийных изделий покупать мозги для стиралок вместо написания таковых самому в качестве хобби.
Или на основной работе столь хорошо платят, что "проще купить и не париццо", а "выходные потратить на отдых", не взирая на разъяснения товарища Ленина смысла слова "отдых" как такового ?[/uquote]
У Вас неадекватное представление о мире. Вы видимо полагаете, что управление стиралкой представляет из себя примитивный код.... Впрочем, с Вашим подходом к проектированию это ожидаемо.
А на работе мне хватает занятий с МК. Более чем хватает. Заниматься всяким бредом дома, если можно купить за 5000 рублей готовый блок я не намерен. Моя зарплата позволяет мне такие траты. Это меньше, чем один день моей работы, есличо...
И в качестве хобби меня подобное не интересует. Мне больше по душе изделия с цифровой обработкой сигналов.

[uquote="psw2.ru",url="/forum/viewtopic.php?p=3499909#p3499909"]Наличие защищённых не контролируемых внешних библиотек, наличие "аппаратных" битов конфигурации защиты (обходные режимы которых известны автору кристалла но не известны широкой публике) - это привязка потребителя к себе, защита авторских прав и попытка Архимеда вместо "перевернуть" Землю - хотя-бы её "подоить".[/uquote]
Опять Вы несете бред. Я на работе трачу кучу времени и сил на написание кода и создание схем. За это получаю деньги от работодателя. С какого перепуга все эти затраты должны пойти лесом лишь на том основании, что кому то хочется халявы?

[uquote="psw2.ru",url="/forum/viewtopic.php?p=3499736#p3499736"]А кто решает "грамотно или безграмотно" и по каким критериям ?
А кто определяет "оптимальность" и по каким критериям и почему именно по ним ?[/uquote] Грамотные специалисты. Критериев много - это и опыт свои-чужой, и фундаментальные знания, и знания документации и много чего еще, что отличает специалиста от дилетанта.



[uquote="psw2.ru",url="/forum/viewtopic.php?p=3499736#p3499736"]А что они тогда подтверждают, тем более в контексте применения МК с самописанной прогой ?
Надёжность алгоритмов программы, надёжность проца, надёжность сопряжений проца и внешних искрящих например элементов - не подтверждается длительным прогоном ?
Именно по этой причине например производители накопителей на жёстких дисках открыто обещают MTBF 500К-2М часов сразу после выхода новой модели, но при этом эти накопители ломаются примерно 15 из 20 за 7+ лет непрерывной работы ?[/uquote]
Это взгляд дилетанта. Нет смысла обсуждать какого то производителя с какими то обещаниями, содержание которых Вы рандомно интерпретируете. Срок службы и гарантийный срок - это "две большие разницы".

[uquote="psw2.ru",url="/forum/viewtopic.php?p=3499736#p3499736"]А где лично я применял "метод тыка" ?[/uquote]
Перечисленные Вами мероприятия и есть "метод тыка".
psw2.ru
Нашел транзистор. Понюхал.
Сообщения: 151
Зарегистрирован: Пт мар 02, 2018 13:47:57

Re: Вычисляемый переход - проблема

Сообщение psw2.ru »

[uquote="ARV",url="/forum/viewtopic.php?p=3499917#p3499917"]не понимаю, как видео может пролить свет на проблему?
на видео видно, как защелкиваются КМОП-структуры? или что?
я продолжаю пребывать в уверенности, что из-за того, что работающие вентили процессора выделяют тепло, которое не может отвестись от них из-за снятия охладителя, происходит температурная деформация (локальная) самого кристалла, подложки и корпуса, из-за чего они и лопаются.
это не так?[/uquote]
Зазор для сомнений/вопросов/такого варианта объяснения есть, вынужден согласится.
www.thg.ru/cpu/20010917/heatvideo-02.html вот статейка и вот видос
Там конечно не видно "кругов на воде", однако - если проц снабжён термозащитой, которая не успевает сработать - то что ему мешает выключить мозги если не сквозняк ?
А трещин и вспучивания на видосе нет, только что переглядел.
Кремний - хрупок, размер кристалла примерно 10х10 мм.
Аватара пользователя
КРАМ
Друг Кота
Сообщения: 25291
Зарегистрирован: Чт янв 10, 2008 22:01:02
Откуда: Московская область, Фрязино

Re: Вычисляемый переход - проблема

Сообщение КРАМ »

[uquote="psw2.ru",url="/forum/viewtopic.php?p=3499933#p3499933"]что ему мешает выключить мозги если не сквозняк ?[/uquote]
"Есть многое на свете, друг Горацио, что и не снилось нашим мудрецам..." (с)
Далось Вам защелкивание... Типа игрушка-погремушка?
:dont_know:
Аватара пользователя
BOB51
Друг Кота
Сообщения: 15575
Зарегистрирован: Вт мар 16, 2010 22:02:27
Откуда: ДОНЕЦК

Re: Вычисляемый переход - проблема

Сообщение BOB51 »

Ну у кого-то и метод тыка - штука вполне здравая.
Только то, что задуманные и самостоятельно созданные схемы оказались работоспособными и дали дальнейший толчек к творчеству - уже достижение.
Остальное прибавится по мере развития проектов.
В то же время особенности схемотезники и правила построения программ лучше всего выявляются в процессе самостоятельной работы и по мере возникновения в том надобности у автора самоделок.
Не всем же термокамера требуется и прочие спецтрюки.
Для домашнего применения хватит и контроля на разброс диапазона питающих напряжений.
Это когда еще универсальное применение в условиях наружной установки и/или промприменения потребуются.
Я вот даже и не помышляю о самодельном USB устройстве - кушаю готовые USB-СОМ, USB-TTL блочки коих в достатке.
Ну и туда же всяки вай-фаи блю тузы и прочие радиоканалы - ПОКА надобности в их изучении нету (и свят боже).
Да и то, что человек написал работоспособную программу на базе 18-й серии тоже весьма достойно (насчет кошерности - надеюсь со временем придет).
8)
Ибо... мня самого уже давноо ЛЕНЬ ПОГЛОТИЛА - даже усами пошевелить ВЛООМ...
:sleep:

AMD БЕЗ РАДИАТОРА??!!
:o
:facepalm:
САДОМАЗОХИЗМ...
:cry:
Ответить

Вернуться в «PIC»