[resolved][puzzle] connection terminated
kuroneko
Posts: 3,623
Devise a way of communicatingA between two PASM cogs which
A For the purpose of this exercise let's say I want to transfer an arbitrary long between them.
- doesn't use/access hub RAM
- doesn't use/access external pins
A For the purpose of this exercise let's say I want to transfer an arbitrary long between them.
Comments
1. The cogs are already running; i.e. the communication doesn't take place upon a coginit/cognew by one cog of the other.
2. The two cogs are already aware of each other's cog ID.
3. The solution has to work between cogs having any pair of cog IDs.
-Phil
Well, I'm eager to see this one.
Technically, though, ??? is hub RAM, so it would not be allowed by the rules.
Andy
2. No.
3. Yes.
Will I ever get it right first time?
Total solutions sent so far 4 (+2 idea).
Are all the solutions submitted so far essentially the same? Or do they use different mechanisms?
Ross.
Let's open this discussion.
Potatohead's [redacted] method is probably the best, although it technically violates the "no hub RAM" rule, since the ????s rely on one bit of hub RAM each.
I was trying to come up with something involving the audio subcarrier, but it always uses a pin and doesn't seem to have a less visible path between two cogs.
Another technique, similar to Potatohead's, but pretty ugly in its own right, is to pick an unused cog to start and stop. The transmitting cog would start and stop it, corresponding to the data bits being sent. The receiving cog would try to start it and read a bit that depended on the success or failure of the coginit. 'Wouldn't work: coginit does not return status.
-Phil
Which bit would that be? IIRC that'd only work if there is one cog left (and then inspect carry). I mean if the receiving cog starts a particular cog then it starts a particular cog, period. Any history this cog may have is gone. Starting the next available looks different (but needs the 0/1 left condition). In which case I'd stick with cogid $ wc,nr.
True, locks are not in the hub RAM address space, but they do constitute flip-flops (i.e. one-bit memory that's randomly accessible) in the hub. That's all. 'Not enough of a technicality for disqualification.
Yes, I realized my error with coginit and corrected my post before your reply. It could still be done, though, by starting all but one cog and getting status from cognew for the last one. But yuck!
-Phil
Well, it was a fun exercise, nonetheless. :-)
Thanks. The depth of knowledge on this forum is truly impressive.
- locks (set/clear)
- cog availability
- lock availability
- system clock modulation (not sure I want to see this)
Let me know if there is more and I add it to the list. Surprisingly - despite looking like black magicA - you can still get a fairly decent 5Mbit/s out of the lock approach (clkfreq/16). Same holds true for #2 above but that relies on consuming all cogs in the system, NG.Here is an example for using locks (courtesy of Andrey Demenev):
[COLOR="blue"]CON _clkmode = XTAL1|PLL16X _xinfreq = 5_000_000[/COLOR] VAR long l OBJ ser : "FullDuplexSerial" PUB main ser.start(31, 30, 0, 115200) [COLOR="blue"]waitcnt(clkfreq*3 + cnt)[/COLOR] l := 0 cognew(@entry, @l) cognew(@entry, @l | $8000) waitcnt(CNT + CLKFREQ / 2) ser.hex(l, 8) ser.tx($0A) DAT entry mov addr, PAR andn addr, flag test flag, PAR wz if_z jmp #tx rx mov data, #0 mov ctr, #32 :loop lockset txlock wc if_c jmp #:loop shl data, #1 lockset datalock wc muxc data, #1 lockclr rxlock djnz ctr, #:loop wrlong data, addr cogid data cogstop data tx lockset txlock lockset rxlock mov data, number mov ctr, #32 :loop shl data, #1 wc if_c lockset datalock if_nc lockclr datalock lockclr txlock :sync lockset rxlock wc if_c jmp #:sync djnz ctr, #:loop cogid data cogstop data flag long $8000 txlock long 0 rxlock long 1 dataLock long 2 number long $1234_5678 ctr res 1 data res 1 addr res 1A just kidding
Wait, what??
So if the first hub access is done at some "random" time after the cog starts up, wouldn't the delay be somewhere between 8 and 22 cycles for the first hub access, and 8 to 20 cycles for any hub accesses after that? Why would there ever be an odd number of cycles? I know, I should look at the timing data and it will reveal all the answers.
All cogs start up with the first instruction being -4 relative to their hub window (which effectively translates to same phase relative to cog 0). Meaning the following (start) sequence doesn't have any penalty:
DAT org 0 entry mov dira, mask ' -4 rdlong data, par ' +0 =The relationship between the cog starting and the one being started only manifests in the startup time. The textual description can also be found [post=864343]here[/post] (halfway down). The example shows cog 0 (re)starting cog 4.Let's start with odd cycles, waitcnt/waitpxx/waitvid. Those can get you successfully out of the 4n raster. Provided you only use 4 cycle instructions and hub access then you'll only encounter 0/4/8/12 penalty (additionally to the 8 cycles it takes for hub access) for the first random hub accessA. Subsequent hub ops are your responsibility but follow the same pattern unless you throw in some wait* stuff. HTH
A the first penalty is actually predictable if you stay clear of wait*