SoftwareSerial

Please do not post requests
User avatar
Rick Kimball
Posts: 1058
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: SoftwareSerial

Post by Rick Kimball » Sat Dec 10, 2016 7:35 pm

-rick

konczakp
Posts: 191
Joined: Thu Jul 14, 2016 4:17 pm

Re: SoftwareSerial

Post by konczakp » Sat Dec 10, 2016 9:30 pm

Yes I did. And none of them were working for me. And not only for me according to this thread: http://www.stm32duino.com/viewtopic.php ... 4&start=10

User avatar
Rick Kimball
Posts: 1058
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: SoftwareSerial

Post by Rick Kimball » Sat Dec 10, 2016 9:32 pm

So for grins I tried changing out the tunedDelay() with one that uses the dwt_timer:

Code: Select all

... and someplace else I defined cycle_timer as dwt_timer and initialized it

inline void SoftSerialSTM32::tunedDelay(uint32_t delay) { 
    cycle_timer.delay_cycles(delay);
}

I had to change the table .. but I only bothered with the tx value

{ 9600, 353, 718, 25, 7425, },

(1/9600)/(1/72000000) = 7500 .. i then measured and adjusted down to get closer
to 104.1666 using the 7425 value. That produced 104.2 us on my scope .. not too bad.

Although this works, you would have to change all the table values. The bigger problem I see is receiving. If you received serial bytes when you aren't expecting them they are bound to get dropped with a cycle timed solution.

-rick
-rick

User avatar
Rick Kimball
Posts: 1058
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: SoftwareSerial

Post by Rick Kimball » Sat Dec 10, 2016 10:11 pm

So @konczakp , how many UARTS do you actually need?

I could imagine the solution above using the dwt_timer maybe working. You could use software serial for devices that are output only. Devices that use a command response protocol where you send data and then wait for a response might also be OK. If you limit the hardware UARTs to those peripherals that send you unsolicited data, like say a user typing data in a terminal, it might all work.

-rick
-rick

User avatar
mrburnette
Posts: 1892
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: SoftwareSerial

Post by mrburnette » Sat Dec 10, 2016 11:16 pm

konczakp wrote:I was using multiprocessors platform with Atmega128P and I don't want to do that again. I'm porting all my code from that multiprocessors platform to maple because making changes was an horror for me. Changing one thing was bringing other changes on other processors etc. Maybe I had badly designed platform ... i don't know. Maybe I could go up with the architecture to get more I/O pins but unfortunately at the time I've started to port my project I didn't have that knowledge. So now I have to stick what I have chosen. So now I have a problem with this software serial so If anyone could help I will appreciate that :)

BTW : Now I'm also using multiprocessors with I2C communication (trying to use as it can be seen in other thread) but this time in different way :)

Sadly, you are going down the "rabbit hole" ... tell the white Rabbit 'hello' for me.

In corporate America, IT Operations, I have heard your argument far too many times; to paraphrase, "... we did not realize the numerous challenges we would face when we started, but we are too deep into this project to start from the beginning ... Now, how to we make what we have work?"

I will tell you that your forward motion is wrong, but I cannot tell if you will fail because I do not know how cleaver you are - the story of Frankenstein is the story of a mad doctor that has success, of sorts.

In summary,
Changing one thing was bringing other changes
, is your design problem. When system design is done correctly, changes to any black-box does not require changes elsewhere (to other black boxes.)


Ray

User avatar
Rick Kimball
Posts: 1058
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: SoftwareSerial

Post by Rick Kimball » Sun Dec 11, 2016 6:00 pm

konczakp wrote:Yes I did. And none of them were working for me. And not only for me according to this thread: http://www.stm32duino.com/viewtopic.php ... 4&start=10
I tried the SoftSerialIntCC class and the examples failed for me on a blue pill but worked on a maple_mini. I switched the pins and I got it to work properly on PA1 and PA0.

Here is code that worked for me on both the maple_mini and bluepill:

Code: Select all

#include <SoftSerialIntCC.h>

SoftSerialInt mySerial(PA1, PA0, 2);

void setup()  
{
  // set the data rate for the SoftwareSerial port
  mySerial.begin(115200);
}

