mirror,
I've had a look at the Main memory using Gear , which I haven't used before.
It took me a while to sort out how to use it - someone needs to do a supporting doco for this!
I may have a go with the debugging tool later.
In the Receiving object I set the variable "num" as Global, so I could spot it in the main memory.
Using the bits that are known to work, I watched the memory and saw the "number" variable changing and also the variable "num" following it.
Then I tried the errant code and observed the "number" changing, but there didn't seem to be any sign of any other byte following it, as there should have been!
So, where has "num" gone?
I don't know what the problem is - the code seems pretty straight forward, but the answer isn't.
I will now try to use your other method of passing Global variable data, once I've understood how it works.
I've come from using PIC's and Picaxes (Basic language) and was attracted to the Propeller with its ability to parallel process, and provide full I/O on all 32 pins .
For my current project it is necessary to auto-monitor Global data, so if I can't get that to work properly with any confidence,
I will have to redesign to use mutliple PIC's instead!
kenmac
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Perth, Western Australia
Time Zone = GMT + 8
kenmac,
You can get it to work properly, and with confidence! But, I did say in an earlier post that at times I've considered writing my entire project (10000+ lines of spin and assembly) in a single project just to ease the agonies associated with this single issue!
There is a reason for it not working and there will be a solution!
1) Make sure you are referencing your bytes, words and longs *as* bytes, words and longs.
2) Make sure all you pointers are words! (to cover the 16 bit address space)
I absolutely convinced that once you get this working you wont want to think about multiple interacting PICs again!
GEAR is a bit obtuse, but it has really saved my bacon on 3 occasions now.
I came across this snippet of code that Chip Gracey put together last year at the official release
of the Propeller in Europe.
It shows 4 cogs all running a simple inc loop .. the individual cogs being displayed on a PC screen which was
projected onto a wall in the conference room.
It blew me away ..this was the first time we saw the Propeller in action..
My original question was related to being able to count ie keep track of 4 high speed pulses coming into
the Propeller all async to each other... all very possible each cog has 2 hardware counters...
========================================
con
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
var
long increment
obj
term : "tv_terminal"
pub go | i
term.start
repeat i from 0 to 3
cognew(@asmcode, @increment)
repeat
repeat i from 0 to 3
term.hex(increment, 8)
term.out(" ")
term.out(13)
waitcnt(80_000_000 + cnt)
Comments
I've had a look at the Main memory using Gear , which I haven't used before.
It took me a while to sort out how to use it - someone needs to do a supporting doco for this!
I may have a go with the debugging tool later.
In the Receiving object I set the variable "num" as Global, so I could spot it in the main memory.
Using the bits that are known to work, I watched the memory and saw the "number" variable changing and also the variable "num" following it.
Then I tried the errant code and observed the "number" changing, but there didn't seem to be any sign of any other byte following it, as there should have been!
So, where has "num" gone?
I don't know what the problem is - the code seems pretty straight forward, but the answer isn't.
I will now try to use your other method of passing Global variable data, once I've understood how it works.
I've come from using PIC's and Picaxes (Basic language) and was attracted to the Propeller with its ability to parallel process, and provide full I/O on all 32 pins .
For my current project it is necessary to auto-monitor Global data, so if I can't get that to work properly with any confidence,
I will have to redesign to use mutliple PIC's instead!
kenmac
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Perth, Western Australia
Time Zone = GMT + 8
You can get it to work properly, and with confidence! But, I did say in an earlier post that at times I've considered writing my entire project (10000+ lines of spin and assembly) in a single project just to ease the agonies associated with this single issue!
There is a reason for it not working and there will be a solution!
1) Make sure you are referencing your bytes, words and longs *as* bytes, words and longs.
2) Make sure all you pointers are words! (to cover the 16 bit address space)
I absolutely convinced that once you get this working you wont want to think about multiple interacting PICs again!
GEAR is a bit obtuse, but it has really saved my bacon on 3 occasions now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It turned out to be caused by insufficient stack space - lesson learnt!
kenmac
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Perth, Western Australia
Time Zone = GMT + 8
I came across this snippet of code that Chip Gracey put together last year at the official release
of the Propeller in Europe.
It shows 4 cogs all running a simple inc loop .. the individual cogs being displayed on a PC screen which was
projected onto a wall in the conference room.
It blew me away ..this was the first time we saw the Propeller in action..
My original question was related to being able to count ie keep track of 4 high speed pulses coming into
the Propeller all async to each other... all very possible each cog has 2 hardware counters...
========================================
con
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
var
long increment
obj
term : "tv_terminal"
pub go | i
term.start
repeat i from 0 to 3
cognew(@asmcode, @increment)
repeat
repeat i from 0 to 3
term.hex(increment, 8)
term.out(" ")
term.out(13)
waitcnt(80_000_000 + cnt)
dat
org
asmcode rdlong value,par
add value,#1
wrlong value,par
jmp #asmcode
value long 0
================================
Cheers
Ronald Nollet Australia