|
Yes, that is a doc I have been using.
I seems to have to run the app twice before the new device shows up as replacement for the SPI 0. Also system("ls -l /dev/fb*") does not show the fb1 on first try.
Maybe I need to do some kind of "update".
Just a note - perhaps fbtft is good only for fb0 / fb1. But taht doe snot matter now.
It's good to know about the "speed" . It just shows to pay attention to every detail.
|
|
|
|
|
I think the answer is in the way Linux "outputs" to memory instead to the physical device.
I may get the terminology wrong - but if I direct framebuffer "memory" to SPI "memory" it should work.
Assuming each "dev" has its own "memory".
Time to hit the books again.
|
|
|
|
|
I need some help, again.
I am posting only what I hope is relevant code, if not ask for clarification or ignore my request.
Basically struct issue.
The error is
/media/os64/Eclipse/eclipse/Workspace/Eclipse_Oxygen_1A/VNA_2/src/MODULES/M_SPI/C_FB.h:63:20: error: expected unqualified-id before numeric constant
#define VGA8x8_IDX 0
^
and I have no idea why. Just guessing something to do with struct initialization, but why?
The code is in header file which contains data to "build" ASCII characters in pixels to be output to TFT display.
I did move all into a class but got same error on #define VGA8x8_IDX 0.
Here is part of the "font" code
static unsigned char fontdata_8x8[FONTDATAMAX] = {
0x00,
0x00,
0x00,
0x00,
0x00,
0x00,
0x00,
0x00,
0x7e,
0x81,
0xa5,
0x81,
0xbd,
0x99,
0x81,
0x7e,
Here is the failing #define
#include "TEST_FONT.h" // local copy
#define VGA8x8_IDX 0
#define DEBUG
And the structs code
struct fbcon_font_desc {
int index ; char *name;
int width, height;
unsigned char *data; int pref;
}font_vga_8x8;
struct font_vga_8x8 {
VGA8x8_IDX,
"VGA8x8",
8,
8,
fontdata_8x8,
0
};
AS always, help will be appreciated.
Cheers
|
|
|
|
|
You have declared font_vga_8x8 as a variable which is a structure of type fbcon_font_desc. You then try to redeclare it as a new struct type, initialised with values rather than declarations. Your code should be:
struct fbcon_font_desc {
int index ; char *name;
int width, height;
unsigned char *data; int pref;
} font_vga_8x8 = {
VGA8x8_IDX,
"VGA8x8",
8,
8,
fontdata_8x8,
0
};
|
|
|
|
|
|
I do not want to sound as smart aleck , but came up with "problem" definition , not particularly solution before I went to sleep last night.
You guys are terrific helpers, I really appreciate this forum staff.
What a difference from others forum!
|
|
|
|
|
I am back. Sorry.
The solution worked, but now I am back with "multiple definitions".
That is where I started before getting into the mess with "struct".
I have the usual
#ifndef
#define
#endif
"scaffolding" at the header file and it is #include only once anyway.
I did add another
#ifndef
#define
#endif
around the "struct" but it did not help.
The "worst" part is - the compiler error does not really tell me where is the multiple definition in the "main()". Or maybe I really do not know how to interpret the error in main().
<pre lang="c++">
#ifndef DEFINITION_
#define DEFINITION_
struct fbcon_font_desc {
int idx;
char *name;
int width, height;
unsigned char *data; // font data
int pref;
}font_vga_8x8 = // test comment
{
VGA8x8_IDX, // test comment
"VGA8x8",
8,
8,
fontdata_8x8,
0
};
#endif</pre>
There is part of the compiler output
<pre lang="c++">
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9)
COMPILER_PATH=/usr/lib/gcc-cross/arm-linux-gnueabihf/5/:/usr/lib/gcc-cross/arm-linux-gnueabihf/5/:/usr/lib/gcc-cross/arm-linux-gnueabihf/:/usr/lib/gcc-cross/arm-linux-gnueabihf/5/:/usr/lib/gcc-cross/arm-linux-gnueabihf/:/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/
LIBRARY_PATH=/usr/lib/gcc-cross/arm-linux-gnueabihf/5/:/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/lib/../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/lib/:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'VNA_2' '-shared-libgcc' '-march=armv7-a' '-mfloat-abi=hard' '-mfpu=vfpv3-d16' '-mthumb' '-mtls-dialect=gnu'
/usr/lib/gcc-cross/arm-linux-gnueabihf/5/collect2 -plugin /usr/lib/gcc-cross/arm-linux-gnueabihf/5/liblto_plugin.so -plugin-opt=/usr/lib/gcc-cross/arm-linux-gnueabihf/5/lto-wrapper -plugin-opt=-fresolution=/tmp/ccC7xvZK.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --sysroot=/ --build-id --eh-frame-hdr -dynamic-linker /lib/ld-linux-armhf.so.3 -X --hash-style=gnu --as-needed -m armelf_linux_eabi -z relro -o VNA_2 /usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/lib/../lib/crt1.o /usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/lib/../lib/crti.o /usr/lib/gcc-cross/arm-linux-gnueabihf/5/crtbegin.o -L/usr/lib/gcc-cross/arm-linux-gnueabihf/5 -L/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/lib/../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/lib ./src/MODULES/M_WIRE/CLASSWIRE.o ./src/MODULES/M_SPI_TEST/CLASSSPITEST.o ./src/MODULES/M_SPI_LCM1602/C_TEMP_SPI.o ./src/MODULES/M_SPI_LCM1602/SAMPLE_CODE.o ./src/MODULES/M_SPI/CLASS_SPI.o ./src/MODULES/M_SPI/CLASS_SPI_BAD.o ./src/MODULES/M_SPI/CTFT.o ./src/MODULES/M_SPI/C_FB.o ./src/MODULES/M_SPI/C_SPI.o ./src/MODULES/M_SPI/_touch.o ./src/MODULES/M_PCF8574/CLASSPCF8574.o ./src/MODULES/M_LCM1602_I2C/CLASSLCM1602.o ./src/MODULES/M_IOCTL/CIOCTL.o ./src/MODULES/M_IOCTL/CLASSI2C.o ./src/MODULES/M_I2CIO/CLASSI2CIO.o ./src/MODULES/M_BASE_TEST/CBASE.o ./src/MODULES/M_BASE_TEST/CDEVICE.o ./src/MODULES/M_BASE_TEST/CINHER.o ./src/MODULES/M_1602_HPP/M_1602_HPP.o ./src/MODULES/MODULE_SPI_DRIVER/CSPIDRIVER.o ./src/MODULES/MODULE_SPI/CSPI.o ./src/MODULES/MODULE_MAP_GPIO/CMAPGPIO.o ./src/MODULES/MODULE_INHERITED_GPIO_MAP/INHERITANCEBASE.o ./src/MODULES/MODULE_INHERITED_GPIO_MAP/INHERITANCEDERIVED.o ./src/MODULES/MODULE_INHERITED_GPIO_MAP/MODULEINHERITEDGPIOMAP.o ./src/MODULES/MODULE_I2C/CI2C.o ./src/MODULES/MODULE_GPIO/CGPIO.o ./src/MODULES/MODULE_BASE_GPIO_MAP/MODULEBASEGPIOMAP.o ./src/MODULES/MODULE_1602/C_1602.o ./src/MODULES/MODULE_1602/C_LCD2_CPP.o ./src/MODULES/MODULE_1602/C_SPI.o ./src/MODULES/MODULE_1602/C_SPI_LCD.o ./src/MODULES/MODULE_1602/C_SSP.o ./src/MODULES/MODULE_1602/C_gpio.o ./src/VNA_2_BAD.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc-cross/arm-linux-gnueabihf/5/crtend.o /usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/lib/../lib/crtn.o
./src/VNA_2_BAD.o data+0x800): multiple definition of `font_vga_8x8'
makefile:63: recipe for target 'VNA_2' failed
./src/MODULES/M_SPI/C_FB.o data+0x800): first defined here
collect2: error: ld returned 1 exit status
make: *** [VNA_2] Error 1
<pre lang="c++"></pre></pre>
|
|
|
|
|
This is a linker error, not a compiler error. You have a definition of font_vga_8x8 in more than one source module. So although that looks OK to the compiler, when you link the object modules together the linker gets confused.
|
|
|
|
|
Thanks.
Good call, I tend to forget to disable unused source files!
Back to drawing board.
|
|
|
|
|
Well - I did try to cheat and renamed the offending variable.
Still same error - multiple definitions. Then I recall something about initializing struct as globals or something to that matter.
So I changed the struct to "static " and the error went away.
Why?
The #include file is global - not part of the class.
|
|
|
|
|
The problem is not specific to struct types, but any variable. If a variable has global scope, i.e. it is declared outside of any method, then it is externally defined by default. That means its name is known to the linker. If it is declared static then it is internal to the compilation unit that contains it, and its name will not be visible to the linker. So if the linker encounters multiple variables with the same name it cannot decide how to link them correctly.
|
|
|
|
|
Ok, so if I put the struct declaration / definition as class variable it should work without being declared as static , right?
Would that defeat the purpose of #include in general?
This "font definitions" came from other application, not my original code.
|
|
|
|
|
Sorry those three statements don't make much sense. The general way of handling situations like yours is to have the definition of the struct in a header file that multiple source modules can then include. Each source module would then declare an instance of the struct in what ever location they required, but not as a global. Having said that, there may be cases where declaring such a variable as global is the right thing to do, as its contents are shared between different modules. Only you (the application designer) can decide which is the right option.
|
|
|
|
|
I have added a C # ActiveX control inside an MFC ActiveX control. How do I get the Com Interface for the added C # ActiveX control? 
|
|
|
|
|
I have a small program. I compile the executable. If I find the executable
and double click on it, everything works fine. I can print, print preview; all is
well.
If within visual studio I hit the green triangle to run the executable and then I
try to print or print preview, I get an error in this code:
inline void* CThreadSlotData::GetThreadValue(int nSlot)
{
EnterCriticalSection(&m_sect);
ASSERT(nSlot != 0 && nSlot < m_nMax);
ASSERT(m_pSlotData != NULL);
ASSERT(m_pSlotData[nSlot].dwFlags & SLOT_USED);
ASSERT(m_tlsIndex != (DWORD)-1);
if( nSlot <= 0 || nSlot >= m_nMax ) // check for retail builds.
{
LeaveCriticalSection(&m_sect);
return NULL;
}
CThreadData* pData = (CThreadData*)TlsGetValue(m_tlsIndex);
if (pData == NULL || nSlot >= pData->nCount)
{
LeaveCriticalSection(&m_sect);
return NULL;
}
void* pRetVal = pData->pData[nSlot];
LeaveCriticalSection(&m_sect);
return pRetVal;
}
It breaks at LeaveCriticalSection(). Im really perplexed as to why this error has arisen
and what to do to get it to go away. If you have any insight, please let me know.
|
|
|
|
|
|
Richard, but there was just a wrong forum!
Therefore (I think) he has reposted the question here....
|
|
|
|
|
Erich Ruth wrote: ...I get an error in this code:
What error?
Erich Ruth wrote: It breaks...
What does that mean, exactly?
Could it be a difference between release vs. debug mode? Have you stepped into LeaveCriticalSection() to see what is happening (e.g., fired assertion)?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
When I say it breaks, that means it pops up a box that says:
"Unhandled exemption x 0x777f6a73 in MultiScreen.exe: 0xC0000005: Access
violation reading location 0xfeeefefa.
and then I have Break or Continue. I hit Break and it shows me this code:
inline void* CThreadSlotData::GetThreadValue(int nSlot)
{
EnterCriticalSection(&m_sect);
ASSERT(nSlot != 0 && nSlot < m_nMax);
ASSERT(m_pSlotData != NULL);
ASSERT(m_pSlotData[nSlot].dwFlags & SLOT_USED);
ASSERT(m_tlsIndex != (DWORD)-1);
if( nSlot <= 0 || nSlot >= m_nMax )
{
LeaveCriticalSection(&m_sect);
return NULL;
}
CThreadData* pData = (CThreadData*)TlsGetValue(m_tlsIndex);
if (pData == NULL || nSlot >= pData->nCount)
{
LeaveCriticalSection(&m_sect);
return NULL;
}
void* pRetVal = pData->pData[nSlot];
LeaveCriticalSection(&m_sect);
return pRetVal;
}
and its pointing to
LeaveCriticalSection(&m_sect); which is the 2nd to last line.
|
|
|
|
|
Hi,
0xfeeefeee is a magic number[^] used by the debug heap for marking memory that's been freed. So it looks like the data at pData->pData[nSlot]; has already been freed by the time you try to read it.
This probably means that the bug also exists in your 'Retail build'. A retail build with a normal heap may happily read garbage data and keep on going.
You can probably debug this by setting up a memory watch[^] for &pData->pData[nSlot];
Best Wishes,
-David Delaune
|
|
|
|
|
Could somebody please correct this code for me ?
I am trying to pass char array to a constructor and USE
LIST to initialize the class variable.
I can do single char - USING LIST - no problem, I can pass a variable and copy it to class variable.
I am trying to learn more about using LIST AND I am hopelessly lost
how to pass a char array - preferably "by pointer".
I have tried all kinds of syntax combinations, samples etc. but I really need some help.
Appreciate any inputs.
<pre lang="c++">
// passing an array of char
char array[16];
public:
CLASS_SPI_NEW(char array): array(array)
{
}</pre>
|
|
|
|
|
Vaclav_ wrote: <pre lang="c++">
// passing an array of char
char array[16];
public:
<b>CLASS_SPI_NEW(char array): array(array)</b>
{
}</pre></blockquote>
Did you probably mean
CLASS_SPI_NEW(char* array): array(array)
|
|
|
|
|
Thanks for the suggestion , here is what I did and it works.
Two more questions
The array actually gets filed with 12 characters and I have "sized" it for two.
This "list constructor " code syntax have no "prototype", but it works.
<pre> char *array = " ";
int channel;
long speed;
int mode;
C_SPI_NEW(char *array, int channel, long speed, int mode )
: array(array), channel(channel), speed(speed), mode(mode)
{
#ifdef DEBUG
cout << "\033[1;31mConstructor \033[0m\n";
cout <<" device " << array <<endl;
cout <<" channel " << channel << endl;
cout <<" speed " << speed << endl;
cout <<" mode " << mode << endl;
cout << " function " << __FUNCTION__ << endl;
cout << " line " << __LINE__ << endl;
#endif
}</pre>
|
|
|
|
|
Is there some very important reason to use plain char array instead of std::string or MFC CString class?
|
|
|
|
|
Yes, but it is complicated.
Since you asked-
I am using PC to remotely compile C++ code for Raspberry Pi.
No MFC needed.
My OS is Ubuntu and my IDE is Eclipse. I have no problem using String on PC locally, but the OS on Raspberry Raspbian complains about wrong version of some library.
When I check the version in question it is current.
Instead of trying to figure out something over my head I simply do no use String.
My application is pretty much "low level bits" communication anyway.
Problem solved.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
