Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Нее, Алекс... Тут очень глубоко зарытая идея защиты от копирования. Ибо всякий обнаруживший такой мазохизм немедля бросит затею реверса. Быть мазохистом - это крайне обидно для настоящего посона. )))
В CCS для "слабых" PICs uint64_t нет. Есть проверенный метод работы с uint64_t? (Метод может быть не быстрым).
Мне примерно нужно "масштабировать" дроби - целочисленный делитель INT, числитель FRAC и знаменатель MOD. Числа большие и достигают "вершины" uint32_t. Число 4095 может быть для другой случай и 1048575. Разделить напр. 1000/1000 в данном случае быть не должно - теряю точность "внизу" [Hz].
В Arduino для FRAC/MOD использую это, но в CCS нет uint64_t:
А в чем может быть проблема? Обычная арифметика и извлечение квадратного корня не имеют вообще никаких ограничений по стандартной "школьной" методике. Вы столбиком арифметику + - и * делать умеете? Это оно и есть. Можете посмотреть как делается 32-разрядная арифметика и воспроизвести ее в 64 разрядах. Деление и извлечение корня я предпочитаю делать итерационным последовательным приближением. Хотя нужно бы посчитать, возможно Ньютон-Рафсон и побыстрее будет для 8 разрядов.
Вот сигнал от UART и от "ногадрыга" Видно, что "ногадрыга" не точно делает паузы в бите Придётся изучать таймер TMR2, чтобы получить стандарт 104мкс Спойлер
Код:
//---------- #include <p18F25K80.h> // для настройки под выбранный контроллер
void init(void) { // настройка генератора // в регистре конфигурации выбран внешний тактовый генератор XT, умножитель выключен // в OSCCON выбираем 4 мГц основной генератор OSCTUNE = 0b00000000; // ||++++++---TUN<5:0>: 000000 = Центральная частота; Быстрый Осциллятор RC работает на калиброванной частоте // |+---------PLLEN: Frequency Multiplier 4xPLL 0 = PLL выключен // +----------: Internal Oscillator Low-Frequency
OSCCON = 0b01010000; // 101 = HF-INTOSC/4 output frequency is used (4 MHz) // ||||||++---SCS<1:0>: тактовая частота берется с основного модуля. основной генератор (работа через PLL должен быть 00) // |||||+-----HFIOFS: бит - Частота стабильна // ||||+------OSTS: бит статуса (какой выбран генератор) // |+++-------IRCF<2:0>: выбор частоты тактового генератора // +----------: функция генератора в режиме сна. SPLLEN умножитель 1-включен OSCCON2 = 0b00000000; // |||||||+---LFIOFS:бит стабильной частоты LFINTOSC режима // ||||||+----MFIOFS:бит стабильной частоты MFINTOSC режима // |||||+-----PRISD:бит отключения главного (внешнего) генератора // ||||+------SOSCGO: бит контроля запуска вторичного (внешнего) генератора // |||+-------MFIOSEL: бит переключения источника чатоты для MFINTOSC режима // ||+--------Unimplemented: Read as ‘0’. // |+---------SOSCRUN: бит статуса источника частоты от вторичного генератора // +----------: бит статуса получения частоты от умножителя тактовой чатоты
//---------- // настройка портов ADCON1=1; // Отключаем все аналоговые буфера ADCON1=0b01111111; // Отключаем все аналоговые буфера TRISBbits.TRISB0 = 0; // 21-нога out // LATBbits.LATB0 = 1; // установить на B0 плюс // UART TRISCbits.TRISC6 = 0; // TX output TRISCbits.TRISC7 = 1; // RX input
// настройка Open1USART Open1USART ( USART_TX_INT_OFF & // Прерывание передачи OFF USART_RX_INT_ON & // Получать прерывание ON USART_ASYNCH_MODE & // Асинхронный режим USART_EIGHT_BIT & // 8-bit Передача / прием USART_CONT_RX & // Непрерывный прием USART_BRGH_HIGH, // Высокая скорость передачи бода SPBRG = 25 ); // ((4000000 : 16) : 9600) - 1 = 25,04 Погрешность скорости обмена 9600
я, конечно, не знаток PIC-ов, но сдается мне, софтовый UART не стоит того, чтобы мусолить его столько времени... более того, таймер для временных интервалов битов там не нужен, т.е. не требуется какая-то "особая" точность. проблема явно где-то в другой области кроется...
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
В интернете нахожу только примеры заточенные на курсовые: арифметика и алгебра. Примеров по K-Line нет. Почему на 2 транзисторах работает, как автомат Калашников А на PIC18F25K80 не хочет.
Почему на 2 транзисторах работает, как автомат Калашников А на PIC18F25K80 не хочет.
может, потому, что на 2 транзисторах сигнал RX инвертируется транзистором, а в варианте "пик" - вопрос? возможно, я что-то упустил из предыдущего, но верно ли я понял, что вы хотите один аппаратный USART использовать для связи с компьютером, а софтовый - для К-линии, причем с возможностью трансляции в К-линию как "своих" данных из МК, так и тех, что присылает комп? ну и в обратную сторону тоже? типа аппаратного сниффера К-линии изобретаете что-то?
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Изучаю K-Line: 1.Протокол связи с ЭБУ 2.Протокол данных Обидно за PIC18F25K80, который проигрывает 2 транзисторам 1.Скорость связи с ЭБУ слабая: Если даже UART поднять до 115200 бод 2.Почему-то говорят, что он не умеет отправлять в ЭБУ байты длиннее 8 байт
Цитата:
один аппаратный USART использовать для связи с компьютером, а софтовый - для К-линии, причем с возможностью трансляции в К-линию как "своих" данных из МК, так и тех, что присылает комп?
- Да Специфика работы с ЭБУ: 1. Скорость связи своя(обычно 10400 бод) 2. Пробуждение ЭБУ(обычно импульс 25/25мс)
1. Скорость связи своя(обычно 10400 бод) 2. Пробуждение ЭБУ(обычно импульс 25/25мс)
формировать программно сигналы K-Line на скорости чуть больше, чем 9600 - имхо, это не может быть проблемой. похуже с приёмом, но, предполагаю, и тут не принципиально. я в PIC-ах вообще ни ухом ни рылом, не могу утверждать, что все получится... только предполагаю по аналогии с AVR, что проблем быть не должно никаких серьёзных.
но на вашем месте я не стал бы заморачиваться с PIC-ом вообще, а просто сниффил бы на компьютере обмен через СОМ-порт, и видел бы то же самое.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 4
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения