UART/CODE problem Oshonsoft

Using the assembler editor you can make the task easier, because it tells you the records and the error percentage. If memory serves, I think that up to a 2% error rate is acceptable but it is recommended that it be <=1%.

; Compiled with: OshonSoft PIC18 Basic Compiler v4.61
; Microcontroller model: PIC18F46K22
; Clock frequency: 64.0MHz
;
ORG 0x000000
BSF RCON,IPEN
GOTO L0002
ORG 0x000008
RETFIE
ORG 0x000018
RETFIE
; User code start
L0002:
; 1: Define CLOCK_FREQUENCY = 64
; The value of 'CLOCK_FREQUENCY' is 64
; 2: Hseropen 9600
; exact baud rate achieved = 9598.08038; bit period = 104.1875µs; baud rate error = 0.01%
BSF TRISC,6
BSF TRISC,7
MOVLW 0x82
MOVWF SPBRG1
MOVLW 0x06
MOVWF SPBRGH1
CLRF BAUDCON1
BSF BAUDCON1,BRG16
MOVLW 0x24
MOVWF TXSTA1
MOVLW 0x90
MOVWF RCSTA1
; 3: End
L0003 BRA L0003
; Library code
L0001:
RETURN
; End of user code
L0004 BRA L0004
;
;
;
;
;
;
; End of listing
END

DogFlu66 said:

Using the assembler editor you can make the task easier, because it tells you the records and the error percentage. If memory serves, I think that up to a 2% error rate is acceptable but it is recommended that it be <=1%.

; Compiled with: OshonSoft PIC18 Basic Compiler v4.61
; Microcontroller model: PIC18F46K22
; Clock frequency: 64.0MHz
;
ORG 0x000000
BSF RCON,IPEN
GOTO L0002
ORG 0x000008
RETFIE
ORG 0x000018
RETFIE
; User code start
L0002:
; 1: Define CLOCK_FREQUENCY = 64
; The value of 'CLOCK_FREQUENCY' is 64
; 2: Hseropen 9600
; exact baud rate achieved = 9598.08038; bit period = 104.1875µs; baud rate error = 0.01%
BSF TRISC,6
BSF TRISC,7
MOVLW 0x82
MOVWF SPBRG1
MOVLW 0x06
MOVWF SPBRGH1
CLRF BAUDCON1
BSF BAUDCON1,BRG16
MOVLW 0x24
MOVWF TXSTA1
MOVLW 0x90
MOVWF RCSTA1
; 3: End
L0003 BRA L0003
; Library code
L0001:
RETURN
; End of user code
L0004 BRA L0004
;
;
;
;
;
;
; End of listing
END

Click to expand...

Hi D,
I wish I understood ASM, but I don't. My friend who helps me however does, and I'll send this to him, thanks.

I also have Crystals, that make the accuracy almost 0%.

Comments on this and other forums, suggest, that it isn't the timing that's the problem, which makes it a bit difficult.

At the moment we are shortening and re-checking the INTERRUPTS to make them as short as poss, while also getting the the bottom of this problem.

Thanks, and hope for the solution soon.
C

I use a ringbuffer that works super well. I have been using the same version but in C for years in my projects and it does not fail.

In all programs I use interruptions every 1mSec. to distribute the time of the functions, along with the serial ringbuffer and to date it works perfectly in both oshonsoft and C.

Hi C.. Remember waaayy back. I wrote a circular buffer for Oshonsoft. I think I gave you a copy.

Now I don't remember, I'll look it up and check to see if it's simpler than the one I use.

I also have Crystals, that make the accuracy almost 0%.

Click to expand...

... and you still have problems so we can FINALLY put this nonsense to bed about baud rate accuracy that has totally side-tracked you from looking for the real isssue.

At the moment we are shortening and re-checking the INTERRUPTS to make them as short as poss

Click to expand...

If you have a lot of code in your ISR that could be an issue. Many people make the mistake of trying to process the uart data inside the ISR instead of using the interrupt for what it should be, which is to gather up the incoming bytes into a buffer.

At 38400 baud you have roughly 250us between bytes. An easy way to check this is to set a pin high on entry to the ISR and set it low right before returning. Watch the pin with a scope/logic analyser to see how long your ISR is taking.

Ian Rogers said:

Hi C.. Remember waaayy back. I wrote a circular buffer for Oshonsoft. I think I gave you a copy.

Click to expand...

tumbleweed said:

... and you still have problems so we can FINALLY put this nonsense to bed about baud rate accuracy that has totally side-tracked you from looking for the real isssue.


If you have a lot of code in your ISR that could be an issue. Many people make the mistake of trying to process the uart data inside the ISR instead of using the interrupt for what it should be, which is to gather up the incoming bytes into a buffer.

At 38400 baud you have roughly 250us between bytes. An easy way to check this is to set a pin high on entry to the ISR and set it low right before returning. Watch the pin with a scope/logic analyser to see how long your ISR is taking.

Click to expand...

