I am sorry that I couldn't find this answer in this site or web. I have an ARM SoC(Host) which needs to communicate with the peripheral having ARM Micro controller using UART. Linux runs on top of ARM SoC. Below are my questions.

  1. From host side, If I want to write or read data, I understand that we have to do:- (The below steps are from "Serial Programming Guide for POSIX Operating Systems" : Michael R. Sweet) fd = open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_NDELAY); fcntl(fd, F_SETFL, FNDELAY); Raw mode other things are there which I understand

    Below are the things which I don't understand:- 1.1 Do I also need to Configure the serial port of the host in the user space? Such as Setting baud rate, Character size, Parity checking, Hardware flow control etc or this will be handled by the linux driver. I am not sure where it should be handled, user space or driver space or U-Boot. 1.2 Also, I want to know where the SoC's ARM UART registers related things will be coded, is it in U-Boot or somewhere else? In AVR, we usually directly access the registers.

  2. Now, the ARM controller peripheral is from a vendor. Do we need to write driver for it or the vendor will provide it and we have to integrate it. If yes, please explain it at a very high level that how we should integrate it. Presence of code in U-Boot, Driver space.

One more thing, I understand that the code that we use to drive the peripherals is called driver code and is present in linux kernel space of the host. What is the name of the code for accessing SoCs(Host) UART registers or any other register on SoC? where is it present? U-Boot, Driver space or somewhere else.

I understand that the experts who are answering this question would have gained this knowledge from some documents, reading code and doing things practically. It would be great if I can get pointers to all the three but even if I get the reference documents alone I will be happy.

  • 3
    \$\begingroup\$ You have two entirely distinct questions here which can't really be properly combined into a single posting. The one about the Linux SoC is vaguely answerable (though not really an EESE question) because the fact that it runs Linux dominates over the unspecified identify of the Soc. The one about the MCU is not, because you've failed to identify it and the software framework (if any) to be used on it, and those facts are hugely relevant there. \$\endgroup\$ – Chris Stratton Apr 27 '18 at 5:02
  • 1
    \$\begingroup\$ I'm voting to close this year-old abandoned question because it has never been specific enough to be answerable. Essentially an embedded system running Linux or similar properly configured operating system does serial communication via standard APIs just like a desktop PC would; while a small embedded system needs hardware targeted code that could only be known when the parts are identified. Neither system has ever been specified. \$\endgroup\$ – Chris Stratton Jun 18 '19 at 14:17
  1. Yes, you need to configure baud rate, parity, etc on your own. But it's not too bad if you're on Linux or BSD (you mentioned POSIX), you don't have to code all this in C. You can use more abstracted languages like Python which have libraries to make such UART interactions easier. Like this: http://pyserial.readthedocs.io/en/latest/shortintro.html You can do all of this in userspace too, it's not needed to do in U-Boot and the paramters can be changed anytime you want with different userspace programs.

  2. Depends on the vendor, most larger ones will have pretty decent Linux kernel support for all their peripherals. Linux has its own libraries and abstractions for common peripherals like GPIO, UART, I2C, SPI, etc. So the vendor needs to write drivers for those common interfaces and then you can use them identically, without having to care about the underlying chip. That's the goal anyway. If you do have to write your own, it'll be hard unless you know your kernel pretty well. Probably best to ask someone who's done it before for help.

Best of luck.

  • \$\begingroup\$ Question 2 is about an embedded MCU, not the Linux-running SoC (though both are ARM variants) However question 2 is too broad to be a fit here, because that MCU has not been identified... \$\endgroup\$ – Chris Stratton Apr 27 '18 at 5:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.