Hi All I’m attempting to write two drivers for the serial ports in UART mode. The drivers need to provide the following features for a pre-existing code base that I’m porting to the NET+50: 1) The first driver needs to provided a single character at a time purely polled TX or RX driver. If a multi-char TX message needs to be sent the interface sends 1 char at a time blocking until all characters in the message are sent… Bad I know but that what the higher level code wants/needs… 2) The second driver needs to provide an interrupt driven TX and RX interface. The TX side gets given a buffer and stuffs data from this into the TX FIFO as fast as possible in the background until finished. The RX side needs to empty the RX FIFO into a buffer and records line status as and when characters/changes occur… preferably a character at a time… My questions are: 1) Can the polled interface needed for driver 1 be done using the UART in interrupt mode but with the TX and RX interrupts off… i.e. are the RXBC + RXRDY / TXBC + TXRDY status flags valid under these conditions? Can I just poll these and the read / write data to the FIFO when appropriate? 2) It appears unclear how the RXBC flag operates… It has the feel (reading between the lines) that it is only set when 4 characters (a whole FIFO row) have been received or one of the timeouts / match conditions have been met… Does anyone know how it really works? 3) Considering question 2 above if the RXBC flag only gets set normally (i.e. without a timeout setup) when 4 chars are ready… If the FIFO starts out empty, will the RXRDY flag be set and continue to be set as chars 1 - 3 are received only finally clearing when the 4th char sets the buffer closed flag? 4) What is the best way to clear the RX FIFO (without interfering with the TX FIFO) if the RX line has been receiving unwanted data while you had RX interrupts disabled? I ask this because, even though I thought I emptied the FIFO in my first attempt to do the interrupt driven driver, I was getting overrun conditions the first char I received after enabling the interrupts… Thanks, Dave PS has anyone else found the datasheet/user manual totally lacking?
Hi All I’ve knocked up a polled driver… which is doing the following at each RX poll: 1) Looks to see if a byte from a previous FIFO read is available in the “RX buffer”. If so the oldest byte in the buffer is made available on this poll and this poll ends. Else it proceeds to step 2 2) Acknowledges the RXBC flag (if set) before continuing to step 3. 3) If the RXRDY flag is set continue to step 4 else end the current poll 4) Reads RXFDB and a full 32-bits from FIFO register into the “RX buffer”. The oldest valid byte is made available this poll and the current poll ends. Any remaining valid bytes from this FIFO read (as determined by the RXFDB read) will be made available at step 1 in subsequent polls of the driver… When I used this to echo what I receive back out the TX FIFO one byte at a time in a tight loop. (i.e. Poll for a character and if I get one write it to the TX FIFO using a byte write to the LS byte of the register) I observe some strange behavior. I send characters from my PC using a terminal app and I see that I only get a response four bytes at a time… i.e. I send a byte at a time (well interspersed)… I get my echoes (all 4 chars at the same time) immediately after I send the 4th character from my PC… Is this the RX side not setting the RXRDY flag until it has 4 bytes?.. or is it the TX side not starting to send until it has a 4 bytes (a full row) in the FIFO… Regards, Dave PS is the FDRN flag valid if RXRDY is set but RXBC wasn’t just acknowledged? i.e. does this reflect the instantaneous valid byte count for FIFO reads…
Hi All BTW I would normally work this out by trial and error using the ICE… unfortunately I’ve got no ICE and until I get the UART up and running my only debug tool is a couple of LEDs… so any help you can give on this would be most appreciated… BBFN Dave
Hi Dave. First I must inform you that the TXBC interrupt does not work (search for TXBC on this forum and you will get information about that)!! To the question: 1) Yes you can poll the status bits and send data when appropriate but if I were you I would still use an ISR. If you want the calling task to be blocked until all data have been sent the ISR could set an event flag when all data have been sent and the calling task is blocked until that flag is asserted. This way you have a better solution and you only have to write one driver. 2) I haven’t used the RXBC interrupt so far but I don’t think the buffer is closed when you have received 4 bytes. A gap timeout och match will close the buffer though. 3) Se #2 4) I don’t think you have any other choice than reading the FIFO until the FIFO is empty if you don’t want to effect the TX FIFO. Hope it helps you a little bit. PS I must agree that they have a lot to learn about writing good documentation. Sometimes it feels that you have more questions that answers after reading some sections. When it comes to the TXBC interrupt not working I find it very strange that it is not present in any errata (not in NET+50 nor in NS7520 anyway). The NS7520 errata was written in may this year and they have known about the problem long before that.
Thanks for the heads up on TXBC… sort of explains why one of my attest experiments with a polled driver did some strange things… Don’t know how I missed the topic seeing as its only a few down from this one 
Regards, Dave
see the attached code… BTW the macros for accessing the UART SFRs all do what you’d expect with the exception of: 1) SSRAN_xxxx_CLEAR() which acknowledges by writing a one to the bit position. 2) FDRN which is *((volatile uint32 *) (FIFO addr)) Anyone see any obvious mistakes? Comment on anything I’ve not understood in the operation of the UART… Thanks Dave
BTW the code example foo.c in my last post gives the following output (local echo on at terminal app): abcdbcde with the last four chars being the echo from the NET+50 in response to sent chars abcd sent at one second intervals. I was sort of expecting: abbccdde Does the gap timer forcing a RXBC condition work? Could I solve my problems by using a gap timeout with a short (couple of character) period? Regards, Dave
Appears the RX buffer gap timer does the trick… now all I’ve got to do is make the interrupt mode driver work 