U-A-U! code size

[milan]

Hi,

I must say that some libraries take a lot more code than before . This is the case for e.g. the "Soft Uart" library (the first one I used ).

I do not know it the same is the case for other libraries...

Soft UART library is the special case.

Old library was made to produce the smallest possible code.
You could have only one Soft UART module in your code.
Knowing that, compiler avoided to pass port/pin parameters as usual, he did some "smart" find-and-replace and produced the smaller code.

Now, many of our users wanted to use more than one Soft UART module in their project and to fulfill that wish we redesigned the library.
Library now passes port/pin parameters as usual.

So now, you can write

Code: Select all

  Soft_Uart_Init(&PORTB, 1, 2, 9600, 0);
  Soft_Uart_Write(65);
  Soft_Uart_Init(&PORTB, 4, 3, 9600, 0);
  Soft_Uart_Write(66); 
  Soft_Uart_Init(&PORTC, 4, 3, 9600, 0);
  Soft_Uart_Write(67); 

and you will have more than one soft module working !!!

Code size increased, but the library is more flexible, it is a trade off.
Now when PRO compiler reduced size of other libraries and user's code - we realized that it is time to release a more flexible library.
Code size may increase, but other code will be smaller - so it shouldn't be critical (in a means that old project can't fit in the Flash now)

This solution is applied to Button, OneWire, Sound and Soft UART library - we supposed that user's projects may request more than one module there.
We didn't do that with Soft I2C and Soft SPI, they are buses, so we supposed there is no need for more than one bus. (devices are selected using address or CS line)

Another thing: All Software communication libraries + Manchester library
now have anti-blocking mechanism (this was another wish from our users).

[Dany]

Milan, thanks for the very elaborate explanation!

[HansDieter]

Soft UART library is the special case.

Old library was made to produce the smallest possible code.
You could have only one Soft UART module in your code.
Knowing that, compiler avoided to pass port/pin parameters as usual, he did some "smart" find-and-replace and produced the smaller code.

Now, many of our users wanted to use more than one Soft UART module in their project and to fulfill that wish we redesigned the library.
Library now passes port/pin parameters as usual.

Hello Milan,

that's fine for many users, but there are still lots off situations where one soft UART is enough but size of code is a real issue. So why not keep the old version of the library, beside the new one, as an option for those who need smaller code size before multiple UARTS?

Hans
München

[milan]

Hi,

can you explain what do you need:
1) how you use soft uart
2) what is time-critical in your project, how code size effects your project

[faramir]

that's fine for many users, but there are still lots off situations where one soft UART is enough but size of code is a real issue. So why not keep the old version of the library, beside the new one, as an option for those who need smaller code size before multiple UARTS?

Yeah, why not take the old code and slap it into single_soft_uart library or something along these lines ? This would allow users to either pick the new (more flexible) library or the old (smaller) one, depending on their needs for each particular project.

[milan]

Hi,

Yeah, why not take the old code and slap it into single_soft_uart library or something along these lines ?

The old mechanism it is not that simple, beside the library function code
compiler did some "smart" find-and-replace in the compile time.

This would allow users to either pick the new (more flexible) library or the old (smaller) one, depending on their needs for each particular project.

Old library is smaller, but as I said before,
"PRO compiler reduced size of other libraries and user's code - we realized that it is time to release a more flexible library".

I understand that you want "less flexible/smaller" library beside new library.
(Is that a wish, or you have the problem in your project because of new library)
That will produce:
- returning of the old compiler mechanism
- more tests
- more examples
- more documentation
- more maintenance

I personally think that new library is much better and I would like to avoid including the old library back.
Smaller code is not that smaller, it is not critical.

If we get reports from users projects that this code size is critical then we will reconsider to get the old library back.

[Tuxmezoo]

I agree with the users. Im now battling for 3 weeks to get some form of uart comms going in a small version. I'm using a Pic12f675 and tried the new lib on it. At compile time it reported that out of memmory. Then i just added a a to d to read a pin. When i removed the library to just read a to d the code was about 3%. Now im battling to get something going in a small form just to send a command to the pic and get values back.

[octal]

I agree with the users. Im now battling for 3 weeks to get some form of uart comms going in a small version. I'm using a Pic12f675 and tried the new lib on it.

I really think that for 12Fxx series if you insist on using a high level language, you better use interrupts and/or implement your own specific soft UART. This is really better as you can fit it to your real needs and make it as small as possible.
This is always the case in embedded world, there is no way to have a generalized and flexible library without compromize, and users working on any chip will need someday to make some coding to answer their need without relaying on the "general case" librarie.