Help with assembly code size

mynet43 · 2012-06-09 10:23

I have a new Propeller Board I've designed. It has two Propellers, SRAM memory and a chip used to convert NTSC video data to RGB565 digital pixel data.

The board is about 90% working. The two Propellers are talking to each other at about 2Mbits/sec. The decoding chip is working and now I'm trying to debug the SRAM interface.

The problem I'm having is with the slave program, running in the second Propeller. It launches an assembly language cog that interfaces with the other hardware on the board. The problem seems to be that the cog is too large, but I'm not sure.

It receives commands from the master Propeller correctly. It calls the routine to capture a picture. This terminates correctly. It processes most of the request to send the first line of pixels back to the master Propeller. Then it hangs up.

If I reduce the amount of assembly code, by removing some debug lines or deleting a routing that's not used, then it gets farther. I haven't been able to spot anything obvious that would cause this.

Can you help me find out if my cog is too large. I'm not sure how to do this. Or if it's some other mistake I'm making.

The code is attached: slave.spin.

Thank you for your help and support.

Jim

Duane Degn · 2012-06-09 11:20

Since you used "org" and "fit" it shouldn't be possible for your cog code to be too large.

I sometime insert this piece of code to stop a PASM cog to try to find where a glitch is occuring.

    jmp  #$

It tell the cog to "jump here".

It's like adding a repeat with nothing being repeated in Spin.

It just puts the code in an infinite loop so you can stop the cog in various locations. This can give you an idea of where the problem code is located.

Duane Degn · 2012-06-09 11:31

Do you know if your I2C communication is working correctly?

I see the code drives both the clock and the data lines. I think with I2C your supposed let the pull-up resistors pull the lines high by making the Prop pins inputs. A few Prop boards don't have pull-up resistors on the clock line so the clock needs to be driven.

I'd be concerned that the Prop might leave the data line as and output and you wouldn't be able to read from the device properly. If you're careful with the code I think you can get away with driving the data line, but I think it's safer to let the pull-up resistor pull the line high.

mynet43 · 2012-06-09 13:00

Hi Duane,

Thanks for taking a look at this.

That's a good suggestion regarding the jmp #$. I'll try it to see if I can pin down where it's having a problem. I've been using my _debug_out routine to track where I'm at, but this should give me a closer look at it.

You also asked about my i2c routine. I have two of these. The one in spin code is used to talk to the AL330B conversion chip. This has been working perfectly for a long time.

The second i2c routine is in assembly code. It's used only to send data back-and-forth between the two Propellers. It's not really i2c protocol. It's more like half-duplex. Where each one knows what to send and what to expect. The slave sits there waiting for a command, in read mode (_get_cmd). Once the master has sent a command, it releases the lines and starts waiting for an expected response, in input mode. Each one releases the lines when they're done. And the scl line is pulled low to prevent false triggers when both have it released. The routine _test_comm is used to test this interface. I've called it over-and-over many times and it seems to be working perfectly.

Let me know if you have any more questions or suggestions. I'm still struggling with this

Thank you for your help.

Jim

kuroneko · 2012-06-09 18:14

Just thinking aloud here. In _get_cmd you expect 32 clock cycles. What if you miss the first due to some timing differences (e.g. hub aliasing)? This may not be an issue in the end but it's hard to tell without seeing the code for the master.

SRLM · 2012-06-09 19:34

Duane Degn wrote: »
I sometime insert this piece of code to stop a PASM cog to try to find where a glitch is occuring.
    jmp  #$
It tell the cog to "jump here".

This is new to me. Do you have a link to where it is documented? From what I can tell, it shouldn't even compile since the $ symbol is a hexadecimal indicator. But in this case it seems to take the value of the PC.

For debugging assembly, I use the BMA debugger. Here's a thread that discusses PASM debugging: http://forums.parallax.com/showthread.php?132221-Best-Practices-tools-for-PASM-debugging&p=1008866#post1008866

kuroneko · 2012-06-09 19:44

SRLM wrote: »

This is new to me. Do you have a link to where it is documented?

Propeller Manual, rev 1.2, page 298

