Read the newbee threads, 16F877A no go.

Hi, I have read the threads here dealing with newbees (that's me) getting the PBP compiler (2.46 in my case) running. No fix so far. I tried making smaller programs, down to the Blink.bas in the sample dir. I have even tried the short example code provided in a post here.
DEFINE OSC 12
TRISB.2=0 'define PORTB.2 as output
start:
Toggle PORTB.2
PAUSE 1000
goto start
I have two of the Momentumfire developement boards (LCD, serial, Keypad, pots, LED numbers, 11.59 MHz), I mention these because both do exactly the same. When I compile to a .hex file (using PM or MPASM 7.1) it appears to go without errors. Then I program the hex file into the part using a Hi-Lo ALL-11
multiple IC type device programmer. When the 16F877A is placed into the circuit nothing happens.
I have read the contents of the part back into the programmer's buffer, and compared it to the printed listing of the .hex file. No problems found.
I copied the original (Dev board exerciser) back into the 16F877A and it runs fine. I can also edit minor changes to this program's hex code in the ALL-11 buffer then rewrite it, this too runs fine. I include this to indicate the programmer is working.

I was able to compile the blink.bas file for the 18F6520, and using CCS's ICD-40U download and run it (albeit very slowly) in a test PWB that just has a 32 KHz clock osc, and a regulator witha reset pulse. It conplained about a couple configuration bits, but ran.
After many hours I'm pretty underwhelmed with this so far, niether the PBP manual nor Chuck Hellebuyck's book do a good job of getting someone who doesn't already know it started with the tool and environment.
Any help or suggestions would be very welcome. If you wish to write my email is: the current year @bobby.net in the form of [email protected] (let the bots figure that one out.)

Thanks,
Bobby

Bobby,

I guess it is a matter of setting the configuration bits.

with a 12 MHz crystal you should select HS Oscillator.
and do you have a 4k7 pullup on the MCLR Pin?

have a look at this Thread

Hi Ralph, Thanks for taking the time to respond.
I do have the pull up in, and saw Melanie's post on configuration fuses.

Her thread wasn't completely clear to me as to where those lines would be entered. The Microcode Studio doesn't provide for switches, nor did the MPASM I tried selecting within Studio.

I did see another thread on editing the .inc file, and I changed it from xt to hs in two places. Hoping that was what he had in mind.

From some other posts it appears that the configuration switches end up embedded in the .hex file. I hope this is correcct as it should be easy to read them out of the file resulting from compiling the short example program in the first msg. I just have to find out what the bits (placement) of that line is supposed to read.

I'm ok with BASIC, but trying to learn PICs and PBP.


Best Regards,
Bobby

Looking further into the configuration bits only confuses things more. From Melanie's thread on setting them up, I looked at the .inc for entries matching the datasheet's Special Features section. The datasheet calls out many configuration bit switches that are not addressed in the .inc file.
I'm really hoping these bits are not important to be set or cleared, otherwise it doesn't inspire confidence. I still have little idea on what the configuration bits should be set to. Learning more every day...

Bobby

Did you read the whole thread??? I post some info myself too
here

So can we assume that something is working now on your side???

The short test program included in my first email will run now.
A number of changes were made, including editing the \PBP\xxxxxx.inc file.
Also turned off the watchdog timer, I may turn it back on to check effect.
Somewhere along the way I've hosed up the MPASM configuration and now
will have to get it working again. But hey this is a learning process right ?

Thank you for the help.
Bobby

I switched the wdt_ configuration back to on, and the toggle program still runs.
The larger program even executes, more or less.
The less part is that I'm required to press the reset button to get my program to run, where the original development board firmware executes on powerup.
Any suggestions where to start looking ?

Thanks,
Bobby

ARGH, are you using some kind of bootloader??? if so add
DEFINE LOADER_USED 1

Thanks for responding.

No, I'm not using a bootloader.

I'm really surprised how poorly this has gone. There are a couple of guys at work who program PICs, they program strickly in assembly. I wondered why they went through all the trouble, at least when assembly wasn't actually required for speed or code size.

The answer is, because the higher level tools aren't ready for prime time.
I can't believe all the convoluted ways to do things I've looked up, which also happen to not work right or as often as not don't work at all.

Sure this is frustration talking, but changing DEFINE OSC 12 to DEFINE OSC 11 (actual clock is 11.0592 MHz) results in 8 assembler errors, minor variations of:
Error c:\pbp\pbppic14.lib 2827 : [225] Undefined Symbol 'PAUSEUS'

and still no readable serial characters (at least with any communication protocol from this planet).

And who's idea is that of a useful or appropriate error msg ?

Bobby

Unfortunately you can't use DEFINE OSC 11

all available crystal speed are 3(3.58) 4 8 10 12 16 20 24 25 32 33 40

so this is one part of your problem. You'll use a DEFINE OSC of 10 or 12. Yep, all the timing will have to be adjusted by yourself but it's not a so much big deal.

to make it work properly, i'll suggest you use the internal USART modules and the dedicated TX/RX pins. Try something like

Code:

---

DEFINE OSC 10
DEFINE HSER_RCSTA 90h
DEFINE HSER_TXSTA 24h
DEFINE HSER_SPBRG 71 ' 9600 Bauds @11.0592 MHZ
DEFINE HSER_CLOERR 1

Start:
      Hserout ["Serial comm test @9600 bauds",13,10]
      pause 500
      goto start

---

about now???

> the higher level tools aren't ready for prime time.

Many hundreds if not thousands of PICBasic users would probably take issue with that statement. My royalty cheques are a reminder that PICBasic works real well. A little time getting to know the product properly will be beneficial.

> but changing DEFINE OSC 12 to DEFINE OSC 11 (actual clock is 11.0592 MHz) results in 8 assembler errors

DEFINE OSC 11 is an illegal setting. I refer you to my previous statement of getting toknow the product.

> The datasheet calls out many configuration bit switches that are not addressed in the .inc file.

For 18F series PICs you will be using MPASM Assembler and not the PM Assembler. You need to locate the appropriate INC file located with MPASM. All the valid Configuration Fuse defines will be located theirin which can be cross-referenced with the PICs Datasheet.

Hi again.
I'll try that, saw similar code to that in another place. One of the interesting things was recalling reading that decimal could be written normally ie. 255, bin used %11111111, hex used $FF, but I didn't think 24h was acceptable (in this flavor of picdom anyway).

I did try:

DEFINE HSER_BAUD 9600
DEFINE HSER_TXSTA 36

Start:
Hserout ["Bob Port Test",13,10]

END
'--------------------------------------

And I tried commenting those out, including the defines, changing PC baud to 2400 and using:

' Read and write hardware USART

B1 var byte

' Initialize USART
TRISC = %10111111 ' Set TX (PortC.6) to out, rest in
SPBRG = 25 ' Set baud rate to 2400
RCSTA = %10010000 ' Enable serial port and continuous receive
TXSTA = %00100000 ' Enable transmit and asynchronous mode


' Echo received characters in infinite loop
loop: Gosub charin ' Get a character from serial input, if any
If B1 = 0 Then loop ' No character yet

Gosub charout ' Send character to serial output
Goto loop ' Do it forever

' Subroutine to get a character from USART receiver
charin: B1 = 0 ' Preset to no character received

If PIR1.5 = 1 Then ' If receive flag then...
B1 = RCREG ' ...get received character to B1
Endif

ciret: Return ' Go back to caller

' Subroutine to send a character to USART transmitter
charout: If PIR1.4 = 0 Then charout ' Wait for transmit register empty

TXREG = B1 ' Send character to transmit register

Return ' Go back to caller
'--------------------------------

And a few others that probably not worth including here.
I'll let you know how the code you sent works.

Best Regards,
Bobby

Hi,
I really don't want to offend, especially having recently contributed to at least one of the royalty checks, but buying and using have so far been different animals.

I still hope to do something useful with PICs. Thank you for responding.

Let me help illustrate my frustration.

>DEFINE OSC 11 is an illegal setting.

Where does any documentation say that ?

I probably would have noticed if somewhere it said:
THE ONLY ACCEPTABLE CLOCK SPEEDS ARE, 3(3.58) 4 8 10 12 16 20 24 25 32 33 40

The datasheet calls out many configuration bit switches that are not addressed in the .inc file.

>For 18F series...

For the 16F877A, the datasheet calls out many configuration bit switches that are not addressed in the c:\pbp\16F877A.INC file, when using PM.

I only used MPASM for a short while when trying to get the toggle program to work targeting an 18F6520, I didn't need to change MPASM .inc file to get it to load and run. It loaded with some minor complaining about configuration bits, the MPASM and the 18F test aren't the issue currently.

It's trying to get all of an 16F877A based development borad's basic functions exercised to have a basis to develop custom applications.
I have gotten a program to run, the LCD to display, a 7 segment LED to work, and 3 analog channels to read.
I haven't got the PIC to start without having to press the reset again, when the original program that came in the PIC starts fine, and I haven't been able to get a readable serial port output, nor have I seen the input function work.

Best Regards,
Bobby

i always use MPASM too. As i often switch for 16XXX to 18XXX i don't want to spend time by switching PM to MPASM and such.

So just comment the PBP default fuse as i described in the FAQ post and try this.

Code:

---

@ __config _HS_OSC & _WDT_ON & _PWRTE_ON & _BODEN_ON & _LVP_OFF                 
    ' XT (4Mhz) oscillator
    ' Enable watch dog timer
    ' Enable power up timer
    ' Enable brown out detect
    ' Disable low voltage programming
   
DEFINE OSC 10
DEFINE HSER_RCSTA 90h
DEFINE HSER_TXSTA 24h
DEFINE HSER_SPBRG 71 ' 9600 Bauds @11.0592 MHZ
DEFINE HSER_CLOERR 1

PAUSE 500 ' kind of start-up delay... could be remove or reduced
Start:
      Hserout ["Serial comm test @9600 bauds",13,10]
      pause 500
      goto start

---

For the available crystal speed... it's hidden in the PBP manual in appendix with all the available DEFINE at the end of the manual AND/OR in the Help file of MicroCode Studio.

And the last thing, just be sure you program with the right PIC model 16F877 is not the same as 16F877A. But as another program work... that couldn't be a problem.

Hi Steve,
You are a very bright fellow, and much more helpful than a bunch of dubious sample programs and not very clear books. At much more reasonable price too.

Suppose I'm spoiled by how long the 8031 based parts and tools have had to refine their efforts. But it shouldn't be that hard to write an example of using a command, a list of what the allowable varibles are, and what each effects.

To paraphrase, there are a lot of learning opportunities here.

Best Regards,
Bobby

Quote:

---

Originally Posted by BobbyA

Hi,
>DEFINE OSC 11 is an illegal setting.

Where does any documentation say that ?

I probably would have noticed if somewhere it said:
THE ONLY ACCEPTABLE CLOCK SPEEDS ARE, 3(3.58) 4 8 10 12 16 20 24 25 32 33 40

---

See PBP Manual Appendix B "Defines"

EDIT:
ok, Steve was faster (as most of the time)

I still stand by the comment that 8 variations of:

Error c:\pbp\pbppic14.lib 2827 : [225] Undefined Symbol 'PAUSEUS'

Is just a goofy error msg for having selected an illegal clock speed.

Bobby

I can agree. It should be something like illegal crystal speed definition but, once you know the problem source... it will never happen again. Well i guess.

Quote:

---

Originally Posted by NavMicroSystems

See PBP Manual Appendix B "Defines"

EDIT:
ok, Steve was faster (as most of the time)

---

Hi Ralph,

Actually I did read quite a bit before coming to the site and forums for help.

The less comprehensive the books the more room for interpetation.
Does:

DEFINE BUTTON_PAUSE 10 mean that only 10 ms is the acceptable period.

DEFINE HSER_TXSTA 20h mean that 24h is an illegal number.

DEFINE OSC 4 mean that 3(3.58) 4 8 10 12 16 20 24 25 32 33 40 are the only acceptable numbers.

All of these are from the appendix you mention.

Point of this is until you know the tools or the manual tells you, you really won't know if the tool calculates the intervals from the number you enter or looks it up from a table, or something else completely. Or can only handle integers for that matter.
I do appreciate the help though.

Best Regards,
Bobby

Quote:

---

Originally Posted by mister_e

I can agree. It should be something like illegal crystal speed definition but, once you know the problem source... it will never happen again. Well i guess.

---

Hi Steve,

I'd be willing to make a small wager, perhaps a drink, that if another assembler were selected the same mistake would produce a different error.
Call me a cynic but I'll go double or nothing that it's equally obsure...

BR,
Bobby

you know, in ALL programming language, error message are often helpfull but often they wouldn't point you the exact line or part of code where the error is. It's amazing what a missplaced or missing ENDIF, WEND, Variable declaration could do also :)

here's a reaally short example

Code:

---

b1 var byte

I2cread PORTB.0,PORTB.1,0,0,[b1]

---

try this as is. Without anything else It compile O.K right ???

Now remove the first line and compile the code and see what's happen :)

ERROR Line 3: Expected '['. (a.bas)

Quote:

---

Originally Posted by BobbyA

...The less comprehensive the books the more room for interpetation.
Does:

DEFINE BUTTON_PAUSE 10 mean that only 10 ms is the acceptable period.

DEFINE HSER_TXSTA 20h mean that 24h is an illegal number.

DEFINE OSC 4 mean that 3(3.58) 4 8 10 12 16 20 24 25 32 33 40 are the only acceptable numbers.

All of these are from the appendix you mention.

---

I agree,
in some things the Manual is not very clear.

The OSC Table is mentioned in Section 5.51 as well without clearly telling you these values are the only ones to be used, but it refers to the "Section on Speed".

and
Section 7.1 "How fast is fast enough" clearly says:

The acceptable oscillator definitions are...

Quote:

---

Originally Posted by BobbyA

I'd be willing to make a small wager, perhaps a drink, that if another assembler were selected the same mistake would produce a different error.

---

For sure, different systems produce different (nonsense) Error Messages.

The best one I have ever seen was:

A Nonexistent error has occured in Module xxxxx at Address yyyy

(Guess what: It was Intel Hardware running a Microsoft OS . . .)

Hi Ralph, I sit corrected, it does say somewhere the "acceptable clocks speeds are". Although in my defense you didn't find it first time either.

Steve, My favorite error occurs on a PC running MS too. If you remove the keyboard the error on POST is: Keyboard bad or missing, press F1 to continue.

By the way adding the other configuration switches to the .inc file didn't resolve the need to press reset to get the program to run. Still learning.

BR,
Bobby

> For the 16F877A, the datasheet calls out many configuration bit switches that are not addressed in the c:\pbp\16F877A.INC file, when using PM.

Many? Name just one. Every item in the Configuration Word Address (Datasheet Register 14-1) is replicated in the PICBasic INC file. Try looking in \pbp\inc\M16f87XA.INC.

If you correctly read the FAQ, I wrote...

Quote:

---

3.a. When using MeLabs default (PM) Assembler

Open up the PBP directory, and in it you will find an INC subdirectory. Opening that up and you'll see a heap of files. Find the Mxxxx.INC file for the PIC you're interested in... (example M12F675.INC). If you can’t locate your exact PIC, it might be listed under a family of PICs that share the same settings (example chose M16F62X.INC if you need the settings for a 16F628).

---

Hi Melanie,

As I said I'm a newbee to PBP, and it's still not clear to me the purpose of the c:\PBP\INC\M16F87xA.INC vs. the C:\PBP\16F877A.INC file.

I do know the suggested fix was to edit the xt_osc to be hs_osc in light of the clock speed used, and to check the Special Features section of the datasheet. While in the PIC datasheet I noticed there were other configuration bit options that didn't have entries in that file.
So I stand by the statement, "the datasheet calls out many configuration bit switches that are not addressed in the c:\pbp\16F877A.INC file, when using PM."

Maybe they don't need to be there, I'm not well versed yet on the effect each configuration bit has on PIC performance. I have to assume if they were not included in this file they are not critical for simple functioning, same with an initial set or cleared condition. This may yet lead me to grief.

BR,
Bobby

Going through the forum posts, I encountered the same problem as in Post#21 above.

Here is the simple code trying to write to DS1307.

Code:

---


Start:

I2CREAD PORTA.3,PORTA.2,$D0,0,[0,0,0,0,0,0,0]

GOTO Start


END

---

I get;
ERROR Line 16: Expected '['. (Untitled8.pbp)
ERROR Line 16: Expected ']'. (Untitled8.pbp)

No variable or alias; just direct values...

What is the cause of this issue?
me?


Thanks.
-------------

Aw c'mon Sayzer, that's a no-brainer...

Too much wine, women and song this festive period...

You're trying to READ from a device, and then attempting to store that data into a series of CONSTANTS??? Maybe that's where CONSTANTinople comes from...

I prescribe a large mug of Turkish coffee and a code revision to something like...

Code:

---

        dA var BYTE
        dB var BYTE
        dC var BYTE
        dD var BYTE
        dE var BYTE
        dF var BYTE
        dG var BYTE
       
Start:

        I2CREAD PORTA.3,PORTA.2,$D0,0,[dA,dB,dC,dD,dE,dF,dG]

        GOTO Start

        END

---

Alternativelty swap IC2READ with I2CWRITE if you are really intending to WRITE.

Happy Holidays everyone!

Quote:

---

Originally Posted by Melanie Newman she who prescribes a large mug of Turkish coffee.

Alternativelty swap IC2READ with I2CWRITE if you are really intending to WRITE.

---

What can I say?

I wanna cry :'(


------------------------

Quote:

---

Originally Posted by BobbyA

The less part is that I'm required to press the reset button to get my program to run, where the original development board firmware executes on powerup.
Any suggestions where to start looking ?

Thanks,
Bobby

---

Hi Bobby A,
I agree with you about the books and manuals ability to convey everything a newbie needs to learn, they basicly blow! This forum is very helpful, very many smart people here!
For the problem above try putting a capacitor of say 1uf from the reset pin to ground. the time it takes to charge through the resistor you have going to B+ will allow the PIC to stabalize on start up. It seems some individual pic chips need this, I do not know why . . . maybe est damaged? Just curious are the chips you are using samples?
JS

Kind of late responding, but the forum just sent out (in Dec) an email notice there were 4 post to the thread (last in Aug ?). Procrastinator club anyone ?
Anyway, it's not ic specific since the original demo program that came with the board can be reloaded (external device programmer) into the exact same ic and it will run from power up. But the PBP compiled program does not start to execute until the reset button is manually pressed.
I don't know what the real cause was, eventually I chucked the board, PBP, and Hellebuyck's book in a drawer, and things got better.
Cheers, Bobby
PS. Royalty checks only prove people bought it, not that they found it useful.

> Procrastinator club anyone ?

Since nothing had been heard over this time I for one assumed your problem was solved.

This year marks six years since I started playing with PICs and PBP. Three hundred designs later (averaging one a week - and if it had a PIC in it, then it was driven by PBP) and close to a million PICs shipped, I have to admit that whether folks found the products useful or consigned them to land-fill that I really don't care.

In all that time, I've never had a customer return that was attributable to design, manufacturing or component defect. I put this down in the main that some of the products are large and heavy >2000kg and Mr Postman just can't fit them through the letterbox. But if they end up useful as boat-anchors, then that's still a success in my book.

What I can say with absolute certainty is that the PBP component works - as do the PICs. That leaves a failure to understand hardware, designs, not reading Datasheets or Manuals or defective logic in coding. A look on the kind of posts on this forum tells you that this accounts for 95% of help requests. PICs only need three things to make them work, POWER, RESET and CLOCK (OK, and a half-sensible program too). I don't know your Development Board, but if you can't even get a simple LED to blink in order to verify that those three conditions to make the PIC run have been met, or have the knowledge to determine which of those three are causing you grief, then chucking everything in a drawer and concentrating on watching Bonsai grow is the way to go. That may be a little strong language for this festive season (even if it is intended in jest), but seriously, PICs will do one of two things for you, they'll either make you very rich, or cause you to lose all your hair. I'd rather everyone was in the former category than the latter - and the secret to making everything work is contained in this paragraph.

Quote:

---

Originally Posted by Melanie Newman

...
they'll either make you very rich, or cause you to lose all your hair...

---

I see you have hair, so have you become rich, very rich or richer?

Also, all things you said above would look good on resume.


---------------------

>> all things you said above would look good on resume.

"I have to admit that whether folks found the products useful or consigned them to land-fill (or used them as boat anchors) that I really don't care."

Yup... that kind of attitude looks real good on the CV!

> I see you have hair, so have you become rich, very rich or richer?

I get invited to all the best parties at the Bank... ...having a skin-tight leather Catwoman outfit with chrome-plated spikey high heels and a passion for dancing on tables probably helps... try it with your Bank Manager and let me know...

