Download the program for the device via the Internet.

[chipfryer27]

Hi

My screenshots are from a logic analyser connected to hardware.

I'll look at the Rx when I get a chance.

Regards

[gilanetugila]

Good evening! I have now turned on the signal decoding function on the oscilloscope. I sent numbers from 1 to 7, there were errors in numbers 2,4,6. But the oscilloscope confirmed that the numbers are being sent normally, there is an error in reading on the receiving controller. I'll continue the rest tomorrow. I made all the drawings in one file, but when sending the quality is greatly lost and nothing is visible. Therefore, I will only send files of numbers that had errors when receiving them. But this time I made a selection from 7 numbers sent.

[chipfryer27]

Hi

Your send chart increments a counter until it reaches 25 then resets. I had no issue at all in sending these values as proved by both an analyser on the Rx pin and a USB-TTL Serial gadget reading the same values as the analyser.

The / my issue seems related to the Receiver but not sure why yet. Unlikely to be transmission related though.

Regards

[gilanetugila]

Good morning! I just looked at the screenshots I sent you this morning and compared them with other drawings where the reception was normal. For some reason, this time, not even numbers were taken correctly, but even numbers incorrectly. I have in my uart settings that it will send 8 bits. The duration of sending odd numbers is the same as even numbers, only the odd ones have a positive impulse at the end and they are shifted relative to the blue triangle at the top of the picture. And it turns out an error in determining the sent number - the uart module misunderstands this additional pulse with the definition of parity-odd. In theory, if the signal for all numbers is 8 bits, then the duration of sending even and odd signals should be the same and start in one place and end in another place. And mine start and end in different places. I am sending screenshots of odd signals (which were determined correctly by the uart bus receiver) so that you can verify this.

[gilanetugila]

Good morning! I am sending the settings of the uarn module. Maybe there's something wrong with it?

[gilanetugila]

Good afternoon! I wanted to send the number 0x55 according to your request, in the decimal system it is 85. But it is not displayed on the lcd screen. I did not check further what the pulses look like, since it is not visible what you are sending or receiving. Moreover, the numbers that I will send will be byte and floating points.

[chipfryer27]

Hi

Settings are the same for me.

If you look back at my analyser traces you can see a series of "dots" in the trace. A green dot representing "start" bit followed by eight "data" bits then a red "stop" bit for my 8-1-N signal. The dots are added by the analyser to indicate sampling points for the bits and if timings are all OK they should be sampling in the middle of the bits.

RS232 is asynchronous therefore if clocks are "out" and drifting the sample points will over time move from the middle and can lead to transmission errors. However in saying that as each new transmission received in effect "resets" the receiver, i.e. moves the sample point back to where it believes the mid point is, you would need to send a long string of data before drift had any noticeable effect (or severely out clocks).

My connections will most likely be as yours:-

Transmitter ---> Receiver

Tx pin - Rx pin
Gnd - Gnd
(with my analyser connected to Gnd and Tx too)

I'm happy that I'm transmitting the value three times (as per your chart) so will look at the receive when I get a chance. What I intend to do is modify the ISR. At present you have it grabbing the incoming value and then stuffing it into the CB (nothing wrong with that at all) so I will add in an extra step before exiting. After grabbing the value I will also send it back out on the Tx thereby "echoing" the received value. I will have another channel on the analyser monitor the receiver Tx pin so I can see exactly what is going into the CB. This will eliminate the transmission as the source of concern (if all good).

Regards

[chipfryer27]

Hi

I wanted to send the number 0x55 according to your request, in the decimal system it is 85. But it is not displayed on the lcd screen.

Not sure where you are setting the value, but remember that in your chart if "a" > 25 then it resets to 0

Regards

[gilanetugila]

Good afternoon! When transmitting the number "0x55", I redid the program - I removed unnecessary ones and tried to send this number as a byte, as an int and as a Long. But after reading your message, I came up with the idea that you can try to send it as a text message, but I don't know how to convert it from this type into a byte one to read on the lcd screen !?

In previous messages, I first sent drawings of the number signals that were incorrectly received. And then those that are correctly accepted, and if you make an edit of the drawing and insert one under the other, you can clearly see that those files that were incorrectly accepted have an offset along the time axis. Most likely, the uart module is not working properly or something needs to be done in the settings. But to be honest, I tried all this before communicating with you: I sent numbers in different bits - there are 7, 8, and 9 and also accepted them, turned on and off the echo, although I do not know what it is used for.

According to your letter, I understood that you do not use the lcd 1602 indicator in this project, but using only a logic analyzer, you want to send a number to another controller, and then send it back via another line and compare the signals. Thus, you can only exclude the possibility that the controller periodically incorrectly displays information. If all your sent and received pulses match, then the controller receives correctly, but displays incorrectly.

[chipfryer27]

Hi

The development boards have buttons and LCDs so I could copy your setup.

As mentioned I connected an analyser to the Tx pin (which is also Rx pin of other chip) and recorded everything being sent correctly. However I did notice that on ocassion I got an incorrect value displayed on the receiver.

Today I echo'd the incoming value first by enabling "echo" in UART settings and then by simply retransmitting what was received. The results were not good. I traced the issue to a bad ground connection linking the two boards which in effect had the Rx pin floating. Once resolved the receiver accurately reflects what is being sent.

I can now transmit and correctly receive the value.

In this trace you can see the bit width of 104uS for Tx indicating all good there but the "echo" shows a random received value.

Echo.jpg (51.13 KiB) Viewed 603 times

Fixed

Tx-22.jpg (50.79 KiB) Viewed 603 times

So, as mentioned before I don't really see any FC reason your charts are having issues. I read earlier that you will now be transmitting float values so you will need a couple of extra steps to turn your values into Strings prior to sending, then at the receive convert back. When I get time I can give an example.

Regards

[gilanetugila]

Good afternoon! I want to argue with you. The option that you suggested will not work in real devices. You wrote that to fix the problem, you connected the ground("-") of one board to the ground ("-") of another board. This is suitable when everything is nearby and on the same table. And when there are long distances, it will not work.

When I was sending data from the Tx output, I decided at the same time to see what was happening on the Rx output.There were some strong noise signals, I saw them on the oscilloscope. But for some reason it is not possible to save them. Well, unless you can try to take a picture of the oscilloscope screen. Maybe there is some kind of hardware solution to the problem of receiving or decrypting the received data. Tighten the Tx and Rx pins to minus after 4.7K.

