FullDuplex in Assembly

Comments

• SRLM Posts: 5,045

  2009-10-26 16:43 edited 2009-10-26 16:43

  The heart of FDS is already in assembly. The Spin sections just give easy access to the underlying pasm code. I've hacked FDS before for one of my drivers, and I was able to just take the transmit and receive routines directly from the code and reproduce them in my code. From there, it's fairly straight forward to write your own routines to do what you want, with them calling the transmit or receive routine as needed.
• jazzed Posts: 11,803

  2009-10-26 17:04 edited 2009-10-26 17:04

  I'm afraid the only way to make it faster is to write the entire application in PASM or use C (or other LMM language). Any Spin method call takes more than 20us (20 micro-seconds at 80MHz). An empty ICCPROP C function call takes about 1us (I have not measured Catalina performance). The C FdSerial in the OBEX will work although the resulting code will be about 4x Spin equivalent size because of LMM implementation.
  
  

  SPIN/PASM/ICCPROP Comparisons
  
  SPIN PASM     ICCPROP *1 - Condition
   
  25us 200ns    1.04us - Bit toggle while loop cycle *2 time.
   
  40us 420ns    2.1us  - Bit toggle while loop set by if-else loop with ndx & 1.
   
  50us 520ns *3 2.9us  - Bit toggle while loop set by if-else loop with ndx & 1 + increment.
   
  40us 420ns    3.8us  - Function call bit toggle while loop cycle time.
   
  26s  800ms    14s    - Fibo29 test (relative ... not necessarily the best performance measure).
   
  Notes:
  1. ImageCraft C default LMM unrolled by 4 and uncached.
  2. A cycle is a transition from state 1 to state 2 back to state 1. Some "periods" of cycles are asymetrical.
  3. Asymetrical comparison if_z, if_nz, then increment.
  4. Performance for Catalina not known.
  
  

  
  
  Fixed table formatting.
  
  Post Edited (jazzed) : 10/26/2009 5:11:36 PM GMT
• Cluso99 Posts: 18,071

  2009-10-26 21:53 edited 2009-10-26 21:53

  FDX runs fine at 115,200 baud and is in pasm as stated above. The problem you are no doubt seeing is the spin upper level code. You could try a larger buffer if your data is received in bursts.
  
  Try FullDuplexSerial_rr004.spin posted in the TriBlade thread. It is in the ZiCog code _rr126 near the end of the posts. See link to TriBlade in my signature below. I have modified FDX to make the buffersize a constant, so change the constant to a larger size, say 256 bytes.
  
  ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  Links to other interesting threads:
  
  · Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
  · Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
  · Prop Tools under Development or Completed (Index)
  · Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
  · Search the Propeller forums·(uses advanced Google search)
  My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
• cts566 Posts: 4

  2009-11-02 16:26 edited 2009-11-02 16:26

  Hey guys,
  
  Thanks for the replies. I looked into my code a little more and you all are indeed right: my slowest portion is due to spin upper level code. I'm going to convert my program and the necessary parts of FDS to PASM code (halfway there!). I'll post the program if anything good comes of it.
  
  On a related note: has anyone heard of a carriage return (or equivalent) in PASM?
  
  - AP
• SRLM Posts: 5,045

  2009-11-02 18:14 edited 2009-11-02 18:14

  CR is just a value (13). It's no different than A (65) or a(97).
• cts566 Posts: 4

  2009-11-09 17:11 edited 2009-11-09 17:11

  Sorry to be a bother again, but is there an easy way to convert the "tx" in FDS to pasm code? Here is what I have so far:
  
  

                          org
  txpasm                  mov txneg, txhead             
                          add txneg, #1                 
                          and txneg, #$F               
  
  
  testloop                cmps txtail, txneg    wz      
             if_z         jmp #testloop
             if_nz        jmp #success
                    
  success                 rdbyte txbuffer, par       
                          add txhead, #1                
                          and txhead, #$F              
                          jmp #txpasm                                    
  
  

  
  
  
  As always, any help is appreciated. Thanks - AP
• SRLM Posts: 5,045

  2009-11-09 18:10 edited 2009-11-09 18:10

  Take a look at the code here: obex.parallax.com/objects/534/
  
  Basically, all you need to do it to slightly modify the tx and rx routines so that it is simplex (one way at a time). Then, MOV txdata, t1 (replace t1 with your value) and CALL #transmit. The linked code does it a bunch, most notably during initialization. This assumes that you are not using the buffer.
• dMajo Posts: 860

  2009-11-09 18:22 edited 2009-11-09 18:22

  pcFullDuplexSerial4FC claims "up to 750kbps single port; up to 100kbps on 4 ports; tested 4 ports to 115Kbps with 6MHz crystal; with RTS/CTS flow control"
  
  Serch the obex for JDCogSerial (supports standard baud rates up to 230400; cog resident fifo).
  
  Also KYE IIRC have made some serial engines with cog resident fifo
  
  ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  · Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search
• fullspeceng Posts: 76

  2009-11-09 18:27 edited 2009-11-09 18:27

  I rewrote the whole thing in assembly for a commercial project (and learn my first pasm project) and can get around 2-3bmps or so.
  
  Hardware flow control would help a LOT.
  
  It's too bad the parallax protoboards/demo boards don't use use the SOIC version of the FT232r. You could just jumper the connections but instead it's the tiny QFN version so you need to roll your own board.
  
  I'm using an FT245r for my next project and hope to get the full 12mbps but it's a parallel bus.
• Cluso99 Posts: 18,071

  2009-11-09 21:29 edited 2009-11-09 21:29

  cts566: You have the idea, but you should be testing (waiting) for your tail to not be equal to the head. Otherwise if ou are too slow and there is more than 1 char in the buffer you will miss a buffer full. As I said before, I modified FDX to handle larger buffer sizes (powers of 2, so 32, 64, 128... bytes) - see the FDX in the ZiCog & TriBlade threads.
  
  ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  Links to other interesting threads:
  
  · Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
  · Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
  · Prop Tools under Development or Completed (Index)
  · Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
  · Search the Propeller forums·(uses advanced Google search)
  My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm