ChibiOS Free Embedded RTOS

It's impossible that these codes show the same behavior.


This will print "test....\r\n" to the SD2 driver once and then it won't do anything anymore in that thread, where the following one will print it over and over again:



~ Tectu

Of course your right i mean these are same in printing the whole of the string but one of them once and the other in a loop.
the problem is to compare a delay with endless loop in this situation.
Thanks for your attention .
Regards

So your problem is still not solved, right?
I sadly forgot to test it on my hardware and right know I'm again somewhere where I don't have any. I will try this tomorrow evening, but as Giovanni already said, this should work (as in, no characters get lost).


~ Tectu

it is solved but not completely.
i sure that the problem is come from chThdSleepMilliseconds(1);
Thank you.

Did you check for stack overflows as I mentioned in my first post?

Giovanni

M.H.Roohi wrote:Thanks for reply.
i use MDK-KEIL
Here is my simple code:

Code: Select all

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include "ch.h"
#include "hal.h"
#include "chprintf.h"

int main(void) {
  /*
   * Shell thread
   */
  halInit();
  chSysInit();

   sdStart(&SD2, NULL);
  palSetPadMode(GPIOA, 2, PAL_MODE_ALTERNATE(7));
  palSetPadMode(GPIOA, 3, PAL_MODE_ALTERNATE(7));
   //while(TRUE)
   {   
      chprintf((BaseChannel *)&SD2, "test....\r\n");
      chThdSleepMilliseconds(1);
   }
}

Regards

I expect the reason this doesn't work is because the //while(TRUE). This function will exit and return to the default clibrary atexit() function or __exit or something along those lines. Either uncomment the //while(TRUE) or add a longer sleep, perhaps 100ms.

The while(TRUE) does for sure not cause the problem unless a memory stack issue as Giovanni now mentioned two times, please check this!


~ Tectu

Tectu wrote:The while(TRUE) does for sure not cause the problem unless a memory stack issue as Giovanni now mentioned two times, please check this!


~ Tectu

It most certainly can. For example, if the baud rate is 9600, it will take 1ms per character to exit the serial data register. In this case, the thread will wake up, and exit the main() function before the complete string has been transmitted out the serial port. If this were to happen, you can probably kiss your stack goodbye, and the OS is no longer running, etc.

I agree, that's why I wrote "unless a stack issue". I just meant that the while(TRUE) itself doesn't do anything to the system or the HAL itself that would do anything bad. And most likely, that's why Giovanni mentioned to check the stack stuff as well.


~ Tectu

Tectu wrote:I agree, that's why I wrote "unless a stack issue". I just meant that the while(TRUE) itself doesn't do anything to the system or the HAL itself that would do anything bad. And most likely, that's why Giovanni mentioned to check the stack stuff as well.


~ Tectu

If the program exits main(), there is no stack issue; there is no stack, there is no system, no hal, it is dead. This is why adding a while(1) after the print works or putting the print in a while(1) loop works. The code is functioning as written and exiting main(). If the uart driver (unbuffered) was used instead of the serial driver (buffered), you would see the complete print.