I also have some bad news, but maybe this will help solve the problem of receiving data. I have made programs for sending and receiving messages (string). A byte variable is also counted, and then sent as a string. And it turns out to be a string. I hoped that at least it would work that way. But no. Does not work. It's just that the errors look different: either it doesn't show anything at all, or it shows part of the number (you send a string, let's say "15" and only 5 comes, or generally some incomprehensible signs. And there are a lot of mistakes too.

Your graphics are beautiful and the main thing is that it works, though with a common ground (minus). We'll have to try this method. The rs232 information says that the communication range is up to 15 meters, most likely an earthen wire is used for such purposes. I'll write as soon as I try it out. Moreover, we need to transmit data not via rs232, but data from the controller goes to esp8266, and they will be located nearby. And from esp8266 to another esp8266 and there on through rs232 to the controller for use and indication.

[chipfryer27]

Hi

ood afternoon! I want to argue with you. The option that you suggested will not work in real devices. You wrote that to fix the problem, you connected the ground("-") of one board to the ground ("-") of another board. This is suitable when everything is nearby and on the same table. And when there are long distances, it will not work.

I agree that the output of a microcontroller isn't best suited to send over long distances but that is not my intent. It was to see if there was anything wrong with the code. You can connect the UART to suitable transceiver components for transmission over real-world (e.g. a RS232 converter or such like) however if your circuit doesn't work with the chips directly connected with some wire, it is unlikely to work over your converter. Personally I would get things running chip-to-chip before introducing a further transmission medium.

Inherently there was nothing in your code to prevent transmission and reception, the errors I had were down to a dodgy ground between boards.

Maybe there is some kind of hardware solution to the problem of receiving or decrypting the received data. Tighten the Tx and Rx pins to minus after 4.7K.

Holding the pins either high or low will prevent transmission as they can never change. I would first check that the noise you are seeing isn't generated elsewhere and appearing on your scope. The UART holds the Tx pin high until told to transmit.

I'm guessing you are seeing single digits fine but not double digits (when sending ascii). This isn't a fault just that your code needs modified to allow such. You grab a value from CB and display it at cursor 0,8 and repeat, meaning the next value from the buffer will overwrite the previous.

When I get a chance I'll give you an example of sending floats etc. Also, I think you should consider a faster clock as anything to do with floats is heavy going so faster is better. You previously ran at 8MHz on another project so perhaps run at that again? The potential for errors at 9600 Baud with a 8MHz clock is negligible (https://mspgcc.sourceforge.net/baudrate.html at 0.0x%

I'll download your charts later.

Regards

[gilanetugila]

Good evening! You are a great technical wizard! Thanks a lot for the tip with the common land-everything worked almost as it should. Well, the most important thing is that all the numbers came correctly! Well, the effect appeared-it consists in the fact that after connecting the power supply cons of the boards, I have not yet connected the power to the data reception board, but the indicator display is already glowing on it. And if you connect power to the receiving board, then the indicator screen will not light up on the sending board.
It is already possible to walk around villages and towns and show technical tricks...Thanks for the link with the error probability calculator. I didn't even know that there was one, but I thought everything was limited to information from the description. Tomorrow I'll try to start without quartz, suddenly it will work just as well.

[AbhijitR]

Hello!

A small input from me seeing your hardware, try to fabricate a PCB if possible as general purpose PCB need inspection many times, most of the time problems are solved if the PCB is done well.

For coding/programming you will always get help on the forum, Chipfryer is one of them, he is very keen to help.

Regards

[chipfryer27]

Hi Abhi

Totally agree with you regarding a proper PCB vs the "rat's nest" once we know the circuit works. Not everyone has access to such though but free software such as KiCad really helps with layout etc. ProtoBoard / VeroBoard is OK if not too complicated but of course the initial development can be really messy (we have ALL been there and got the t-shirt )

Your boards always look very professional though.

Following on from above posts, it was mentioned that the intent would be to send floating point values. The easiest way is to first convert into a string and send that.

In the attached as examples I created Byte, Signed Integer and Floating Point variables and assigned values (17 / -27000 / 123.456789). I then used a calculation to convert the Byte / Integer values to Floating Point and then to a String limited to two decimal places. The original FP value is just converted into a String to two decimal places.

These three strings could be sent individually, prefixed by an identifier or combined into one comma separated value string. Whatever works best for individual needs.

I then include a calculation to convert the strings back to respective numbers (note in FC v8 when converting back to FP the decimal place limiter value seems to be ignored, but in v10 it's fine).

Stepping through the chart you will see in the component debugger the values change as you progress.

To_Strings.fcfx

(10.09 KiB) Downloaded 7 times

Regards

[gilanetugila]

Good evening! Thanks for the examples! I will try to send and receive similar variables in the near future. Today I managed to check the sending and receiving of data via uart without using quartz. I sent everything at a frequency of 1 MHz and received everything, but for some reason it did not work at all at a frequency of 8 MHz.Then I'll try again on 4 and 8 MHz without quartz.

[chipfryer27]

Hi

When you say "without quartz" do you mean the chip is configured to run on it's internal oscillator? If so it's quite easy to overlook a setting so running a one-second flash test is really helpful to ensure it's running as it should.

Regards

[gilanetugila]

Good afternoon! Thanks for the hint, but I do not know what a one-second flash test is?! Now I'm trying to figure out the program that you gave me. I was surprised that you had a kind of double text conversion there, I did it wrong all the time - there was no need to see. According to the old constructions in my brain, it was just receiving a text message, yes, I could see what number I passed (except for the byte one-it was still possible to work with it), but I couldn't do anything with other variables. I even thought from the beginning that you made a mistake in writing the "Float2String$" function...

[chipfryer27]

Hi

A one-second-flash test is a really useful test especially if using a new chip or messing with clocks. It's also known as a "sanity check" as an incorrect clock can drive you crazy.

Basically it is one of the simplest tests to perform. Connect an LED or a Scope to a pin on your chip then create the following in an endless loop:-

Enable Pin / LED On
Delay 1 second
Disable Pin / LED Off
Delay 1 second
(Repeat)

If your clock is correct you will see your LED flash on/off every second or your scope will show a perfect square wave with a period of 1second. If not then you need to check your settings.

Regards

[gilanetugila]

Good morning! yes, you're right, I often use such a test myself to check the correct connection and operability of the controller. And I also liked your technique, so that when simulating a text variable, it does not swear, its value is indicated by "", thank you very much for sharing your experience and knowledge! Unfortunately, everything did not work out right away, today I was only able to send the floating point number as text and accept it as text, display it on the screen and perform an operation with it. But I did it not using your technique "Rz = ground (StringToFloat$ (Sz),2)", but simply "StringToFloat$". What is the difference between them?

And if the floating point number is negative, then how to send and receive it and what is the difference between the operation "Su = FloatToString$ (y,2)" and "Sy = FloatToString$ (int2float (y),2)"? and what is the difference between "Sx= Float2String$" and "Sx=FloatToString$"?

[chipfryer27]

Hi

"Rz = ground (StringToFloat$ (Sz),2)", but simply "StringToFloat$". What is the difference between them?

I think you have a typo in that ground should be fround which rounds a floating point to "x" decimal places, in this case 2.

If Sz was a string with value "123.456"

Rz = fround(StringToFloat$(Sz),2)

would first convert the string Sz "123.456" to a Floating Point value of 123.456
then round the value to 2 decimal places giving 123.46

You could break it down into two separate calculations

Rz = StringToFloat$(Sz)
(Rz would then equal 123.456)

Rz = fround(Rz,2)
(Rz would then equal 123.46)

In saying that there appears to be a bug in v8 which isn't there in v10 in that the fround command isn't removing the remaining digits, but when / if you convert back to a string to print it works then e.g. Float2String$(x,2)

Regards

[gilanetugila]

Good evening! Thanks for the clarification about my questions. We managed to send and receive a negative value of a variable of the float point type today. For some reason, I thought there would be problems with this. In the near future, I will find out the settings of my router and password and try to transfer and receive data using the esp8266 module.

[gilanetugila]

Good afternoon! I have looked at several articles on these modules. Often everything is sharpened under arduino and there is such a complicated discussion that I look at it as a Chinese letter...Well, I realized that in order to check the operation of the esp8266 modules, you need to connect them to a 3.3 volt power supply, I have it! further, if they are connected correctly, certain LEDs should light up, either blue or green or both together. I can see that too. But then they say that you can see that a new wi-fi device will appear in the phone. I don't have such a device. Then we are talking about the fact that initially at the factory the esp 8266 module is configured for frequencies 57600 or 115 200 to work on the uart bus. And then you need to use some kind of program and some kind of device to configure the esp 8266 module. The question is, is this all relevant for arduino or in the flowcode program, you can configure this module by downloading the program from the controller to the esp8266 module. If you have the opportunity, can you explain.

And at the same time, a link to materials on this topic and is it possible to do without any additional devices, or then it will be like walking and searching for a black cat in a dark room?

[chipfryer27]

Hi

Initially it can be a little confusing.

First things first, when dealing with any UART it is extremely helpful to have a USB-TTL Serial converter such as this

https://www.amazon.co.uk/Fasizi-convert ... C98&sr=8-9

The above link is just an example but they really are your best friend when dealing with UART/RS232 and I would go so far as to say essential.

Next up you need a terminal program and there are many free versions such as "PuTTY" or "Terminal by Br@dy".

With the above two items you can "see" what is happening to / from your modules and they make faultfinding / developing so easy.

You don't need a mobile phone, any PC or any device really that has WiFi can be used to check if the module is transmitting. However many modules come with outdated firmware or are incorrectly setup especially if sourced from the cheaper vendors. To update firmware to latest (highly recommended) then you will need the items I described above as you will need to interact directly with the modules. A bit of breadboard comes in very handy too.

All modules I've used operate at 3.3v but are 5v tolerant so you can connect Tx/Rx pins directly to most microcontrollers. If they are a "module" then they will most likely have a 3.3v regulator onboard allowing 5v to power too, but check on that.

Depending on what you read, the default Baud rate (for the RS232 interface) could be 9600 / 38400 / 57600 / 115200 and the only way to tell is to try. Using the above components connect your USB-TTL Serial converter to the ESP8266 and open a terminal program set at 8-1-N. Trying each Baud rate in turn "Connect" and send "AT". If the module replies with "OK" you know you are connected and therefore are well on the way to getting things done. To update the firmware you need a PC and a USB-TTL device. I documented the process in another post and will look it out.

Whilst it is possible to configure the ESP8266 using a microcontroller, it is much, much easier to check settings etc and get them into a known state first by using a PC.

Regards

PS
If you follow the link to this post, and further links within, you should find useful info.

https://www.matrixtsl.com/mmforums/view ... 26#p107726

[gilanetugila]

Good afternoon! Thanks for the tip and advice, I just started checking yesterday.
with the help of a tester and a piece of paperclip, I found that one seemed to be whole, but no voltage was coming through it. Then I decided to check how the tips of the connecting wires feel in other wires, they were hanging out there. I found information on the web that this may cause problems during testing and startup. I decided that it would be better to have a ration. He began to solder the wires. Here you report that you cannot do without the usb-ttl module, you will have to solder and try the module. I have seen such pads with 8 slots.I hope they won't be hanging out there. Thanks for the explanation. I also found information on some sites that free conclusions should be tightened after 10k to plus. Connect the reset output to the minus via the button. I will attach the drawing, please take a look so that it is correct there. But as I understood it all only after setting up using the usb- ttl module.