On 11/11/2014 1:06 AM, Daniel Doron wrote:
>> Are you already using the 3 on chip USARTs on the 9263? If not how about
>> just using one of them as a serial device from Linux.
>
> yes. using all of them already.
>

How about the TWI or SPI ports ??

Will you need two way communication ??

Creating a real time serial data in a non-realtime operating system 
seems doomed to failure.

Thinking out loud, to send serial data bytes: how about the SPI data 
port acting as the 8-bit serial data.

As the SPI port holds the state of the last bit sent, three bytes 
0x01,(Txdata>,0x80.

Setting the SPI baud rate timer for 104.166 uSec would give you ~9600 board.
Update time between byte would be ~.83 mSec.

The SPI holding register will keep the bytes side-by-side.

RxData will be much harder.

On 2014-11-11, Vladimir Ivanov <none@none.tld> wrote:

>> Trying to do it from Linux (and with a very old kernel on a slow
>> processor) is going to be difficult unless he can dedicate a high
>> priority timer interrupt to the job.  With a timer interrupt with fairly
>> low jitter, it should be fine, even with Linux running.  If possible,
>> the interrupt code and the relevant data should be put in internal ram
>> so that cache misses do not slow it down.
>
> If possible, OP could try FIQ with highest priority and write own
> small handler in assembler, using the FIQ banked registers for speed.
> No kernel API usage at all, just plain FIFO (ring buffer) somewhere
> in memory for lowest overhead.
>
> All the implications with kernel disabling the interrupts remain.

The kernel never uses and never disables the FIQ.  It runs completely
outside of kernel awareness and control.

> As a very quick test, I'd put short FIQ code that simply toggles
> GPIO, and then check visually how bad the jitter goes under load.

Been there, done that.  The FIQ jitter does not change noticably under
load.  Any interactions with normal kernel code have to be done very
carefully, since you can't use any of the kernel's normal
synchronization mechanisms.

-- 
Grant Edwards               grant.b.edwards        Yow! And then we could sit
                                  at               on the hoods of cars at
                              gmail.com            stop lights!

On 2014-11-11, David Brown <david.brown@hesbynett.no> wrote:

> My record for bit-banged uarts is 38.4 kBaud on a 9.8 MHz processor.

I did 57.6K on a ~1 MHz processor, but it was tx only. Still, it
worked great for printf() output while bringing the board up.  IIRC,
on that same processor, I did a 1200 Bell-202 modem (rx and tx) using
a counter/timer, but I used a hardware UART for that.

-- 
Grant Edwards               grant.b.edwards        Yow! Th' MIND is the Pizza
                                  at               Palace of th' SOUL
                              gmail.com

On 11/11/14 12:04, Vladimir Ivanov wrote:
> 
> On Tue, 11 Nov 2014, David Brown wrote:
> 
>>>>> On 10.11.2014 21:44, Daniel Doron wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I have tried to look an answer for this on the web, but I mainly got
>>>>>> "no can do" (timing issue).
>>>>>>
>>>>>> Kernel: 2.6.3x
>>>>>> MCU: atmel at91 (9263)
>>>>>>
>>>>>> I wish to get/write a driver to bitbang a couple of gpios to
>>>>>> emulate a
>>>>>> uart. the communication is with a remote PIC (PIC12F683) to which I
>>>>>> have already wrote the software and checked with linux terminal.
>>>>>> the communication does not have to be fast at all (1200 would be
>>>>>> fine). only a few bytes are exchanged.
>>>>>>
>>>>>> can someone point me in the right direction? did someone already
>>>>>> develop such a driver? is there an example/guide I can follow to
>>>>>> do it?
>>>>>>
>>>>>> Daniel.
>>
>> Trying to do it from Linux (and with a very old kernel on a slow
>> processor) is going to be difficult unless he can dedicate a high
>> priority timer interrupt to the job.  With a timer interrupt with fairly
>> low jitter, it should be fine, even with Linux running.  If possible,
>> the interrupt code and the relevant data should be put in internal ram
>> so that cache misses do not slow it down.
> 
> If possible, OP could try FIQ with highest priority and write own small
> handler in assembler, using the FIQ banked registers for speed. No
> kernel API usage at all, just plain FIFO (ring buffer) somewhere in
> memory for lowest overhead.

Agreed.  It may also be possible to use the compiler but with restricted
register access - he would have to check the details here.

> 
> All the implications with kernel disabling the interrupts remain.
> 

Since it is Linux, and he has the source code, it is actually possible
for him to modify the interrupt enable/disable code to make sure the FIQ
(or other interrupt) is still enabled.  Real-time Linux extensions that
combine an RTOS with Linux running as the RTOS's idle task do that.

> As a very quick test, I'd put short FIQ code that simply toggles GPIO,
> and then check visually how bad the jitter goes under load.

Good idea.

On Tue, 11 Nov 2014, David Brown wrote:

>>>> On 10.11.2014 21:44, Daniel Doron wrote:
>>>>> Hi all,
>>>>>
>>>>> I have tried to look an answer for this on the web, but I mainly got
>>>>> "no can do" (timing issue).
>>>>>
>>>>> Kernel: 2.6.3x
>>>>> MCU: atmel at91 (9263)
>>>>>
>>>>> I wish to get/write a driver to bitbang a couple of gpios to emulate a
>>>>> uart. the communication is with a remote PIC (PIC12F683) to which I
>>>>> have already wrote the software and checked with linux terminal.
>>>>> the communication does not have to be fast at all (1200 would be
>>>>> fine). only a few bytes are exchanged.
>>>>>
>>>>> can someone point me in the right direction? did someone already
>>>>> develop such a driver? is there an example/guide I can follow to do it?
>>>>>
>>>>> Daniel.
>
> Trying to do it from Linux (and with a very old kernel on a slow
> processor) is going to be difficult unless he can dedicate a high
> priority timer interrupt to the job.  With a timer interrupt with fairly
> low jitter, it should be fine, even with Linux running.  If possible,
> the interrupt code and the relevant data should be put in internal ram
> so that cache misses do not slow it down.

If possible, OP could try FIQ with highest priority and write own small 
handler in assembler, using the FIQ banked registers for speed. No kernel 
API usage at all, just plain FIFO (ring buffer) somewhere in memory for 
lowest overhead.

All the implications with kernel disabling the interrupts remain.

As a very quick test, I'd put short FIQ code that simply toggles GPIO, and 
then check visually how bad the jitter goes under load.

On 11/11/2014 3:06 AM, Daniel Doron wrote:
> On Monday, November 10, 2014 9:41:24 PM UTC+2, Dennis wrote:
>> On 11/10/2014 07:44 AM, Daniel Doron wrote:
>>> Hi all,
>>>
>>> I have tried to look an answer for this on the web, but I mainly got "no can do" (timing issue).
>>>
>>> Kernel: 2.6.3x
>>> MCU: atmel at91 (9263)
>>>
>>> I wish to get/write a driver to bitbang a couple of gpios to emulate a uart. the communication is with a remote PIC (PIC12F683) to which I have already wrote the software and checked with linux terminal.
>>> the communication does not have to be fast at all (1200 would be fine). only a few bytes are exchanged.
>>>
>>> can someone point me in the right direction? did someone already develop such a driver? is there an example/guide I can follow to do it?
>>>
>>> Daniel.
>>>
>>
>> Are you already using the 3 on chip USARTs on the 9263? If not how about
>> just using one of them as a serial device from Linux.
>
> yes. using all of them already.

Someone suggested you use a high speed interrupt with a fast 
timer/counter.  I think you can do better using the timer directly in 
interval measurement mode.  I haven't looked at the details, but it 
should be possible for the timer to detect the falling edge of the 
input, measure the time to the rising edge and then repeat for the 
rising edge to the falling edge again.  Each of these intervals will be 
some multiple of the bit period giving you the number of bits of that 
polarity.  I'd bet this is less work than writing a proper UART in 
software using an interrupt on the input pin, and highly accurate.

On the output side you can use the PWM facility to generate the high and 
low pulses of the output bits.  Since both of these approaches do the 
timing for you, the CPU has little to do except handle the logic.

-- 

Rick

On Monday, November 10, 2014 9:41:24 PM UTC+2, Dennis wrote:
> On 11/10/2014 07:44 AM, Daniel Doron wrote:
> > Hi all,
> >
> > I have tried to look an answer for this on the web, but I mainly got "no can do" (timing issue).
> >
> > Kernel: 2.6.3x
> > MCU: atmel at91 (9263)
> >
> > I wish to get/write a driver to bitbang a couple of gpios to emulate a uart. the communication is with a remote PIC (PIC12F683) to which I have already wrote the software and checked with linux terminal.
> > the communication does not have to be fast at all (1200 would be fine). only a few bytes are exchanged.
> >
> > can someone point me in the right direction? did someone already develop such a driver? is there an example/guide I can follow to do it?
> >
> > Daniel.
> >
> 
> Are you already using the 3 on chip USARTs on the 9263? If not how about 
> just using one of them as a serial device from Linux.

yes. using all of them already.

On 10/11/14 19:17, John Devereux wrote:
> John Speth <johnspeth@yahoo.com> writes:
> 
>> On 11/9/2014 10:00 PM, rbehm wrote:
>>> On 10.11.2014 21:44, Daniel Doron wrote:
>>>> Hi all,
>>>>
>>>> I have tried to look an answer for this on the web, but I mainly got
>>>> "no can do" (timing issue).
>>>>
>>>> Kernel: 2.6.3x
>>>> MCU: atmel at91 (9263)
>>>>
>>>> I wish to get/write a driver to bitbang a couple of gpios to emulate a
>>>> uart. the communication is with a remote PIC (PIC12F683) to which I
>>>> have already wrote the software and checked with linux terminal.
>>>> the communication does not have to be fast at all (1200 would be
>>>> fine). only a few bytes are exchanged.
>>>>
>>>> can someone point me in the right direction? did someone already
>>>> develop such a driver? is there an example/guide I can follow to do it?
>>>>
>>>> Daniel.
>>>>
>>> You will probably fail with this, because you need hard real time
>>> operation.
>>> Even if it is not really fast, you need to sample at least 4 times/bit
>>> time to find the start bit and its center and from there on sample the
>>> bits at each center point. Anything else will be to sensitive on minor
>>> variations from the sender. This timing must be met with at least half a
>>> bit time. The sender is a bit easier bit you also have to meet the timing.
>>> At 1200 bit/sec this means about 200&micro;sec. Sounds long, but a lot of
>>> things can come in the way even if running inside the kernel. It might
>>> work if your kernel is doing not much more.
>>
>> I disagree with the failure prediction.  I did a bit banged MIDI
>> interface with a PIC16F84 at more than a decade ago with great
>> success. The real predictor of success or failure will be your
>> requirements. It's true that hard real time response is needed however
>> there are many ways to skin this cat.  If there's no RTOS, your odds
>> of success improve.  If there are no other interrupts active, you will
>> likely succeed.  How many times you need to sample a bit cell will be
>> determined by your operating environment, baud rate, reliability
>> requirements, etc.
> 
> But did you do it *from linux* (that is what the OP seems to want to do
> AIUI).
> 

Trying to do it from Linux (and with a very old kernel on a slow
processor) is going to be difficult unless he can dedicate a high
priority timer interrupt to the job.  With a timer interrupt with fairly
low jitter, it should be fine, even with Linux running.  If possible,
the interrupt code and the relevant data should be put in internal ram
so that cache misses do not slow it down.

My record for bit-banged uarts is 38.4 kBaud on a 9.8 MHz processor.

On Mon, 10 Nov 2014 05:44:38 -0800 (PST), Daniel Doron
<danielmeirdoron@gmail.com> wrote:

>Hi all,
>
>I have tried to look an answer for this on the web, but I mainly got "no can do" (timing issue).
>
>Kernel: 2.6.3x
>MCU: atmel at91 (9263)
>
>I wish to get/write a driver to bitbang a couple of gpios to emulate a uart. the communication is with a remote PIC (PIC12F683) to which I have already wrote the software and checked with linux terminal. 
>the communication does not have to be fast at all (1200 would be fine). only a few bytes are exchanged. 

Can you get an interrupt on that GPIO pin for both rising and falling
edge ? 

If that is the case, read a free running high frequency counter (at
least a few kHz) and save the transition time in ISR and later on, use
user mode processing of pulse edges to determine how many 1s or 0s
there are between transitions. As long as the _variation_ of the
interrupt latency is shorter than a serial bit time, you should be
able to extract the data.

John Speth wrote:

> On 11/9/2014 10:00 PM, rbehm wrote:
>> On 10.11.2014 21:44, Daniel Doron wrote:
>>> Hi all,
>>>
>>> I have tried to look an answer for this on the web, but I mainly got
>>> "no can do" (timing issue).
>>>
>>> Kernel: 2.6.3x
>>> MCU: atmel at91 (9263)
>>>
>>> I wish to get/write a driver to bitbang a couple of gpios to emulate a
>>> uart. the communication is with a remote PIC (PIC12F683) to which I
>>> have already wrote the software and checked with linux terminal.
>>> the communication does not have to be fast at all (1200 would be
>>> fine). only a few bytes are exchanged.
>>>
>>> can someone point me in the right direction? did someone already
>>> develop such a driver? is there an example/guide I can follow to do it?
>>>
>>> Daniel.
>>>
>> You will probably fail with this, because you need hard real time
>> operation.
>> Even if it is not really fast, you need to sample at least 4 times/bit
>> time to find the start bit and its center and from there on sample the
>> bits at each center point. Anything else will be to sensitive on minor
>> variations from the sender. This timing must be met with at least half a
>> bit time. The sender is a bit easier bit you also have to meet the
>> timing. At 1200 bit/sec this means about 200&micro;sec. Sounds long, but a lot
>> of things can come in the way even if running inside the kernel. It might
>> work if your kernel is doing not much more.
> 
> I disagree with the failure prediction.  I did a bit banged MIDI
> interface with a PIC16F84 at more than a decade ago with great success.
>   The real predictor of success or failure will be your requirements.
> It's true that hard real time response is needed however there are many
> ways to skin this cat.  If there's no RTOS, your odds of success
> improve.  If there are no other interrupts active, you will likely
> succeed.  How many times you need to sample a bit cell will be
> determined by your operating environment, baud rate, reliability
> requirements, etc.
> 
> JJS
I see not real problem of to do that, if no OS comes in the way. I have done 
such things many times on even smaller CPUs, e.g. a Z8 running at 6MHz 
internally full duplex 9600Baud. The suggested sampling rate comes from the 
experience doing it for an industrial environment. 

But the OP mentioned Kernel: 2.6.3x which tells me there is a Linux "in the 
way" and it will very probably not have real time extensions by default.

-- 
Reinhardt