Multiprocessor Communication by UART

UART use 9th bit to differentiate address frame(1) from data frame(0).

If a slave mcu is not selected by the address frame, it will ignore all data frame. 8051 use register bit "SM2" in SCON to control if data frame should be ignored.

And it seems that mega series mcu (avr) use "MPCM" bit to control it. I searched the simulIDE sourcecode but found no "MPCM" related things. And the current implementation of UartRx will trigger the interrupt for every frame. So if it is not implemented in avr , maybe it could be implemented together?

Multiprocessor Communication basic implementation at Rev 1974 (AVR, PIC and 8051).
Not tested, and no special cases.
For example 8051 UART mode 1 works different.

arcachofo wrote:Multiprocessor Communication basic implementation at Rev 1974 (AVR, PIC and 8051).
Not tested, and no special cases.
For example 8051 UART mode 1  works different.

Great! I'll test it with 8051

I've found some issues in R1976 and made a patch.

Issues fixed:
- Crash when Serial Port receives data.

I restored the interrupt NULL check in UartRx()::byteReceived();

- send/receive bit 8  doesn't work in 8051

I rename I51Usart::getBit9()/setBit9() to the correct override name getBit8Tx()/setBit9Rx();

- Bit 8 received is not correctly set

In UartRx::getData(), value "frame & ( 1 << 8 )" will always be 0 after converted to u_int8.

- 8051: change sm2 but don't change mode(SM0,SM1) doesn't work.

i51usart::configureA() only proceed with mode change.

Issues that not fixed:
- setBit9Rx() is called in receiver's getData(), so the data(SBUF) MUST be read before the bit 8 (RB8) get read, to get that bit right. Since 8051 set the RB8  before TI is set, I think it's bug.


Minor change:
- Serial Port's close button text not translatable.

The test project is compressed with 7z and zip to bypass the 50k attachment limit. So I suggest to add .7z to the supported attachment suffix list.

Thank you.

Issues that not fixed:
- setBit9Rx() is called in receiver's getData(), so the data(SBUF) MUST be read before the bit 8 (RB8) get read, to get that bit right. Since 8051 set the RB8 before TI is set, I think it's bug.

I am fixing this and some other issues related to this:
I realized that all the error flags are not handled correctly, so I'm refactoring all this part.

The test project is compressed with 7z and zip to bypass the 50k attachment limit. So I suggest to add .7z to the supported attachment suffix list.

I can't change these settings, they are hardcoded by the forum.

Seems that there is a problem here:
UART receiver has a double buffer (FIFO), it can hold 2 characters while receiving a third one.
This is how AVR & PIC works, but seems that 8051 has a single buffer (the Rx Register itself), so this must be refactored.

arcachofo wrote:Seems that there is a problem here:
UART receiver has a double buffer (FIFO), it can hold 2 characters while receiving a third one.
This is how AVR & PIC works, but seems that 8051 has a single buffer (the Rx Register itself), so this must be refactored.

Yeah... I thought that's not a big problem because buffer 1 or 2 frames doesn't make much difference for users - data should read out as soon as possible... so I thought that you PURPOSELY let all UART use a 2 frame fifo to make things simple... though change the const size of the fifo to variable would not complicate the code much....

But I think there is a little problem in 8051:
The received data can only be read once from .
If a data X is received. We read from SBUF to get it, then write to SBUF to send another data Y, then read SBUF, we'll get Y instead of X because the second call to UartRX::getData() will fail and SBUF not correctly updated.

If SBUF is watched in the mcu monitor, this may cause error. (Data is read out by the mcu monitor before user code).

arcachofo wrote:Seems that there is a problem here:
UART receiver has a double buffer (FIFO), it can hold 2 characters while receiving a third one.
This is how AVR & PIC works, but seems that 8051 has a single buffer (the Rx Register itself), so this must be refactored.

I had a look at mega328p datasheet ( https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7810-Automotive-Microcontrollers-ATmega328P_Datasheet.pdf ) , and it use the following code to read data:

The received data can only be read once from .
If a data X is received. We read from SBUF to get it, then write to SBUF to send another data Y, then read SBUF, we'll get Y instead of X because the second call to UartRX::getData() will fail and SBUF not correctly updated.

Not sure if I understand what you mean.
But you can't read the data you wrote to SBUF. This data is just pushed into the trasmit shift register and is not readable.
When you read SBUF it will always read from the receive buffer.

If SBUF is watched in the mcu monitor, this may cause error. (Data is read out by the mcu monitor before user code).

Yes, that's true.

I had a look at mega328p datasheet ( https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7810-Automotive-Microcontrollers-ATmega328P_Datasheet.pdf ) , and it use the following code to read data:

unsigned char USART_Receive(void)
{
/* Wait for data to be received */
while (!(UCSRnA & (1<

I don't understand what you mean here.
It just read UCSRnA.RXCn flag that indicates if there is data available.

arcachofo wrote:
But you can't read the data you wrote to SBUF. This data is just pushed into the trasmit shift register and is not readable.
When you read SBUF it will always read from the receive buffer.

That's what happens in a real mcu. In simulide, writing to SBUF would trigger data send AND modify the memory, so the old value in SBUF would be updated.

Maybe we should change the write watcher for SBUF to a write interceptor which don't update the memory?

arcachofo wrote:

If SBUF is watched in the mcu monitor, this may cause error. (Data is read out by the mcu monitor before user code).

Yes, that's true.

If fifo[0] and fifo[1] both have valid data, it could happen that fifo[1] is read by mcu monitor and can't be read by the user's mcu code...

A simple solution is don't use fifo in UartRx at all. I think that cache one extra data frame doesn't make a difference in most cases ... But since read from receiver buffer would clear the data received flag bit ( the mega328 datasheet says so), it doesn't really fix this case.

Another solution is only pop the fifo when the receive flag bit changed from 1 to 0. But the mega328 datasheet clearly states that the receive buffer is read triggered.

The third solution is to change memory monitor to only update when change happened. I think it's the only solution that really works. But that needs a lot of change to codes.

arcachofo wrote:

I had a look at mega328p datasheet ( https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7810-Automotive-Microcontrollers-ATmega328P_Datasheet.pdf ) , and it use the following code to read data:

I don't understand what you mean here.
It just read UCSRnA.RXCn flag that indicates if there is data available.

The forum truncated my post

From atmega328p's example code for reading data, it seems that avr sets the RXCn flag for every data frame received. But in simulide, move data from m_fifo[0] to m_fifo[1] wont raise the interrupt(set the flag), I think this might be a bug.

That's what happens in a real mcu. In simulide, writing to SBUF would trigger data send AND modify the memory, so the old value in SBUF would be updated.

Maybe we should change the write watcher for SBUF to a write interceptor which don't update the memory?

Yes, you are right.
This can be solved using a "mask", for example:

Code:

<register name="SBUF"   addr="25"  mask="00000000"/>

If fifo[0] and fifo[1] both have valid data, it could happen that fifo[1] is read by mcu monitor and can't be read by the user's mcu code...

A simple solution is don't use fifo in UartRx at all. I think that cache one extra data frame doesn't make a difference in most cases ... But since read from receiver buffer would clear the data received flag bit ( the mega328 datasheet says so), it doesn't really fix this case.

Another solution is only pop the fifo when the receive flag bit changed from 1 to 0. But the mega328 datasheet clearly states that the receive buffer is read triggered.

The third solution is to change memory monitor to only update when change happened. I think it's the only solution that really works. But that needs a lot of change to codes.

I think it should be solved at Rev 1980 (read RAM directly).

The forum truncated my post Sad

Yes, the forum was doing weird things for a few days. All text in bold and some other errors.

From atmega328p's example code for reading data, it seems that avr sets the RXCn flag for every data frame received. But in simulide, move data from m_fifo[0] to m_fifo[1] wont raise the interrupt(set the flag), I think this might be a bug.

Yes, I noticed it. It is already solved.

I'm refactoring USART module, to fix some issues and to work well in all modes.
I also removed the "runHardware" feature, this was complicating the code a lot and causing many problems.
This feature disables the bitbanging if the pins are not connected.

Apart of the USART modes for each MCU and different clock sources, it can receive data from the Serial Monitor, so the number of posible combinations are huge, adding the "runHardware" feature on top of that makes it a mess.

I'm thinking to remove the "send data" feature from the Serial Monitor as well and use a "Serial Terminal Component" connected to the pins instead.
There are a lot of problems related to this that are difficult to solve.

arcachofo wrote:
I'm refactoring USART module, to fix some issues and to work well in all modes.
I also removed the "runHardware" feature, this was complicating the code a lot and causing many problems.
This feature disables the bitbanging if the pins are not connected.

Apart of the USART modes for each MCU and different clock sources, it can receive data from the Serial Monitor, so the number of posible combinations are huge, adding the "runHardware" feature on top of that makes it a mess.

Yes，I've found that there's some bugs in it when it's using with a timer triggered UART.

I'm thinking to remove the "send data" feature from the Serial Monitor as well and use a "Serial Terminal Component" connected to the pins instead.

I think that would be nice. Sending data to itself  (not really send data the pins) doesn't make much sense   and  confuses user (at least it did confuse me )
And we do need a dummy component to facilitate testing UART.

One more point: I think he textedits in the serial monitor should be readonly. A non-readonly textedit could lead user to think he can use it to send something out...

I think that would be nice. Sending data to itself  (not really send data the pins) doesn't make much sense   and  confuses user (at least it did confuse me Sad )

It makes sense in it's context:
Before 1.0.0 only 1 MCU could be in the circuit and UART bitbanging was not implemented because there was nothing to connect to it, so this was the only way to send data to the MCU.
Even now it is an easy way to to send data to the MCU in many cases.

And we do need a dummy component to facilitate testing UART.

What I'm doing:
1- Disable (and hide) send text/value from Serial Monitor by default, so it just shows the data comoing in/out.
2- Creating a "Serial Terminal" component. For this component's Serial Monitor send text/value is shown but works the oposite: it sends data out.

I'm not 100% sure about 2, but it is an easy way to implement a Serial Terminal reusing the code we have now.

One more point: I think he textedits in the serial monitor should be readonly. A non-readonly textedit could lead user to think he can use it to send something out...

Not sure about this.
It is very useful to me to be able to add annotations, divissions and so on.

Still raw but I commited my changes to USART at Rev 1981:

- Simplified and fixed some issues.
- Removed "runHardware".
- Serial Monitor can't send data.
- New Serial Terminal Component (Serial Monitor can send data).

arcachofo wrote:Still raw but I commited my changes to USART at Rev 1981:

- Simplified and fixed some issues.
- Removed "runHardware".
- Serial Monitor can't send data.
- New Serial Terminal Component (Serial Monitor can send data).

Great works! I've did some test and it seems all projects are ok.

Just one thing: It seems that mcu config files are not changed( mask for SBUF, etc. )

Just one thing: It seems that mcu config files are not changed( mask for SBUF, etc. )

No... I still have to do it for all MCUs.

arcachofo wrote:Seems that there is a problem here:
UART receiver has a double buffer (FIFO), it can hold 2 characters while receiving a third one.
This is how AVR & PIC works, but seems that 8051 has a single buffer (the Rx Register itself), so this must be refactored.

Solved at Rev 1990.
Also simplified Timer 1 interrupt call.