Uart comunication

[AlbaChris]

Hey there I'm new to develop STM32 software ,my setup is 2 dev kits with bluepill cards ADC sensors buttons etc (they ll use same code and comunicate each other ), I have doubt on Uart COM, because I see a problem on PA2_EX_CRONO and PA2_EX_ADC which I cant receive data from 2nd kit and code stucks on that part of process , there is an example of video what happens and the code requirements list:

a.1) From the MCU RESET, test to see if the displays (4x7-SEG) are working on the shield. The test should turn on all display segments and their decimal points: and remain that way;

a.2) Also from the RESET, the program should trigger an increasing timer; a.3) and should also trigger an ADC converter that samples continuously, we will read an analog value on pin PA0. The ADC sampling rate will be 5 samples / second.

b) Whenever you press button A1 (PA1) on the Arduino shield, the 7-SEG display alternates the timer and ADC value every 4 seconds (2v/4s: 2 values/4 secs => timer for 4s, ADC for 4s, continuous loop). b.1) The timer will be shown on the display panel in the following format: minutes (1 digit), “decimal point” on, seconds (with 2 digits), “decimal point” on, tenths of a second (1 digit): ; b.2) The ADC will be shown in the following format: unit, “point” on, hundredths, tenths, and thousandths of a Volt; that is, as was done in practice 5 of the laboratory classes: ; b.3) to distinguish the value shown on the display, blink LED 1 (PB15) when the timer is displayed, and blink LED 2 (PB14) when the ADC value is displayed. Of course, the format of the values ​​on the 7-SEG display already indicates which measurement is on the display, but we will use the blinking LEDs as well;

c) Whenever you press button A2 (PA2), your kit should start communicating with another board and should, from then on, search for data from a colleague’s kit. You start to ‘request data’ from the other board. c.1) If you press A2 before A1, your values ​​will not be displayed, but the values ​​from the other kit will be; that is, your board will continue to display , but the data from the other kit will be displayed. d) When you press A2, your board changes the display mode to 4 values ​​for 2 seconds (4v/2s); showing: * for 2 seconds, LED D1 flashing, it should display its own timer (or ); ** for 2 seconds, LED D2 flashing, it should display its own ADC (or ); *** for 2 seconds, LED D3 - PB13 flashing, it should display the value of your colleague’s timer; **** for 2 seconds, LED D4 - PB12 flashing, it should display the value of your colleague’s ADC;

d.1) If you press A1, your board returns to displaying secs mode (2v/4s); e) when pressing button A3 (PA3) you will request a service from your colleague's board: you ask that the buzzer on your colleague's kit (alarm) be activated five times for 200 ms with a 200 ms interval of silence. When pressing A3, you must send a message to the other kit asking it to sound the alarm. Vice-versa, when your colleague sends you the same message, you must activate the buzzer on your board.

f) HOW will communication between the boards work:

f.1) what type of data will your boards exchange? * 5 bytes encoded in ASCII I made the description clearer in the main.h file: /* -=-=-=- "rqcrn" requests the sending of the TIMER value from the other kit to yours "rqadc" requests the sending of the voltage value, in Volts.millivolts, from the ADC of the other kit to yours "rqbzz" requests that the colleague sound the buzzer (5x 200ms for 200 ms OFF) "XXXXa" your kit receives / sends 'a' + the ADC digits in ASCII "XXXXc" your kit receives / sends 'c' + the timer digits in ASCII The message with data is assembled from MSD BufOUT[0] to LSD BufOUT[4], with 5 characters; BufOUT[4] contains the 'token' "a" or "c" indicating the type of value EXAMPLE: if the value to be sent in the ADC is 1.234 V then the message will be like this in the OUT buffer:

BufOUT[0] ='1'; // unit of volt

BufOUT[1] ='2';

BufOUT[2] ='3';

BufOUT[3] ='4'; // thousandth of a volt

BufOUT[4] ='a'; // token

[Peter BENSCH]

Welcome @AlbaChris to the community of STMicroelectronics!

Blue and other colourful Pills are neither a product of STMicroelectronics nor use an original MCU from STMicroelectronics, but have only contained counterfeit MCUs for years. There are plenty of similar threads here in the community with similar problems, e.g. here or there.

In this respect, you should contact the manufacturer or the supplier of this Blue Pill.

Regards
/Peter

[Andrew Neil]

You seem to have posted your entire homework assignment - most of it has nothing to do with UARTs.

So which part(s) of that, exactly, are you having trouble with? 

When working on any comms project, it's always a mistake to try to develop both ends of the link at once: because then you won't know whether problems are with one end, or the other end - or both ends.

https://community.st.com/t5/stm32-mcus-products/i2c-communication-between-two-different-stm32-evk-boards/m-p/755042/highlight/true#M268963 

Instead, work on just one end, and test it against a known-good device at the other end.

For UART comms, a PC COM port and terminal program are ideal as a "known-good device".

So take things step-by-step:

1. send a single, fixed string from your microcontroller to the PC terminal.
   Verify that it's received correctly.
   Practice using the debugger to observe the operation in your microcontroller.
2. Once that's working, use it as a basis to move on to sending variable strings.
   Again, verify against the terminal.
   Keep practicing with the debugger.
3. Add receiving characters.
   Test by sending characters from the terminal; examine what's received in the debugger.
4. Bring the two parts together: send what you receive back to the terminal (ie, do a "loopback").
5. etc, etc, ...

Once you have it working well with the terminal, then you can move on to connecting two microcontrollers.

And the practice with the debugger will help you to debug your code...

General Getting Started tips:

https://community.st.com/t5/stm32-mcus-products/for-better-learning-stm32-programming-and-debugging/m-p/719468/highlight/true#M260690

Getting Started with the STM32 UART:

https://wiki.st.com/stm32mcu/wiki/Getting_started_with_UART

https://community.st.com/t5/stm32-mcus/implementing-uart-receive-and-transmit-functions-on-an-stm32/ta-p/694926

Debugging Serial Comms:

https://community.st.com/t5/community-guidelines/how-to-write-your-question-to-maximize-your-chances-to-find-a/tac-p/706966/highlight/true#M49

#BothEnds #UARTBothEnds #UARTGettingStarted