Usart Baud Rate Error

[xor]

Just so you understand totally, you saying SF is not as good as the other compilers you mention is because SF does not tell you something about the PIC you that should find out for yourself ,is complete rubbish, it is because you do not know how to use a PIC correctly and are too lazy to figure it out.

The other opinion is that I am 100% wrong. mmmmm.

I wouldn't be so severe. SF allows more user control over the high/low BRGH, something that hansolo was not aware. I know him as a mikroBasic user and setting up BRGH is not an option with that compiler in their USART library for setting baud speed. It is 100% managed with the preprocessor.

[octal]

the secret is to stick with one and figure out how to use it

I agree.

a good programmer will make a poor compiler work well, a poor programmer will make all compilers work equally poorly.

Not if the compiler is so buggy (which is far from being the case for SF). If you think that spending hours testing and checking ASM code is a solution, I think that it's better to write your own libs and framework in ASM and develop completely in ASM. Basic or any other language compiler is considered to give you support to write programs quickly and easily. It does not replace the good understanding of your chip, I agree, it's not like basic for PC that relays on the OS functions to make a very high level of abstraction of hardware, but it"s supposed to make your life easier. If the compiler if fully buggy (like so many on the market, and like those who led HANSOLO here) it's better to never deal with them. The compiler must offer a minimum of usability and relyability. Hopefully SF is far from to be compared to those ugly and beta version sold on the market. SF is one of (and for me it's) the Best on PIC market.

and I bet you have not paid for one of them, please tell me I am wrong, I will be happy to say well done for supporting all these compilers with your money, but I bet you are a freeloader who steals software or never moves beyond the free trial packages.

Just to be fair with Hansolo (since I know him personnaly) he already paid for other compilers and he paid for SF license.

Doj, your answer concerning reading the datasheet is correct and right, but please keep the debate a bit non personal.
I think that what SF gives great, and what Steven has already mentioned, is that SF gives open source libs written in SF itself. It's a golden mine of information that any user has to dive in.

regards
Octal

[hansolo]

Doj,

Have I step on your toes?

Mind you. every copy of the 4 different compilers I had tested is original copy. I may be from a third world country but I am not a pirate.

As for your wierd behavior, I leave to others to comment.

Hansolo

[Doj]

All good points made, but as I do not know hansolo yet, I can only go on what he has written, and to quote him:-

Hope that David can improve the USART.bas library for the benefit of the beginners like me and others that do not bother to read the PIC datasheet.

This tells me that Hansolo does not read the data sheet and he thinks David should write the code for him!!!, how can anyone expect to write serious code for a PIC(or any micro) if they do not read the data sheets, it is just impossible, and then making a public statement that he thinks David should improve his work is ridiculous in my mind, I do not wish to speak for David personally but if I was the authour of a piece of software that someone was telling other people was poor because the user was not reading the instructions at all then I would be as mad as hell!

xor, you say BRGH is not an option, as it is aregister in the PIC surely you can set this register(and any other) at any time in the code?

octal, my comments are not meant to be entirely personal, they are also related to anyone who expects the code to write itself and then blame the compiler for their poor knowledge.

Finally to quote myself:-

please tell me I am wrong, I will be happy to say well done for supporting all these compilers with your money

I am very happy to with draw this point 100% and appologise for any upset cause to Hansolo, well done for supporting the software with your very hard earned money!, many people choose not to do that.
Now you need to learn to read the documentation and you will not need to spend any more money as this compiler will do everything you wish when understood.

My reason to post in this thread is not to be unkind to Hansolo but to defend the compiler from what I see as very unfair critisim, which to a casual reader would seem to make the compiler at fault when it is not.
Please read my replies with that thought in mind

[xor]

xor, you say BRGH is not an option, as it is aregister in the PIC surely you can set this register(and any other) at any time in the code?

Yes, you can manually set all the registers to get the desired baud and set up the USART hardware module. The mikroBasic USART_Init() library function takes care of all that at compile time. You only declare the desired standard baudrate, like this:

Code: Select all

USART_Init(9600)

[David Barker]

As XOR has pointed out, the MikroE version is configured at compile time. This has the advantage in that you can look at OSC and BAUD and generate code accordingly.

The Swordfish SetBaudrate() call is a runtime routine. This enables you to set different baudrates as the program is running. You could add additional code to SetBaudrate to check OSC and BAUD, but this would really inflate the code footprint of the program, as it would need to be computed at runtime.

The Swordfish pre-processor is quite powerful and you could implement a compile time option to do the same as MikroE (or PROTON). For example,

#option USART_BAUD = 19200

you could then look at OSC and BAUD and compile time and set all register values accordingly.

[David Barker]

I've posted a little module on the wiki, showing how you can set the baudrate at compile time...

http://www.sfcompiler.co.uk/wiki/pmwiki ... er.Options