Read the newbee threads, 16F877A no go.

[BobbyA]

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

[BobbyA]

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

[mister_e]

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

[BobbyA]

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

[mister_e]

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

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???

[BobbyA]

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

[BobbyA]

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

[Melanie]

> 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.

[Archangel]

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

[BobbyA]

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.

[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.

[sayzer]

...
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.


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

[Melanie]

>> 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...

[skimask]

> 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?