topic Re: Seek help for the SCI module for NE64 in S12 / MagniV Microcontrollers

Seek help for the SCI module for NE64

Jonah — Fri, 22 Feb 2008 00:10:56 GMT

I am making a program that receive bytes from the SCI interface and transmit it by the ehternet
The bytes from the SCI interface is very large so that it is not possible to buffer all of them.

Right now, I am coming to a solution that use a circular buffer of reasomable size and use it to buffer the data. after that, use the OpenTCP module to transmit the byte.

The program work fine when the byte from SCI is transmitted one by one.
However, some byte would miss when I try to send a lot of data through the SCI.

Right now, the receiveing of byte from SCI module is by Receiver Full Interrupt, and the protocol I am using is TCP protocol.

Any one can give me some hints about the problem?
Thank You

Re: Seek help for the SCI module for NE64

JimDon — Fri, 22 Feb 2008 01:02:09 GMT

Here is a hint - what baud rate are you using, and what other devices are also interrupting, perhaps delaying the servicing of the SCI interrupt.

Re: Seek help for the SCI module for NE64

Jonah — Fri, 22 Feb 2008 13:20:06 GMT

The rate of the SCI is 57600
I wounder whether it is too fast for a NE64 using 25M clock

I am woundering whether it is the interrupt used in OpenTCP causing the touble.
Is it possible to change the priority of of SCI interrupt to be higher than the other interrupt?

Re: Seek help for the SCI module for NE64

JimDon — Fri, 22 Feb 2008 13:50:45 GMT

Ya, just as a test cut the baud down and see what happens.

It could probably handle it if nothing else is going on, but with other stuff going on it could be a problem.
A that baud rate, its a character every 175us.
It is possible to change prioritys, and you will have to do a cli in the other handler I belive. Make sure your stack is big enough. You will have to read the manual as I don't recall the priority scheme.

Message Edited by JimDon on 2008-02-22 12:53 AM

Re: Seek help for the SCI module for NE64

colinh — Sun, 24 Feb 2008 18:48:46 GMT

If you need to change your interrupt priorities you can do so via the HPRIO. You can only mod this while the I bit in CCR is set (via sei is one option)

I would recommend not using the option of a cli within your other interrupt routine(s) unless you are very careful - nesting interrupts is one of those things you dont do unless you are really need to. If you're taking more than 175us in an ISR running at 25MHz bus then your approach to embedded programming needs a rethink - or its time for an ARM9

Cheers
Colin

Re: Seek help for the SCI module for NE64

mjbcswitzerland — Mon, 25 Feb 2008 05:45:05 GMT

Hi

We have done voice-over-IP work with the NE64 and measured a bi-directional 64kb/s overhead of around 20% for the serial port interrupt processing (tested with SCI and SPI interfaces). Therefore the speed of the interface (baud) should not be an issue.

You may like to look at the uTasker project since it includes support for much of what you require. It is free for non-commercial work and has a forum for support.

Best regards

Mark

www.uTasker.com

Re: Seek help for the SCI module for NE64

JimDon — Mon, 25 Feb 2008 14:38:19 GMT

While I agree that nested interrupts can be tricky to get right, if you don't cli then changing priorities will only have an effect when the interrupts occur simultaneously, and will do little to solve the lock out of interrupts.

I rarely do this, because as you said proper design or at least improved design is usually the best solution.
Take a long hard look at what you are doing in the other interrupt handlers, and see how much you can move to a foreground task. An RTK will make this much easier, as you can get timely execution off the interrupt thread and pass events using queues.

See what Mark has to offer...

Re: Seek help for the SCI module for NE64

colinh — Tue, 26 Feb 2008 15:06:14 GMT

A different slant on the usefulness of changing interrupt priorities:

The interrupts do not have to be simulataneous for the lowest priority to lose out. All it needs is for there to be 2 or more interrupts pending on exit from an ISR since this is when the priorities are evaluated (ie there isn't a first in first out queue - its a case of the core evaluating the highest priority when the I flag is clear).

Say you have 3 interrupts enabled and call then INT1, INT2, INT3 and lets assume INT1 has the highest and INT3 the lowest priority. Now if INT1 and INT2 keep hogging the processor bandwidth, momentarily chewing up 100% (due to poor design or whatever), then poor old INT3 might have to wait for them to both to be idle. By prioritising INT3 at the highest level it will be the first ISR handled on completion of the current ISR, whichever that is. Obviously the more interrupts in a system the longer it could take to the lowest priority if the higher priorities keep overlapping.

Therefore if you (a) keep your ISRs to a minimal execution time, and (b) set an appropriate highest priority, you can have deterministic max latency to the specific highest priority interrupt.

Re-enabling interrupts in an ISR is not for the feint hearted and I would want to see a very good justification for it if I were doing a design review..

Cheers
Colin