Quote:

---

Originally Posted by Melanie

> Procrastinator club anyone ?

Since nothing had been heard over this time I for one assumed your problem was solved.

This year marks six years since I started playing with PICs and PBP. Three hundred designs later (averaging one a week - and if it had a PIC in it, then it was driven by PBP) and close to a million PICs shipped, I have to admit that whether folks found the products useful or consigned them to land-fill that I really don't care.

In all that time, I've never had a customer return that was attributable to design, manufacturing or component defect. I put this down in the main that some of the products are large and heavy >2000kg and Mr Postman just can't fit them through the letterbox. But if they end up useful as boat-anchors, then that's still a success in my book.

What I can say with absolute certainty is that the PBP component works - as do the PICs. That leaves a failure to understand hardware, designs, not reading Datasheets or Manuals or defective logic in coding. A look on the kind of posts on this forum tells you that this accounts for 95% of help requests. PICs only need three things to make them work, POWER, RESET and CLOCK (OK, and a half-sensible program too). I don't know your Development Board, but if you can't even get a simple LED to blink in order to verify that those three conditions to make the PIC run have been met, or have the knowledge to determine which of those three are causing you grief, then chucking everything in a drawer and concentrating on watching Bonsai grow is the way to go. That may be a little strong language for this festive season (even if it is intended in jest), but seriously, PICs will do one of two things for you, they'll either make you very rich, or cause you to lose all your hair. I'd rather everyone was in the former category than the latter - and the secret to making everything work is contained in this paragraph.

---

VERY WELL PUT, M.

I think I can say that every failure I've ever had with PICs (except for one!) and/or PBP, or any combination thereof, has been attributed to my own stupidity or ignorance. I've had a lot of things (and I'm sure everybody else has too) I thought 'should work because it looks close to what the manufacturer wanted' ended up not working because 'it wasn't what the manufacturer specified'. The fix has always been to step back for a little bit, go through the datasheets, think about it, and finally do it the right way (except for that one time).
It's amazing how so many have gotten along so well for so long with PIC/PBP. I wonder what we're doing wrong?

Quote:

---

Originally Posted by Melanie

>> .. ...having a skin-tight leather Catwoman outfit with chrome-plated spikey high heels and a passion for dancing on tables probably helps... try it with your Bank Manager and let me know...

---

Wow Mel.
I don't know which would be more entertaining, you or sayzer dancing in that outfit! I suspect BOTH for different reasons :)

Melanie
http://www.mister-e.org/Pics/catwom.gif

Sayzer
http://www.home.earthlink.net/~lsiuw...tas/catman.jpg

mmm hard to say :D

My vision was of sayzer wearing melenies costume, something like Cheech Marin in his appearence onstage in the movie UP in Smoke where he was dressed in a pink tutu and combat boots - very funny stuff - Not that I think Sayzer would ever do it ;) still it would be entertaining.

Hehe, not Cheech Marin but...

http://steelturman.typepad.com/photo.../tutu_much.JPG

Dear google images :D

Ok, EOT!

Happy New Years to all!!!

I guess this is good as any of an opportunity to say that I am amazed at the projects that people write to this forum asking for with. Some of them seem like pretty heavy items. And yet many of them haven't a clue what they're doing.

I hadn't done any electronics work in ten years up unitl 2003 when I was asked to design a system to detect when a train was coming to light up signs that would tell motorists outside the immediate area that the railroad crossings were blocked by a train and you might want to go a different way. Using the Basic Stamp2 I was able to get a system designed and tested in less than 2 weeks! After that, I found a book on programming PICs with Basic and I haven't stopped since. I've put out some nice items for both pleasure and profit.

I will say though, like anything in life there is a learning curve. Being in the alarm business, everytime we try to use a different brand of alarm panel, there is a considerable amount of time spent and learning the programming.

The whole point here is what the forum pros are saying is true. Start out small taking bites of the project then build it up. I started using CMOS logic gates along time ago. I still design my projects that way then try to eliminate hardware with software. It works for me!

As for the procrastinators club, I could be its president. I once bought a book on procrastination. Kept putting off reading it!!!

Good night to all and once again Happy New Years! I thank you for all of the great information you contribute here.

BobK