When writing to the port, write() should indicate number of bytes written. Are you checking the return value and is it less than expected?
Note that write() enqueues the bytes but returns before write complete. If port is closed before hardware finishes shifting all the bits out, message will be truncated. Note that most MCUs have errata related to UART completion: usually the "busy" bit (or whatever a particular micro calls it) indicates transmission done before it actually shifts out the last bits. On Thu, May 9, 2024 at 12:41 PM Mark Stevens <mark.stev...@wildernesslabs.co.invalid> wrote: > This is a direct connection between the two chips on a PCB. > > Regards, > Mark > — > Mark Stevens > mark.stev...@wildernesslabs.co > > > > > > > > On 9 May 2024, at 17:38, Bill Rees <redskyo...@icloud.com.INVALID> > wrote: > > > > > > I've seen this problem before which revolved around flow control; > essentially soft versus hard flow control (xmit off/ xmit on) > > > > Are you using a null modem cable? If not that may give you the accuracy > you're looking for, else hardware flow control is the only other > possibility if it is flow control. > > > > Bill > > > > On 5/9/2024 9:24 AM, Tomek CEDRO wrote: > >> On Thu, May 9, 2024 at 6:15 PM Mark Stevens > >> <mark.stev...@wildernesslabs.co.invalid> wrote: > >>> Yes, I am sure both side are configured correctly. > >>> If I run the kernel code only then all works as expected. > >>> If I run user space code alone all works as expected. > >>> The problems happen when I transition from kernel use of the UART to > user space use of the UART. > >>> I have also connected a logic analyser to the system and all looks > good. > >>> Also, my current problem is NuttX reading data not sending it. > Sending may also be a problem but I have not got that far at the moment. > >> Which UART do you use? What happens when you use different UART? Are > >> you sure it does not interfere with console? > >> > >> -- > >> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > >
