repstosw

-HT - в QFP Это хотел сказать, что нужна плавучка, а то как она реализована - в виде юнита или в составе команд основного АЛУ - уже не интересует :) В смысле, что экзамплы входят в неё или нет? Наподобие как у Visual DSP: в папке есть примеры работы с периферией Блекфина (наподобие SDK). А почему бы и нет? Ха! Эмуляция только одного графического чипа Capcom Play System-2 и его звуковой части Q-Sound + FM- синтез чего только стоят. Быстрая числодробилка напрашивается!

В разработанном устройстве "nanoPlayer" и на ПК ошибок нет и быть не может (при условии, если настройка режимов ядра и периферии выполнены корректно). Если же говорить о линии связи или промежуточном агенте переноса информации (радиоволны, оптоволокно и прочее...), то в данном кодеке используется форсированная вставка ключевого фрейма - каждый 12-й кадр, что даёт время восстановления 1 секунду при 12 FPS. В новой ревизии 1 кодека, ключевой кадр может идти чаще, но не реже, чем 1 раз на 12 кадров. Ok, спасибо! Я перепробовал 4 версии кодера Хаффмана (качал с гитхаба) и все они жали по-разному. Был даже один вариант, который декодировался с ошибкой. Я выбрал тот, который при проверке не даёт ошибок и с лучшим сжатием.

Хороший вопрос! :) Честно, я не смог определить - адаптивный или нет, прилагаю сорец реализации Хаффмана, пожалуйста гляньте если нетрудно, тоже интересно - адаптивный или нет? huffman.txt Иногда, когда много пустоты в кадре из-за пустой таблицы частот приходится дожимать с помощью RLE поверх Хаффмана.

OMAPL137-HT в QFP корпусе. В свете сегодняшних политических событий его вряд-ли возможно из США в Россию передать. Так сказал mouser.com. Порылся в ТиШных DSP, нашёл ещё красавца - TMS320C6745 - тоже в QFP, версия 456 МГц. Если его сравнить с BF532 на 400 МГц, то очевидно , что TMS лучше ? Заинтересовал VLIW и наличие FPU, чего нет у Блекфина. А также подключение SDRAM с шириной ШД аж 32 бита! Ну и доставаем. На счёт Code Composer Studio, поддержка TMS там на уровне? Или всё спрятано в линуксах? С БГА пичаль, мне надо чтоб без ухищрений распаять. Или всё-же долбить Allwinner? Я очень часто работаю с чужим исходным кодом и не могу позволить себе роскошь потратить время на тотальное переписывание исходных кодов эмуляторов (это не только процессор, но и периферия). Это к вопросу "Либо вы точно знаете свои алгоритмы и что в них хотите улучшить, либо не знаете" Ну и ZX эмулировать совсем неинтересно. GameBoy Color или NES куда интереснее будут! :)

Я конечно могу привести таблицу, но поверят ли? Проще проверить было самому. Тесты: 1) "Винни-Пух": 211 МБ С учётом 6 бит из 8: 158.25 МБ PackMan rev.0: 59.6 МБ PackMan rev.1: 56.9 МБ Lagarith: 69.4 МБ MSU: 46 МБ 2) "Yurizan Beltran": 406 МБ С учётом 6 бит из 8: 304.5 МБ PackMan rev.0: 106 МБ PackMan rev.1: 102 МБ Lagarith: 98.5 МБ MSU: 97.7 МБ 3) "Space Cobra": 1034.24 МБ С учётом 6 бит из 8: 775.68 МБ PackMan rev.0: 225 МБ PackMan rev.1: 211 МБ Lagarith: 240 МБ MSU: 178 МБ 4) "Ashton Pierce": 877 МБ С учётом 6 бит из 8: 657.75 МБ PackMan rev.0: 234 МБ PackMan rev.1: 228 МБ Lagarith: 242 МБ MSU: 247 МБ Во втором случае кодек проиграл всем остальным по сжатию. В четвертом случае - победил всех. В большинстве случаев разработанный кодек между Lagarith и MSU по степени сжатия, при этом не уступающий в скорости кодирования-декодирования (про MSU лучше вообще не вспоминать, там где нужна скорость декодирования) Реализовал улучшенный вариант кодера: PackMan rev.1, декодер остался тем же. Когда отлажу, выложу. Я смотрел на ней[железке] весь сериал "Space Cobra" все 31 эпизодов по 25 минут каждый.

Для BF532, BF533 я абстракцию писал сам :) На выходе получилось что-то вроде своего SDK (или API), делающий всю необходимые функции: установка клоков CPU, SDRAM, SPI, настройка периферии, стека , кучи... Повезло что Блекфины линуксоеды и прочие ОСо-любы не испортили :)

Под этот же плеер исходники с прошивками, декодирующие: ADPCM, MP3, FLAC, MJPEG, MP4(H264): nanoPlay_IMA_MP3_FLAC_MJPEG_H264.zip

Нет, GUI не нужен. Нужно просто быстрое ядро под универсальные алгоритмические задачи (эмуляция 8- и 16- битных процессоров) + обработка графики (копирование из одной области памяти в другую, копирование массива в регистр данных дисплея). DDR я как понимаю будет лучше смотреться, чем обычная PC133 SDRAM. Приобрёл 2 платы на A13: Olinuxino и SOM-модуль. И-за текущих работ не могу пока до них добраться, поэтому в режиме сбора информации. Есть ещё v3s, к счастью там не надо DDR разводить. Ничё, время лечит, думаю за пол-года-год будет SDK "чистый поток сознания", наподобие как китайцы перелопатили SPL-говнокод на "регистры" для STM32. Если нет, то сам займусь. Под железным подходом имел ввиду - не использовать HAL, OS; только хедеры регистров и их бит. Ну может ещё что-то типа SPL допускается. Не более! Никаких абстракций, только имена регистров и их биты! Ну писать только C/C++, Asm , никаких питонов, сишарпов и прочих джав. Вы как человек с опвытом можете сказать, OMAP-L137 отвечает моим хотелкам или там тоже абстракция с пингвинами?

Фото плеера: Принципиальная схема (элементы, помеченные как NC - отсутствуют): Видео в действии (на мерцание экрана не обращать внимание, это из-за фотоаппарата): video1.zip и video2.zip

Есть ли достойная замена STM32F... на частоте от 400 МГц, QFP корпус, внутренняя память не менее 512 кБ с железным подходом программирования?

делал, жмёт лучше (пример: 205 вместо 240 МБ), но на ПК (3 ГГц) скорость воспроизведения декодированного видео в 2 раза медленее. Реализация: "Д. Мастрюков, "Монитор", N1, 1994. Алгоритмы сжатия информации. Адаптивное арифметическое кодирование. Демонстративная программа." Встроенной РАМы STM32F407 не хватит. Изначально планировал Lossy :) Но потом понял, что это слишком легко, часть коэффициентов - особенно сильно ВЧ можно обнулить, те что более НЧ проквантовать, Low оставить без изменений. Да, была фантастика - сжатие в несколько десятков раз, но c артефактами вокруг чётких контуров. У меня есть пара идей как усовершенствовать кодек. Первая идея даже не требует изменения алгоритма декодера. Вторая - с пересмотром алгоритмов обоих. Интернет. Без шуток... 0) http://compression.ru/ 1) описание JPEG, JPEG2000 - трудностей с поиском не должно возникнуть 2) Хабр: https://habrahabr.ru/post/168517/ https://habrahabr.ru/post/169615/ и https://habrahabr.ru/post/142242/ https://habrahabr.ru/post/142492/ и https://github.com/VadimKirilchuk/jawelet/w...velet-Transform https://github.com/VadimKirilchuk/jawelet/w...velet-Transform 3) всякие научные статьи учёных деятелей (индусских в основном), чьи перлы просочились через интернет 4) github.com , pudn.com - исходные тексты кодеров Хаффмана, RLE, арифметик-кодера. Много нерабочего говнокода!!! Надо проверять на правильность работы и фильтровать! 5) Ну и конечно, сам Бог велел: https://hightech.in.ua/content/art-c-cpp-co...ler-for-windows или http://pmg.org.ru/gamedev/djgpp.htm - на выбор. 6) Ну и без этого не достичь большой скорости декодирования: http://infocenter.arm.com/help/index.jsp http://www.keil.com/support/man/docs/armasm/ или хотя-бы для начала: https://www.compel.ru/lib/ne/2012/6/3-bogat...yadre-cortex-m4 7) И смотреть чё делается в критических местах: ASM-листинги компилируемой программы

Тут беда была не из-за прагм. Прагмы как раз работали. И компилятор свежий (версии тоже писал выше). Скачал ARM Compiler V6. Попробую его к Кейлу прикрутить (если будет клянчить лицензию - тогда fail)

