Starting and stopping FDS Extended

Hugh

The code I have written is using all cogs but I could really, really, do with another serial interface.

I may be being naive but what I hoped I would be able to do with a single FullDuplexSerialExtended object was along the lines of:

Repeat 
    Start the FDSE object (Pin 'A', 9600 baud).
    Tx stuff
    Stop the FDSE object
    Start the FDSE object (Pin 'B', 115200 baud).
    Tx stuff
    Stop the FDSE object

i.e., service two outputs alternately with only a single cog.

It doesn't seem to work (the second .start returns a value of -1).

I have tried storing the cogID returned when FDS is first started and then using cognew to start FDSE again in the same cog; I have tried including a delay between the steps.

So,

• Should this be possible?
• Am I missing a step between starting and stopping?

Cheers
Hugh

kwinn

Simpler to switch to the 4 port serial object. It runs in one cog and provides 1 to 4 serial ports.

Duane Degn

kwinn wrote: »

Simpler to switch to the 4 port serial object. It runs in one cog and provides 1 to 4 serial ports.

+1

Here's a link to the OBEX. The development of this object was discussed in this thread.

If you're running low on RAM, I have a two port version which is smaller than the four port version. The two port version is part of the archive attached to this post.

Hugh

Thanks

My recalcitrance with regard to fullDuplexSerial4port was a degree of uncertainty on my part as to whether the four ports could be used across several cogs (I have individual cogs spending their time reading serial data and making it available to the main code).

I will try it when I get back home this evening.

Cheers
Hugh

Tracy Allen

Can you define more what you mean by "across several cogs"?

The 4port object is usually initialized and started from the top level object. Then, other objects can declare it in their OBJ block and use it, other cogs if necessary. All the objects have access to those same 4 serial ports.

If multiple cogs try to access one of the ports at the same time, reading or writing, that would mingle the data streams, probably not a good thing.

Hugh

Thanks Tracy,

In the top object file I have declared "ser" as the FDS4P object and added ports as below, with the intention that other PUBs running in dedicated cogs could use them:

(This code is in PUB Main)

 ser.init   
 '  ser.AddPort(portGPS,   pinSerGPS,          -1, -1, -1, 0, 0,   9600)
 '  ser.AddPort(portFF,     pinSerFF,          -1, -1, -1, 0, 0,   4800)
 ser.AddPort(0,                -1,          29, -1, -1, 0, 0, 115200)
 'ser.start

At this point the other PUBs/cogs have not been started.

As written the code in 'Main' continues as expected. However, uncommenting the "ser.start" (Line 286 in "FFGPS115fsds4 - New board, tacho.spin", attached) causes 'Main' to stop 60 or so lines later (Line 347) . I don't think memory is being trampled over but it has got me scratching my head!

When in a spin file that contains only the code shown above data is sent perfectly (i.e., "Digital tacho2.spin")

I think I am stumped.

FFGPS115fsds4 - New board, tacho - Archive [Date 2014.05.22 Time 18.57].zip

Digital tacho2 - Archive [Date 2014.05.22 Time 18.59].zip

Hugh

I've been working through the .start method of the FDS4P object and despite the comments am a bit confused as to what it actually does and how it might be causing problems: would I be right in assuming that 'buffers' is an address followed by a list of longs that start from the @buffers?

Thanks

Hugh

Tracy Allen

The size of each of the 4 rx buffers and the 4 tx buffers are defined in the CONstants section. Those sizes default to 80 bytes for rx and 20 bytes for tx. Down in the DATa section, after the pasm program you will find a section titled "Start of HUB overlay" and there you will find the name "buffers". The first part of the Start method allocates space (in units of bytes) in HUB ram for the 4 rx & 4 tx buffers. The first tx buffer starts right at the location @buffers. The second tx buffer starts at @buffers+20, and so on for all 8 buffers. Those are the base addresses of the buffers and they do not change during program execution. The second half of the Start method initializes the head and tail pointers. Those addresses change dynamically as data sloshes in and out of the individual buffers.

Note that you can change the CONstants for the buffer sizes. The Start method takes care of fitting them in. For example, you might want one buffer to be much larger in order to receive and send asynchronous packets, lets's say 1024 bytes and 120 bytes. And you might not need all 4 ports, so you can set SIZE constants to a small number. Make their SIZE = 4 (don't make it zero, dicey results)

Tracy Allen

Your AddPort statement directs the serial tx to the pin normally used for sda communication with the eeprom. Is that really what you want?

[FONT=courier new]ser.AddPort(0, -1, [COLOR=#ff0000]29[/COLOR], -1, -1, 0, 0, 115200) [/FONT]