void loop() // run over and over
{
  pinMode(LED_BUILTIN,OUTPUT);
  digitalWrite(LED_BUILTIN,LOW);
  while(1) {
    digitalWrite(LED_BUILTIN,HIGH);
    mySerial.write('U');
    delay(100);
    digitalWrite(LED_BUILTIN,LOW);
    delay(400);
  }
}
I think the problem is the PIN_MAP configuration of the generic stm32f103c8 with regard to timers and channels. However, the SoftSerialIntCC code should be smart about it and yell at you if you are using the wrong pins or trying to use a pin not configured for PWM.

There might be other pin/timer combinations that might work but you will have to dig in yourself. So that is yet another option to you. @konczakp

Note: If it seems I might be obsessed with this it comes from when I first started working with the msp430g series. None of chips they offered had a real UART. I spent an inordinate amount of time perfecting a timer based UART serial. Eventually, I got it to happily do 115200 baud in full duplex. So it seems to me that an STM32F103 with all the CPU cycles and available timers should be able to do even better than that.

-rick
-rick

konczakp
Posts: 191
Joined: Thu Jul 14, 2016 4:17 pm

Re: SoftwareSerial

Post by konczakp » Mon Dec 12, 2016 1:44 pm

I don't know how You are doing this :( I cannot get this working. Here is my test code :

Code: Select all

#include <SoftSerialIntCC.h>
//#include <SoftSerialSTM32.h>

#define TX_PIN PC14
#define RX_PIN PC15

SoftSerialInt mySerial(RX_PIN, TX_PIN, 4);
//SoftSerialSTM32 mySerial(RX_PIN, TX_PIN);

unsigned long previousMillis = 0;       


const long interval = 2000;           

void setup() {
  Serial.begin(115200);
  mySerial.begin(9600);
}

void loop() {

  unsigned long currentMillis = millis();


  if (mySerial.available() > 0){
    Serial.println(mySerial.readStringUntil('\n'));
  }


  if (currentMillis - previousMillis >= interval) {
    
    previousMillis = currentMillis;

    mySerial.println("AT");
    Serial.println("Sent");
    
  }
}

If I use softserialSTM it is working while if I change to softserialCC it is not. I've tried all 4 timers. Where is the problem? Does it mean that I can use only those pins which has a timer attached to them and PWM option? Then It should work with UART 1 which I've tried and I also cannot get this working.

I didn't understand Your earlier post about softserialSTM. What should I change to get second softserialSTM working? You have mentioned some table and delays but can You clarify that in a simpler language ?

User avatar
mrburnette
Posts: 1892
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: SoftwareSerial

Post by mrburnette » Mon Dec 12, 2016 2:01 pm

konczakp wrote:<...>
If I use softserialSTM it is working while if I change to softserialCC it is not. I've tried all 4 timers. Where is the problem? Does it mean that I can use only those pins which has a timer attached to them and PWM option? Then It should work with UART 1 which I've tried and I also cannot get this working.
<...>?
In a forum of brilliant people, such a question of "Where is the problem?" is simply not a polite inquiry, IMO. We are all working with a 1-off core, that is, it is not officially supported by Arduino. All of the effort todate has come from volunteers who have a soft-spot in their heart for the STM32 devices. Everything that is published comes with the no-guarantee guarantee! You get what you get. If you are knowledgeable, have the expertise, and are willing then ferret out the issue(s) in softserialCC and fix them for the greater good.

As I see it from a project standpoint, you have a working solution in softserialSTM; therefore you have a working base of code to compare to softserialCC that will assist you should you wish to investigate further. There are a number of folks in the forum very familiar with the inner workings of the STM32F1xx and it is likely that one or more will delve into the problem ... but, maybe not. There seems to be lots of activity, but also a good deal of distraction with individual initiatives and forum initiatives such as the new Arduino core for the Discovery board.

Most of the member I know will go out of their way to help a member get over a blocked path so they can continue forward. But if you have a personal preference between "A" and "B" and one works and one does not ... seems to me that the critical nature of your problem is a personal one. Perhaps if you make a matrix of your findings, timer settings, and snippets of code then that will assist you in finding your own solution - and if not, perhaps one of the members will be able to take your effort, do some analysis, and see something that is obvious.

Ray

konczakp
Posts: 191
Joined: Thu Jul 14, 2016 4:17 pm

Re: SoftwareSerial

Post by konczakp » Mon Dec 12, 2016 3:17 pm