Здравствуйте! :) Решил поделиться с общественностью своими наработками в области сжатия видео без потери качества. :yeah: Разработан битэкзактный 4,5 ступенчатый Lossless Bitexact кодек видео под названием "PackMan" rev.0. Кодек соперничает с MSU и Lagarith, исходники открыты и доступны для платформ: - ПК (ДОС, все Винды) - ARM Cortex-M4 (STM32F407), только декодер Конвейер кодера: Декодер - обратим. Подробное описание здесь: http://vrtp.ru/index.php?act=categories&am...mp;article=3713 Про nanoPlayer здесь: http://vrtp.ru/index.php?showtopic=29688&st=90 и здесь: http://vrtp.ru/index.php?act=categories&am...mp;article=3712 Макет плеера: Релиз будет скоро спаян, печатные платы есть: Принципиальная схема плеера: http://vrtp.ru/index.php?act=Attach&ty...t&id=769410 Исходники кодера и декодера + билды под форточки, ДОС, скрипт, тестовый образец: PackMan_Codec.zip Исходники декодера для STM32F407, вывод оптимизирован, параллельно играет FLAC с asm-оптимизацией: nanoPlay_PackMan.zip Кодек зарелижен, оттестирован. Битэкзактный на уровне 6 бит (специфика железа) Замечания, пожелания, эксперименты и предложения по улучшению сжатия кодера и/или скорости декодера приветствуются!

А по первому пункту вопроса, в ходе копаний стало ясно почему программа не работала с -O3. Не стартовал ЦАП и не происходило прерывание от него, которое синхронизировало внутренний цикл программы. Программа просто зависала и ждала снятия флага по прерыванию. А ЦАП не стартовал из-за некорректной отработки функции инициализации ЦАП+ДМА+Таймер. Заменил обычную память под выделяемые структуры на динамическую. Всё сразу заработало! Вполне возможно, что SPL-ный говнокод приводит к большому потреблению памяти на структуры инициализации и переполнению стека, что при разных оптимизациях вполне возможно. Ну и как проинитил часть железа - сразу осовобожать память. Вот фрагмент кода в котором происходила проблема: static void DAC_DMA_IRQ_Config() { DMA_DeInit(DMA1_Stream5); DMA_InitTypeDef *DMA_InitStructure=malloc(sizeof(DMA_InitTypeDef)); DMA_InitStructure->DMA_Channel =DMA_Channel_7; DMA_InitStructure->DMA_PeripheralBaseAddr=DAC_DHR12R1; DMA_InitStructure->DMA_Memory0BaseAddr =(u32)&AudioBuffer; DMA_InitStructure->DMA_DIR =DMA_DIR_MemoryToPeripheral; DMA_InitStructure->DMA_BufferSize =L<<1; DMA_InitStructure->DMA_PeripheralInc =DMA_PeripheralInc_Disable; DMA_InitStructure->DMA_MemoryInc =DMA_MemoryInc_Enable; DMA_InitStructure->DMA_PeripheralDataSize=DMA_PeripheralDataSize_HalfWord; DMA_InitStructure->DMA_MemoryDataSize =DMA_MemoryDataSize_HalfWord; DMA_InitStructure->DMA_Mode =DMA_Mode_Circular; DMA_InitStructure->DMA_Priority =DMA_Priority_VeryHigh; DMA_InitStructure->DMA_FIFOMode =DMA_FIFOMode_Disable; DMA_InitStructure->DMA_FIFOThreshold =DMA_FIFOThreshold_HalfFull; DMA_InitStructure->DMA_MemoryBurst =DMA_MemoryBurst_Single; DMA_InitStructure->DMA_PeripheralBurst =DMA_PeripheralBurst_Single; DMA_Init(DMA1_Stream5,DMA_InitStructure); free(DMA_InitStructure); DMA_ITConfig(DMA1_Stream5,DMA_IT_HT|DMA_IT_TC,ENABLE); NVIC_InitTypeDef *NVIC_InitStructure=malloc(sizeof(NVIC_InitStructure)); NVIC_InitStructure->NVIC_IRQChannel=DMA1_Stream5_IRQn; NVIC_InitStructure->NVIC_IRQChannelPreemptionPriority=0; NVIC_InitStructure->NVIC_IRQChannelSubPriority=0; NVIC_InitStructure->NVIC_IRQChannelCmd=ENABLE; NVIC_Init(NVIC_InitStructure); free(NVIC_InitStructure); DAC_InitTypeDef *DAC_InitStructure=malloc(sizeof(DAC_InitTypeDef)); DAC_InitStructure->DAC_Trigger =DAC_Trigger_T6_TRGO; DAC_InitStructure->DAC_WaveGeneration=DAC_WaveGeneration_None; DAC_InitStructure->DAC_OutputBuffer =DAC_OutputBuffer_Enable; DAC_Init(DAC_Channel_1,DAC_InitStructure); free(DAC_InitStructure); } Но стоит только выделить под структуры статическую память (а она будет будет взята из секции стека, так как идёт из вызова процедуры), работать при -O3 перестанет. Код работает и со статической памятью, если его вызвать не как функцию, а в main() написать всё что внутри void DAC_DMA_IRQ_Config(). Потому что память на структуры берется уже не из секции стека, а из секции DATA, которая больше. К сожалению говнокод, который в SPL приводит к таким вот неприятным вещам ... Проблема решена. :)

Старый добрый ДОС мне много счастья подарил :) С сектором да, разобрался - 512 байт и не меняется. Скачал SDFormatter, форматнул карточку им, произошло чудо - медленные карты теперь идут без заиканий. Теперь вопрос: какой смысл использовать DMA для карт памяти через SDIO при использовании FatFs ? Допустим надо считать порцию с файла. Вызывается чтение секторов, но ведь пока DMA не передаст все данные - прийдётся ждать! И сделать ничего не могу дальше, пока файл не считан. Оперативы - сколько в штатном STM32F407, так что спроецировать файловую систему в память не смогу (хотя в другом проекте такое успешно делал, но там памяти 64 МБ было). Есть ли шанс реорганизовать работу Fatfs без ожидания завершения чтения секторов? Мне кажется, что нет. Остаётся толко низкоуровневое чтение секторов одного за другим (причем блочное). Пробовал переводить карту в High Speed Mode, тактовая частота 36 - 52 МГц ( менял делитель PLL_Q для USB, так как согласно эррате на STM32F407 Bypass там не работает) - выигрыша с медленными картами не дало. Медленная карта - без обозначения класса скорости вообще на 2 ГБ. С классом скорости 4 - работает отлично. Я так понял, что разгон тактовой для карты памяти не имеет смысл, когда читаешь 1-секторный блок, так как задержки перед чтением у карты могут быть более длинными по времени. Так ли это, как я тут изложил свои думалки?

С IAR-ом незнаком, смотреть лучше в любом случае, если критично по скорости. UB - undefined behavior (неопределенное поведение?). Вполне возможно, что вы правы, приходится много работать с чужими исходными кодами, в которых может быть всё что угодно. Утечка памяти и выход за пределы массива с нечётко объявленными границами, например. Вот недавно пришлось скрестить C + C++ + ASM :) Потому что часть исходников написаны на плюсах, с объявлением классов, а часть обработки звука на Асме :) :) Я очень ревностно слежу за волатайлами, чтоб они были объявлены должным образом! Все регистры периферии, порты ввода-выводи и переменные в обработчиках прерываний, использующиеся внаружу - всё volatile :) Чтоб небыть голословным: Дано: Keil uVision 5.16a. Более старшие не идут в WinXP. Версии компилеров: 5.06(build 20) и 5.05 upd.2 (build 169). Оптмизация: -O3, -oTime (максимальная по скорости). Установка глобальная. В сорцах прочих прагм оптимизации нет. Фрагмент кода: *pL++=(__REV16(G)&0xFF0000FF)|(R&0x00FF0000)|(B&0x0000FF00); В листинге выглядит так: ... RRS r0,r0,r1 STR r0,[r4],#4 MOV r0,r11 BL __asm___6_main_c_NEXT____REV16 BFC r0,#8,#16 AND r1,r7,#0xff0000 ORRS r0,r0,r1 ... AREA ||.rev16_text||, CODE THUMB EXPORT |__asm___6_main_c_NEXT____REV16| #line 129 "C:\\Keil_v5\\ARM\\CMSIS\\Include\\core_cmInstr.h" |__asm___6_main_c_NEXT____REV16| PROC #line 130 rev16 r0, r0 bx lr ENDP ... Смешно и грустно одовременно. Пришлось с-инлайнить самостоятельно.

