i have STM32F4 with 512kb flash. i have 2 project: c++ with iostream and c with printf ( in both i have override __io_putchar to USART ). Code woth iostram has ~400kb, code with printf has 10kb. Is it normal? is any way to more optimalize cout ?
Thank you for help : )
Related
I tried this example for opening an adapter and capturing packets:
https://www.winpcap.org/docs/docs_412/html/group__wpcap__tut3.html
It prints the adapter list but after that pcap_open does not
return and locks Matlab. I have to quit and restart Matlab to continue.
If I do not pass the correct devicename to pcap_open but
something like "dummy", I get the correct error message.
Windump and WireShark function perfectly, so the installed WinPcap 4.1.3
is o.k.
I use Microsoft Windows SDK 7.1 (C) on Windows 10 and compile
in Matlab with:
mex -I.\WinPcap_developers_pack\Include .\WinPcap_developers_pack\Lib\x64\wpcap.lib ReadPackets.c
The defines and includes are:
#define WIN32 // otherwise the Unix branch is selected in pcap.h
#define HAVE_REMOTE // needed according to Q-23 of the WinPcap FAQ
#include "mex.h" // needed for Matlab
#include "pcap.h" // straight from this WinPcap example
Any ideas?
It only seemed like pcap_open did not return. Everything worked fine - invisibly. The cause was that stdout is buffered heavily so print statements for debugging did print only at the program's end.
The next statement was eventually used to flush and reveal what was going on:
mexEvalString("pause(0.01);");
The standard fflush and _flushall have no effect in mex-files.
On the web i have found a nice LCD library for use with a PIC16F877A. I worked with a sample but I need to change the output ports of the PIC.
The lib indicates a possibility but that does not work. So no other way then trying to understand the lib.
#define LCD_DATA_TRIS D
#define LCD_DATA_POS 0
//LCD_DATA_TRIS &=(~(0x0F<<LCD_DATA_POS));
TRISD &=(~0x0F);
The above brings me to a reduced and working macro but I want to eliminate it completely. Somehow that does not succeed. It has to do with the ~. I can not find the working of it.
Help appreciated
In the meanwhile I have found the answer.
TRISD &= 0xF0 since the ~ reverses all the bits in the hex value.
I'm trying to send sample text for making sure that UART_GPIO_Transmit function works well. I'm using two char arrays:
char aMESSAGE[8] = "WHATEVER";
char bMESSAGE[10] = "0123456789";
and this code for UART transmission:
HAL_UART_Transmit(&UartHandle, &aMESSAGE,10, 0xFFF);
HAL_UART_Transmit(&UartHandle, &bMESSAGE,10, 0xFFF);
Using screen in Mac OS X for viewing the serial output. However, I see this:
W��TE�ER�12�4��78�
The problem is on receiving side, screen has probably enabled parity checking and your MCU program don't set parity for transmitting, so in your example all characters with even parity are not accepted and you see ?
Or the problem could be also on opposite side that MCU set parity and computer don't accept characters with zero stop bit.
I am new to the site, and this looks like it may be a place to get some tips and help if any.
I am learning about "C calling Fortran subroutine", I have knowledge with C but not too much with Fortran.
Plus side: I've looked at some examples, and was able to compile a few.
Negative side: I am somewhat lost. I have a main program which can be designed using C or Fortran 90, and print_matrix.f and print_matrix.c.
Within the main.c program,
- populate array of 1-9 of a matrix size 3 by 3
- call the c function
- call the fortran subrountine
I already have the populated side(it may not be accurate), but I am stuck on the subrountine. The output of fortran and C has to be the same which will output through the print_matrix.f90 and print_matrix.c using makefile. I need help with the calling subrountine part, I just don't know where to begin with that :(
I just need help, any will be appreciated.
Honestly, it's a little hard to tell exactly what your problem is. But here's an example that works on my linux machine:
callf.c:
#include<stdio.h>
int main(int argc, char **argv) {
int i=0;
increment_(&i);
printf("%d\n",i);
return;
}
increment.f90:
subroutine increment(n)
integer n
n=n+1
return
end subroutine
Compiled with:
gcc -c callf.c
gfortran -c increment.f90
gcc callf.o increment.o -lgfortran
Result:
> ./a.out
1
The two hard parts are 1) getting the exact name of the function call and 2) knowing what flags are needed to link the two codes. Re: 1) I knew to use "increment_" because, after compiling my FORTRAN code, I ran the "nm" utility on increment.o and found the name of the object was "increment_". On some systems, you might see "INCREMENT", "_increment", or all sorts of other things. Re: 2) Information should be available for whatever compiler you are using. It varies alot.
I read the different topics that deal with that kind of problem, but I still have no answer.
Here is my problem :
In my header file, i have this :
int cl, ch, _a = a, _b = b;\
__asm__ ("smull %0, %1, %2, %3\n"
"mov %0, %0, lsr %4\n"
"orr %0, %0, %1, lsl %5\n"
: "=&r" (cl), "=&r" (ch)
: "r" (_a), "r" (_b), "i" (r), "i" (32-(r)));
cl; })
In my project settings, I verified that these following options was ckecked
link text
But I have a console error :
{standard input}:242:selected processor doesn't support -- smull r0,r1,r2,r3'
{standard input}:244:unshifted register required --orr r0,r0,r1,lsl#20'
Could you help me ?
Are you compiling the file for arm? By default code for the iPhone is compiled for thumb (which is usually preferable unless you are doing floating point math). The ASM you listed is arm. You will need to set any file that uses that header to compile as arm, since GCC does not allow you to switch backends inside a single compilation unit. You can change it by deselecting "Compile for Thumb" under "GCC 4.x Code Generation."
Compiling your entire project as arm will most likely have a significant (negative) impact on memory usage, and by proxy performance. Including ASM via a macro in a header like that is going to prove very messy on the iPhone. In general you are better off putting all your ASM in a single file and compiling that one file as arm, but for what is only a 3 instruction sequence that will probably not be worth while either.