|
|
| Author |
Message |
sturgessb
Joined: 25 Apr 2008
Posts: 246
Location: Norwich, UK
|
|
Posted: 15 April 2009, 2:57 AM Post subject: |
|
|
Sorry mike I would do that but I don't understand what you mean by a structure
Re the crashing, ive stripped down the code so its just this function and its still doing it, ill keep fiddling. |
|
| Back to top |
|
 |
mikep
Joined: 24 Sep 2005
Posts: 771
Location: Austin, TX
|
|
Posted: 15 April 2009, 3:11 AM Post subject: |
|
|
See section 3.25 Structures For the sender you need code such as:
| Code: | Public Structure FlightData
Public RC_Throttle as Integer
Public RC_Pitch as Integer
Public RC_Roll as Integer
Public RC_Yaw as Integer
End Structure
Dim d as FlightData
d.RC_Throttle = 1300
d.RC_Pitch = 600
d.RC_Roll = 100
d.RC_Yaw = 100
Call PutQueue(sendQueue, d, SizeOf(d)) | The receiver also needs the declaration of the structure. I recommend using a common module for this. |
|
| Back to top |
|
 |
sturgessb
Joined: 25 Apr 2008
Posts: 246
Location: Norwich, UK
|
|
Posted: 15 April 2009, 10:55 AM Post subject: |
|
|
Thanks, implemented that.
Very odd though, If i set all value (throttle, pitch roll etc) to be static hard coded values its fine and runs forever, but as soon as i start changing those values, either by moving the sticks, or I've even tried just setting the values to count up in code, the receiving zx crashes. |
|
| Back to top |
|
 |
sturgessb
Joined: 25 Apr 2008
Posts: 246
Location: Norwich, UK
|
|
Posted: 15 April 2009, 21:16 PM Post subject: |
|
|
After bashing my head against this all night, I tried replacing the zx128ne with a new one, exact same code, exact same hardware setup, and its fine!?
Mike: are there any changes between v0608 (crashes) and v0805 (works fine) that could cause this? |
|
| Back to top |
|
 |
mikep
Joined: 24 Sep 2005
Posts: 771
Location: Austin, TX
|
|
Posted: 15 April 2009, 21:36 PM Post subject: |
|
|
| sturgessb wrote: | | Mike: are there any changes between v0608 (crashes) and v0805 (works fine) that could cause this? | The version number of the PCB is in a YYMM format so the v0805 is newer. In terms of the device itself there are very little changes. A closer inspection will reveal some layout changes around the MAX202 serial level converter but that's about it.
When you say the same code, I assume you mean the exact same code is downloaded to each device.
I believe the older device used to work before you moved from strings to a structure on the queue. You can verify that this older version of code still works.
Do you have a cutdown example that you can post so we (Don and I) can try it out? |
|
| Back to top |
|
 |
sturgessb
Joined: 25 Apr 2008
Posts: 246
Location: Norwich, UK
|
|
Posted: 15 April 2009, 23:09 PM Post subject: |
|
|
Yes exactly the same code and PCB, no change.
I can also confirm the string method still works on the old 128ne. Odd. |
|
| Back to top |
|
 |
mikep
Joined: 24 Sep 2005
Posts: 771
Location: Austin, TX
|
|
Posted: 15 April 2009, 23:20 PM Post subject: ZX Copter Update |
|
|
ZX-24 wrote: | Quote: | Yes exactly the same code and PCB, no change.
I can also confirm the string method still works on the old 128ne. Odd.
|
|
|
| Back to top |
|
 |
mikep
Joined: 24 Sep 2005
Posts: 771
Location: Austin, TX
|
|
Posted: 15 April 2009, 23:24 PM Post subject: |
|
|
The ATmega128 has the same date code. The ZX bootloader is the same. That doesn't leave many more possibilities especially since your old code works.
My bet is on a timing issue from multi-tasking in the new code. You might be reading off the end of the queue or something like that. Sometime problem isolation down to a few tens of lines also helps with debugging. |
|
| Back to top |
|
 |
spamiam
Joined: 13 Nov 2005
Posts: 689
|
|
Posted: 16 April 2009, 17:00 PM Post subject: |
|
|
| mikep wrote: | | My bet is on a timing issue from multi-tasking in the new code. You might be reading off the end of the queue or something like that. Sometime problem isolation down to a few tens of lines also helps with debugging. |
But wouldn't the timing issues be the same as well?
-Tony |
|
| Back to top |
|
 |
mikep
Joined: 24 Sep 2005
Posts: 771
Location: Austin, TX
|
|
Posted: 17 April 2009, 1:32 AM Post subject: |
|
|
| spamiam wrote: | | But wouldn't the timing issues be the same as well? | There are not many alternatives left. It sounds like a software problem and in my experience this type of problem is related to the sequence of events. Let me give you example from some ZBasic code I wrote.
I had a receiver thread that infrequently would get into a problem on startup. I could not find what was wrong or what was causing it. I have a watchdog thread that automatically restarts the ZX device if any of the threads do not set a keep alive variable every so often.
I left the code alone for a while and then a few months later I implemented some additional function that required a longer startup sequence. This code crashed more often.
After some more debugging I found that the receive thread was processing certain kinds of messages too early in the initialization sequence. Some messages (call them system messages) needed to be processed during init but other messages (call them application messages) did not.
Occassionally during initialization an application message was received which would cause a crash. The correct functionality is to process system messages but ignore all application messages during startup. The sender was setup in such a way that unknowledged application messages are retried every so often. The longer initialization time meant the there was a longer period in which to send an application message and thus cause a problem.
Obviously this is not Ben's problem but it shows how some other timing event can change the order of processing and thus cause a problem. |
|
| Back to top |
|
 |
|