It'll work on a 628.
Check out this thread
Instant Interrupts - Revisited
http://www.picbasic.co.uk/forum/showthread.php?t=3251
The first post shows where to get the files.
And the rest of the thread will answer many questions.
hth,
It'll work on a 628.
Check out this thread
Instant Interrupts - Revisited
http://www.picbasic.co.uk/forum/showthread.php?t=3251
The first post shows where to get the files.
And the rest of the thread will answer many questions.
hth,
DT
Thank you sir.
Well, after I read a group of posts I started to understand what your interest of introducing these new interrupts was. I am not very familiar with interrupts but I want to take advantage of this new approach. First I did was to try to play with your Blink program and at compilation time (16F628) I got an error: “Variable wsave3 position request 416 beyond Ram_End 335” I have look every where for an explanation of this error with no luck. Please, advice.
There is a section in the DT_INTS-14.bas file that has to be adjusted for the chip you are compiling for.
I wish I could make it automatic, but there's no way to do that.
For a 16F628, it doesn't have any General Purpose RAM in BANK3. So you have to comment out the wsave3 variable in this section.The 628 also has Access RAM at address $70 which can be accessed from any bank.Code:wsave var byte $20 SYSTEM ' location for W if in bank0 ;wsave var byte $70 SYSTEM ' alternate save location for W ' if using $70, comment out wsave1-3 ' --- IF any of these three lines cause an error ?? ---------------------------- ' Comment them out to fix the problem ---- ' -- It depends on which Chip you are using, as to which variables are needed -- wsave1 var byte $A0 SYSTEM ' location for W if in bank1 wsave2 var byte $120 SYSTEM ' location for W if in bank2 ;wsave3 var byte $1A0 SYSTEM ' location for W if in bank3 ' ------------------------------------------------------------------------------
So commenting everything and uncommenting the $70 variable will work too.
Either way will work ... take your pick.
Code:;wsave var byte $20 SYSTEM ' location for W if in bank0 wsave var byte $70 SYSTEM ' alternate save location for W ' if using $70, comment out wsave1-3 ' --- IF any of these three lines cause an error ?? ---------------------------- ' Comment them out to fix the problem ---- ' -- It depends on which Chip you are using, as to which variables are needed -- ;wsave1 var byte $A0 SYSTEM ' location for W if in bank1 ;wsave2 var byte $120 SYSTEM ' location for W if in bank2 ;wsave3 var byte $1A0 SYSTEM ' location for W if in bank3 ' ------------------------------------------------------------------------------
DT
I'll report to you. Thanks
Well, beautiful. I comment out the 3 wsaves and everything came out as planned. I tested the 628 on my breadboard and the led blinked as expected. After that triumph I load your Serialin (I called Parallel to Serial) program and compiled it. I got one error only
“Error [118] C:\program~1\mecanic~1\mcs\parallel~3 asm 200:Overwriting previous address contents(2007)” As always I try to find that error on the posts and I did but I don’t understand how to fix it. Thanks.
I think you've found just about every possible problem.
With the following advice from mister_e, I'm sure you'll reach the finish line.
http://www.picbasic.co.uk/forum/show...=6775#post6775
DT
I got it!!! It complied perfectly and now comes the hardware test. I’ll do the setup and let you know how it worked. I think the worse part is over. I thank you and indirectly to Melanie, Steve and many others that post their problems and solution in this forum. I want to learn all about these unique interrupts from the bottom up. I’ll be around here for some time. TimSeven
Great, and don't forget Joe S.
It's his serial backpack program.
DT
while it's alive..
Darrel, i've made changes as per your recommandation,
So, the skipchar label down here take care of characters not to be sent to LCD.
that works!
and then I had the *brilliant* idea to add something else...which failed.
I know we're, but not sure why.
Next I wanted to disable interrupt while I do my little LED dance at start, and send some message on the LCD.
It seems like the code will stop at > ; @ INT_ENABLE RX_INT; this seem buggy...
Do you see why I couldn't disable/enable INterrupts at start, or at that specific place?
I taught maybe i should put this in a sub routine?
Code:; @ INT_DISABLE RX_INT ; Ignore input at initialisation HIGH LedPort ' Some visual sign of life for the PIC Pause 500 LOW LedPort pause 50 lcdout $FE,1 'LCD INIT lcdout $FE,2 LCDOUT "LCD SERIAL - READY" PAUSE 300 ' Timeout for LCD to settle ; @ INT_ENABLE RX_INT ; this seem buggy... ' * * * * Main program starts here * * * * * * * * loop: For i = 0 to 10 ' Delay for .02 seconds (10*2mS) Pause 2 ' Use a short pause within a loop Next i ' instead of one long pause For i = 0 to 10 ' Delay for .02 seconds (10*2mS) Pause 2 ' Use a short pause within a loop Next i ' instead of one long pause skipachar: ; Will come back here if a char has to be skipped skipchar=0 ; reset the flag so next char could be displayed display: ' dump the buffer to the LCD IF errflag Then error ' Handle error if needed IF index_in = index_out Then goto loop ' loop if nothing in buffer endif GoSub getbuf ' Get a character from buffer if skipchar=1 then skipachar ; with goto up there, skipping display of the last read char LCDOut bufchar ' Send the character to LCD IF col > 20 Then ' Check for end of line col = 1 ' Reset LCD location LCDOut $fe,$c0,REP " "\20 ' Clear line-2 of LCD LCDOut $FE,2 ' Tell LCD to return home EndIF if ShowRTC=1 then LCDOut $FE,$D4,"RTC ACTIVED" EndIF GoTo display ' Check for more characters in buffer ' Subroutines ;Disable ' Don't check for interrupts in this section getbuf: ' move the next character in buffer to bufchar @ INT_DISABLE RX_INT index_out = (index_out + 1) ' Increment index_out pointer (0 to 63) ' Reset pointer if outside of buffer IF index_out > (buffer_size-1) Then index_out = 0 bufchar = buffer[index_out] ' Read buffer location if skipLCDComm>0 then skipLCDComm=skipLCDComm-1 endif ;Routine for buffering LCD commands if (GrabBkLt=1) then ; WE have signal to watch for value for LCD backlight next ; LCDOut $FE,$94,"BACKLIGHT set:<",#bufchar,">" ; for debug only HPWM 1,bufchar ,1250 ; Setting Pulse Mod to desired value ' Observe minimum FREQ for given OSC speed. 20Mhz is 1221Hz Low LedPort ; Debug only GrabBkLt=0 ; All is done, signal to close the loop skipchar=1 ; to skip displaying this char in main loop endif ;Following will trigger the routine up here on the next chr received ; but if skip if $fe has been called 2 shots ago if (bufchar=20) and (skipLCDComm=0) then ; 14h, trigger for special LCD command HIGH LedPort ; Debug only GrabBkLt=1 ; Signal to get the value of backlight level skipchar=1 ; ;to skip displaying this char in main loop endif ;Prevent value of 14h to be trapped for other command, we memorize previous call of $FE (254) if bufchar=254 then skipLCDComm=2 ; endif @ INT_ENABLE RX_INT Return
flipper_MD,
Are you a doctor, cause I've got this pain in my ...
Oh ... you're probably a porpoise doctor
Ummm no, I don't really see a reason for problems disabling at that point.
The closest thing to a problem I can see is that the GrabBkLt command will take over 3ms to display the LCD data ... 2ms for the command and 20+ chars at 50us delay = 1ms.
3ms by itself shouldn't be a problem, and it should only happen infrequently, but it's the closest thing to a problem I can see at first glance.
What are the symptoms?
DT
Apparently, It will lock the PIC from receiving commands, if external data is received before it enter the main loop.
Visually, It will flash the LED, show "LCD Serial - READY", but stop there and not respond.
may I suggest Dr Pepper ?
Sugar is food for the brain
Yes Mr. Taylor I can't forget Joe S. as this backpack originator, I am sorry.
Well, I am almost there. I had some lines modified to the program to adapt it to my hardware. I modified:
DEFINE LCD_LINES from 4 to 2. ‘My LCD is 2X20
DEFINE OSC from 20 TO 4 ‘My 628 is 4 Mhz
DEFINE HSER_SPBRG from 32 to 25 ‘My 628 is 4 Mhz
The rest is unchanged.
When I turned it on I got the “Your text goes here” message and then over it a second later I got “Clearing display buffer” error. It’s something else that I need to change on the program to prevent the buffer to overrun? Thanks.
Change TXSTA to ...9600 baud at 4Mhz needs the BRGH bit set to 1 with SPBRG = 25.Code:DEFINE HSER_TXSTA 24h
DT
I did the change on “DEFINE HSER_TXSTA from 20H to 25H and tested with same error. I restored all the DEFINES back to its original values (DEFINE OSC 20, DEFINE HSER_TXSTA 20H, DEFINE HSER_SPBRG 32) and used this time a 628-20 Mhz chip. I got the same error “Cleaning Display Buffer”. Any suggestion?
Maybe it was just a typo, but TXSTA should have been changed to 24h, not 25h. But it probably wouldn't matter.
And when you say "and used this time a 628-20 Mhz chip"...
Do you mean that you used a 16F628 with a 20Mhz crystal and two 15-33pf capacitors?
DT
Tim,
are you sending data to the screen to see if the message will clear out?
I always see the clearing display message at start, but everything works fine when I send data (without my silly Disabled Interrupt trial..of course).
Yes, was a typo I mean 24h. Yes, I used a 16F628-20 Mhz. I changed the crystal but not the caps, sorry. Mr. Flipper_ND, when I received the error I thought I shouldn’t go on, but I think that you got a point there, I’ll. First I’ll do the test with the two 15-33 pf caps in place and next test sending some data. I’ll report to both of you. Thanks.
Let me report to both of you: I changed the caps and same error. I send the serial data and received it but unreadable and there is no clear screen neither. The program I am using reads as:
PAUSE 1000
SEROUT PORTB.1, 4, [254, 1] ‘Clear the screen
SEROUT PORTB.1, 4, [“ABCDE”]
END
I don’t know why but the PBP 2.50A compiler doesn’t accept
SEROUT PORTB.1, N2400, [254, 1]. (Bad Expression) doesn’t like the N2400. I don’t know if there is a distinction between the N2400 and the 4 alone.
I have spent hours investigating the hardware and the software for any error but find nothing bad. There may be a test program to check the backpack program.
BTW, To be able to write and compile this four lines “text sending serial program” I had to restore the 16F628 .INC file back to it’s original text. (Take the (;) out).
Any ideas of what may I doing wrong? Thanks.
The standard USART requires "TRUE" levels.
N2400 is "Inverted".
Use mode 0 (T2400).
And to use the N2400, T2400 T9600 etc.
Code:INCLUDE "modedefs.bas"
DT
I did the Include "modedefs.bas" and also sent all kind of modes from 0 to 11 with different characters on the display but none of them good. What I thought would be the simplest trouble shooting became the hardest for me. I don’t know what to do next. Thanks
Me neither.I don’t know what to do next.
DT
Thank you any ways. I'll keep reading post about it and see what ideas comes up. Thanks to all of you. TimSeven.
Hi Guys
I was having trouble the other days with serial stuff and Bruce(rentron) pointed me at using PIC to PIC for testing.
So I setted up a cute 12F683 running it's internal 8mhz osc (then you plug only Power+Ground, it's running), and have a little program sending:
- TRUE 9600 on one pin with serout,
- INVERTED 9600 on another with serout,
- and debug at 38400 on another one, constantly in a loop.
Validate that your computer can see the data(with a max232) and then you should be able to use it to feed directly a PIC.
um, let me grab that proggie
Hi, everything is working fine. I got the backpack working perfectly as I always wanted. I am very thankful mainly to Joe s. the promoter and secondly to Steve , Melanie and Mr. Darrel who perfected the program and gave me so much help. I apologize to all because to my bad English, I am from the Caribbean and English is my second language. This serial backpack will serve for my experimental board. I was using a parallel 2X20 but too many pins were required. Now I only need one pin. Thanks to all of you again. This forum, it's great place to learn !!!
Stay Tuned for an update. I figured out how to give this multiple baud rate and still use the USART, I have to get a new ISP first though as I am not internet enabled at home right now.
If you do not believe in MAGIC, Consider how currency has value simply by printing it, and is then traded for real assets.
.
Gold is the money of kings, silver is the money of gentlemen, barter is the money of peasants - but debt is the money of slaves
.
There simply is no "Happy Spam" If you do it you will disappear from this forum.
ok, i'm tuned now. where to???
I must say I did tried running at higher speed and from the experiments, I concluded that 19,2 kBaud was about the fastest I could run without troubles.
57K gave very odd results...
Someone promoted this thread to an article. I promised some additions and if you go to the article I have posted the code for this backpack with selectable baud rate and it still employs the hardware USART. The article is here: http://www.picbasic.co.uk/forum/cont...rial-backpacks
If you do not believe in MAGIC, Consider how currency has value simply by printing it, and is then traded for real assets.
.
Gold is the money of kings, silver is the money of gentlemen, barter is the money of peasants - but debt is the money of slaves
.
There simply is no "Happy Spam" If you do it you will disappear from this forum.
Bookmarks