The Here Symbol $
The Here Symbol, $, represents the current address. During development and debugging, the Here Symbol $ is often used in the JMP instructions Address field (i.e., JMP #$) to cause the cog to endlessly loop in place. It may also be used as a relative jump back or forward a number of instructions, ...

mynet43 · 2012-06-09 20:36

@ kuroneko

Thank you for taking a look at the code. I appreciate it!

When I first read your post about missing a bit, I thought this couldn't happen, with the waitpeq/waitpne in the code.

Then, when I thought about it, I decided I wanted to be sure. So I put in a loop to send messages back and forth 10000 times, to see if I could get it to fail. I ran this several times and it worked perfectly all the time, so I'm pretty confident in the basic comm between the two Propellers.

In this case, I'm only sending one 32 bit word each way for each loop of the test. What occurred to me was that when I ask for the second prop to return a line of pixels, it asks for a continuous stream of 160 32-bit longs, to send the 320 pixels in a scan line. I haven't thoroughly tested this yet, so it's possible with that much continuous traffic that it might still be missing something. I'll expand the test to try this too.

Here's a snippet of the current code I'm using, to test the 10000 messages. I've also included the "master.spin" which is the assembly code on the master Propeller. Please let me know if you see anything else I should look at.

OBJ
  cam   : "master"              ' Camera Driver Routine

VAR
  long  cam_err                 ' error code returned by camera routines

PUB TM3000 | ct,i,j,k,w_wdth,w_hgt,v_ofs
  initialize                    ' set up drivers and initial conditions

  init_terminal                 ' initialize the terminal, ready for commands
  str_t(string("Terminal Started...",13))

  cam.start(@line_of_pixels[0]) ' start camera routines
  str_t(string("Camera Initialized...",13,13))

  repeat i from 0 to cols-1     ' debug * set up line of pixels array
    line_of_pixels[i] := $F800  ' debug *****************************

  waitcnt(clkfreq*2+cnt)        ' wait for other Prop to initialize
  str_t(string("Ready...",13))

  repeat i from 0 to 10000       ' send command, wait for ack
    cursloc_t(5,20) 
    str_t(string("Test Command Called - cam_err = "))
    cam_err := cam.test_command ' debug, see if we're talking to other Propeller
    dec_t(cam_err)
    space_t
    dec_t(i)
    tx_t(13)
 
  str_t(string(13,"cam.take_picture - cam_err = "))
  cam_err := cam.take_picture   ' take a picture with the camera
  dec_t(cam_err)
  tx_t(13)

  repeat                        ' debug ***** wait here forever to keep cogs running

Thank you for your help.

Jim

mynet43 · 2012-06-14 07:43

Hi everyone.

Just a quick update from all the help you provided earlier. I now have everything working.

I can send data between the two Propellers at about 2M-bits/sec. I have the SRAM working at 6.5MHz, to capture a picture from the camera. And I can send a complete 320x240 color picture across the link, from the SRAM, thru one Prop, to the other Prop and then to the touch-screen display terminal. See attached picture.

If any of this is useful, I'll be happy to provide the code or the schematics.

Thank you for all your help getting through this.

Jim

Duane Degn · 2012-06-14 11:32

Wow, That's is super cool!

I'd love to know which chip you're using and if you're willing to share the code, I'd like to see it.

I'd also like to know what touchscreen you're using.

mynet43 · 2012-06-14 22:34

Hi Duane,

The touchscreen I'm using is a 7" color from reachtech.com. It has a serial interface and a built-in bios that supports windows, buttons and many other functions.

The chip I'm using to convert NTSC analog video to RGB565 is the AL330B from AverLogic Technologies. It's a 128 pin chip that is a little tricky to solder to the board. It has an i2c interface for control commands. I currently send it about 100 commands to set it up, and I'm still tweaking it a little to adjust the color.

The pixel output from the chip is too fast for the Propeller to capture directly, so I installed enough 45ns SRAM to capture a single frame. 320x240x16 bits/pixel is 153600 bytes/frame. I'm using two 256Kx8bit SRAMS in parallel, to capture 16 bits per clock. The pixel clock is running at 6.5MHz, so I use that to control an address counter while the picture is being captured. After this, I turn the I/O around and read the SRAM from the Prop at a slower speed. One scan line at a time until I transfer the picture from one Prop to the other.

If you want to see the code or the schematic, send me a PM with your email address and I'll forward it to you.

Thanks for your interest. Let me know if you have any questions.

Jim

Help with assembly code size

Comments