Hi again, Correction to my last post. All working good using serial_software, with invert bit to false. But, still Frame or Break issues in communication using serial_hardware...
Have done this Kiste test; forever loop serial_hw_data=0x22 serial_hw_data=0x22 delay_1s(1) end loop and here's the results; d7 00 ×. d5 00 Õ. d7 00 ×. d7 00 ×. d7 00 ×. d7 00 ×. d7 00 ×. d7 00 ×. d7 00 ×. d7 00 ×. d7 00 ×. d5 00 Õ. d7 00 ×. d7 00 ×. d7 00 ×. d7 00 ×. d5 00 Õ. d7 00 ×. d7 00 ×. d5 00 Õ. d7 00 ×. d5 00 Õ. d5 00 Õ. d7 00 ×. d7 00 ×. Any ideas? Thank you very much. Cheers, Filipe Santos On Monday, May 16, 2022 at 7:22:48 PM UTC+1 flyway38 wrote: > Hey all, > > Miracles do happen. > Maybe I have an easier way. > Am using and FTDI cable (USB - RS232/5V) and it has a configurable EEprom. > This configuration includes inversion of all RS232 signals. Have inverted > RX and TX and this way am using now serial_software with that inversion bit > to false. > Computer receives good data, but it seems RX on PIC side shouldn't be > inverted... not receiveing good data from computer. > Can anyone confirm this? TX should be the only one to be inverted? > Thank you very much. > > Kind regrads, > Filipe Santos. > > On Monday, May 16, 2022 at 6:33:38 PM UTC+1 flyway38 wrote: > >> Hi Rob, >> >> Yes, You're right. >> And yes, will change my design for that hardware comm line inversion. >> Then will back here for results or new issues :D >> Thank you very much for all help. >> Cheers. >> >> Kind regards, >> Filipe Santos. >> >> On Monday, May 16, 2022 at 11:41:31 AM UTC+1 [email protected] wrote: >> >>> Hi Filip, >>> >>> If I understand you right you use inverted serial data. In the serial >>> software library everything - including the startbit - is inverted if you >>> select the inverted mode. In hardware only the data can be inverted but not >>> the startbit. >>> >>> Is it not possible to add an inverter to your board so that the data is >>> not inverted and so you can use serial hardware? You could make an inverter >>> with one transistor and 2 resistors. >>> >>> Kind regards, >>> >>> Rob >>> >>> ------------------------------ >>> *Van:* [email protected] <[email protected]> namens >>> flyway38 <[email protected]> >>> *Verzonden:* zondag 15 mei 2022 21:20 >>> *Aan:* jallib <[email protected]> >>> >>> *Onderwerp:* Re: [jallib] Help about serial_hardware library for the >>> 16F18313 >>> Hey all, >>> >>> Thank you very much to all. >>> Yes, tried timeout option, but I loose alot of received data. >>> I think that , for now (8 pin PIC), sending to pic dummy data to unlock >>> that loop is my best option. >>> This way works better than timeout solution under serial_software lib >>> usage. >>> Unless some miraculous idea comes along.. :D >>> >>> Anyways, later on, will redesign this project for a bigger board and use >>> a bigger PIC. >>> Thank you to all once again. >>> >>> Kind regards, >>> Filipe Santos. >>> >>> On Sunday, May 15, 2022 at 4:44:36 PM UTC+1 [email protected] wrote: >>> >>> Hi Kiste, >>> >>> I fully agree with you. Not worth to add a timeout. >>> >>> Kind regards, >>> >>> Rob >>> >>> ------------------------------ >>> *Van:* 'Oliver Seitz' via jallib <[email protected]> >>> *Verzonden:* zondag 15 mei 2022 17:33 >>> >>> *Aan:* [email protected] <[email protected]> >>> *Onderwerp:* Re: [jallib] Help about serial_hardware library for the >>> 16F18313 >>> Hi Rob, >>> >>> the most critical thing when receiving asynchronous data, is to >>> precisely catch the starting edge of the start bit, as all the timing in >>> the following byte depends on it. >>> >>> while serial_sw_rx_pin loop >>> end loop >>> >>> This is in fact only two machine instructions, and therefore reacts >>> within 2Tcy or 2µs at 4MHz. >>> >>> I did not count the machine instructions for subtracting a dword, but I >>> think it must be more than 12 instructions, and another 12 for comparing to >>> 0. Plus the 1µs delay, plus the "&"... Will take at least 30µs at 4MHz. If >>> that is more than half a bit, data corruption is more than likely. >>> 1/60µs=16666 baud is the speed beyond that a 4MHz controller will certainly >>> not be able to follow anymore. >>> >>> If the transmission starts right after the timeout is over, depending on >>> the main program, corrupt data will be received (or a byte is completely >>> lost). >>> >>> Serial_software is a poor thing on the receiving side anyway. If you see >>> it as an improvement, go ahead. I would under all circumstances avoid using >>> serial_software for receiving, even more so with that timeout. >>> >>> Greets, >>> Kiste >>> >>> Am Sonntag, 15. Mai 2022, 16:57:09 MESZ hat Rob CJ <[email protected]> >>> Folgendes geschrieben: >>> >>> >>> Hi Kiste, Filip, >>> >>> An option would be to extend the serial_software.jal library with a >>> maximum wait time for reading and when a timeout occurs return a '0' as >>> data. >>> >>> So something like. >>> -- See if a timeout is defined to prevent an endless wait >>> if defined(SERIAL_SOFTWARE_READ_TIMEOUT) then >>> var dword _serial_timeout = SERIAL_SOFTWARE_READ_TIMEOUT >>> -- wait for startbit with timeout >>> while serial_sw_rx_pin & (_serial_timeout > 0) loop >>> _serial_timeout = _serial_timeout - 1 >>> _usec_delay(1) >>> end loop >>> else >>> -- wait for startbit without a timeout >>> while serial_sw_rx_pin loop end loop >>> end if >>> >>> -- When a timeout is defined and a timeout occcured return 0 as data. >>> if defined(SERIAL_SOFTWARE_READ_TIMEOUT) then >>> if (_serial_timeout == 0) then >>> data = 0 >>> end if >>> end if >>> >>> Would that work? >>> >>> Kind regards, >>> >>> Rob >>> >>> ------------------------------ >>> *Van:* 'Oliver Seitz' via jallib <[email protected]> >>> *Verzonden:* zondag 15 mei 2022 15:46 >>> *Aan:* [email protected] <[email protected]> >>> *Onderwerp:* Re: [jallib] Help about serial_hardware library for the >>> 16F18313 >>> >>> Hi! >>> >>> Well... 8 pin is a problem... I only have solutions which aren't that >>> elegant... >>> >>> >>> - use a different USB UART, which uses the idle high mode (which in fact >>> is standard on 3.3 and 5 volt levels) >>> - if you have an I/O pin (other than RA4) to spare, use the comparator >>> or a CLC to invert the signal, and connect the output and RX to that same >>> pin via PPS >>> - use external circuitry to invert the signal, like a MAX232, which is >>> inverting since the 1970s and therefore in fact the reason for all the >>> confusion ;-) >>> - write a new library, which receives by timers and pin-change interrupts >>> >>> Greets, >>> Kiste >>> >>> Am Sonntag, 15. Mai 2022, 14:56:49 MESZ hat flyway38 <[email protected]> >>> Folgendes geschrieben: >>> >>> >>> Hi Kiste, >>> >>> Understad your points. >>> The main issue am trying to solve while using serial_software (wich >>> makes my project runs good enough) is that loop while trying to receive >>> data; >>> "while !serial_sw_rx_pin loop". >>> Because of this loop have to constantly send dummy data to allow PIC out >>> of the loop. >>> All other code runs fairly ok (somewhat sluggish, but good enough for >>> the needs). >>> Checked PIC18F14K2, the problem is I need to stick to 8pin THT PIC right >>> now... >>> On Sunday, May 15, 2022 at 12:42:01 PM UTC+1 Kiste wrote: >>> >>> Hi Filipe, >>> >>> that's an important information: seral_sw_invert defaults to "true". If >>> you had to set it, you have set it to "false". That means, the line you are >>> driving is in "idle low" mode. That mode is not supported by >>> serial_hardware, as it is not supported by the classical USART hardware in >>> PIC controllers. >>> >>> You can not cure that problem by sendig serial_hw_data=!value , as that >>> does not alter the polarity of start- and stopbits. >>> >>> With the delay of 300µs between bytes, you do not cure the framing >>> error. By doing so, you mislead the receiver to recognise data bits as >>> framing bits, so it's one error masking the other error. >>> >>> If you can use another PIC, like PIC18F14K22, the hardware can be set to >>> "idle low" mode for sending and receiving, your 16f18313 can only use the >>> transmission side in that mode. So, to make the receiving side work, you >>> would have to use additional hardware (or peripherals like CLC or >>> comparators) to invert incoming data. >>> >>> Greets, >>> Kiste >>> >>> Am Sonntag, 15. Mai 2022, 13:06:54 MESZ hat flyway38 <[email protected]> >>> Folgendes geschrieben: >>> >>> >>> Hi Kiste, >>> >>> Thak you very much for your input. >>> Will test your code to check and answer you. >>> Anyways, right now I can avoid the Framming Error but still receiving >>> incorrect data while using serial_hardware library. >>> >>> About framming Error, the problem was due to the way I sent data to >>> transmit reg. >>> I was sending two bytes with no delay in between (it works good like >>> this using serial_software lib). >>> But if I use a delay of about 300us between the two bytes sent, Frame >>> Error disppears, but as said above, received data by computer is incorrect. >>> Less than that delay, I get Frame Error. >>> >>> Can answer your question about "const bit serial_sw_invert". * Yes*, >>> needed to set this var using serial_software. >>> Will back here with answer for your second quest. >>> Thank you >>> >>> Cheers, >>> Filipe Santos. >>> On Sunday, May 15, 2022 at 10:48:19 AM UTC+1 Kiste wrote: >>> >>> That data is a bit complex for easy analysis, though I see that you've >>> got a repeating value every five bytes in all of the samples. The baud rate >>> therefore should not be the problem. >>> >>> If you want to rely on my guess, insert after "seral_hw_init()" >>> >>> BAUDCON1_SCKP=1 >>> If this helps for transmission, you can't use the USART directly for >>> receiving, as it has no inversion option for RX. In that case, you can use >>> a CLC or a comparator as inverter. >>> >>> >>> If you want to track down the error and learn how to do that, please >>> answer my questions: >>> >>> Have you set "const bit serial_sw_invert" with serial software? >>> >>> What is the result if you just transmit a single character with pauses? >>> >>> forever loop >>> serial_hw_data="@" >>> delay_1s(1) >>> end loop >>> >>> >>> Greets, >>> Kiste >>> >>> Am Sonntag, 15. Mai 2022, 11:11:09 MESZ hat flyway38 <[email protected]> >>> Folgendes geschrieben: >>> >>> >>> Hello Kiste, >>> >>> I use Termite to check what flows in my comm line. >>> Here's what I see and makes my project work good enough, using >>> serial_software (small extract): >>> >>> 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef ..íï*ñ..íï*ñ..íï >>> 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 *ñ..íï*ñ..íï*ñ.. >>> ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 íï*ñ..íï*ñ..íï*ñ >>> 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef ..íï*ñ..íï*ñ..íï >>> 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 *ñ..íï*ñ..íï*ñ.. >>> ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 íï*ñ..íï*ñ..íï*ñ >>> 09 00 ee ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef ..îï*ñ..íï*ñ..íï >>> 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 *ñ..íï*ñ..íï*ñ.. >>> ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 íï*ñ..íï*ñ..íï*ñ >>> 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef ..íï*ñ..íï*ñ..íï >>> 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 *ñ..íï*ñ..íï*ñ.. >>> ed ef 2a f1 09 00 ee ef 2a f1 09 00 ee ef 2a f1 íï*ñ..îï*ñ..îï*ñ >>> 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef ..íï*ñ..íï*ñ..íï >>> 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 *ñ..íï*ñ..íï*ñ.. >>> >>> Now here's what I see using serial_hardware: >>> >>> 9a f1 81 80 f5 ef 92 f1 81 80 fd ef 9a f1 81 80 šñ €õï’ñ €ýïšñ € >>> f5 ef 9a f1 81 80 f6 ef 9a f1 89 80 fd ef 9a f1 õïšñ €öïšñ‰€ýïšñ >>> 89 80 fe ef 9a f1 89 80 fd ef 9a f1 89 80 f5 ef ‰€þïšñ‰€ýïšñ‰€õï >>> 92 f1 81 80 f5 ef 9a f1 81 80 f5 ef 92 f1 89 80 ’ñ €õïšñ €õï’ñ‰€ >>> f5 ef 9a f1 81 80 f5 ef 9a f1 81 80 fd ef 9a f1 õïšñ €õïšñ €ýïšñ >>> 89 80 fe ef 9a f1 89 80 fd ef 9a f1 89 80 fd ef ‰€þïšñ‰€ýïšñ‰€ýï >>> 9a f1 89 80 f5 ef 92 f1 81 80 fd ef 9a f1 89 80 šñ‰€õï’ñ €ýïšñ‰€ >>> fd ef 9a f1 81 80 fd ef 92 f1 89 80 fe ef 9a f1 ýïšñ €ýï’ñ‰€þïšñ >>> 81 80 fd ef 9a f1 89 80 f5 ef 9a f1 81 80 fd ef €ýïšñ‰€õïšñ €ýï >>> 9a f1 81 80 fe ef 9a f1 81 80 f5 ef 9a f1 89 80 šñ €þïšñ €õïšñ‰€ >>> f5 ef 9a f1 81 80 ed ef 9a f1 81 80 f5 ef 9a f1 õïšñ €íïšñ €õïšñ >>> 89 80 fd ef 9a f1 89 80 f6 ef 92 f1 89 80 fe ef ‰€ýïšñ‰€öï’ñ‰€þï >>> 92 f1 89 80 fd ef 92 f1 81 80 fe ef 92 f1 89 80 ’ñ‰€ýï’ñ €þï’ñ‰€ >>> f5 ef 9a f1 81 80 fe ef 92 f1 89 80 fd ef 9a f1 õïšñ €þï’ñ‰€ýïšñ >>> 81 80 fd ef 8a f1 89 80 fd ef 92 f1 81 80 fd ef €ýïŠñ‰€ýï’ñ €ýï >>> 92 f1 81 80 fd ef 9a f1 81 80 ed ef 92 f1 89 80 ’ñ €ýïšñ €íï’ñ‰€ >>> >>> Finally, here's what I see using serial_hardware, inverted data in >>> serial_hw_write function ("TXREG = !data"): >>> >>> 82 90 e5 8e fe ff 82 90 e5 8e f6 ff 8a 90 ed 8e ‚ åŽþÿ‚ åŽöÿŠ íŽ >>> fe ff 8a 90 ed 8e fe ff 8a 90 e5 8e fe ff 89 90 þÿŠ íŽþÿŠ åŽþÿ‰ >>> e5 8e fe ff 82 90 e5 8e f6 ff 81 90 ed 8e f6 ff åŽþÿ‚ åŽöÿ íŽöÿ >>> 82 90 ed 8e f6 ff 8a 90 e5 8e f6 ff 82 90 ed 8e ‚ íŽöÿŠ åŽöÿ‚ íŽ >>> f6 ff 8a 90 ed 8e fe ff 82 90 e5 8e f6 ff 81 90 öÿŠ íŽþÿ‚ åŽöÿ >>> ed 8e f6 ff 82 90 e5 8e f6 ff 82 90 e5 8e fe ff íŽöÿ‚ åŽöÿ‚ åŽþÿ >>> 8a 90 e5 8e f6 ff 8a 90 e5 8e f6 ff 82 90 ed 8e Š åŽöÿŠ åŽöÿ‚ íŽ >>> f6 ff 82 90 e5 8e fe ff 81 90 e5 8e fe ff 82 90 öÿ‚ åŽþÿ åŽþÿ‚ >>> ed 8e fe ff 82 90 ed 8e fe ff 8a 90 ed 8e fe ff íŽþÿ‚ íŽþÿŠ íŽþÿ >>> 82 90 e5 8e fe ff 82 90 ed 8e fe ff 82 90 e5 8e ‚ åŽþÿ‚ íŽþÿ‚ åŽ >>> fe ff 8a 90 e5 8e f6 ff 82 90 ed 8e fe ff 82 90 þÿŠ åŽöÿ‚ íŽþÿ‚ >>> e5 8e fe ff 82 90 e5 8e fe ff 82 90 e5 8e f6 ff åŽþÿ‚ åŽþÿ‚ åŽöÿ >>> 82 90 e5 8e f6 ff 81 90 ed 8e f6 ff 8a 90 ed 8e ‚ åŽöÿ íŽöÿŠ íŽ >>> f6 ff 82 90 e5 8e f6 ff 8a 90 e5 8e f6 ff 89 90 öÿ‚ åŽöÿŠ åŽöÿ‰ >>> ed 8e f6 ff 8a 90 e5 8e fe ff 82 90 ed 8e fe ff íŽöÿŠ åŽþÿ‚ íŽþÿ >>> 82 90 ed 8e f6 ff 82 90 e5 8e f6 ff 82 90 e5 8e ‚ íŽöÿ‚ åŽöÿ‚ åŽ >>> >>> It seems serial_hardware is not transmitting same data. >>> Any help would be great. >>> Thank you. >>> >>> Cheers, >>> Filipe Santos >>> >>> On Sunday, May 15, 2022 at 6:57:39 AM UTC+1 Kiste wrote: >>> >>> Hi Filipe, >>> >>> If serial_software works with "const bit serial_sw_invert = true", then >>> serial_hardware should also work. serial_software supports the non-inverted >>> mode, the uart hardware in newer PICs also supports the non-inverted mode, >>> but the serial_hardware library does not yet support that mode natively. >>> >>> Have you tried single chars with time in between? >>> >>> forever loop >>> serial_hw_data="@" >>> delay_1s(1) >>> end loop >>> >>> This loop transmits a start bit and a single set data bit every second. >>> From the results you're seeing on the PC, the error might be narrowed down. >>> >>> Greets, >>> Kiste >>> >>> >>> Am Samstag, 14. Mai 2022, 22:58:28 MESZ hat flyway38 <[email protected]> >>> Folgendes geschrieben: >>> >>> >>> Hi to all, >>> >>> Have been using serial_software library with enough success until now. >>> Am coding for use a TTL-232R-5V-AI USB Cable to connect to computer. >>> Using serial_software library with invert bit activated, am getting good >>> results. >>> It all works good enough sending data to computer >>> The problem with this library is while receiving data from computer. As >>> soon as this funcion is activated in PIC code, the library locks in a loop >>> waiting for data. >>> So, started to migrate my code for use with serial_hardware library >>> instead, to avoid this lock. >>> But now I get Frame Error from COMM PORT with not usefull data, all the >>> time. Even if I invert data received. Have also tried different baud rates, >>> etc... >>> Can anyone help about this issue? >>> Thank you very much. >>> >>> Kind regards, >>> Filipe Santos. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "jallib" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jallib/ac896057-cc8b-40e2-9e84-5cc7d7843640n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/jallib/ac896057-cc8b-40e2-9e84-5cc7d7843640n%40googlegroups.com?utm_medium=email&utm_source=footer>. >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "jallib" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> >>> https://groups.google.com/d/msgid/jallib/1c5acd16-71a0-4b4f-b5a8-f156ebc81377n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/jallib/1c5acd16-71a0-4b4f-b5a8-f156ebc81377n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> >>> . >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "jallib" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> >>> https://groups.google.com/d/msgid/jallib/2841ae74-69b7-47ee-be97-6bee2a92cdb9n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/jallib/2841ae74-69b7-47ee-be97-6bee2a92cdb9n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> >>> . >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "jallib" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> >>> https://groups.google.com/d/msgid/jallib/7d84e3e6-3865-4d5d-9c1a-f8d125e72413n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/jallib/7d84e3e6-3865-4d5d-9c1a-f8d125e72413n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> >>> . >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "jallib" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jallib/1114301196.1951990.1652622400015%40mail.yahoo.com >>> >>> <https://groups.google.com/d/msgid/jallib/1114301196.1951990.1652622400015%40mail.yahoo.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "jallib" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jallib/GVXP195MB1637F8C203E2069FC8861EC5E6CC9%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM >>> >>> <https://groups.google.com/d/msgid/jallib/GVXP195MB1637F8C203E2069FC8861EC5E6CC9%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "jallib" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jallib/1514115999.1967130.1652628794740%40mail.yahoo.com >>> >>> <https://groups.google.com/d/msgid/jallib/1514115999.1967130.1652628794740%40mail.yahoo.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "jallib" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jallib/e2ba34a7-50da-42ab-b20c-4c861f08a423n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/jallib/e2ba34a7-50da-42ab-b20c-4c861f08a423n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "jallib" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/e1466126-db21-4b80-a992-bd31734a3042n%40googlegroups.com.
