не гарантирует, что для всех индексов прописаны строки.
А это толком и не отследить. Разве что в рантайме пройтись циклом и проверить длину каждой строки. В любом случае это куда менее опасная ошибка, чем сдвиг вообще всех индексов.
Пример по сути демонстрирует, что используя плохие практики программирования, можно получить трудноуловимые ошибки. Ну так не используйте плохие практики.
А это автор надеется, что кто-нибудь вдохновится его идеей и начнет выпускать ардуино-полобные платы на v003 и с прошитым загрузчиком. Лучше бы он сначала загрузчик допилил...
Я могу, конечно, придумать пару способов зашить таблицу векторов отдельно от прошивки. Но вы сначала скажите зачем вам это надо. Или вы пытались сказать, что таблица векторов прерываний в gd32f103 отличается от таблицы в stm32f103, и без переклмпиляции один и тот же бинарник может не заработать? Так тоже экзотическая ситуация.
Я предполагаю, что для этой цели должны использоваться ножки PB6 и PB7, на которых как раз есть и USB и USART1. У CH32V203K8 - 29 и 30.
Заинтересовали вы меня этим корпусом и вот что получилось. UART1 выведен на PA9,PA10 (19,20, как почти во всех остальных камнях). SWD на PA13,PA14(23,24, ни с чем не конфликтует), USB выведены на PA11,PA12 и PB6,PB7 (21,22 и 29,30, причем USBD конфликтует с CAN, а USBFS - с I2C). Boot0 совмещен с PB8 (31). Ну и выводы кварца в наличии - PD0,PD1 (2,3). На всякий случай, если там бутлоадер тоже кривой, UART2 это PA2,PA3 (8,9). Что еще интересно, там упомянут UART4, но нет UART3. Но, похоже, реально и 4-го там нет, он только в C8, RB. И что-то есть подозрение, что USBFS (который на PB6,PB7) там не выведен... Интересная штука, наверное, стоит купить.
Anton1906, вы не могли бы проверить через какой UART он реально прошивается?
шаг между ножками бывает разный и можно случайно неправильно развести плату или купить неправильный адаптер (как я, например).
Ага, мне тоже это удалось. Оказывается, шаг 0.635 это не 0.65. Хорошо, что это обнаружилось всего лишь на макетке.
USART1. У CH32V203G8 это должны быть 2 и 3 ножки
Нет. Там другая распиновка. UART1 на PA9,PA10 (25, 26), а прошивается через PA2,PA3 (11,12, которые на UART2). Ни с чем интересным они не конфликтуют.
Ну и можно предположить, что в документации просто допущена ошибка, которые там периодически встречаются.
Похоже, не в документации, а в кристалле. Уж написать код для проверки на какие ножки выведен UART1, а на какие UART2 несложно. Собственно, я бы предположил, что умудрился купить поддельный кристалл, но так и не смог представить как же именно надо было накосячить вот для такого эффекта.
А еще, смотрю, там ножки кварца выведены. И boot0 не забыли. Вы правы, надо будет посмотреть этот камень более подробно. Не знаете, у него с бутлоадером не накосячено как у g8? Но на счет шага зря вы так: 0.635мм развести и запаять намного проще, чем 0.5.
Единственное, что подходит под это описание - прерывания вроде 43-го "TIM8_BRK_TIM12", где один и тот же обработчик вызывается для событий от двух таймеров. Но при чем здесь "бинарник не зашить", как прошивка контроллера связана с таблицей векторов?
Да с v203 они вообще упоролись. Я нашел чуть ли не единственный камень с какой-никакой периферией и удобным корпусом (лучше бы, конечно, DIP, но это уже из области фантастики) - ch32v203g8. Но и тут не без фокусов. Китайцы умудрились не вывести ножки кварца. А что еще веселее, отдали под бутлоадер UART2. Вот у всех остальных камней на UART1, а тут на UART2. И в документации об этом ни слова.
Кстати к автору. Если хотите, чтобы вашей разработкой пользовались и для v003 и для более мощных контроллеров, и раз все равно приходится подменять загрузчик своим, стоит его сделать совместимым с более старшими. Благо протокол не слишком сложный, я его где-то год назад реверсил.
По крайней мере, сразу видно и номер ножки, и режим. А магическое чиселко GPIO_CFGLR_CNF4_0 ничуть не лучше, чем 0x00010000, абсолютно ни о чем не говорит. Ну и само собой, шаблонную операцию x = (x &~mask) | val можно завернуть в макрос. Лично у меня это бы выглядело как-то так:
#define LED D,4,1,GPIO_PP50
#define BTN D,2,0,GPIO_PULL
...
GPIO_config(LED);
GPIO_config(BTN);
__enable_irq();
Это не обязательно. Стартап от wch сам включает прерывания.
В смысле risc-v, а не arm? Ну и что, на организацию кристалла это не влияет: и у тех, и у других флешка внешняя.
По остальному - ничего нового: как не было у меня возможности проверить границу кеша самостоятельно, так и нет. Разве что в ch32 (да, это тоже risc-v, как и gd32vf, о которых мы в этой ветке говорили). Но там про него пишут прямым текстом.
Если у вас есть gd32f103rk - отлично, можете проверить скорость доступа и рассказать что там с кешированием. У меня же под рукой только gd32vf103c8. Из всех riscv контроллеров gd у него больше всего памяти - целых 128 кБ. Но из того, что я от вас услышал, этого недостаточно.
На счет именно gd32 сказать не могу, но в некоторых других настраивается.
Скажем, в ch32v303 можно настроить 288+32 | 256+64 | 224+96 | 192+128. А вся флешка целиком 480к, так что всегда остается некешируемый хвост, который можно использовать для хранения данных. На счет хранения кода не уверен, поскольку настроек wait-state-ов там вроде бы нет. Настраивается это через option-byte-ы, что-то вроде фьюзов.
А в других контроллерах от тех же wch, такой настройки нет. В ch32v203 (кроме RB) размеры флеш и ОЗУ заданы жестко.
Думаю, самым простым критерием кешируется ли флеш, будет скорость доступа. Если предусмотрены wait-state (пара битов в конце FLASH->ACTLR), то кеша нет.
А это толком и не отследить. Разве что в рантайме пройтись циклом и проверить длину каждой строки. В любом случае это куда менее опасная ошибка, чем сдвиг вообще всех индексов.
Пример по сути демонстрирует, что используя плохие практики программирования, можно получить трудноуловимые ошибки. Ну так не используйте плохие практики.
Да тут сам массив строк выглядит ужасно.
И все.
Странный вопрос. Во всех случаях, кроме отладки.
А это автор надеется, что кто-нибудь вдохновится его идеей и начнет выпускать ардуино-полобные платы на v003 и с прошитым загрузчиком. Лучше бы он сначала загрузчик допилил...
Для ATmega328, которая установлена в ардуину, тоже нужен программатор, минимум один раз.
Я могу, конечно, придумать пару способов зашить таблицу векторов отдельно от прошивки. Но вы сначала скажите зачем вам это надо.
Или вы пытались сказать, что таблица векторов прерываний в gd32f103 отличается от таблицы в stm32f103, и без переклмпиляции один и тот же бинарник может не заработать? Так тоже экзотическая ситуация.
Спасибо
Заинтересовали вы меня этим корпусом и вот что получилось. UART1 выведен на PA9,PA10 (19,20, как почти во всех остальных камнях). SWD на PA13,PA14(23,24, ни с чем не конфликтует), USB выведены на PA11,PA12 и PB6,PB7 (21,22 и 29,30, причем USBD конфликтует с CAN, а USBFS - с I2C). Boot0 совмещен с PB8 (31). Ну и выводы кварца в наличии - PD0,PD1 (2,3).
На всякий случай, если там бутлоадер тоже кривой, UART2 это PA2,PA3 (8,9).
Что еще интересно, там упомянут UART4, но нет UART3. Но, похоже, реально и 4-го там нет, он только в C8, RB. И что-то есть подозрение, что USBFS (который на PB6,PB7) там не выведен...
Интересная штука, наверное, стоит купить.
Anton1906, вы не могли бы проверить через какой UART он реально прошивается?
Ага, мне тоже это удалось. Оказывается, шаг 0.635 это не 0.65. Хорошо, что это обнаружилось всего лишь на макетке.
Нет. Там другая распиновка. UART1 на PA9,PA10 (25, 26), а прошивается через PA2,PA3 (11,12, которые на UART2). Ни с чем интересным они не конфликтуют.
Похоже, не в документации, а в кристалле. Уж написать код для проверки на какие ножки выведен UART1, а на какие UART2 несложно. Собственно, я бы предположил, что умудрился купить поддельный кристалл, но так и не смог представить как же именно надо было накосячить вот для такого эффекта.
А еще, смотрю, там ножки кварца выведены. И boot0 не забыли. Вы правы, надо будет посмотреть этот камень более подробно. Не знаете, у него с бутлоадером не накосячено как у g8?
Но на счет шага зря вы так: 0.635мм развести и запаять намного проще, чем 0.5.
Единственное, что подходит под это описание - прерывания вроде 43-го "TIM8_BRK_TIM12", где один и тот же обработчик вызывается для событий от двух таймеров. Но при чем здесь "бинарник не зашить", как прошивка контроллера связана с таблицей векторов?
Да с v203 они вообще упоролись. Я нашел чуть ли не единственный камень с какой-никакой периферией и удобным корпусом (лучше бы, конечно, DIP, но это уже из области фантастики) - ch32v203g8. Но и тут не без фокусов. Китайцы умудрились не вывести ножки кварца. А что еще веселее, отдали под бутлоадер UART2. Вот у всех остальных камней на UART1, а тут на UART2. И в документации об этом ни слова.
Кстати к автору. Если хотите, чтобы вашей разработкой пользовались и для v003 и для более мощных контроллеров, и раз все равно приходится подменять загрузчик своим, стоит его сделать совместимым с более старшими. Благо протокол не слишком сложный, я его где-то год назад реверсил.
Если нет объективной необходимости, лучше использовать обычные прерывания, чтобы можно было собрать ваш код обычным gcc, не патченным wch-ами.
Лучше что-то вроде
По крайней мере, сразу видно и номер ножки, и режим. А магическое чиселко GPIO_CFGLR_CNF4_0 ничуть не лучше, чем 0x00010000, абсолютно ни о чем не говорит. Ну и само собой, шаблонную операцию
x = (x &~mask) | valможно завернуть в макрос. Лично у меня это бы выглядело как-то так:Это не обязательно. Стартап от wch сам включает прерывания.
В смысле risc-v, а не arm? Ну и что, на организацию кристалла это не влияет: и у тех, и у других флешка внешняя.
По остальному - ничего нового: как не было у меня возможности проверить границу кеша самостоятельно, так и нет. Разве что в ch32 (да, это тоже risc-v, как и gd32vf, о которых мы в этой ветке говорили). Но там про него пишут прямым текстом.
Если у вас есть gd32f103rk - отлично, можете проверить скорость доступа и рассказать что там с кешированием. У меня же под рукой только gd32vf103c8. Из всех riscv контроллеров gd у него больше всего памяти - целых 128 кБ. Но из того, что я от вас услышал, этого недостаточно.
256к? Тогда не проверю. У vf103 всей памяти максимум 128к
Не очень понял. 30к кешируется или 256к? Впрочем, тему вы подняли интересную, надо будет проверить
Вот это интересно. Получается, вы проверяли скорость доступа к началу флеша и концу? А подскажите, какой у gd32 объем кеша.
На счет именно gd32 сказать не могу, но в некоторых других настраивается.
Скажем, в ch32v303 можно настроить 288+32 | 256+64 | 224+96 | 192+128. А вся флешка целиком 480к, так что всегда остается некешируемый хвост, который можно использовать для хранения данных. На счет хранения кода не уверен, поскольку настроек wait-state-ов там вроде бы нет. Настраивается это через option-byte-ы, что-то вроде фьюзов.
А в других контроллерах от тех же wch, такой настройки нет. В ch32v203 (кроме RB) размеры флеш и ОЗУ заданы жестко.
Думаю, самым простым критерием кешируется ли флеш, будет скорость доступа. Если предусмотрены wait-state (пара битов в конце FLASH->ACTLR), то кеша нет.
UPD: допилил прошивку чтобы не только себя позволяла скачать, но и свои исходники. Максимум опенсорса!
Более того, именно это и произошло: