This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Printing "Hello World" to terminal from some board including nrf51822.

I'm a begginer in embedded program. I have a mbed HRM 1017 that is pin-compatible with Nordic PCA10004. . I'd like to make a simple app to print out "Hello World" to terminal.

#include <stdio.h>

/*
 *
 * Print a greeting message on standard output and exit.
 *
 * On embedded platforms this might require semi-hosting or similar.
 *
 * For example, for toolchains derived from GNU Tools for Embedded,
 * to enable semi-hosting, the following was added to the linker:
 *
 * --specs=rdimon.specs -Wl,--start-group -lgcc -lc -lc -lm -lrdimon -Wl,--end-group
 *
 * Adjust it for other toolchains.
 *
 */

int
main(void)
{
	while(1)
		printf("Hello ARM World!" "\n");
  return 0;
}

image description

This code was created by eclipse on Mac. I built this code to hex file and copied it to mbed through USB.

although I had been watching terminal by "screen /dev/tty.usbmodem1422 9600", Nothing printed.

Parents
  • This isn't what you asked, but for posterity:

    I spent some time trying to get semi-hosting based IO working on the NRF51822. This would allow, for example, printf output from code running on the chip to be displayed in a debugger like GDB.

    While I was finally able to get it to "work," but it's so slow that it causes the BLE stack to fault due to timing errors. Your code is essentially paused while the semi hosting software interrupt is running, which means that you potentially miss responding to BLE stack events in a timely manner.

    I think UART serial is the best answer for debug logging, as Håkon described.

    HTH,

    -c

Reply
  • This isn't what you asked, but for posterity:

    I spent some time trying to get semi-hosting based IO working on the NRF51822. This would allow, for example, printf output from code running on the chip to be displayed in a debugger like GDB.

    While I was finally able to get it to "work," but it's so slow that it causes the BLE stack to fault due to timing errors. Your code is essentially paused while the semi hosting software interrupt is running, which means that you potentially miss responding to BLE stack events in a timely manner.

    I think UART serial is the best answer for debug logging, as Håkon described.

    HTH,

    -c

Children
No Data
Related