@mrburnette Since a few posts You are saying how wrong I am and how badly is my project designed in a sarcastic way which is impolite IMO. While You have nothing to say in the subject of this topic! As You wrote there are many brilliant people on this forum, with a very good programming skills, willing to help. I'm also helping If I have a knowledge on that particular problem. As I wrote earlier the problem is not that I have one working code and I need another solution but the problem is that it is not working well and I did some tests asking for help. You would know that If You would read whole topic. And yes maybe someone will point me something that is obvious but I'm trying with this since few days and I've stuck. Maybe some day someone will show You something that is obvious for everyone but not You! Will that change anything? But IMO forum is a place to help each other without being impolite. Moreover here are also people with a basic skills willing to build something and asking as You said "obvious" questions. With Your attitude I would rather say that You think this forum is for hi level skilled programmers only. I don't want to waste Your time so simply unsubscribe from this topic unless You have something to say in a topic of SoftwareSerial.

User avatar
Rick Kimball
Posts: 1058
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: SoftwareSerial

Post by Rick Kimball » Mon Dec 12, 2016 3:22 pm

konczakp wrote:I don't know how You are doing this I cannot get this working. Here is my test code :
SoftSerialIntCC has specific restrictions per the readme. You can't just use arbitrary pins and timers. I went looking though the PIN_MAP table (defined in variants/bluepill/board.cpp) to find some pins configured to meet those restrictions. There are only a few and I only tested the one I mentioned in the test code above.

Specifically in the readme, it states:
"Restrictions

Must use correct pins assigned to the capture/compare input/outputs of the timer you select. As currently defined: TX pin = Timer channel 1 RX pin = Timer channel 2 Of course, this can be changed by modifing the definitions under "Timer Channel Definitions" in this file."


That means you have to find 2 pins that are configured to use the same timer and then happen to use channels 1 and 2 of that timer. These tables are specific to each the variant board you are using. Based on the bluepill board.cpp PA0 and PA1 seem to meet the criteria:

PA0 needs to be the TX pin
{&gpioa, &timer2, &adc1, 0, 1, 0}, /*PA0*/

PA1 needs to be the RX pin
{&gpioa, &timer2, &adc1, 1, 2, 1}, /*PA1*/

Looking further down the table it seems like PB6 and PB7 might also work you would need to try.

I mentioned earlier that the SoftSerialIntCC code knows what is valid but doesn't do anything to enforce it. It just fails silently. If you use two pins that are different timers it is going to fail. If you use two pins that aren't using channel 1 and 2 it is going to fail. If you use a pin for TX that is configured for channel 2 it is going to fail. If you use a pin for RX that is channel 1 it is going to fail. My point was, the SoftSerialIntCC knows these problems and does nothing to prevent you from falling down. Unlike the arduino avr world where the pins and their function are cast in stone and make it easy to write code everyone can use, you are using a "generic" stm32 board and that comes with lots of responsibility for figuring out why your code does or doesn't work.

I extracted the pin_map table from board.cpp so I could use linux filters utilities on it:

Code: Select all

$ sort -t, -n -k5,5 a.c | grep timer1
{&gpioa,&timer1,NULL,8,1,ADCx},/*PA8*/
{&gpioa,&timer1,NULL,9,2,ADCx},/*PA9*/
$ sort -t, -n -k5,5 a.c | grep timer2
{&gpioa,&timer2,&adc1,0,1,0},/*PA0*/
{&gpioa,&timer2,&adc1,1,2,1},/*PA1*/
$ sort -t, -n -k5,5 a.c | grep timer3
{&gpioa,&timer3,&adc1,6,1,6},/*PA6*/
{&gpioa,&timer3,&adc1,7,2,7},/*PA7*/
$ sort -t, -n -k5,5 a.c | grep timer4
{&gpiob,&timer4,NULL,6,1,ADCx},/*PB6*/
{&gpiob,&timer4,NULL,7,2,ADCx},/*PB7*/
The list of above are the pins that might work. You have to verify. .. Although PA8/PA9 is probably useless as that is already a HW UART and PA6/PA7 are SPI pins. and PB6/PB7 are I2C pins. ... So you don't have many real choices with those. You might actually have to change the SoftSerialIntCC code to use different channels to make this work for you.

-rick

[edit]
Show where the timer# & channel numbers are found for PA0 and PA1 in the stm32f103c8 datasheet:
f103_pin_table.png
f103_pin_table.png (35.76 KiB) Viewed 566 times
[/edit]
Last edited by Rick Kimball on Mon Dec 12, 2016 11:28 pm, edited 2 times in total.
-rick

Post Reply