| ??? 11/19/11 22:13 Read: times |
#184820 - But what delays did you try before original release? Responding to: ???'s previous message |
Mahmood Elnasser said:
Yes I actually tested with shorter delays than 1ms and they didn't work, 1 msec or greater delays worked for 19200 baud rates. I didn't test other baud rates. I think you missed my point. What delays did you test with two years ago? What safety margin did you add in the original code based on your testing? It's this safety margin that is intended to be the protection from problems after delivery. I used the settings and equations for baud rate in the datasheet and verified my results with picbaud calculator and error was 0.16% at crystal frequency of 4MHz. Could this be the reason? No. That baudrate is fine. I wrote my post because I don't think the chip is at fault. Either the original program was all the time at the limit. Or the original design contains some parts that is affected by the actual values sent or how you produce the value to send. Maybe some other part of the code that slows down because of the actual data values, resulting in an extra I2C interrupt or something interleaving with the UART communication. That a switch of master didn't help is one further indication that it is an issue with the software. Yes, I do make beautiful mistakes too. Like a program I wrote many years ago using serial communication. I then lifted the serial code to another program. Then a third program. Maybe once/year I got a comment about people having problem using the program if selecting a non-existing serial port, but neither me nor anyone else at work could reproduce. Having many hundreds of installations and one (unreproducible) error reported / year was quite a good track record. Until I - after maybe 5 years - used the code in yet another program and suddenly got stuck myself. The program tried to retrieve an english resource string to report that it couldn't open the serial port. If not using an english installation of Windows, it failed to retrieve the resource string. Then it tried to fetch an english resource string for the error of not being able to load any resource string. It obviously failed that too, quickly recursing through all stack space the OS could manage to map in. |
| Topic | Author | Date |
| NXP Promises ARM Cortex-M0 in DIL Package! | 01/01/70 00:00 | |
| Amazing! I thought DIL was DEAD. | 01/01/70 00:00 | |
| Me too! | 01/01/70 00:00 | |
| Hmm.. | 01/01/70 00:00 | |
| maybe | 01/01/70 00:00 | |
| dsPIC is a waste of time | 01/01/70 00:00 | |
| We Await The Results... | 01/01/70 00:00 | |
| Which one(s)? | 01/01/70 00:00 | |
| two | 01/01/70 00:00 | |
| Why so long? | 01/01/70 00:00 | |
| Well | 01/01/70 00:00 | |
| Two years | 01/01/70 00:00 | |
| Answers | 01/01/70 00:00 | |
| But what delays did you try before original release? | 01/01/70 00:00 | |
| shorter delays | 01/01/70 00:00 | |
| good thinking | 01/01/70 00:00 | |
| Can't get the error | 01/01/70 00:00 | |
What changed? | 01/01/70 00:00 | |
| Seems a little harsh | 01/01/70 00:00 | |
| Never blame manufacturer without proofs | 01/01/70 00:00 | |
| Proven Product Syndrome | 01/01/70 00:00 | |
| My response ... | 01/01/70 00:00 | |
| No Offense | 01/01/70 00:00 | |
| What I Do and Not Do | 01/01/70 00:00 | |
| NXP are mistaken | 01/01/70 00:00 |