Изучаем STM32 Cortex M3

[SkataniK]

боюсь у меня далеко не тоже самое
привожу на ассемблере, потому, что в коде на си все правильно, уже сверился с кучей работающий примеров, лажа происходит именно в ассемблере и мне интересно почему это так
почему после прихода нужных данных они сразу же заменяются на белеберду?

[=GM=]

Ну, нет, так нет, сами разбирайтесь. Подсказка: лажа происходит из-за неполного понимания вами работы ииц в кортексе

[Sergi_alc]

=GM=,
Сегодня проверил в железе. Команды
LDR R0, [R5, #0x8]
STRB R0, [R4, #0x1]
выполняются за 4 такта,а жаль. Придется переписывать всю оболочку.

[=GM=]

=GM=,
Сегодня проверил в железе. Команды
LDR R0, [R5, #0x8]
STRB R0, [R4, #0x1]
выполняются за 4 такта,а жаль. Придется переписывать всю оболочку.

У вас команды совсем не те, про которые я говорил
1. LDR R0, [R5,#0x8] - откуда взялось смещение 0х08?
2. STRB R0, [R4,#0x1] - команда должна быть такая: STRB R0,[R4],#0x1

Цитата из технического руководства. Ваш случай - второй.

LDR any are pipelined when possible. This means that if the next instruction is
an LDR or non-base updating STR, and the destination of the first LDR is not
used to compute the address for the next instruction, then one cycle is removed from the cost of the next instruction. So, an LDR might be followed by an STR, so that the STR writes out what the LDR loaded. More multiple LDRs can be pipelined together. Some optimized examples:
— LDR R0,[R1]; LDR R1,[R2] - normally three cycles total
— LDR R0,[R1,R2]; STR R0,[R3,#20] - normally three cycles total
— LDR R0,[R1,R2]; STR R1,[R3,R2] - normally three cycles total
— LDR R0,[R1,R5]; LDR R1,[R2]; LDR R2,[R3,#4] - normally four cycles
total.

[Sergi_alc]

Для проверки вот так написал на С:
while (1)
{
fill_screen(black);
//Ввод
inp[0]=GPIOB-›IDR;
inp[1]=GPIOB-›IDR;
inp[2]=GPIOB-›IDR;
.......
inp[98]=GPIOB-›IDR;
inp[99]=GPIOB-›IDR;
// Вывод
for (i=0;i‹99;i++)
{
drawLine(i*4,240-(inp[i]››1),(i+1)*4,240-(inp[i+1]››1),white);
};
};
Чего-то с косвенной адресацией не получилось,буду учиться дальше.

[SkataniK]

ну почему же сразу нет, я же сказал, что мой код не отличается от всех других
но если хотется посмотреть, пожалуйста
функция чтения
void I2C_read (uint8_t SlaveAddrR,uint8_t SlaveAddrW, uint8_t RegisterAddr)
{
I2C2-›CR1 |= I2C_CR1_PE;
I2C2-›CR1 |= I2C_CR1_START;
while (!(I2C2-›SR1 & I2C_SR1_SB))

////////////////////
I2C2-›DR=SlaveAddrW;
//////////////////////

while((I2C1-›SR1 & I2C_SR1_ADDR)==0);

(void) I2C1-›SR1;
(void) I2C1-›SR2;

/////////////////////
I2C2-›DR=RegisterAddr;
while ((I2C2-›SR1 & I2C_SR1_TXE)==0)
//////
I2C2-›CR1 |= I2C_CR1_START;
while ((I2C2-›SR1 & I2C_SR1_SB)==0)
(void) I2C2-›SR1;

I2C2-›DR=SlaveAddrR; //send slave addr with R-bit
(вся запарка происходит в ассемблерном коде операции выше)

I2C_data=I2C2-›DR;

I2C2-›CR1 &= ~I2C_CR1_ACK ;
I2C2-›CR1 |= I2C_CR1_STOP;
I2C2-›CR1 &=~ I2C_CR1_PE;

}
убрал пару проверок, нафиг их, всё и так работает- смотрел на осциллографе
ещё раз повторю, данные приходят корректные - это видно в при внутрисхемной отладке (делаю на STM32 -Discovery), но сразу после их прихода в датаригистер заменяются на FF

[=GM=]

Для начала надо бы после операторов while(. . .) точку с запятой ставить, а то у вас многократно следующий оператор выполняется

[=GM=]

Чего-то с косвенной адресацией не получилось, буду учиться дальше

Попробуйте вот так

char buf[256];
char *p=buf;
unsigned long *pbi;
pbi=&GPIOB-›IDR;

*p++=*pbi;
*p++=*pbi;
. . . . . . . . .
*p++=*pbi;

[Sergi_alc]

Попробовал. Не получилось
char inp[100];
char *p=inp;
uint32_t volatile *pbi;

pbi=&(GPIOB-›IDR);

*p++=*pbi;

дает вот такой код при любой оптимизации
LDR R1, [R4, #0x6c]
ADDS R0, R1, #1
STR R0, [R4, #0x6c]
LDR R0, [R4, #0x70]
LDR R0, [R0]
STRB R0, [R1]

[=GM=]

Компилятор делает то, что вы хотите. А вы хотите на каждой выборке за каким-то шутом сохранять содержимое текущего указателя в памяти. Спрашивается, зачем? Вы ж его тут же на следующей выборке затираете. Снимите атрибут volatile, и будет вам щастье.