Hi T,
Thanks, I think you have explained this recently, I haven't forgotten.
C

Ian Rogers said:

Hi C.. Remember waaayy back. I wrote a circular buffer for Oshonsoft. I think I gave you a copy.

Click to expand...

Hi R and D,
I remember the ring buffer, and as mentioned. My mate is the skilled one, and I think he has the CODE set up to read each CHAR and put them individually into register memories, but I'll mention ring buffers to him, and see what he thinks.
Cheers, C

You don't have to use ring buffers, it just usually makes the code easier.
As long as your mate is processing the chars in < 250us you shouldn't have much of a problem from that side of things.

tumbleweed said:

You don't have to use ring buffers, it just usually makes the code easier.
As long as your mate is processing the chars in < 250us you shouldn't have much of a problem from that side of things.

Click to expand...

Hi T,
I sent the link to #41, and the folowing posts, which he's read.

We'll meet on Saturday, and go over 'ring buffers', shortening the INTERRUPTS, pointers etc.

I'll ask about the timing/speed.
Thanks, c.

You don't have to use ring buffers, it just usually makes the code easier.

Click to expand...

I should probably clarify this...

You don't have to use ring buffers, it just usually makes the code timing easier.

Click to expand...

Adding circular buffers won't usually make the coding itself easier, it's just that if all the ISR has to do is add chars to the buffer with no/little processing then the ISR is simpler and faster. You still have to deal with processing things outside the ISR in your main program, which can actually make it a bit more complicated.

tumbleweed said:

I should probably clarify this...


Adding circular buffers won't usually make the coding itself easier, it's just that if all the ISR has to do is add chars to the buffer with no/little processing then the ISR is simpler and faster. You still have to deal with processing things outside the ISR in your main program, which can actually make it a bit more complicated.

Click to expand...

Hi T,
I spoke to my mate this morning, and he understands, what you say. There is another thing to watch, that is loss of GPS signal, which will need extra CODE, but it's all in hand. Previously, there were 'guards' for loss of signal, but he says these add extra time.
C.

Question:
If you are relying on someone else to do much of the programming anyway - why does the language matter???

If you had used C, far more people could help, using fully proven code, and the project could have been working long ago?

rjenkinsgb said:

Question:
If you are relying on someone else to do much of the programming anyway - why does the language matter???

If you had used C, far more people could help, using fully proven code, and the project could have been working long ago?

Click to expand...

Hi R,
This project is eons long, and I didn't ever think it would be so long, complicated, and includes 4x different programs, and a set of peripherals, that have to be coordinated and all working. Each of the peripherals has been an adventure in themselves, and again very challenging.

You will have to accept that I am incapable of learning another language, and am still limited with BASIC, after 40years, it's either BASIC, or I stop. I would really like to use C++, no chance! Be happy you can. I have been lucky enough to be able to carry on in my own terms, and over the years this question has popped up occassionally.

Again, thanks to all that have helped me.
C.

camerart said:

I would really like to use C++, no chance!

Click to expand...

Not a chance on an 18F PIC - C only.

Does not IAR offer C++ on 18F PIC ?


And these folks - http://www.sourceboost.com/Products/BoostCpp/SupportedDevices.html


Regards, Dana.

Nigel Goodwin said:

Not a chance on an 18F PIC - C only.

Click to expand...

Hi N and D,
When I said "not a chance" I meant that there is no chance that I could learn C.
C.

camerart said:

Hi N and D,
When I said "not a chance" I meant that there is no chance that I could learn C.
C.

Click to expand...

Never say never, I did after MANY years, and numerous failed attempts.

@camerart

This is an aside on block based / visual programming.

There are a number of block programmers developed for folks that learn in visual fashion.
MIT with its Scratch, mBlock, Snap4arduino, Flowcode, Nodered, Visuino, Tuniot.....

Here is an example of what a simple voltage to pulse width converter looks like (just 5 blocks) :


You take blocks out of second window, place them in design area (3'rd window),
configure them, and then hit the connect button and mBlock generates C/C++
code and then uses the Arduino IDE programmer to program the target board/part.
The rightmost window is Arduino C/C++ code that mBlock generates from your block
configuration.

I am not advocating this as a way to learn C, rather an adjunct to easily program
simple designs and be able to look at what C/C++ code looks like. Its not optimal
code by any stretch but for simple one off projects fast to get something going.
Some examples :




Flow code is done with a flowchart like interface (multiple ways, mix and match) :



A number of folks experimenting with ChatGPT and other AI programs to generate code. Its a
new world in which complex ideas are getting whittled down into simple code methods. C/C++
was/is a strongly typed language, meaning its exact at how you enter and code with it, not forgiving,
"do it my way or die" type language. These new languages are born out of that and making simple
designs a lot easier. Talking voltmeter above link great example of a complex design reduced to
simple block approach.

C/C++, Python, still the "professional" methods, but block and AI catching up rapidly.

Have some fun, try it out on the simple stuff.


Regards, Dana.