2009-03-10 11:52:12     Unlimited Software-UARTS on BF561-CORE-B design considerations

Document created by Aaronwu Employee on Aug 14, 2013
Version 1Show Document
  • View in full screen mode

2009-03-10 11:52:12     Unlimited Software-UARTS on BF561-CORE-B design considerations

Marco Rohleder (GERMANY)

Message: 70707   

 

Hi !

 

I have an application where i need to run 10 and more UARTS to communicate with several serial devices ( ATMs, modems, alarm centrals, etc ).

 

I've build a solution to run this as software emulation on core B of BF561.

 

How many UARTS you can run simultaneously depends only on the remaining processing power of core B.

 

In practice i tested for example 4 softuarts running at 115000 Baud and running 6 others at 9600 Baud.

 

Before making it public to other users I would like to discuss if my way of implementation could be upgraded.

 

As i told, the whole core B is just 'uarting'. This is done by creating several soft-UARTs objects which all have a look to the CORE Timer and than to decide if it is the right time to send or receive a bit by using a PortFlag.

 

In core A runs a driver, which behaves like a normal TTY and communicates with core B.

 

The first implementation allocated a piece of kernel memory and when core b started, the start address of this was committed.

 

For slow baudrates this worked well, but with higher baudrates i got a lot of missing bits. I found  out, when both cores are working on the same SDRAM-locations there are some times longer pauses up to a few microseconds. Thats to much to come back to the receive routine to receive the next bits. Secondary, the caches had to be disabled, otherwise sometimes core A didnt see new received characters by Core B and core B didnt see new bytes to send initiated be core A.

 

So in the second implementation i designed a 32Bit-wide command interface to core B. For avoiding cache problems i used a timer period register for this. So in case an instance of the TTY-driver on core A side wants to send a byte, he sends a command in form of | CMD=SENDCHAR | UARTINSTANCE  | BYTETOSEND | ( 32bits ) by writing it to timer period register. Core B watches permanently on this timer period register for a command. And if there is one, processes it and gives back the answer to this timer period register.

 

Receiving characters is done in a similar way.

 

The send- and receive-buffers are located in the 16K SRAM of core B.

 

For very specific applications where very fast response to a received telegram is needed ( less than 10 msec ), i upgraded the core A side with an interrupt function. Because i cannot do any signalling to the kernel by core B, i implemented this with a PortFlag. When core B has any received charecters left, it sets the Portflag to 1. The driver on core A has an interrupt implementation for that corresponding portflag and so can handle the received char immediately.

 

What i am asking me:

 

1) Is is possible to use the 128K SRAM which is accessible to both cores instead of using a timer period register. Is that area cached and if, is it possible to disable the cache only for that region. Is that 128K area anywhere used within the kernel.

 

2) Are there better solutions instead of using a portflag to do signals between both cores.

 

3) The handling of the whole scenery is as follows:

 

a) start softuart application on core B

b) start softuart driver on core A

c) create nodes in /dev belonging to the major number of softuart driver

d) use this uart by typing for example ls -l > /dev/softuart1

 

The configuration, which portflags belong to which softuart instance is done within the softuart driver code. This is not very smart because of the need of recompilation to change the port flags, baudrates etc.

 

By the way ? How is done with normal TTY drivers ? I think on user code side with ioctl. But how to change it by command line ?

 

I would prefer a solution with a configuration file as for example with fstab.

But with my state of knowledge it is not possible to open a file, while in a kernel module, isnt it ?

 

Any ideas, to do this in a more 'linux-friendly' way.

 

Looking forward to your suggestions

 

Marco

 

 

QuoteReplyEditDelete

 

 

2009-03-10 15:45:53     Re: Unlimited Software-UARTS on BF561-CORE-B design considerations

Mike Frysinger (UNITED STATES)

Message: 70721   

 

if you need fast locking, then do not enable caching on L2 and then use the testandset instruction on it.

 

for signaling core a from core b, use the supplemental interrupts.  read about SICB_SYSCR in the BF561 HRM.

 

normal TTY drivers do not have kernel command line options to change settings.  consoles do, but not TTY drivers.

 

i dont know how much of a UART you are emulating on the Linux side, but the TTY stack has full termios support for changing settings from userspace.

QuoteReplyEditDelete

 

 

2009-03-12 12:59:43     Re: Unlimited Software-UARTS on BF561-CORE-B design considerations

Marco Rohleder (GERMANY)

Message: 70878   

 

Mike,

 

 

many thanks for your advice !

 

I didnt know, that there is already a generic serial driver core.

I took a look to the bfin and bfin-sport emulation drivers.

It's now clear to me and i will adapt my source to that.

 

But one question left:

Is that piece of 128K SRAM which is available to both processors, anywhere used within the linux kernel ?

 

I read in the SMP doku, that it used for semaphores when SMP is switched on.

Thats not a problem, because you cannot run uart-software-emulation and SMP at the same time.

 

Is that 128K usually cached and when, what to do to make it uncashed ?

 

 

 

QuoteReplyEditDelete

 

 

2009-03-12 17:24:25     Re: Unlimited Software-UARTS on BF561-CORE-B design considerations

Mike Frysinger (UNITED STATES)

Message: 70892   

 

by default, L2 is completely unused.  with the next release (current trunk), you can reserve storage yourself by using the normal attributes or sram alloc functions.

 

it isnt cached by default ... it's a kernel option under trunk

Attachments

    Outcomes