В традициях Старого Доброго ДОС-а считаю до сих пор словом - 2 байта (WORD) 4 байта - это уже двойное слово (DWORD) Впрочем мне известно, что в кортексиках слово - 4 байта :rolleyes: Пробовал отформатировать карту в винде на другой размер сектора - не даёт, только стандартный 512 байт. Чем отформатировать можно карту с скеторами 2048 байт или больше? Уменьшится ли время чтения? В High speed mode есть смысл переводить чтоб быстрее читать с карты?

Чтение секторов через DMA заработало. После чтения надо ждать завершения ДМА: while(DMA2_Stream3->CR&DMA_SxCR_EN); DMA2->LIFCR=DMA_IT_TCIF3&0x0F7D0F7D; DMA2_Stream3->CR|=DMA_SxCR_EN; То что выше, работает и без разрешения прерываний. С разрешёнными прерываниям работает стандартный кусок: SDError = SD_WaitReadOperation(); while( SD_GetStatus() != SD_TRANSFER_OK ); Сектор читается корректно, но FatFs не работает! При открытии файла - ошибка 4 - FR_NO_FILE, /* (4) Could not find the file */ Без DMA работает. В чём подвох работы FatFs с DMA ? WORD_ACCESS стоит 0. Всё разобрался с FatFs! Проверил, что при чтении из файла библиотека суёт указатели, которые не выровнены на границу двойного слова(4 байта). Решил путём промежуточного буфера, выровненного на 16 байт для DMA: /*-----------------------------------------------------------------------*/ /* Read Sector(s) */ /*-----------------------------------------------------------------------*/ #define BLOCK_SIZE 512 unsigned char abuf[512] __attribute__((aligned (16))); //выровненный на 16 байт буфер extern void align_error(void); //для отладки DRESULT disk_read ( BYTE pdrv, /* Physical drive nmuber (0..) */ BYTE *buff, /* Data buffer to store read data */ DWORD sector, /* Sector address (LBA) */ BYTE count /* Number of sectors to read (1..128) */ ) { DRESULT dresult = RES_OK; SD_Error SDError; if( pdrv == SD_DISK_PDRV ) { if((((unsigned long int)buff)&0x00000003)!=0)align_error(); for(int i=0;i<count;i++) //карта поддерживает только одно-блочную команду чтения, мультиблоки не работают :( { SDError = SD_ReadBlock(abuf,(sector+i)*BLOCK_SIZE, BLOCK_SIZE); //читаем в выровненный буфер DMA #ifdef SD_DMA_MODE SDError = SD_WaitReadOperation(); #endif while( SD_GetStatus() != SD_TRANSFER_OK ); if(SDError != SD_OK)dresult = RES_ERROR; memcpy(buff+(i<<9),abuf,512); //копируем в выходной буфер со смещением } return dresult; } return RES_PARERR; } :rolleyes:

Здравствуйте! Использую Дискавери на STM32F407 + карту SD Micro 4 GB на чтение. Чтение через поллинг (Polling) идет отлично, даже файлы верно читаются с помощью FatFs. Но через DMA не удаётся нормально работать. Помотрел как читается нулевой(первый сектор) карты в 2 случаях: Polling и DMA. Фрагменты кода (прерывания включил, карту проинитил, данные выровнял на 16 байт) : u8 buff[512] __attribute__((aligned (16))); void SDIO_IRQHandler(void) { SD_ProcessIRQSrc(); } void SD_SDIO_DMA_IRQHANDLER(void) { SD_ProcessDMAIRQ(); } void SD_NVIC_Configuration(void) { // SDIO Interrupt ENABLE NVIC_InitTypeDef NVIC_InitStructure; NVIC_InitStructure.NVIC_IRQChannel = SDIO_IRQn; NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0; NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0; NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE; NVIC_Init(&NVIC_InitStructure); // DMA2 STREAMx Interrupt ENABLE NVIC_InitStructure.NVIC_IRQChannel = SD_SDIO_DMA_IRQn; NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 1; NVIC_Init(&NVIC_InitStructure); } SD_Init(); SD_NVIC_Configuration(); __enable_irq(); SD_ReadBlock(buff,0<<9,512); OLED_ON(); #define COL 255 for(u32 i=0;i<512;i++)OLED_Char(i%20,i/20,buff[i],COL|(COL<<8)|(COL<<16)); while(1); Фотки прикладываю. Вывод содержимого нулевого сектора на дисплей. Первая картинка - перез Polling - там всё OK. Вторая через DMA - первые байты (от трети до половины всего экрана) - нулевые. Куда копать, чтобы DMA нормально на чтение с SDIO начал работать?

1) Собираю проект в Keil ARM 5.16a для STM32F407 с максимальной оптимизацией по скорости Otime, O3. По мере написания проекта столкнулся со странным поведением, при максимальной оптимизации O3 программа иногда идёт иногда нет, зависит от порядка расположения переменных, функций. Если поменять их порядок местами, то иногда удаётся получить работающий код при O3. Опытным путём через #pragma optimize был выявлен проблемный кусок: им оказалась точка входа в main(). Если всё заоптимизировать с O3, но точку входа в main сделать O1 (выше может не пойти), то будет работать: #pragma push #pragma Otime #pragma O3 //Тут переменные, функции , константы, макросы............ //Точка входа в main с уровнем оптимизации не более O1, если поставить выше, то в некоторых случаях может не заработать. Глюк Keil ??? #pragma push #pragma Otime #pragma O1 int main(void) { #pragma push #pragma Otime #pragma O3 //тут программа......... #pragma pop } #pragma pop #pragma pop С чем может быть связано такое поведение? 2) Использую CMSIS-овскую функцию __REV16(), в ассемблерном листинге она вставляется в виде перехода на функцию, а не как одна ассемблерная инструкция. Причем остальные типа: __REV() , __CLZ() встраиваются в виде инструкций. Заменил __REV16() на : inline u32 rev16(u32 x) { __asm("REV16 x,x"); return x; } и в листинге идёт вставка ассемблерной инструкции без перехода как на функцию. Получается, что используя CMSIS , доверяй, но проверяй?

Кроме как напряжение на выходе будет падать, изменятся ещё какие-нибудь характеристики? Схема работоспособна до 2,7V что соответствует входному 2,8V с учетом DROP. LDO не будет стабилизировать, но ток отдачи будет таким же как и в режиме стабилизации? Или это неустойчивый режим LDO, не гарантирующий устойчивой отдачи тока при напряжениях ниже чем DROP+IN ?

Это когда все пиксели белые. Даташит на OLED (на его контроллер) приложил. SEPS525.pdf А на 3V нельзя ставить? По логике если LDO на 3V, и падение на нем 0,1V, то при входном 3V будет 2,9V, и при дальнейшем понижении входного напряжения будет падать выходное на величину DROP Voltage. Но при питании от 3,1V и выше будет 3V стабильно, что опять не так? Мне главное обеспечить напряжение питания контроллера на интервале [2,8 .... 3,6 V ]. И кстати, при каком напряжении Li-Ion считается разряженным? Гугл говорит неоднозначно: 2,7 - 3,2 V. Аккум от сотового ТЛФ.

А стоит ли игра свеч? В плане экономии каких-то микроджоулей? Тем более максимальный ток OLED матрицы по даташиту и экспериметально выходит 150 мА, и это при 12 V !!! Что даёт ещё больший ток во входной цепи повышающего dc/dc (с 3,7V). Как будет работать LDO на 3,3V с падением 0,1В , при входном напряжении 3V ? Если будут нормальные 2,9V то меня устроит. Мне главное срезать всё что выше 3,6V (для STM32). Вот тут вообще на 3,3V LDO ставят. http://forum.easyelectronics.ru/viewtopic....=10&t=19047 пост от oxford

Ещё вопросик по питанию. Использую li-Ion аккумулятор на 3,7 V (номинал) 950 мАч , ток потребления аналоговой части 70 мА, цифровой столько же. Стабилизирую питание двумя LDO на 3V ровно. Использую LDO TK11230A - выдернул их из старых сотовых телефонов, у них до 150 мА максимум и падение напряжения 0,16V на 60 мА. других лучших по близости не оказалось. Птитание сделал так: С аккумулятора идет питание на: 1) повышающий DC/DC для матрицы OLED дисплея на 12V 2) на LDO 3V для аналоговой части 3) на LDO 3V для цифровой части Стоит ли на SD карту делать отдельный третий LDO или нет? Боюсь что 150 мА не вытянет, хотя работает всегда, ни разу сбоя не возникало Посмотрел на схему OLINUXINO на A13, там берется 3,3V с LDO 200 мА. А дока на Kingston SD говорит о пиковых бросках в 400 мА !!!! Где истина? Ещё нашёл схему включения SD карты с защитой от бросков питания, стоит ли так делать или это костыли, которые в финальной разводке будут не нужны? (сейчас карта болтается на проводах 4см без слоя земли)

Что есть power cycle? При включении устройства, карта начинает работать менее чем через 1с. И зачем ключ на карте?