There you go again, asking so many questions all at once. Almost everything you say is wrong. You need to clear up one thing at a time.

Single variables are stored in RAM. You don’t need to know where it is because the assembler/compiler will allocate memory space for it.

 

I have mixed what I tried to ask when I read it again but I understood it reading the first Paragraph.

But I'll try to ask something else, will the C also remember which bytes are the character bytes ? Like lets say 12h, 13h and 15h are the bytes that contain H, i, !
Why 15h ? Because in 14h is variable "a" which is equal let's say 5. I understand that C will know that 12h, 13h and 15h stored in RAM are the characters and with take 14h as a character.

It wouldn't work that way. If you declared a string variable (an array of characters), say 10 characters long, it would allocate ten consecutive bytes for them, so you would not have a different 8-bit variable half-way along.

A okey so like I create an array that is 10 character wide. Any more information that the UART want to send to this array will be discarded ? Ignored ? Untill this array is reseted and ready to read new info from UART ?

Again, entirely the responsibility of the programmer. When the 11th character was received, the program should know not to put it in the array, either to ignore it, or to start overwriting at the beginning. If it stored it in char[11] then there is a possibility that it would overwrite something important, and C wouldn't stop you doing that. The compiler will laugh at you as you try to find out what keeps going wrong with the variable that is stored next in ram.

 

It wouldn't work that way. If you declared a string variable (an array of characters), say 10 characters long, it would allocate ten consecutive bytes for them, so you would not have a different 8-bit variable half-way along.

Okay got it.

Again, entirely the responsibility of the programmer. When the 11th character was received, the program should know not to put it in the array, either to ignore it, or to start overwriting at the beginning. If it stored it in char[11] then there is a possibility that it would overwrite something important, and C wouldn't stop you doing that. The compiler will laugh at you as you try to find out what keeps going wrong with the variable that is stored next in ram.

Aha !
So if I want to use UART as a debugger I have to reserve a lot of space for arrays with text or data for graphic interface ?
Or make many arrays ?

But I understand the concept of overwriting or ignoring the additional data.
I don't know if I am overthinking this to but so many things there is to think about setting the UART etc. like how many data it will send what type of data it is, should I use it as array or what, how many arrays etc, when to delete all accumulated data and start getting new data or to leave it overwriting.

I wonder how the UART setting goes with more complex stuff, because now it was more simple which was send one message "Hello World" what about data for the LCD Screen or from PC etc. Is there somekind defined size or something that helps define how much space I have to reserve for UART data ? Or something of Screen stuff is how fast I delete the old stuff from UART and replace it with new by overwriting or deleting ? And what type of space should it be array or something else for huge data transfer ?

 

You have a UART on a small microcontroller project. What is anyone likely to send it via its UART? Probably nothing much!

 

You have a UART on a small microcontroller project. What is anyone likely to send it via its UART? Probably nothing much!

Just asking
I saw some projects using UART to send data. UART for speakers or for LCD Screen (less or more complicated screens), or for debugging. I don't really much know how much info each external devices transfer. I know that UART can transfer 8 bit of info so how much of these 8 bits the mikroprocessor needs to get all info from external devices. Like 1 big array or many small arrays or something else I might have missed.
Like how do I know how much space I have to make for speakers UART sends many info I think a whole music track must be send from one device to another. Or for screen which actualise what we see on it everytime. Or for debugger that changes everytime so the UART works all the time I guess and cleares the arrays all the time but how much space it takes ?

For speakers I can imagine because we send a track with specific size like a ring tone from a phone etc. so it is read once and that's all, eventually new track overwrites the old ones. The screen I guess it is also specified with how bit the screen is and every row is one array or something similar. But the debugger ?

I was just wondering how to determine sometimes the size of ram reserved for UART info we receive or the one we want to send ?

 

UART for speakers? I think not.

Typical use of a UART for debugging, is that the program sends out messages about what it is doing, for instance values it reads from a sensor, then connect it to a PC and use a terminal emulator to view the messages.

In that scenario, the micro does not receive anything, and does not need to allocate any memory for receiving.

 

UART for speakers? I think not.

Can't send the audio from PC to micro usins UART and then send this audio using UART to DAC and from there to Speaker ?

Typical use of a UART for debugging, is that the program sends out messages about what it is doing, for instance values it reads from a sensor, then connect it to a PC and use a terminal emulator to view the messages.

Oh it makes sense, so for debugging it doesn't really matter for micro

I wonder how it works then with LCD bigger than 2x16. As I can assume for 2x16 it's 2 arrays with 16 characters I guess. And a module to clear the micro memory of those 2x16 characters and reads again I guess ? Because the micro must contain the info of every character and must clear the whole memory of 2x16 when we want to write new message ? Or the bigger ones.

 

Oh it makes sense, so for debugging it doesn't really matter for micro

No, I have implemented exactly what I said in multiple micro projects that had no LCD attached. It is the simplest way to get info to a screen. And no additional hardware is needed.

And, yes, you could send audio out through a UART, but simply going directly to a DAC would be more practical. Don’t know of any audio device that takes a UART input, which is not to say there are none.

 

I wonder how it works then with LCD bigger than 2x16. As I can assume for 2x16 it's 2 arrays with 16 characters I guess. And a module to clear the micro memory of those 2x16 characters and reads again I guess ? Because the micro must contain the info of every character and must clear the whole memory of 2x16 when we want to write new message ? Or the bigger ones.

LCDs are interfaced using either a parallel connection, I2C or SPI. (I use SPI to interface to a 800x480 LCD). It doesn't use the UART.
I have all the strings I am likely to send to the display (there are about 40 of them) declared as char arrays in ROM, and I send them via the SPI interface when required. The LCD doesn't send any information back to the processor.

 

LCDs are interfaced using either a parallel connection, I2C or SPI. (I use SPI to interface to a 800x480 LCD). It doesn't use the UART.
I have all the strings I am likely to send to the display (there are about 40 of them) declared as char arrays in ROM, and I send them via the SPI interface when required. The LCD doesn't send any information back to the processor.

So UART isn't very likely used ? What is it good for and what not ? I know it is many time mentioned in courses so I thought it is very used.
And 40 arrays are enough to fill whole screen I don't know what size of the letters are but good to know :> Do I have to always know how many strings/arrays I need to fill the whole screen or the program know to not fill the rest of the screen if there is not enough strings or if there is to much strings ?

I thought that if I want to use this screen like writing a message or anything it would require a space (which you've said 40 arrays) and some mechanism that would clear some letters or whole message. But this is programming aspect of clearing the ram etc. But yes you are right the LCD doesn't send any information rather other external devices.

And, yes, you could send audio out through a UART, but simply going directly to a DAC would be more practical. Don’t know of any audio device that takes a UART input, which is not to say there are none.

I thought that sending an audio to DAC I need UART somehow I have to connection between micro and DAC if there is not a build one.

 

So UART isn't very likely used ? What is it good for and what not ? I know it is many time mentioned in courses so I thought it is very used.
And 40 arrays are enough to fill whole screen I don't know what size of the letters are but good to know :> Do I have to always know how many strings/arrays I need to fill the whole screen or the program know to not fill the rest of the screen if there is not enough strings or if there is to much strings ?

I thought that if I want to use this screen like writing a message or anything it would require a space (which you've said 40 arrays) and some mechanism that would clear some letters or whole message. But this is programming aspect of clearing the ram etc. But yes you are right the LCD doesn't send any information rather other external devices.

If you think about a machine that is controlled by a microcontroller, it's unlikely to have a huge vocabulary! It's not going to engage you in intelligent conversation! There is only a limited amount of information it could possible impart to its user! Think about how many states it could possibly be in during normal operation (about 10 for my machine) and how many faults it can detect (32) each one could have a line of information on the LCD screen (32 characters). It's not going suddenly to think up something new it could tell its user. All the things it could possibly say would be known beforehand.

I thought that sending an audio to DAC I need UART somehow I have to connection between micro and DAC if there is not a build one.

no - you need an I2S interface for that (yes, I2S, not I2C)

 

If you think about a machine that is controlled by a microcontroller, it's unlikely to have a huge vocabulary! It's not going to engage you in intelligent conversation! There is only a limited amount of information it could possible impart to its user! Think about how many states it could possibly be in during normal operation (about 10 for my machine) and how many faults it can detect (32) each one could have a line of information on the LCD screen (32 characters). It's not going suddenly to think up something new it could tell its user. All the things it could possibly say would be known beforehand.

Sorry I didn't understand this paragraph, what did you try to tell basing on my paragraph ?

EDITED :
I am basing my knowladge with only theory (with some experience with MCS-51) and with some imagination.
This type of knowladge is unknown for me like, do I have to define a specific maximum amount of arrays or strings for it work? What happens if I give not enough arrays/strings will the rest of the screen will be just unused or will error pop out or what (like I have 2 arrays/2 strings will the rest of the screen will just not work) ?
Or what will happen if the string is to long or I add to much arrays than it is needed ?

These type of questions are a bit "sketchy" for me.
I am basing my knowlagle with only theory (and with some experience with MCS-51), so I don't know how much of a space it takes to fill the screen or how these stuff works.

My imagination is what happens if I didn't predict something. How do I know how much I have to predict like for the screen. I have only in mind what I have to predict or how to set things how do I know it :>?

Also 32 characters ? This is how much your screen can make ? 32 faults ?
Or like what is UART used then.

 

There are many flaws in your posts. In all cases, you are overthinking the problem.

1) You keep talking about clearing data in registers or variables or RAM. One usually never has to clear data containers. The containers are simply overwritten with new data the next time your write new data.

2) UART communications is still a simple and useful mode of communicating between any two devices. For example, an MCU can send data to an LCD display via UART protocol if the LCD is configured to receive UART protocol.

3) Suppose your LCD display is a 2-line by 16-character display. Usually, one is interested in updating the information displayed on Line 1 or Line 2. It is a simple matter to write a routine that accepts 16 characters for Line 1 and 16 characters for Line 2. Hence, you know that you will never be required to receive more than 16 characters at any one time. Hence your receiver code can be limited to receive 16 characters plus a delimiter character. Mission accomplished.

4) You can use UART protocol for debugging purposes. It used to be that the longest text line you can type on a printed page is 80 characters long. Right there, that defines the maximum storage you should allocate for the UART RX routine. In reality, you define for yourself, what is the longest message you would want to send on a single debug line? For me, 20 characters would be enough for one line of text.

5) Sure, you can send DAC data using UART protocol. Ask yourself, what is the word size and sample rate at which you want to transmit uncompressed analog data. Let us assume that 8-bit data at 8kHz sample rate gives you adequate audio quality. Therefore, simply send one byte every 125μs at a baud higher than 80kHz, for example 115200 baud. You would have to create a mechanism for buffering the data and also to reply to the sender when the buffer is full or approaching a full state.

 

So UART isn't very likely used ?

No, it isn’t very likely used for what you asked about. I told you what I used it for. It is also frequently used for two micros to communicate. I can be used with an RF or IR transmitter and receiver to make a remoter control, which I have also done.

 

3) Suppose your LCD display is a 2-line by 16-character display. Usually, one is interested in updating the information displayed on Line 1 or Line 2. It is a simple matter to write a routine that accepts 16 characters for Line 1 and 16 characters for Line 2. Hence, you know that you will never be required to receive more than 16 characters at any one time. Hence your receiver code can be limited to receive 16 characters plus a delimiter character. Mission accomplished.

So I understand from this example that usually LCD displays have known maximum characters to display.
Even in LCD that can change the size of characters that in result makes more space for character like changing from 20 characters to 24. I remember my friends had a screen that he could change every pixel in it, so I wondered how to handle these type of things.

But I understood I guess the fact that LCD have predefined number of characters in line or something like that :> So like bigger screens can have more characters in line or just more lines.

1) You keep talking about clearing data in registers or variables or RAM. One usually never has to clear data containers. The containers are simply overwritten with new data the next time your write new data.

Understandable

5) Sure, you can send DAC data using UART protocol. Ask yourself, what is the word size and sample rate at which you want to transmit uncompressed analog data. Let us assume that 8-bit data at 8kHz sample rate gives you adequate audio quality. Therefore, simply send one byte every 125μs at a baud higher than 80kHz, for example 115200 baud. You would have to create a mechanism for buffering the data and also to reply to the sender when the buffer is full or approaching a full state.

I thought it was easier. Like sending from PC to micro through UART whole music track that is 16 kB ? And I know how much space reserve for this transfer and the same transfer goes from micro (it's RAM) to the DAC and from there to speaker.

I think I need to educate myself more with that ...

 

You are not thinking things through thoroughly enough.

Ask yourself, how much time would it take to transmit 16kB of data?
How would you send 16kB data to a DAC?
How would you get information from DAC to speaker?

 

You are not thinking things through thoroughly enough.

Ask yourself, how much time would it take to transmit 16kB of data?
How would you send 16kB data to a DAC?
How would you get information from DAC to speaker?

Before I just stated that I need to educate myself more, because I just don't know how it works exactly (I mean why the speed mattered etc or how the music works in speaker with specific data speed ?) ;>
I was just in a wrong assumption.
But trying to answer it :

- how much time it takes to transmit 16kB of data ? It depends if it matters. Because the speaker I guess works when the data is already loaded fully in RAM (my assumption).
- How would I send 16 kB data to a DAC ? I know only UARF, but I heard her of SPI I2C or I2S.
- from DAC to Speaker ? Isn't Speaker directly connected to DAC ? Or additionally added a filter.

How it works or why it must be a specific speed of transfering data from micro to DAC is something I have to learn.

Although then this paragraph is correct I assume ?

So I understand from this example that usually LCD displays have known maximum characters to display.
Even in LCD that can change the size of characters that in result makes more space for character like changing from 20 characters to 24. I remember my friends had a screen that he could change every pixel in it, so I wondered how to handle these type of things.

But I understood I guess the fact that LCD have predefined number of characters in line or something like that :> So like bigger screens can have more characters in line or just more lines.

I just knew that there were screens that could change the size of characters so there could be longers characters from 16 to 20 from reducing the size or have more lines.

 

Sorry. You have not answered any one of the three questions.
I want total details that would allow me to do this. Not just hand waving.

Let us take the last question.
How would you get information from the DAC to the loudspeaker?

Connecting a loudspeaker to the DAC does not work, unless…?

You have to do more study.

What is the voltage output of the DAC?
How much current can the DAC deliver?
What is the output impedance of the DAC?

What is the impedance of the loudspeaker?
How much current can the loudspeaker handle?
How loud do you want the sound to be?

What kind of circuit is necessary to match the output of the DAC to the loudspeaker? What are the voltage and current requirements of such circuit?

(Observe, I have taken one single question and tried to break it down into minute details in order to solve the problem. I have not deviated from the problem by going off with a different question. This is the art of problem solving which you need to learn. You also need to learn how to analyze and answer these questions on your own otherwise you are going nowhere.)

 

- how much time it takes to transmit 16kB of data ? It depends if it matters. Because the speaker I guess works when the data is already loaded fully in RAM (my assumption).
- How would I send 16 kB data to a DAC ? I know only UARF, but I heard her of SPI I2C or I2S.

16kbytes of audio is 4000 samples - enough to last 90ms
you need four bytes every sample, and 44100 samples a second, that requires a baud rate of almost 2Mbaud. That would be a challenge for most UARTs to receive. BUT you would need a maximum of 4 bytes of storage - the data would be straight in and straight out again to the DAC. A typical audio track of 3.5 minutes needs 37Mbytes of storage.

 

Question #1
How much time would it take to transmit 16kB of data?

Let's keep it simple. UART protocal at 9600 baud is about 1ms per byte. 16kB would take 16 seconds.
So let's increase the baud to 115200. That would still take about 1.3 seconds.