PRI vs PUB using Frequency Synthesizer object
Harley
Posts: 997
My project uses two Props; Prop#1 generates a 5 MHz signal for Prop#2 X1 input.
Recently I cleaned up my sources and thought it would be better to have all the COGNEWs in PUB rather spread in both PRI and PUB the way it had grown. Made a number of 'small' changes to the source, actually for both Props, and then NOTHING worked.
Finally today I used a ProtoBoard rather than the 2 Prop pcb to scope if the FreqSynth worked on that board. NOPE. So tried it with Fsynth.synth moved after the first PRI. And then it worked. Yet FDS and Display (TV_text) worked OK in PUB.
Is there a rule for where cogs get init'ed? Wasted many man hours tracking why Prop#2 didn't work right. It received a 5 MHz timing from Prop#1 via Fsynth.
Nice to see things working properly again. But don't understand why it had to be this way. Can someone enlighten me?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Recently I cleaned up my sources and thought it would be better to have all the COGNEWs in PUB rather spread in both PRI and PUB the way it had grown. Made a number of 'small' changes to the source, actually for both Props, and then NOTHING worked.
Finally today I used a ProtoBoard rather than the 2 Prop pcb to scope if the FreqSynth worked on that board. NOPE. So tried it with Fsynth.synth moved after the first PRI. And then it worked. Yet FDS and Display (TV_text) worked OK in PUB.
Is there a rule for where cogs get init'ed? Wasted many man hours tracking why Prop#2 didn't work right. It received a 5 MHz timing from Prop#1 via Fsynth.
Nice to see things working properly again. But don't understand why it had to be this way. Can someone enlighten me?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Comments
Can anyone explain why it shouldn't have worked at line marked AAA?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
That 'InitP1' is just a Call to a separate PRI for initialization of on-screen headings of Prop#1 and Prop#2 areas for the TV monitor debug screen.
This included communications to read and display version#, date and #cogs used by Prop#2. Each use about 1/2 of the screen. When the Fsynth wasn't working, Prop#2 wouldn't run therefore I had to temporariy comment out that communications source lines, so I could continue after hitting a brick wall on what wasn't working right. Had made too many changes at once and couldn't determine where all the problems were.
InitP1 begins with
Dispaysetcolors(@tv_palette)
Might that, setting the foreground/background colors table, have upset Fsynth?
Maybe it has more to do with being invoked after the
id := cognew(Control1,@stack) ' " Cog 5
line?
I'd like to know about this strange effect. I was dumbfounded when I moved the Fsynth init a few lines later and it worked; need to know the 'logic' behind this.
Thanks, anyone for clarification on this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
I was not able to locate somthing as "Synth", neither in the OBEX nor from this forum. May be Steven is right...
More likely you are shutting pin 24 dowm in your main COG after FSYNTH had been called. This will not disturb the COG5 you run CONTROL in, so it continues transmitting its signal...
The purpose of the 5 MHz signal is for 'clock' for Prop#2. I suppose I could generate it another way with less code, but probably still would need its own cog, no? Prop#1 uses a 5 MHz crystal, but over 3 inches from Prop#2 X1 pin. Are you implying the counter wouldn't have to be in another cog; that would be cool. Should be a square wave though.
@ deSilva
I've had 'Synth' for about 9 months. Don't recall if it came with the IDE originally, or ran across it elsewhere. But works well.
I'm constantly amazed how much Chip 'n crew incorporated in the Propeller. Looks like I need to reread that counter AN001 again (and again and again).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Yes, I'd actually 'forgotten' about doing it that way. No timers used yet on this project (except for what Fsynth uses).
So much to learn, not enough time usually. LIFE!
Thank you deSilva and stevenmess2004.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
·
Not sure why you are seeing this issue, but I suspect it's exactly what deSilva suggests... "More likely you are shutting pin 24 down in your main COG after FSYNTH had been called."
·
It's difficult to tell without all of your code (i.e. some of the OBJ definitions) to see what is happening.· The Synth.spin object is basically a passive object in that it uses the current COG it is called from and does not launch another COG.· So if another object does something similar and is also passive, it could be clobbering the CTR and FRQ settings.· Try using the Synth.spin object with the "B" counter rather than the "A" counter just to see if it might go away that way.
·
Object exchange Synth.spin reference:
http://obex.parallax.com/objects/47/
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
I'll try your suggestion. I'm also going to try using AN001 counter instead of Fsynth obj.
Hadn't looked into the counters except for scanning AN001 months ago. Lots available in just that part of the Propeller. Thanks for the suggestion.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
If I put the Fsynth.synth("A", 24, 5_000_000) before the PRI it doesn't work, whether "A" or "B" is assigned.
But if after the PRI either "A" or "B" works.
To my knowledge I am not altering pin 33/A24 in the program in any manner either.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
When you clear DIRA[noparse][[/noparse]24] "A" or "B" won't make any difference...
Before you post the complete code there is no chance to help you further. There just is a "bug" in your program.. somewhere
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
but it doesn't seem to work as I understand AN001. I'm using the DIP40 Props.
Am I interpreting things incorrectly?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
You are trying to output 40 MHz..... And feeding the PLL with this
I think your major misunderstanding comes from "PLL/16". When using the PLL you multiply with 16 in the first place. A divison happens AFTERWARDA. So PLL/16 gives no change in frequency (but a better pulse shape). The PLL works best around 8 MHz yielding 128 MHz which you can divide as you wish.... Though there is no special need to use the PLL in the first place for your application...
Sorry, it escaped my attention yesterday: Your main program TERMINATES just after calling FSYNTH.
Re: post 1:
You say main program terminates, must imply that FSynth is all SPIN, but the others, PICSer, PropSer and Display are separate assembly cogs for them to continue running properly?
Re: oost 2:
OK, now I guess I should have used NCO mode; skipped it when I saw PWM. But tried it and, after providing the proper value for the 'division' now have nice 5 MHz square wave on the scope. Some nice ringing; scope is only 100 MHz Tektronix 2247A.
I was hoping to get into the 'counters' some day; didn't think I'd need them yet. So, now have just this 3 SPIN vs Fsynth of about 25 SPIN lines:
I like this better. Would have been a matter of time as AN001 use was high on the list AFTER this project. Glad it came up now. Thanks for the 'nudge' and help.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
ad2: Glad you made is with the counters. AFter understanding them you have to admit it is SIMPLE
BTW: don't write %011000 - that's confusing! Write 24!
re: 1 If, as I've used it, with the FDS and TV_text in Main, why does that work if the Main cog has terminated?
re: 2 They mean the same (re '24), but YES, it is much more clear for our 'decimal' brains. Thanks for the clarity. I suppose after teaching such points stand out.
I was able to use a ProtoBoard for verifying the 5 MHz counter; was a good platform for the scope probe, as I had a terminal for ground on it in the VGA connector area (I don't yet have a VGA monitor). Very handy boards; haven't used all 6 but fell for the deal of $100 a six-pack when first released.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Your routine CONTROL is not running in the main COG but in its own...