Printable View
Hi,
I'm trying to write a function which can modify the values of an array passed to it, and the compiler keeps telling me, "invalid operands to binary *"
Here's the function as I'm trying it:
Code:void TryLocationCalculation(int& cricket_dist[3], double& location[3])
{
location[0] = cricket_dist[0]*cricket_dist[0];
}
For this particular case, I don't see why you need to use a reference. An array, when used as argument for a function in C++ will turn into the address of the first element. Remove the & signs in TryLocationCalculation and I think you will find that it works just fine.
--
Mats
What pointers?
I see references, but no pointers.
Pointers look like: int* num;
But like matsp said, just take out the '&' symbols and you should be fine since arrays automatically degrade to pointers.
I took out the &'s and the code compiled. Now I'm having some difficulty with the threads in my code. I have three threads that I want to run simultaneously. They essentially listen to three different serial ports. The problem is the first thread loops far faster (more often?) than the other two for some reason. Is there a way I can easily synchronize the three threads so that they execute the same fast? Without wasting cpu time?
Here is the code. I added the printfs so I could see what was going on.
Code:void *serial_thread_1()
{
for(;;)
{
printf("thread1");
calling_to_beacon = 2;
RequestMsg[5] = '2';
TxBytes = write(comfd1, &RequestMsg, 7)
cricket_dist1[0] = GetCricketDist(RxData1, comfd1);
TryLocationCalculation(cricket_dist1, location1);
calling_to_beacon = 4;
RequestMsg[5] = '4';
TxBytes = write(comfd1, &RequestMsg, 7)
cricket_dist1[0] = GetCricketDist(RxData1, comfd1);
TryLocationCalculation(cricket_dist1, location1);
calling_to_beacon = 3;
RequestMsg[5] = '3';
TxBytes = write(comfd1, &RequestMsg, 7)
cricket_dist1[0] = GetCricketDist(RxData1, comfd1);
}
return 0;
}
void *serial_thread_2()
{
while(calling_to_beacon !=0)
{
printf("thread2");
if(calling_to_beacon ==2)
cricket_dist2[0] = GetCricketDist(RxData2,comfd2);
if(calling_to_beacon ==4)
cricket_dist2[0] = GetCricketDist(RxData2,comfd2);
if(calling_to_beacon ==3)
cricket_dist2[0] = GetCricketDist(RxData2,comfd2);
}
}
void *serial_thread_3()
{
while(calling_to_beacon !=0)
{
printf("thread3");
if(calling_to_beacon ==2)
cricket_dist2[0] = GetCricketDist(RxData2,comfd2);
if(calling_to_beacon ==4)
cricket_dist2[0] = GetCricketDist(RxData2,comfd2);
if(calling_to_beacon ==3)
cricket_dist2[0] = GetCricketDist(RxData2,comfd2);
}
}
Of course, though the better solutions that I have to offer are all platform specific. So what say ye? Windows or Linux or Mac OS? Or if you are feeling adventurous in C++, you could check out the qthead library.
This is an application for embedded linux, running on Gumstix. I don't know the details of the kernel and whatnot, and don't understand such things very well at all anyway. However, I think it wouldn't be too difficult to switch to C++. Is it necessary? A messy solution will do for now, as this project is "due" in two days... I can refine it afterwards
I just assumed you were a C++ fan since you posted code that has C++ specific features that do not exist in C. Be that as it may, the qthread library is actually very clean and easy to impliment. There are other options such as POSIX which should be boxed with your compiler (hell, mine came with qthreads too). Is the C++ thing an issue for your skill level or your project's guidelines? If so, POSIX is fine.
Does GetCricketDist() block on read? If so, then you should manually alternate between threads, i think.
EDIT: ah, sorry, i thought 2nd thread is more often than 3rd (not 1st more than 2nd & 3rd).
You are, I take it, aware that the code in thread 2 and thread 3 in your posted code use the same comfd2 and RxData2 to access the comport?
--
Mats
That confused me :)Quote:
Originally Posted by matsp
But, would sched_yield() be too much of "wasting cpu time"? It is a waste, but minimal...
EDIT: actually, it's a "delay", not "waste". And these are serial ports after all...
I have no idea what sched_yield() does or would do, and a little "wasting" can be tolerated...
I didn't know that my code used functions that were C++ specific... this is concerning as I thought I was using a C compiler. Hmm...
I don't mind using the qthread libraries if they help make things simpler, however I think what I am using now is the POSIX stuff?
Yeah, I'm sorry. It's supposed to be comfd3 and RxData3. I copied it down wrong.Quote:
You are, I take it, aware that the code in thread 2 and thread 3 in your posted code use the same comfd2 and RxData2 to access the comport?
The funciton GetCricketDist blocks (waits/listens?) for 0.4 seconds on read, which is what I intended. The hardware is waiting for an ultrasonic signal to arrive and if it hasn't arrived in 0.4 seconds, its not coming. I set this up in my options struct by setting VTIME = 4 and VMIN = 0
You call sched_yield() for manual, cooperative multitasking - you return control to scheduler and it then schedules (runs) next process/thread. I'd place one call in thread #2 & #3 as last line in while block, and in #1 in-between changes to that variable, whenever you'd prefer for other thread(s) to run. But you know your code better and should make more proper choices, i believe. (And i could be always wrong ;)) But, this way you have no direct/explicit control over threads, you just make a "cycle around process queue". It also depends on individual priorities, of course.
EDIT:sched_yield() man page
References are C++ only.Quote:
Originally Posted by Franklin
References have & appended after type: T&.
Examples:
int&
long&
double&
etc.
C only has pointers: T*.
int*
long*
double*
etc.
For your reference, only.
On the thread matter: I'm always dubious to coding that doesn't rely on proper synchronization between threads and yet wishes to control order of execution or otherwise "mess with the scheduling". It generally doesn't work out right in the longer term.
If the thread in itself is not depending on something to block, then make something that it will block on until you think it should run. Or, don't use threads - in this case, perhaps asynchronous IO would be the right solution?
--
Mats
Just add two join statements to the end of each thread. Then when one thread finishes it will wait for the other to to finish before starting the loop again.
Thanks for all the advice and suggestions. You guys are awesome!