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 !
Related
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 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.
I am very new in Blackfin processors and I suppose to write a tester program for Blackfin, BF527. This tester program should test the connection of the board and 2 peripheral RAMs.
So far I have downloaded and installed VisualDSP++ (90-day trial version).
Can anyone help me to know how can I write a simple program to write in port G and read From port H, including initialization (preferably in C).
I have looked for sample code on internet but unfortunately all the codes are very advance.
I went through the data sheet, but it was on assembly not C, still I couldn't find any solid sample program for my purpose.
Look in the VisualDSP installation folder (under Program Files). There is lots of sample C and C++ code in Analog Devices\VisualDSP 5.0\Blackfin\Examples
To program the hardware peripherals from C/C++ you need the header files which contain the pointer definitions for the memory-mapped registers. These will be found in Analog Devices\VisualDSP 5.0\Blackfin\include
In your code you can automatically select the correct include file for the project's processor using:
#include <blackfin.h>
I am working with XC8 1.20 and a PIC18F66K80 and having some trouble with using the pwm.h library. Whenever I open pwm.h, the only functions that are actually being generated (IE, the #ifdef compile time conditionals are returning true) are for PWM1. After tracing through the code, I came to the pconfig.h file and went down to the section regarding the 18F66K80, and it was all being ignored.
The conditional that was returning false is:
#ifdef __18F66K80
In fact, there were no sections that were being compiled. It was like I had no chip selected, even though the project was targeting the 18F66K80. I went into the compiler macro options and add __18F66K80 as a defined macro, and this block suddenly was compiling, giving me access to PWM2-5.
My question is - what is the correct way to tell pconfig.h what chip I am using? My project settings clearly show the PIC18F66K80 as the target device, but pconfig.h was acting like I had no chosen device. By adding this macro, it appears to work, but I have a feeling this is a hack and not the right way to do things.
I am not getting answers on the AVR Freaks forum and wonder if someone here could help me.
The answer might lie in this SO question, but I am not sure why it would be necessary.
Basically, I have my fist ever Atmel project (AVR studio 6, UC3 processor). The code compiles and links and I can load it to the Atmel board and step through in the debugger.
However, when I try to step over (or run until a breakpoint on the line after) a (valid) call to sprintf(), malloc() or memcpy() (there may be more, which I have not yet discovered), the IDE never returns to the next line of my code, just seeming to hang, or run forever.
[Note] Compiler optimization is off
Do I need to set some linker options (e.g link static (which I tried & it didn't help)? Or build with some library?
What confuses me is that the code compilers and links - what is being linked when I call these standard functions? If I need something else I would expect a compiler or linker error, but get none - so why won't my code run?
Sorry for such a stupid n00nb question, but it is my first micro-controller project.
I discovered that the CPU on my board is an Engineering Sample and not supported by Atmel Studio without a new io.h file.
I sort of figured that out from this question: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=106652
Sorry to have troubled you.
what is being linked when I call these standard functions?
The AVR-libc, the implementation of the C standard library ported to the AVR platform.
so why won't my code run?
Compiler errors and runtime errors are not even related. Both of these lines are valid C and they compile, however, on most systems, I'd expect them to dump core:
int x = 1 / 0;
*(int *)0 = 41;
So it might be either:
a bug in the standard library (very unlikely), or
a bug in the online debugger (very unlikely), or
maybe you just expect something that is not supposed to happen?
Instead of trying to step over, what happens if you set a breakpoint at next line after the line you want to step over?
Also, does the operation change if you turn off compiler optimization?