Object reference questions
Paul M
Posts: 95
First, according to the manual, the scope of an·object declared in an OBJ block is·global to the·declaring object.
In the following code:
·the 'DoSomething' method does not seem to·get called ??
Secondly, is it possible to pass an object reference created in one object to another object? For example:
How can· 'FunctionA' use the LCD object?
PS I hope this·post doesn't start such a vociferous debate as my last post
In the following code:
. . OBJ objref : "MyObject" PUB Main objref.init() cognew(MyFunc(value),@stack) PUB MyFunc(param) objref.DoSomething
·the 'DoSomething' method does not seem to·get called ??
Secondly, is it possible to pass an object reference created in one object to another object? For example:
- the main application·declares an LCD object and two other objects
- the main app initialises the LCD
- the main app calls 'init' or 'start' methods on the other objects which call: cognew(FunctionA, @stack) etc.
How can· 'FunctionA' use the LCD object?
PS I hope this·post doesn't start such a vociferous debate as my last post
Comments
(a) Your example works fine. Maybe your Stack had been to small?
(b) There is no such thing as an "object reference", it is nothing but a syntactic notion
(c) You do not "declare" an object, but "instantiate" one. This means a new set of its VAR space is allocated.
Instantiating more than one object can lead to different effects... When not using any VAR at all it is possible to create a "singleton" which works as - naively - expected.
Many discussions here all the time. Look also at the Q&A sticky
(d) You tend to mix COG and object matters. Nothing of your questions has anything to do with different COGs (= processes)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK
Loading a COG takes 100 µs. Even
REPEAT 100
will be some overkill...
---
Edit: Paul, try this:
OBJ objref : "MyObj" PUB Main | stack[noparse][[/noparse]10] cognew(MyFunc,@stack) PUB MyFunc objref.blink '''''''''''''''''''''''''''''''''''''' 'this is MyObj CON led = 8 PUB blink DIRA[noparse][[/noparse]led] := TRUE REPEAT !OUTA[noparse][[/noparse]led] WAITCNT(CNT+CLKFREQ/4)Note: Don't do
That is - terribile dictu - a "bug"!
Post Edited (deSilva) : 12/27/2007 2:29:55 PM GMT
OK, there are no 'object rerferences' as in the higher level language sense·- I should have used 'object symbol' (the manual uses the term 'declare') This answers my second question.
deSilva, I understand·your latest code snippet. I am trying to do someting slightly different but am obviously still missing something:
CON _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 OBJ term : "FullDuplexSerial" VAR long rx_p,tx_p long s[noparse][[/noparse]100] PUB Main | r rx_p:=31 '26 tx_p:=30 '27 r:=term.start(rx_p,tx_p,0,56000) term.str(string("Hello from Main")) cognew(newproc,s) 'newproc delay(500) term.str(string("In Main again")) . . . PUB newProc term.str(string("Hello from newproc")) PRI Delay(ms) waitcnt(ms*80_000+cnt)The·result is·unexpected and sometimes causes the prop to latch up and·the Prop Tool·can't communicate with it (a hazard of also·using the prog pins for comms).·I understand there is possibility of contention and will use semaphores or locks to prevent this in the real code - ·hence the 'delay(500)' here
In this example, the 'newproc' code runs but the last statement in·'Main' is not called??
What's happening after the call to term.str(string("In Main again"))? If it's something that may cause the Propeller to reset/reboot, the serial output doesn't have a chance to complete. The cog doing the "Hello from newproc" is stopped as soon as that text is added to the serial buffer. If what you've written is all there is, the main cog also stops itself by exiting after adding "In Main again" to the serial buffer and the only thing left running is the serial I/O cog which should just sit there waiting for more data which will never come.
The Prop should never be able to be latched up. The DTR line being toggled should force a reset and the Propeller Tool does this whenever you do an Identify Propeller or download something. The fact that you use the Rx and Tx lines for program comms would not affect this. Some of the FemtoBasic derivatives use the download comms for console I/O and I've never had any kind of latch up at any time while debugging them.
It prevents multiple cogs to write to the debug output simultaneously,
and it allows you to send formatted text and you can claim the output channel
by passing a boolean value. This is so you can send a few lines that are
guaranteed not to be interleaved with text from other cogs.
regards peter
In the test code there is nothing after the last write to the serial object. And it definitely hangs up sometimes, sometimes·sending vast quantities of garbage to the defined serial lines. BTW I'm using an FTDI USB/Serial cable and using RTS but I can't see this should cause a problem.
Peter's program will exactly do the synchronization you are well aware of is necessary. DELAY(500) will suffice to avoid any conflict. I also tend to Mike's opinion wrt your problem..
Note that you have been lucky that FullDuplex runs its own COG. Otherwise (as with SimpleSerial) it would be not possible to sucessfully call TX from a different COG. Do you understand why?
Just had to reboot as the FTDI driver got confused and I couldn' even see the COM port - it may have·been this confusion that was preventing the Prop reset - ie the RTS line may not actually have been asserted.
Thanks again for the help and I shall·have a look at the MultiCogSerialDebug object.
>Note that you have been lucky that FullDuplex runs its own COG. Otherwise (as with .....
deSilva, enlighten me.