Completion of serial transmission - strange behaviour

From a quick look at that PDF it seems to use a system that is essentially identical to regular serial transmission with a bit interval of 417µsec which is probably 2400 baud.

Have you tried treating the data as a 2400baud serial stream?

If I was trying to detect that data I would use an interrupt to detect the start bit and then sample the following bits at 417µs intervals. I posted code that works like that in Yet Another Software Serial

It should be straightforward to check if a byte is not received within some time limit.

...R

There are two parts to the data stream

The host computer transmits a standard 2400 8N2 serial byte, then looks for a reply from the slave. The slave response is in the form of a pwm signal, with start bit of about 2 ms and bit time of 1.1 ms. A "0" is indicated by a pulse width of < 400 us, and a "1" of > 400 (in practice, times are about 300 and 800 us).

A host computer port can be connected to up to 4 slaves. These are effectively polled in turn using the last nibble of the 6-byte command stream as an address. Polling will rotate through all 4 possible slave addresses. If a slave is not present, this is detected because the signal line remains high rather than being pulled low. To cover this case, I am using a timer to indicate that the expected period has expired and the response is effectively "null".

I need to send a serial stream of 6 bytes, then disable the serial transmitter and turn the pin around to receive the slave response. I am using pin 18 on the Mega for communication, acting as TXD1 on transmit and INT3 on receive. The TXC1 flag in transmit mode indicates that the command stream has been transmitted completely, disables the transmitter, starts Timer3, and enables INT3. If there is no activity on INT3 before Timer3 times out, a "null" response is recorded.

Generating a command and interpreting the response is not the issue I intended to raise in my original post. As I said there, if I set my timer to 15 ms, the timeout starts in the middle of the process of transmitting the command stream - if it is reduced to 12 ms, it works as expected. My question is:

What is the mechanism that apparently allows the timer setting to affect the operation of the USART?

bmd1103:
There are two parts to the data stream

I was reading the section of the PDF headed "VI. The Data Stream from the MeccaBrain". If that is not the correct part, then which part is?

Life would have been a lot simpler if you posted that PDF in your Original Post.

...R

My project involves both types of communication. I am using pin 18 on an Arduino Mega in its TXD1 configuration to send a serial string as per section VI. When a transmission is completed, I am then receiving data sent from a slave device to the "Brain" as detailed in "Section VII. The Data Stream to the MeccaBrain", as detailed on page 10, using pin 18 in its INT3 configuration. As I have said, I am successfully doing this, and can send a command string from an Arduino and receive the appropriate response from slave devices.

I'm triggering the changeover process from send to receive using TXC1 to indicate that the transmitted stream has been completely sent. This simultaneously starts a timeout using Timer3 to check that a response is received within a suitable time, and sets up INT3 to handle the received stream. The process works as required except for a limited range of values in the preset I'm using for Timer3, when TXC1 is apparently triggered in the middle of transmitting the command stream. The only way I can actually detect this is through observing that the timer starts mid-command instead of at the end.

I do not need any assistance with either communication format. I am sure I am not the only one who has wanted to do something similar with an Arduino, but can't find any references to this situation. There is quite possibly a very simple explanation and I am simply trying to find out why the timer setting apparently affects the operation of the UART.

bmd1103:
My project involves both types of communication. I am using pin 18 on an Arduino Mega in its TXD1 configuration to send a serial string as per section VI. When a transmission is completed, I am then receiving data sent from a slave device to the "Brain" as detailed in "Section VII. The Data Stream to the MeccaBrain", as detailed on page 10

No wonder I am confused. Do you mean that you are pretending the Mega is the MeccaBrain?

I will try to remember to have another look at the PDF tomorrow.

...R

The Meccabrain is somewhat limited although it can be driven from a tablet via Bluetooth. Some of the peripherals are interesting and I'm looking into how they can be used. The published document mentions servos and "Smart LEDs" but the MAX robot also has "Smart motors" and an ultrasonic sensor using the same protocols.

I'm also working on a signal sniffer that can read the traffic on one of the lines which will hopefully allow me to work out how an Arduino can make use of these devices. Again, I've got the communications sorted apart from a minor timing issue.

bmd1103:
The Meccabrain is somewhat limited although it can be driven from a tablet via Bluetooth. Some of the peripherals are interesting and I'm looking into how they can be used. The published document mentions servos and "Smart LEDs" but the MAX robot also has "Smart motors" and an ultrasonic sensor using the same protocols.

I'm also working on a signal sniffer that can read the traffic on one of the lines which will hopefully allow me to work out how an Arduino can make use of these devices. Again, I've got the communications sorted apart from a minor timing issue.

I have not had time to re-study the PDF yet but I am commenting on this because it does not answer the question in my Reply #13, and a clear answer will make my study of the PDF much more effective.

...R

My objective is to use an Arduino to monitor and control the Meccano peripherals. This will allow them to be used in a much wider range of applications than the very limited ones for the kits they are supplied with.

bmd1103:
My objective is to use an Arduino to monitor and control the Meccano peripherals. This will allow them to be used in a much wider range of applications than the very limited ones for the kits they are supplied with.

I sorta figured that out a while back.

But you have still not answered the question in Reply #13 - perhaps in my confusion I have not asked the right question.

Can you post a diagram that illustrates the relationship between the Mega and the various Meccano items and the data flows between them. It would also help if you indicate which sections of the PDF relate to each of the Meccano items in the diagram.

I am very confused, but I suspect I could help if you can clarify stuff.

...R

I can't definitively produce a diagram showing how the various parts connect as I am trying to find out what potential the Meccano modules have for use with Arduino systems, and that is still a work in progress. The diagram shows the official connections to the MAX system, and what I hope to be able to do with the Arduino. As shown in the protocol document, each channel on the Meccabrain can handle up to 4 modules in positions 1 to 4, daisy-chained so that 1 is the module connected directly to the Meccabrain, 2 is connected to 1, etc. The Meccabrain unit described in the Protocol Description is an older unit with 8 channels whereas the one I am dealing with has only 4, as shown in the diagram.

Each channel uses the signal formats specified in Sections VI and VII as shown in the diagram - commands from the Meccabrain to the modules use the standard serial protocol described in Section VI while the responses from the modules to the Meccabrain use the "PWM" format described in Section VII. The Meccabrain also provides power to the modules and this places a limit on the number of modules that can be connected to each channel. Since the modules reply one at a time in turn, the existing format is very inefficient - commands are issued about every 45 ms, but each module replies once in 180 ms. If no module is connected, the others in that channel still have to wait for the full cycle.

I intend to replicate this structure, but in a more flexible way, so that any unconnected modules can be skipped, and that the full channel capacity can be used if possible.

I honestly don't know what other information I can give you - since this is an exploratory exercise intended to find out the capabilities of the system, I can't say definitely that I want to achieve a specific objective. Thanks for your time and assistance.

Your diagram is a big help - it seems like you do want the Mega to take the place of the Meccabrain - which was my question in Reply #13

However the 2 sides of your drawing are not equivalent. On the Meccabrain side there are familiar things (servo, motor. LED, sensor) all of which are regularly used with Arduinos but on the Arduno side you have Modules. I don't understand why the two sides are different.

If the ultimate purpose of the Meccabrain system is to control servos and motors then why not ditch the whole system and just use the Arduino to control those things directly - cut out the middle-man. My guess is that the Meccabrain was designed for those unfortunate folks who don't have Arduinos :slight_smile:

...R

My "modules" can be any of the items listed in the other diagram, so I should be able to connect up a string with two servos and an ultrasonic sensor into a single channel, for example. The "off-the-shelf" configuration is quite limited but has some promise as the basis of a flexible system that allows the mechanical/structural components of the Meccano world to include some computer control.

So I am trying to cut out the Meccabrain element and allow the various components that are provided with the Meccano "robot"s to be connected into the Arduino world.

OK so it seems like your requirement can be summarised like this ...

You want to program an Arduino Mega to communicate with Meccabrain modules in place of the Meccabrain master unit. The definition of the communication from the master unit to the modules is defined in Section VI of the manual and the communication from the modules to the master is defined in Section VII. You need help with implementing code to deal with the communication from the module to the Mega acting as master.

If that is a fair summary it would have saved a lot of time if you had put it in your Original Post.

My approach to interpreting the data from the modules (as described in Section VII) would use a series of interrupts. First you need to detect the start bit (a LOW to HIGH transition) and save the time (micros() ) then at each subsequent transition also save the time. If it is a HIGH to LOW transition then the interval from the last saved value will be the HIGH pulse width. After 8 bits you will be back to waiting for a start bit.

...R

As I have said in a number of the preceding posts, I have got two-way communication with the various supplied modules from an Arduino. I am also successfully decoding the traffic between the Meccabrain and the various modules.

I am using an interrupt-driven approach exactly as you described. I am connecting the Meccano signal line to pin 18, using it as TXD1 during the transmit part of the operation, then as INT3 for the receive part.

My original question arose because, depending on the value of the timeout I selected to cover the case where there is no connected module, the TXC1 interrupt appeared to be triggered mid-way through transmitting the 6-byte command string instead at the very end of it. I can see no mechanism that would give rise to any interaction between the timer setting and the operation of the UART.

I have never stated that I need help in code to implement the communication, and I have said several times that this was not a problem.

bmd1103:
Further testing ...

I changed the value of the timer preset to see if that had any effect - the program fails for values of the preset between 0x8A6F and 0x8D9F. I have not tested much outside this range. I have also tried changing to Timer 3 with no effect on the problem.

As the program is working with a delay of 12 ms - preset of 0xA23A - I'm moving on with other areas.

bmd1103:
The sequence I am using is based on a state transition approach. The first set of states deal with the command transmission. Once the command has been completely sent (I am using the TXC flag to signal this), the system moves on to the receive function, where it looks for a low-high transition on the pin previously used as TX1. When this is detected, the time is grabbed and the INT function changed to look for the next high-low transition. This then allows the pulse width to be calculated and the response bit set or cleared as appropriate.

I have got working code for this, and with the 12 ms delay I can manage to decipher the response strings. However, I am still baffled as to why the TXC flag is apparently triggered early if the timeout is within a fairly restricted range of values.

bmd1103:
I do not need any assistance with either communication format. I am sure I am not the only one who has wanted to do something similar with an Arduino, but can't find any references to this situation. There is quite possibly a very simple explanation and I am simply trying to find out why the timer setting apparently affects the operation of the UART.

I'm sorry if you feel you have been wasting time on this, but I think I have made it clear in a number of posts that getting the communications going was not the issue.

bmd1103:
I'm sorry if you feel you have been wasting time on this, but I think I have made it clear in a number of posts that getting the communications going was not the issue.

OK. So I got my summary of the problem wrong.

Now can you describe the real problem equally succinctly?

...R

OK- I'll try again.

In the program I have written to transmit commands from the Arduino to a Meccano slave module, I an using Serial1, using the TXD1 function of pin 18. When the 6 bytes of the command have been transmitted, I have to change function of pin 18 so that I can use the INT3 function of pin 18 to detect transitions, using a LO-HIGH interrupt to indicate the start of a pulse and a HIGH-LOW transition to find its end.

Since I cannot stop the serial transmitter and enable INT3 until the serial transmission has been completed, I am using TXC1 which according to my research fires when the last bit of the byte has been sent and the UDR1 transmit buffer is empty. Because it is likely that for at least half the commands there will be no slave module at an address, I have to use a timeout feature so as not to wait forever for the INT3 interrupt. I am using a 16-bit timer in the "normal"mode of operation (WGM33:WGM3:0 =0000) pre-loading a fixed value into the TCNT3 register. Initially I was aiming at a 15-ms timeout, with a counter preset of 0x8ACF or decimal (65535 - 30000) and prescaler of 8:1. However, I found that the timeout was occurring at about the end of the 4th byte of the 6-byte command stream, instead of at the end of the 6th byte as I expected. This effect is shown in the first pair of screen dumps in my initial post. The yellow line shows when the timer is active - the green line is the activity on the signal line.

When trying to see if I could find what was affecting this, I adjusted the timeout delay down to 12 ms using the value of the timer preset set of 0xA23F. With this value, the timeout commenced at the end of the transmission as expected, and as shown in the second pair of screen dumps. I tried a number of different values of the timer preset and found the expected operation for values of preset outside the range of 0x8A6F - 0x8D9E. The issue was present with Timer3 and also with Timer5.

So it appears that there is some mechanism connecting the timers with the Serial1 UART. I can visualise a number of different possibilities but without a detailed knowledge of the processor's internal operation these will be speculative only. As my application operates quite happily with a 12 ms timeout, the problem is not preventing any sort of progress. However, I would like to know if anyone has come across this before, or if there is some totally stupid glitch in my code.

bmd1103:
In the program I have written to transmit commands from the Arduino to a Meccano slave module, I an using Serial1, using the TXD1 function of pin 18. When the 6 bytes of the command have been transmitted, I have to change function of pin 18 so that I can use the INT3 function of pin 18 to detect transitions,

Why are you using pin 18 for both purposes? If the module responds on the Tx line then why not use a jumper to connect it to another convenient I/O pin and use your ISR on that?

You must also allow for the fact that the normal Serial behaviour is to hold the Tx line HIGH when nothing is being sent.

...R

I don't see that my choice of pin changes the issue - I still have to change the function of the Arduino between transmit and receive modes, and would still have the issue of the timer preset apparently interfering withe UART.

How about starting the timeout (by saving the value of micros() ) when you start sending the data. If you know how many bytes you send then the time taken to send them should be easy to calculate. And if you are working to a 12msec interval no great precision seems to be required such that Hardware Timers add any value.

It would also mean that the timeout was entirely separate from the finer detail needed to decode a response if one arrives.

...R