block of bytes transmission, array is the only way?

Amin · Joined: 19 Feb 2004 Posts: 15

Hi

I trying to send 16 bytes over the serial port. I have an array of 16 cells and the ISR increment the index and grabs the byte and sends it for transmission until it reaches the end when it stops the cycle.

I am wondering if there is any faster way? Array handling seems like a slow way of doing it.

THANKS
_________________
McMaster Solar Car Project
http://www.solarcar.mcmaster.ca

ckielstra · Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands

The slowest thing in transmitting anything over a serial line is the actual transmission of the data itself. If you don't want to wait for the transmission to finish the most common solution is to move the transmission away from your main process. Write the data to a large enough buffer and than have an interrupt driven routine transmit the data in the background.
An implementation example of this approach is EX_STISR.C in the examples directory, or search this forum for the keywords 'circular buffer'.

Ttelmah · Guest

Array handling is 'slow', but we are talking 'slow' in computer terms here. Typically perhaps 30 machine cycles to access a byte (will depend on the size of the element, and the processsor involved). A circular buffer will impose the same 'sloth'. Any other process will involve this same overhead.
I have posted warnings about the 'sloth' of array accesses in the past, but here dealing with operations, where people have multiple array accesses in one ISR, perhaps unneccessarily. You can reduce the 'work' slightly, by declaring the access variable as a int pointer, and just incrementing this for each access, up to the size of the array. Advantage here is that the address does not need to be recalculated on each interrupt.
Nothing else is going to be 'faster', for accessing a block of data. It is the internal overhead involved in using indirect addressing of the RAM, which causes the rest of the sloth, and this is inherent in the processor architecture.

Best Wishes

Amin · Joined: 19 Feb 2004 Posts: 15

thanks guys,

Ttelmah,

That really sounds like a better solution because of that lack of address calculation each time.
You think you could give me some lead there, how to use an INT or char as pointer?

When I say slow, it is not in comparison with my 2400bps serial communication. But the I mean in term of processor time.

ckielstra,
When you say let the ISR handle it in the background, the problem is this background processing is time from the mainloop, there is a single cpu anyways.
_________________
McMaster Solar Car Project
http://www.solarcar.mcmaster.ca

Ttelmah · Guest

You don't 'use an int or char as a pointer'. You just use a pointer to an int.
If (for instance), your data is sitting in memory declared as a structure, or an array of int 16's, then declare a pointer, and a size.
So if the structure is called 'fred', then just declare:

Ttelmah · Guest

Make the last line 'val-=size', not fred....

Best Wishes

Ttelmah · Guest

Aaargh. My typing is going to pot.
ptr-=size;
God, I am gladI don't type that wrongly too often!...

Best Wishes

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

Amin · Joined: 19 Feb 2004 Posts: 15

PCM Programmer,

thanks for the try. I never really looked at the dispatcher's default code. Mostly because I thought it would just right from the vector to the start my code.
I might have to just do something other than using CCS IRQ handlers.

Ttelman,

I haven't got a chance to try the pointer way, and I made a simple change (taken from your post) and that was to make my index to decrement from SIZE to zero as opposed to zero to size and that reduced the code size by 19 INSTR!!!! thanks

EDIT:
I goofed up, the 19 count decrease happened because I had index=0 as opposed to index==0!
and I will try the pointer business soon.
_________________
McMaster Solar Car Project
http://www.solarcar.mcmaster.ca

Amin · Joined: 19 Feb 2004 Posts: 15

ckielstra · Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands

I compared both implementations for a PIC18F458, PCWH v3.245.

1) Using index:

Ttelmah · Guest

It is important here to distinguish between simple arrays, and larger forms. A integer array, with a one byte index, is pretty good. The problems appear with larger arrays, involving me complex data sizes, where the array fetch, has to involve multiplying the index, by the element size, and for multi-dimensional arrays, by the row size as well. This is why I am quite 'happy' about the array fetch for normal buffer handling. As I said, my 'worry' about arrays, comes in places, where people are using multiple arrays inside an ISR, where I have seen twenty or thirty extra instruction times being involved, for this type of work..

My suggestion, was not to use the ptr form, as a replacement for normal buffer handling (the savings are gnerally too small to be worthwhile), but as a method of transmitting data, sitting in something like a complex structure, where the pointer form, allows this to be handled as if it was in a simple array (an alternative is a union to an integer array, but this then involves redeclaring the variables, if they are used elsewhere).

The times given by Ckielstra are 'interesting', since I looked at these times some while ago, and the differences where then rather more marked. Improvements have obviously happened to the optimiser.

Best Wishes

ckielstra · Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands

I guess it would be better when Amin explains a bit more of the troubles he is experiencing. We are now trying to optimize array access while we have very little info; What does the array look like? Why is timing so critical? How is it possible that reversing the loop from counting up to down counting gives a 19 byte reduction? I never get more than about 4 instructions reduction. etc.

Transmitting at 2400bps means the interrupt routine will only be entered 300 times per second. Assume the processor is running at 4MHz, 1 million instructions/second, and that we can save 100 instructions (which is a lot). Than this will give a performance increase of 3%. Nice, but not huge. Very likely there are other more effective targets for increasing performance.