I am trying to make a program which includes a beep noise. I work on a 32 bit Windows Vista. I am using the Code::Blocks IDE which runs on a GNU compiler. My sample code is -
#include <stdio.h>
#include <windows.h>
#include <dos.h>
int main(void)
{
Beep(750, 300);
printf("\n \n \t This is a dummy program for Beep.");
getch();
return 0;
}
On the Internet I read that we could also use \a in printf to make a beep. I tried that but it is not working. I checked my speakers and sound card. Everything is perfect but I hear no beep. Even the method I displayed in my sample code does not work.
The C standard recommends that writing '\a' to standard output produce an audible or visible alert signal, but it will not work if standard output is redirected. Likewise, some newer computers lack the PC beeper on which Windows Beep() and some terminals rely. To cause a Windows PC to play an alert sound in a desktop application, you can call the Windows-specific MessageBeep function, which plays a sound "asynchronously" (in the background while your program continues to run). The user can configure which sound is associated with each of these four values in the Sound control panel.
#include <windows.h>
/* Include one of these in a function */
MessageBeep(MB_OK); /* play Windows default beep */
MessageBeep(MB_ICONINFORMATION); /* play asterisk sound */
MessageBeep(MB_ICONQUESTION); /* play question sound */
MessageBeep(MB_ICONWARNING); /* play warning sound */
MessageBeep() is defined in User32.dll, so if this gives you link errors, make sure you're linking to the corresponding import library. In MinGW GCC (the compiler in Code::Blocks), add -lUser32 to the list of libraries passed to the linker.
MessageBeep(-1);
From the MSDN documentation:
MessageBeep function
Plays a waveform sound. The waveform sound for each sound type is
identified by an entry in the registry.
BOOL WINAPI MessageBeep( _In_ UINT uType );
... ...
Value for uType: 0xFFFFFFFF
Meaning: A simple beep. If the
sound card is not available, the sound is generated using the speaker.
Also, and to my surprise, I've tested that. at least Windows 7 32 bits (and Windows Vista surely too) do some sort of emulation for the old 8253 I/O ports and the keyboard port, available to ring 3 processes, so the old implementation of sound() and nosound() should work. Unfornately, I haven't got any 32 bit machine available ATM so I cannot confirm this.
Beep does work again in Windows since windows 7. The format is:
Beep(frequency, duration) where frequency is the pitch in hertz, and duration is the length in milliseconds
See https://msdn.microsoft.com/en-us/library/windows/desktop/ms679277(v=vs.85).aspx
For the Beep() function in windows.h to actually work, you have to have a "PC speaker" buzzer in your PC, as stated in the function's documentation. So you need to have a fairly old PC and with Windows XP or older, since support for the function was apparently dropped in Windows Vista.
On newer Windows versions, calling Beep() gives a beep in the speakers instead, using your sound card. If you aren't getting any beep, it is possibly not related to the program, but perhaps to your specific computer hardware.
This one works to on Windows 7 compiled with Visual Studio 2017. No problems with that.
printf("\n Bad request - check status code parameter\a");
You can use \a. At least it works in my computer.
Related
I am using a SAMD21XPlained Pro board on Mac (OS Big Sur) with MPLAB X IDE v6.00 (XC32 compiler) and I am currently experiencing a problem when trying to display a message on my terminal via the printf() function.
I am a beginner in embedded programming and I try to follow this tutorial about STDIO Serial Communications : https://www.youtube.com/watch?v=3pwdpYj5s_A&t=397s
Based on this tutorial I first tried to do only a printf() but I didn't see anything on the terminal (I didn't try the scanf() for this first try).
The only thing I changed is that I included the stdio.h file and I did a second test with a baud rate 9600 (because I don't really know how to define the baud rate and I wanted to test like that).
I have read on several forums that the problem comes from the fact that the XC32 compiler uses by default the UART2 while the printf() must use the UART1 to be displayed on the terminal.
Several people suggest to include xc.h to redefine the default UART1 (__XC_UART = 1) but this seems to work only for PIC32MX µCs.
According to my research in the XC32 compiler files, the xc.h file for PIC32MX is not the same as the one for PIC32/SAM and only the one for PIC32MX defines __XC_UART.
I also tried to apply what is proposed in "Microchip Developer Help" for "Redirect stdout for Use With printf()" in the XC32 category:
https://microchipdeveloper.com/xc32:redirect-stdout
The problem is that it also seems to be only for PIC32MX µCs (the p32xxxx.h file that is included at the beginning of the code exists only for PIC32MX in the XC32 compiler).
After a few days of research, I tried many solutions proposed on different forums but I still can't find the one that works so I was wondering if you have an idea?
Thank you !
I'm trying out RIOT OS for the first time. After downloading source, I can build applications pretty easily, including targets that need the ARM toolchain.
The hello-world application runs fine on my Linux build machine (built using BOARD=native) and prints in the terminal.
When I switch to an embedded platform (Nucleo F411 e.g. ARM Cortex M4) where can I expect any puts() or printf() calls to appear? Further, how can I setup printf() to go to UART1 if that's not where it's going already?
Apologies if this is too specific for SO. I'm not familiar with the RIOT OS mailing lists but I'll try there as well.
EDIT: The hello-world example is really bare bones, as follows:
#include <stdio.h>
int main(void)
{
puts("Hello World!");
printf("You are running RIOT on a(n) %s board.\n", RIOT_BOARD);
printf("This board features a(n) %s MCU.\n", RIOT_MCU);
return 0;
}
I am compiling with the ARM GNU toolchain, gcc-arm-none-eabi-7-2017-q4, after following install instructions here: link. I figure I am going to need some extra compiler flags, or editing the board init functions outside the application code above. But, at this stage, I don't know where to start. My end goal is to observe "Hello World!" and "You are running..." on pin TX/D1 of my dev kit after configuring it to go there.
In RIOT OS, by default the stdio is mapped to UART0. This can be seen here:
https://github.com/RIOT-OS/RIOT/blob/master/sys/include/stdio_uart.h#L38
By redefining STDIO_UART_DEV you can map the stdio to a different UART. If you want to know which UART is mapped to which pins, have a look in the periph_conf.h of your board, which in case of the Nucleo F411 is here:
https://github.com/RIOT-OS/RIOT/blob/master/boards/nucleo-f411re/include/periph_conf.h#L56
The toolchain you are using uses the Newlib C library (rather than GNU's libc which has POSIX dependencies). To port newlib to your target, some standard functions require re-implementation of at least some of the syscalls stub.
Specifically for stdout to work, you need to implement at least _write_r(). If the UART is the only device you will ever support, you can ignore the file descriptor - for stdout it will always be 1 (0 = stdin, 2 = stderr).
As an aside if you want malloc() et al to work, you need ot implement _sbrk_r().
Bill Gatliff's article on embedded.com provides examples for Newlib porting for uC/OS - the principles are probably similar for RIOT OS, but equally you could make it simpler if your library I/O needs do not need to be that sophisticated.
On embedded systems the user has to implement the function putchar(char chr) to output a single char. This function can use UART for example.
The function should look something like:
int fputc(int ch, FILE *f)
{
/* Place your implementation of fputc here */
/* e.g. write a character to the USART */
HAL_UART_Transmit(&huart1, (uint8_t *)&ch, 1, 100);
return ch;
}
Here you find a more complex example for an STM32F0
https://github.com/bjornfor/stm32-test/blob/master/STM32F0xx_StdPeriph_Lib_V1.0.0/Project/STM32F0xx_StdPeriph_Examples/USART/Printf/main.c
Embedded microcontroller system compilers fall into a category called freestanding implementations. This means that they don't have to provide libraries like stdio.h and you can't expect printf to be available.
There is however a probability that there's a compiler library implementing stdio.h through UART transmission. You will have to check if your compiler implements this or not.
Just for simple tests and "hello world"-like applications, it is far easier just to use GPIO pins. The embedded systems equivalent of "hello world" is to flash a LED.
I have the original code that is meant to compile in Windows and Linux using gcc.
It works fine even under cygwin. Now, when I try to compile for iOS
echo $OSTYPE
darwin14
everything seems fine and a build is successfully obtained. However, when I tried to run the CUI app, a message Segmentation fault 11 is displayed.
After a couple of days searching on internet, by chance I found this link.
As a result, I made the following change in one of the *.c file
-#define _POSIX_C_SOURCE 199309
+#define _POSIX_C_SOURCE 199506
and the new build works fine. Although I am not a programmer, I am wondering what would be so significant different between these two macros? Could you comment on why such change becomes so significant.
though it is only 1 line of code,but it may make big difference,POSIX is a standard,it define the interface between OS and applications,and it has many different version(you can think it similar with a hardware USB standard , it has many version, like USB 1.0 and USB 2.0).
sometimes programmer can't determine which platform the program will be work on , it may run on Linux , may run on windows, maybe the system provide old standard interface, maybe a new one.
So , programmer add this kind of macros, write codes for many different interface,for example ,a source code like this:
#define WIN
#ifdef WIN
<part 1:1000 lines of code>
#endif
#ifdef LINUX
<part 2:1000 lines of code>
#endif
<1000 lines that not depend on system , can both run on Linux and Windows.>
the compiler will compile part 1(discard part 2), but when you change #define WIN to #define LINUX , it will contain part 2(and discard part 1) ! you may think you only changed 1 line , but the compiler may choose or discard thousands of lines (maybe even more ,maybe less, that depend on the code)
I have written a simple C program that outputs '\a' to the standard output via printf(). I have compiled it with gcc under Cygwin on a PC running Windows 7. The sound I hear when I execute the program is a VERY faint version of the one of the usual Windows alert sounds (it sounds like a chord being struck on some kind of musical instrument). But I cannot get a sound that has the usual volume of this sound. Is there a way to get that volume?
Output '\a' with printf() normaly outputs a beep through the integrated pc-speaker. To play a veep via the soundcard use MessageBeep from the WinAPI.
For example:
#include <Windows.h>
int main() {
MessageBeep(MB_ICONERROR);
return 0;
}
I have a little routine that's run under Linux and Windows written in C and displays output on the console. I'm not linking in any form of curses or anything like that.
Currently I clear the screen using
#ifdef __WIN32
system( "cls" );
#else
system( "clear" );
#endif
Then I have a bunch of printf statements to update the status. What I'd like just reset the screenpointer to 0,0 so I can then just overlay my printfs. I'd rather avoid compiling in any more extensions especially since I'm coding for 2 different OS'.
For Unix-like platforms, the usual way to do this is using the curses library.
Looks like I may have found a windows specific way of doing it SetConsoleCursorPosition
Ansi escape sequence \033[0;0H for Linux - just printf that to the console.
Yes, for unix platforms, curses (or ncurses, these days) is the way to go. And there are versions that work under windows, so you could do it the same way on both systems.
For windows - You can use ANSI escape characters.
http://www.lexipixel.com/news/star_dot_star/using_ansi_escape_sequences.htm
http://www.robvanderwoude.com/ansi.html
printf "\x[0;0H"
It used to be that Ansi.sys needed to be loaded before you could do this, but it's worth a shot.
Instructions for adding ANSI support
http://www.windowsnetworking.com/kbase/WindowsTips/WindowsXP/UserTips/CommandPrompt/CommandInterpreterAnsiSupport.html
Note: that Ansi.sys only works under command.com. You can't use it with cmd.exe