Author Topic: STM32F4Discovery USART problems  (Read 15126 times)

0 Members and 1 Guest are viewing this topic.

Offline HackedFridgeMagnet

  • Super Contributor
  • ***
  • Posts: 1969
  • Country: au
Re: STM32F4Discovery USART problems
« Reply #25 on: February 10, 2013, 02:40:04 pm »
Sorry to be pedantic, but because I didn't know this I looked it up.

Apparently ++ and * have the same binding precedence but their group bind RL instead of LR. 

Yeah yeah, which effectively means ++ has the higher binding precedence.
 

Offline enz

  • Regular Contributor
  • *
  • Posts: 116
  • Country: de
Re: STM32F4Discovery USART problems
« Reply #26 on: February 10, 2013, 02:49:31 pm »
But then the asterisk does not do anything and is needless.

O_o

You don't use pointers very often, do you?

Of course i do.
Maybe you can explain what the asterisk would do exactly (and why they would be neccessary) in the following two statements:
1. *x++;
2. *(x++);

Regards,
Martin
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2018
  • Country: nl
Re: STM32F4Discovery USART problems
« Reply #27 on: February 10, 2013, 03:46:13 pm »
With the asterisk in you were incrementing the data you want to send, not the pointer. So this was an endless loop.
Actually, no. In C, "++" binds more tightly than "*". So "*x++" is really "*(x++)" which is why you can do e.g ."*x++ = 0;". The before and after statements are equivalent.

You are right, i missed the binding precedence.
But then the asterisk does not do anything and is needless.

I was replying to this particular quote. As in the combination of "*x++ = 0;" and "But then the asterisk does not do anything and is needless.". I was not replying to what you may or may not have been thinking while you were writing that. ;-)

But from your question I see what you meant to say.

Quote
Maybe you can explain what the asterisk would do exactly (and why they would be neccessary) in the following two statements:
1. *x++;
2. *(x++);
As for the answer, that would depend on how naive the compiler is, and what optimizations and such. In general I would expect those to just increment the x pointer. In fully pedantic mode, and on a platform where a memory access also performs a particular operation (memory mapped control register or whatnot) that cannot be optimized away, you could also expect it to do: 1) access memory at location x and then 2) increment x pointer.
 

Offline enz

  • Regular Contributor
  • *
  • Posts: 116
  • Country: de
Re: STM32F4Discovery USART problems
« Reply #28 on: February 10, 2013, 03:56:47 pm »
Quote
I was replying to this particular quote. As in the combination of "*x++ = 0;" and "But then the asterisk does not do anything and is needless.". I was not replying to what you may or may not have been thinking while you were writing that. ;-)

Ah, now that was the misunderstanding. I was only referring to the original code from the OP (where there is no assignement), not to the "*x++ = 0;" example.

In the original code (*x++;) there is no need for the asterisk. In fact, it leads to false understanding what should be achieved with this statement and should be removed.
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2018
  • Country: nl
Re: STM32F4Discovery USART problems
« Reply #29 on: February 10, 2013, 10:34:03 pm »
For extra confuzlement you could do "++*x++";. ;)
 

Offline enz

  • Regular Contributor
  • *
  • Posts: 116
  • Country: de
Re: STM32F4Discovery USART problems
« Reply #30 on: February 11, 2013, 07:48:10 am »
For extra confuzlement you could do "++*x++";. ;)

Nice try. But i think it may not be enough for getting acknowledged by the obfuscated c aficionados.  ;)
 

Offline skerdzius

  • Contributor
  • Posts: 26
Re: STM32F4Discovery USART problems
« Reply #31 on: February 15, 2013, 08:21:39 pm »
i can't explain this but i fix my connection like this:  i am using 115200 baudrate on my discovery board
Code: [Select]
init_USART1(115200); // initialize USART1 @ 115200 baud and on terminal i am listening at 38400 baudrate. then it works great  ;D thanks for help. maybe later i will find out a better solution, but it's enough  for now  :)

In other words, the baud rate is still wrong and was always wrong. And you are still in denial and call that a fix.
so i found out what was my problem. and it's rather shame for me :) i was using STM32F4xx_DSP_StdPeriph_Lib_V1.0.1 for all my projects, but all clocks, and settings were for STM32_eval board, and i am usint STM32F4Discovery. so i downloaded STM32F4-Discovery_FW_V1.1.0 edited project a bit, and now program is running as it's supposed to do. so happy now  ^-^
 

Offline ericksantosjaquez

  • Newbie
  • Posts: 1
Re: STM32F4Discovery USART problems
« Reply #32 on: December 01, 2013, 01:41:42 am »
Where you find the correct template?
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2018
  • Country: nl
Re: STM32F4Discovery USART problems
« Reply #33 on: December 02, 2013, 11:07:37 am »
Where you find the correct template?
If you read the previous posts you'll find code snippets by various posters.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf