'm writing a code where a intel hex-80 file is send through the hyperterminal..in my code,i decode the hex file,extract the data and write it onto the flash memory....the problem is when i type the hex file through hyperterminal,its workin fine...bt whn i send a file ,many charcaters are missing...pls help...the baud rate is set as 9600....workin on p89lpc915 on keil....
... the one between your ears - you need to think about the symptom(s) you are seeing; think what could be causing them; etc, etc,...
In this case, what do you think is the key difference between typing manually and having a computer send a whole file?
How do you think this would affect the microcontroller?
Hint: What are the constraints that it imposes on the microcontroller to receive and process each character...?
i tried setting the baudrate to 2400...but then nothin s transmitted/receivd...:O
If it works when you type manually, then it can't be the baud rate that's wrong - can it?
Again: think what is the key difference between typing manually, and having a computer send a whole file? It's not the baud rate, is it?!
Think: How would this affect the microcontroller?
what constraints..??help me out plssss...
Are you an extremely fast touch typist? 9600 baud means an ability to send around 1000 characters/second. How many characters / second can you type?
You need to think - for yourself!
Start with the basics: what is the key difference between typing manually, and having a computer send a whole file:
How fast can you type? ie, how long does the microcontroller get between each character when you type manually?
How fast can a computer send? ie, how long does the microcontroller get between each character when the computer sends?
obviously the computer sends super quick than me typing...but wat can i do abt it???if i code a program to simply receiv n transmit a file,it works fine...but when i add the data decoding part,certain characters start missing...i cant use a receive ISR,cos then my flash memory writing part dosnt work since interrupts are disabled there.....
Exactly! Well done!
"but wat can i do abt it???"
Well, you need to keep thinking! These are exactly the types issues that you will always need to address as a fundamental part of any programming task!
Three choices should be obvious:
1. Ensure that you process each character quickly enough to be ready before the next one arrives;
2. Provide some way to quickly store the data as it arrives, so that you can process it later, at your leisure. This is known as buffering.
3. Devise some scheme - or "protocol" - so that the microcontroller can tell the PC when it's ready to receive more data. This is known as Flow-Control or Pacing.
i cant use a receive ISR,cos then my flash memory writing part dosnt work since interrupts are disabled there.....
This is the key. You should definitely continue to use interrupt based serial communication. Either collect all the hex data in RAM first so you do not have to disable interrupts to program, or, of you have limited RAM, write your own application that sends serial data via your own protocol, so that the microcontroller can say: "stop sending until I am done programming the data I have collected so far. I'll let you know when I'm ready". There are other solutions possible, of course.
I have just noticed that Andy post is very similar to mine. I guess we where writing our posts at the same time (it is not plagiarism - I swear!). Either way OP, stop panicking. In your professional life you are going to have to deal with similar and presumably much more complicated situations and problems. Get ready, use your head and stay cool!
Absolutely!
There are two key lessons that you need to learn from this:
1. Timing is important!
2. Blindly sending data and just assuming that it arrives complete & unaltered is not a good plan!
And, of course, the need to think!
While it is certainly possible, and might be appropriate, to develop a custom protocol, you should first invstigate what standard protocols are available.
I suggest that you look carefully at XMODEM: it is a simple protocol - well within the capabilities of a small microcontroller - and is (almost) universally supported by terminal applications - which obviates the need to write your own application. It is also widely supported by comms libraries if you do want/need a custom app...
wel my boss is averse to the idea of using a flow control...i was thinking of continue using the interrupt-driven reception and when the control shifts to flash memory writing function(wherein interrupts are disabled),use the polling method to continue receiving...is that possible???
In that case, get your boss to suggest a suitable method of doing this!
In the list of 3 options that I gave earlier, note that "flow control" is used as a general term for any form of "pacing" - not just the RTS/CTS ("hardware") or XON/XOFF ("software") terms used by Hyperterminal.
As already noted, protocols such as XMODEM are self-pacing
Anyhow, If you really "can't" use any form of pacing, that obviously just leaves you with the other 2 options:
2. Provide some way to quickly store the data as it arrives, so that you can process it later, at your leisure. This is known as buffering
"i was thinking of continue using the interrupt-driven reception and when the control shifts to flash memory writing function(wherein interrupts are disabled),use the polling method to continue receiving...is that possible?"
How do you think that would help? What problem does it actually solve?
You still don't seem to have understood the problem yet! Look again at my post of 9-Jun-2011 07:31 GMT - and think about it!
You don't appear to have learned them; here they are again - note particularly number 2: