Ocelot driver questions
Holidays are over... Back to the grind... sigh....
When I use the cmax debug timers and vars function, it sends...
2A 00 00 91 AA 00 00 A6
The data returned back corresponds to the variables in my ocelot.
I haven't dug through the serial trace yet for the timers.
I'm really starting to wonder if the memory locations for the ocelot have changed, despite folks saying they haven't.
Tim
When I use the cmax debug timers and vars function, it sends...
2A 00 00 91 AA 00 00 A6
The data returned back corresponds to the variables in my ocelot.
I haven't dug through the serial trace yet for the timers.
I'm really starting to wonder if the memory locations for the ocelot have changed, despite folks saying they haven't.
Tim
So the world from ADI is...
~~~~~~~~~~~~~~~~~~~
"The old compiler we used would change the location of the variables and timers. C-Max would have to request the location from the Ocelot. This should no longer be the case. Use the new location. The location should no longer change."
~~~~~~~~~~~~~~~~~~~
Not sure how you want to handle it. Use the memory locations for the latest firmware only. i.e. Forcing folks who want to use this feature to ensure they have the latest Ocelot firmware and OS.
Or make it selectable between the old memory location and new memory location, and hope that no other locations or old Ocelot versions show up.
Or maybe make it so the user has to input the string to be passed to Ocelot.
Or or or... (Just throwing out ideas here.)
Thanks
Tim
~~~~~~~~~~~~~~~~~~~
"The old compiler we used would change the location of the variables and timers. C-Max would have to request the location from the Ocelot. This should no longer be the case. Use the new location. The location should no longer change."
~~~~~~~~~~~~~~~~~~~
Not sure how you want to handle it. Use the memory locations for the latest firmware only. i.e. Forcing folks who want to use this feature to ensure they have the latest Ocelot firmware and OS.
Or make it selectable between the old memory location and new memory location, and hope that no other locations or old Ocelot versions show up.
Or maybe make it so the user has to input the string to be passed to Ocelot.
Or or or... (Just throwing out ideas here.)
Thanks
Tim
I have firmware 8.31/58 and application (Ocelot OS?) 3.18.
This is the latest and greatest from ADI. Which was released last year for the DST change.
We could always request what the protocol is for getting the var and timer locations or, as you say, reverse engineer it.
Since ADI has said this new memeory location is unlikely to change, I would specify this firmware/Ocelot application level as the minimum level to use the get var and timer features in the Housebot Ocelot interface. This will save the hassle of having to maintain the interface for multiple Ocelot versions.
Tim
This is the latest and greatest from ADI. Which was released last year for the DST change.
We could always request what the protocol is for getting the var and timer locations or, as you say, reverse engineer it.
Since ADI has said this new memeory location is unlikely to change, I would specify this firmware/Ocelot application level as the minimum level to use the get var and timer features in the Housebot Ocelot interface. This will save the hassle of having to maintain the interface for multiple Ocelot versions.
Tim
Hi Scott,
Would you like me to follow up with ADI to see if we can get the protocol that requests the timer and var locations from the Ocelot?
Or will you merely code in the latest location/command into the Ocelot and make it a requirement that folks are at a minimum firmware 8.31/58 and application (Ocelot OS) 3.18 level?
I should have time this tonight or this weekend to pull the command out of the serial stream that grabs the timers.
Thanks
Tim
Would you like me to follow up with ADI to see if we can get the protocol that requests the timer and var locations from the Ocelot?
Or will you merely code in the latest location/command into the Ocelot and make it a requirement that folks are at a minimum firmware 8.31/58 and application (Ocelot OS) 3.18 level?
I should have time this tonight or this weekend to pull the command out of the serial stream that grabs the timers.
Thanks
Tim
If you can find the protocol info from them, that would be great. I'm still not clear on when the memory locations are different and what they are in the other case. Seems like if I call the API to get me the timers, it would return the timers in the buffer according to however it manages it in memory. I just get a buffer returned for that, I don't read any memory directly.
Sorry that I'm not being much help. I'm just working on 1000 other things at the moment.
Sorry that I'm not being much help. I'm just working on 1000 other things at the moment.
Scott
Still waiting on ADI to see if we can still query the var and timer locations on the recent Ocelot executive version.
In the meantime, everyone responded that they are running Ocelot exec v3.18. This is the most recent version.
As for reading the timers and thinking they're coming from a buffer... Nope... Any command that starts in hex 2A 00 is a memory dump command. All we are doing for both timers and vars is dumping the memory location that contains those values.
As for when the var and timer locations are different... On older versions of the Ocelot, when ADI compiled the executive that you load into the Ocelot, the locations of the vars and timers in memory would change. Hence the need to query the Ocelot for the locations. But on the new version of the Ocelot executive, they always force the vars and timers to the same memory location. 2A 00 00 91 AA 00 00 A6 for variables. Timers it is ??? I haven't pulled it from a com port trace yet.
Tim
In the meantime, everyone responded that they are running Ocelot exec v3.18. This is the most recent version.
As for reading the timers and thinking they're coming from a buffer... Nope... Any command that starts in hex 2A 00 is a memory dump command. All we are doing for both timers and vars is dumping the memory location that contains those values.
As for when the var and timer locations are different... On older versions of the Ocelot, when ADI compiled the executive that you load into the Ocelot, the locations of the vars and timers in memory would change. Hence the need to query the Ocelot for the locations. But on the new version of the Ocelot executive, they always force the vars and timers to the same memory location. 2A 00 00 91 AA 00 00 A6 for variables. Timers it is ??? I haven't pulled it from a com port trace yet.
Tim
Still no response after two emails from ADI on whether or not we can still query the Ocelot for the var and timer locations.
But since ADI have said the locations will not change on future Ocelot exec versions...
Maybe when you get a chance you can upgrade your dev Ocelot to v3.18. (This is version everyone seems to be running and the most current.)
And then redevelop for that exec version and make it a minimum Ocelot requirement for timer and var support. (Since it won't change in future versions.)
Tim
But since ADI have said the locations will not change on future Ocelot exec versions...
Maybe when you get a chance you can upgrade your dev Ocelot to v3.18. (This is version everyone seems to be running and the most current.)
And then redevelop for that exec version and make it a minimum Ocelot requirement for timer and var support. (Since it won't change in future versions.)
Tim
Oh no no no....
Just download the latest cmax version/executive. http://www.appdig.com/adicon_new/download.htm
In the cmax menus there is an option called reload executive (or something to that effect). It takes a few mins and you are done. If you have any program running in the Ocelot, you will need to reload that afterwards.
Really it's very painless.
Tim
Just download the latest cmax version/executive. http://www.appdig.com/adicon_new/download.htm
In the cmax menus there is an option called reload executive (or something to that effect). It takes a few mins and you are done. If you have any program running in the Ocelot, you will need to reload that afterwards.
Really it's very painless.
Tim
ok. I think I have my ... wits ... together now. I was assuming that I *WAS* running the latest version, even though you were proving that I wasn't. Since I thought I was, I thought it was a chip upgrade that I was missing.
Anyway, now that I've upgraded the firmware, I've updated the plugin to use the new memory locations. I think it's reasonable to expect that users use the latest firmware (even if I can't) to use the plugin!
Try this venison.
Anyway, now that I've upgraded the firmware, I've updated the plugin to use the new memory locations. I think it's reasonable to expect that users use the latest firmware (even if I can't) to use the plugin!
Try this venison.
Scott