Your picture is hot enough...
Melanie>>I'm told I look better in real-life than in the photo...<<
If that is so....I am moving to your country...:}
Dwayne
Your picture is hot enough...
Melanie>>I'm told I look better in real-life than in the photo...<<
If that is so....I am moving to your country...:}
Dwayne
Ability to Fly:
Hurling yourself towards the ground, and missing.
Engineers that Contribute to flying:
Both optimists and pessimists contribute to the society. The optimist invents the aeroplane, the pessimist the parachute
Pilots that are Flying:
Those who know their limitations, and respect the green side of the grass...
yup...i need the interrupt to multiplex the array. the whole array serin's at more than the interrupt interval and yes...there's a small flicker
building my own usart code feels like an oncoming nightmare...unless you tell me otherwise....
what do think about using serin2 and implementing the flowpin. Will that walk me through the array input even if it is broken by an interrupt? it also allows for a higher baud.... Does the flowpin go down between items?....
...garret
...and there I was deliberating over that piccy or the one in the tight-leather catsuit with thigh-high boots and chromed spikey heels (work tax-deductable as they have low ESD)...Your picture is hot enough...
You're caught between a rock and a hard-place... if your interrupt has priority over PICBasic then you WILL lose bit synchronisation and your incomming Data stream will corrupt. If PICBasic has priority over your interrupts then your display will flicker. Take your choice.
The professional option is Hardware USART. It's quite simple really... poll for an incomming byte... if it's there, go grab and store into a buffer, if not, go to your LED routine. At 9600 baud, a byte will arrive every 1mS (give or take), plenty of time to grab and do something with it... you only need to devote a few uS to this task every millisecond... the rest of the time is yours to do with as you wish... with software async input, you need to devote 100% of that time to bit-bang the result.
good morning mel and all,
So....setup the harware usart using pbp hserout command...done....
initiate usart receiver...... but don't use pbp hserin command...right?
It would seem that using the hserin command takes me back to software control and timeout periods.
So....i poll pir1<5> to check for reception myself
read the rcreg into a variable
and go back to poll
voila..... it's the question of not using pbp hserin that i'm after. yes...no....?
We're just talking RECEIVE here...
Avoid SERIN, SERIN2, HSERIN, DEBUGIN etc
all these end up catching Data out of your control...
Refer to the PICs Datasheet as to which flags within which registers pop-up anouncing that goodies have arrived.
The nice thing is that there's a small buffer in the PICs USART... if your program is a bit lazy picking up data, then no worries, it just holds it for you and stacks another byte behind...
thanx for everything mel. I'm off to jam it together.
-first i'm going to try and poll for an arrival and then use hserin...knowing that there is something there...shouldn't lose any time.
-Second, i'll try polling and then go straight to the registers and transfer in...no hserin. Mind you here there is no control on assignment to variables and control bytes. I liked what you showed me the other day with an ending confirmation byte...
-third...everything working well....place the usart reception bit into interrupt status and run it as an interrupt....
mel...u'sart the bestest...garret
Bookmarks