Odd results from connecting two propellors

DiverBob

I connected 2 propeller boards together through a single wire. One prop is configured as an output and the other as an input. The output prop is showing programmatically that the output is changing but the input prop pin is not registering the change. This is a relatively slow changing output and although both props run at different oscillator speeds, this should not make a difference. I tried using a resistor to ground on the line but that didn't make a difference. I have verified multiple times that the ports are both configured properly. I ran out of ideas of what to check for?

JonnyMac

Simple stuff:
-- common ground?
-- bad connection?

You might try putting a pull-up on the input, and then control the state of that pin by making the output ground for 0, or floating (input) for 1 (via the pull-up).

wmosscrop

Just some basic questions -

You stated that the output prop is "showing programmatically" that the output is changing. Did you verify this on the actual output pin?

What value resistor did you use for the pulldown?

Walter

RS_Jim

Bob,
Did you get your problem solved?
Jim

DiverBob

With the holiday I haven’t been able to get into the shop to try anything yet. Hopefully today will be the day, so far nothing scheduled, no place to go to, and the wife hasn’t come up with anything yet.

rjo__

I have had similar problems when there is are multiple power supplies driving everything. Try supplying your second prop directly from the first... if your first board will support it.

DiverBob

rjo__ wrote: »

I have had similar problems when there is are multiple power supplies driving everything. Try supplying your second prop directly from the first... if your first board will support it.

In my case one prop board is being supplied by the first board so I know I have common grounds. I tried swapping to a different pin on both prop boards with no change. I did a number of different troubleshooting ideas with no success. After a while I commented out this section of the code intending to return to it later, however I messed up somewhere else and now nothing works! I tried to back out of the changes but I must have missed something since everything stopped working. I finally went back to the last backup file which worked fine. Unfortunately I now need to reproduce several changes before I can attempt to implement the prop to prop link. Maybe by the time I get all the updates back into the program I will see where I messed up the setup.
Thanks for everyone’s attempt to help, I won’t be able to revisit this until I fix the code again. At least this time I had a relatively recent backup file to use.

rjo__

God, that's sounds familiar. I wonder if there are others having the same issues:)

Cluso99

I use multiple backups. Every time I add code, I backup. I use a name plus 3 numerals and an alpha as my revision level. When my code achieves a nice working point, I increment the 3 digit number and reset the alpha to "a". Sometimes I could backup (ie save) my code many times in one day. I also document my code with what I have done.

Its regimented, but has saved my bacon many times in the last 40+ years!

Here is a sample...

'' RR20130317  Cluso99  Tx routine derived from Chip's P2 Monitor
'' RR20130320  v0.10    LMM & HUB_tx working
''             v0.10a   add functions 
'' RR20130322  v0.10c   char/hex/hexrev/str working
''             v0.10c   ascii working
''             v0.10e   add dump (cog/hub)
'' RR20130322  v0.11e   dump working (hub only)
''             v0.20    sample release
'' RR20130323  v0.21a   Tx now can send up to 4 chars in one LmmTx call
''                  c   add cog mode to dump (not working!!)
''                  d   add Rx routine (working) <esc> to exit to monitor
'' RR20130324  v0.22    dump cog mode not working
'' RR20130327  v0.23a   fix _LmmRX branch backwards
''             v0.25    sample release
''                      WARNING: There seems to be a bug with pnut that will not
''                              compile code past $165F. It seems to use $1660-167F.
''                              DAT and ORG do not seem to matter.
''                              i.e code seems restricted to $800 longs = 2KB
''             v0.26x   add "byte 0[$E80] at the beginning to ensure correct hub addresses w/o offset
''             v0.27    use pnut to compile, and "p2load -v xxxx.obj -s -t" to load;  
''             v0.30    sample release
'' Note: Rather than tidy up the code, I am proceeding on adding new features such as rxstring, etc
'' RR20130329  v0.32    add rxstring (see restrictions to be fixed within code)
''             v0.33    temporary monitor command to dump working
''             v0.34    
''             v0.35    temp release
'' RR20130401  v0.36    use p2load v0.002 "p2load -v -s lsd_036.obj" to load and switch to PST quickly
''              0.37    rxstring to use lmm_ptr2 (same as dump)(not SP)
''                      DEBUG working - but single time only.
''              0.38    lmm_sp -> lmm_p3 freeup the stackpointer for use as a stack
''              0.39    use p2load v0.004a "p2load -v -s lsd_039.obj -h" or "p2load -v -s lsd039.obj -c 0,1000:0"
''                        and PST.
''              0.40    HEX: options: REV, SPACE, DIGITS 0-7 (8->0) convert routines
''              0.41    use lmm_sp (SP = @_hub_stack) for _HubXxxx calls 
''              0.42    convert dump & debug to stack calls; <esc><cr> returns from debug
''              0.43    DEBUG:  xxxxx.<cr> dumps hub; xxx,<cr> dumps cog; <cr> dumps next addr; 
''                              <esc><cr> returns to user program
''                      sample release
''              0.44    use __hubtable for mode decode
'' RR20130414   0.45    add _DUMP _CODE option (for Sapieha) _COG
''              0.46    add _DUMP _CODE _HUB and also add to DEBUG using ' and "
'' RR20130415   0.47    DEBUG: add xxx!<cr> for Goto Cog address (i.e. resumes user code at address xxx)
''                      add hex outputs to dump code 
''                      Ctl-Z now exits to the ROM MONITOR (was <esc>)
''              0.48    DEBUG:  aaa$dddddddd<cr>   stores long "dddddddd" at cog address "aaa"
''                              aaaaa#dddddddd<cr> stores long "dddddddd" at hub address "aaaaa"
''              0.49    add _RXSTRING _PROMPT option (for debug prompt as suggested by Sapieha)
''              0.50    mark the cog code with ''#####.. that can be removed (it is just example code)
''                      add _MONITOR for goto rom monitor (saves cog space)
''                      example of TxString with the string residing in hub (thanks Sapieha)
'' RR20130417   0.51    Ctl-Z returns to user cog program
''                      Ctl-Q quits & goto rom monitor
'' Sapieha has verified it works on DE2 also.
'' RR20130419   0.55    code tidy: now push/pop lmm_y; lmm_y -> lmm_f (function/mode)
''-----------------------------------------------------------------------------------------------
''      Call parameters (revised definition)...
''              lmm_f   calling function/mode ( eg: mov lmm_f, #_DEBUG ) (was lmm_y)
''              lmm_x   typically a value
''              lmm_c   typically a count                                (was lmm_2)
''              lmm_p   typically a pointer to a hub location ( eg: location of a string ) (was sometimes lmm_x)
''      Return parameters (revised definition)...
''              lmm_f   calling function/mode ( eg: mov lmm_f, #_DEBUG ) (was lmm_y)
''                              always returns unchanged (ie: "sticky")
''              lmm_x   typically a value
''                              only valid for specific calls - maybe destroyed
''              lmm_c   typically a count                                (was lmm_2)
''                              only valid for specific calls - maybe destroyed                         
''              lmm_p   typically a pointer to a hub location ( eg: location of a string ) (was sometimes lmm_x)
''                              returns set/unchanged/incremented/destroyed, according to the call function/mode
''-----------------------------------------------------------------------------------------------
'' RR20130420   0.56    Q quits & goto rom monitor (was Ctl-Q)
''                      revised _LIST options... (was _DUMP)
''                        _LIST         = 3 << 5        ' LIST a line (1/4 longs)   from cog/hub
''                          _ADDR2      = 1 << 4        ' 1= use lmm_c as a to-adress
''                          _COUNT      = 1 << 3        ' 1= use lmm_c to display 'n' lines (counter)
''                          _HDG        = 1 << 2        ' 1=display heading for opcode format
''                          _MON        = 00            ' \ Format 0:   4 longs, rom "MON"itor format
''                          _SMON       = 01            ' |        1:   4 longs, "S"hort rom "MON"itor format (no ascii)
''                          _CODE       = 10            ' |        2:   1 long,  code format
''                          _LONG       = 11            ' /        3:   4 longs, xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx (Sapieha)
''                      revised _LIST parameters...
''                        lmm_p = cog/hub addr (was lmm_x); lmm_2 = count(optional)
''-----------------------------------------------------------------------------------------------
'' RR20130421   0.57
'' RR20130421   0.58    calling convention (lmm_p now also used for txstring & rxstring)
''                      add _RXSTRING options _ADDR and _NOLF
'' RR20130422   0.59    
'' RR20130423   0.60    ParseHex skips leading spaces
''                      M command has options: M=normal(monitor) M1=short, M2=code, M3=long
''                      L is removed (replaced by M2)
''              0.61    add new parameters for M: xxxxx[.yyyyy][,cc]M[n]<cr> where yyyyy=to-addr cc=count
''                      add new parameter to _DUMP _ADDR2 for from/to address lmm_p to lmm_c
''              0.62    Change M command to L command
''                      Add code for Sapieha
''              0.64    incl code for Sapieha; change _DUMP to _LIST
''              0.65    add new command "?" for help (thanks to Sapieha for the help detail)
''              0.66    code tidy, add new ReverseByte, enable demo, fix demo bug in hex display
'' RR20130425   0.67    new command "P": displays port PINn & DIRn values (added by Sapieha)
''                      new command "M": moves memory xxxxx.yyyyy,ccM<cr>
'' RR20130426   0.68    faster/smaller ReverseByte
''                      command "-": terminate input when single quote (ascii text) reached
''              0.69
'' RR20130427   0.70    structure change using stack; remove ASCII mode
''                      replaced _HubHex & _HubNibble with new _HubHex routine
''                      major code tidy for _HubTx, _HubTxString, _HubHex, _HubRx, _HubRxString
''                      modify calling structure for LmmTx,LmmRx,LmmFun
''                      remove use of lmm_v
''                      Note: lmm_w is only for internal use and is destroyed on returns from calls
''              0.71    Add Sapieha's mods
''              0.72    new command V (by Sapieha), incorporate Sapieha's mods to help strings, etc
'' RR20130428   0.73    further code tidy: _HubList (not complete), _HubMove, _RdLongCogHub, _WrLongCogHub
''                        ParseHex, ParseDec, _HubMonitor
'' *****        Sapieha - please see ParseHex and ParseDec
''                      remove command info from immediately below as they are specified in the _str_help string 
''                        at the end of this program (need to be recovered from the help string later for docs)
''              0.74    commence ParseCommand
''                      re-specify interactive debug commands (help string)
''                      major code tidy for _HubList (note 'f' is restored on return to caller)
'' RR20130509   0.76    restore 'c' in hublist
'' RR20130510   0.77    commence cccc for LIST/CODE disassembly
''              0.78    fix Move command (store not wkg)
''              0.79    recombine Sapieha's special code & Vx commands
''              0.80    fix Store command (debug input) and further tidy
''              0.81    add instruction disassem for list/code
'' RR20130513   0.82    ... basic disassem for list/code
''                         note L has a temporary count restriction of 32
''                      if_ etc to lowercase (thanks Sapieha)
''              0.83    most of opcode 000011 decoded (need to fix S display)
''              0.85    swap rdxxxx/wrxxxx R bit test
''              0.85c   fix source corruption lf problem (Notepad++ error???)
''              0.85e   add in Sapieha's changed V code
''              0.86    note fix/setindx instrs display cond if_... (shouldn't)
''                           other instrs display D,[#]S wz,wc,nr when shouldn't
''                           cmp/test only display tha base instr with nr
''                           other simple shortcuts have been made
''                           add instruction docn to end
'' RR20130517           create v0.86m fork (min version - removes demo clutter in cog space)
'' RR20130518           0.87
''-----------------------------------------------------------------------------------------------
'' RR20131003   0.90    mods for new fpga code and pnut compiler
''                           xinfreq = 80MHz; orgh $E80; monitor start = $700
''                           remove filler from $E80-EFF because F11 causes start at $E80 only!!!
''                      instruction decoding need fixing for new format, otherwise works for new fpga
''              0.91    fix instruction decoding for new fpga
''              0.92    continued  (minimal version)
''              0.93    new instruction set
'' RR20131126   095     new instruction set/emulation/pnut
''                      var wait -> waitx (wait cannot be used as a label)
''                      parameters now start $1D0 (was $1E0)
''                              $1F2..$1F3 INDA, INDB
''                              $1F4..$1F7 PINA..PIND (read only)
''                              $1F8..$1FB OUTA..OUTD
''                              $1FC..$1FF DIRA..DIRD
''                      movs -> sets, movd -> setd
''                      shr xxx,#nn+1 wc,nr -> shr xxx,#nn wc
''                      setcog xxx -> setnib :setcog,xxx,#6 (2 clock delay) &
''                      coginit pgm,ptr -> :setcog coginit pgm,ptr,#0-0
''                      _ROM_SIZE = $0E80 -> $0E00
''                      _MON_START = $00700 -> $006E4
''                      cannot use _period because 644 @ 80MHz
''                      waitcnt bug in P2 emulation
'' RR20131206   095f    use SERIAL A
''                 h    works (Hub Tx & Rx use Serial A)
'' RR20131220      j    new instr tables
''                      fix _HubTx to send all chars in lmm_x
'' RR20131222      m    new table decode wkg (opcode only)
''                 r    new table_cccc
'' RR20131224      z    code tidy _ListOpcode

rjo__

That looks pretty good to me. Except that I would have to do something very much simpler:)

I'm thinking that Chip must do something similar. I can't imagine keeping a project like the P2v organized.
The way he adds, subtracts, rips apart, glues together, changes names, and supports all of the different platforms is amazing to watch.

rbehm

It's simple. Get some revision control system, best one of the older simpler one like CVS.
When I develop software or other stuff like schematics, layouts, even documents, I check it into the CVS. For example when writing some larger software I check it in when something is working, even only partially. CVS takes care of the numbering that Cluso is talking about. Each Check-in gets a comment.
If making changes which lead to non-working version I can always go back and check out older version. When I leave my desk in the evening I usually check in everything, that gives me some king of backup.
If a version gets released it will be tagged and I can go on with modifications and tests. I can always check out the tagged version.
I never will work without such a safety net.
Having started that about 40 years ago (with RCS on OS/2) I cannot imagine working without that.
The newer revision control systems (GIT, Mercurial, etc) are often more complex in handling and setup and do not allow me that freedom. All checked in repositories are simple ASCII text. If any thng goes wrong I can manually repair it.
And there are tools that show me what has been changed from version 1.2 to 3.4.2.1. This sometimes helps you to find what you have messed up.

Cluso99

I don't like anything backed up in the cloud. I like to control my own destiny.

I developed my own regime long before PCs or Apple's were thought of, even before the microchip. It has saved my bacon so many times, there is no need for me to relinquish control to another system.

Mark_T

But a version control system is nothing to do with the cloud - its just a piece of software you can run
wherever you want to organize multiple versions of documents. Yes, there's a lot of functionality to
support collaborative working that naturally fits with a cloud-based server, but you aren't compelled to
do that for your own projects.

Tor

Install Git and get total control of your work and your revisions.

DiverBob

I've downloaded SmartCVS for windows and will give that a try. Back when I worked as a developer we used a MS product for version control but that was many years ago and it would be too much admin for home use. I'll give this a go and see how well it works. Normally I rename my files with a new version number whenever I get a stable, working code but there can be quite a bit of time between these copies. I have backup software that is supposed to run weekly but since that computer is normally on only when I'm using it, the backup doesn't run normally unless I manually trigger it. This was how I got my last update, found the last backup that was only 5 weeks old. I guess its a 'good' thing I haven't been using the computer much this summer so there hasn't been too much lose between then and now!
Anyway, I was able to recreate most of the code changes last night from memory and got the software to work again. I was then able to implement the prop to prop link and now it appears to be working. I don't know what is different this time, same commands are being used but the master prop is reading the other prop pin output. I went back to a direct connection between the two prop pins.