16F877 Programming (newbie)

[weirdjim]

OK, let me admit something right up front. I'm an analog cat in a room full of digital rocking chairs. I've been doing stuff from audio through microwave all my engineering and teaching career, but this is my first foray into microcontroller programming ever. Please be gentle with my stupid questions.

I also admit to having a moderate command of Dartmouth Basic, but have absolutely no experience with my brand new PicBasic Pro Compiler, programmer, Lab X1, assembler, or machine language. None whatsoever.

However, I have a project that will lend itself nicely to a uC solution I believe. It is a simple audio switching panel that accepts audio from/to up to three transceivers, a couple more receivers, four analog microphone inputs and all that stuff ... more later, but if you want to see it, please click www.rstengineering.com/picpro

The basic question is this...all those pushbutton switches you see control the leds you see (and by extension the audio channel they represent) in a simple sequence of blue, green, blue & green, all off. The logic to do this in PBasic is quite simple. However, I have just about 40 inputs/outputs and that is a bit much for a through-hole uC, especially as most of the time they will not be doing anything. The device generally goes at least ten minutes and sometimes up to an hour without any of the buttons being pushed.

So, given that the inputs/outputs are MOSTLY binary (on or off) and fairly stable, I want to store the data in the onboard flash memory for a couple of reasons. One is that I want to refresh all of the outputs once per program cycle on the off chance that something burps and turns off an on or on an off. Two is that I want the device to come up in the same manner that it was turned off. (Turn on and turn off are from another power switch in the vehicle.)

So it comes down as to how to "read" a digital 8 bit byte bit by bit or "write" a digital byte bit by bit. That is, if I have eight variables and each bit of the byte represents the condition of one of the 8 variables, how do I assign the value of the variables as a function of the associated bit being high or low? How do I rewrite the byte if one or more of the bits changes?

Before I go making wrong assumptions, I have sort of deduced from the ops manual for PBP (not exactly a literary gem) that (a) you have to define each variable before you use it and (b) a BIT is binary, a BYTE is octal, and a WORD is two bytes in hexadecimal. Yes?

There must be a common name for this sort of process, and if I knew what the name was I could have searched this message board for the name. Sorry to have rambled on so long.

Later questions will address external storage/output of the data, voice recording, and all the rest of the stuff. However, I want to get a basic loop programmed before I do anything else.

Thanks for reading all this drivel.

Jim

[weirdjim]

Rather than go to an offsite web page, I'll attach the file to this reply. Sorry for the hassle; I'll get the hang of this soon.

Jim

[Melanie]

Example. You have Eight Receiver Inputs, each can be on or off... so define a BYTE for the Receiver states... give it a meaningful name...

Receive var Byte

Now you've got eight bits in that byte called Receive... so define those...

RxChannelA var Receive.0
RxChannelB var Receive.1
RxChannelC var Receive.2
RxChannelD var Receive.3
RxChannelE var Receive.4
RxChannelF var Receive.5
RxChannelG var Receive.6
RxChannelH var Receive.7

The nice thing is that so far, the above nine statements have cost you NOTHING, NIL, ZIPPO in program space... now use those like so...

If PushButtonA=0 then RxChannelA=RxChannelA^1

For example, the above will toggle the state of the RxChannelA BIT each time the PushButtonA is pressed.

Use READ and WRITE and DATA (see manual) to save your BYTE into your pics EEPROM accordingly.

btw... You are aware that somebody's done what you're doing already?

http://www.ncsradio.com/m_switch.html

Now, once you've looked at the competition, you'll probably want the ability to assign each receiver channel input to more than one output, in that case BIT operations would be inappropriate and you'll probably want to assign a BYTE to each channel rather than a BIT.

[weirdjim]

Yes, I am aware of NCS. However ...

1.) The device shown is not set up to the aircraft standard, nor can it be modified to do so.

2.) The device shown has three times the volume that is allowable for a device of this type.

3.) For the last 34 years we have been producing nothing but kits (a la Heathkit) for the owner-pilot to assemble themselves.

4.) The price is approximately 3 dB more than our target price.

But the tech info for manipulating bits of a byte are most appreciated.

Jim

[weirdjim]

"If PushButtonA=0 then RxChannelA=RxChannelA^1

For example, the above will toggle the state of the RxChannelA BIT each time the PushButtonA is pressed."


I'm not at all sure I understand the logic behind this program line. You appear to be XORing something with ... oh, I see now. I'm not used to negative logic yet. You have one side of the pushbutton GROUNDED and a pullup to keep it high until pushed, yes? And then the old combinational (discrete) logic trick of holding one of the pins high to do an invert of the data. Nice.

I'm presuming that this is a way of implementing the NOT function of GeeWhiz Basic in PBP? (i.e. If x=0 then x=^1 is equivalent to x=not(x)) But wait a minnit -- page 37 says that there IS a NOT operator. Would this work also?



"Use READ and WRITE and DATA (see manual) to save your BYTE into your pics EEPROM accordingly."

Yes, this wasn't too difficult to understand. I'm not altogether sure that I understand the DATA "location" parameter unless "location" simply means the next chunk of space for storage. "Location" doesn't necessarily mean a defined number of bits but merely "store it in the first place you can"? I'm not at all sure how to read that, but the processor is probably smarter than I am.

Jim

[Melanie]

The XOR simply toggles the BIT in that example. If it was a 0 it becomes a 1, and vice-versa. What you do with that BIT thereafter depends on you and your schematic.

As for the DATA statement, it presets the state of the on-board EEPROM at program time. The EEPROM is not usually all zero's when you get it from Microchip... actually, I wouldn't trust what state it's in. After erasing, it'll probably full of $FF which may not be what you want... after all, on power-up, your device will look in EEPROM to determine the state of your various I/O's, so when you design your device, when it's powered ON for the very first time, you will want it to come-up with the various I/O's and options in a default state, so in that instance you will use the DATA statements to preset the PICs EEPROM accordingly. Thereafter, their state can be altered by the equipments operation, but initially you will want your device to initialise a certain way. The DATA statements will ensure the EEROM is pre-set to those values at program-time and not to some random value.

You buy a brand-new TV set and plug it in the wall, you don't expect it to switch-on for the very first time with the factory default volume set to maximum.

LOCATION is the address in EEPROM space.

For example, the volume setting can be located at address 5 in EEPROM. It can be a value from 0 (minimum) to 255 (maximum) the default (brand-new, untampered out-of-the-box) setting is 75. You would ensure in your program that...

DATA @5,75

[weirdjim]

The XOR simply toggles the BIT in that example. If it was a 0 it becomes a 1, and vice-versa. What you do with that BIT thereafter depends on you and your schematic.

That's what I meant by the trick using discrete XOR logic in the analog world. It is the way we get a 180° phase shift without a lot of folderol.



As for the DATA statement, it presets the state of the on-board EEPROM at program time. The EEPROM is not usually all zero's when you get it from Microchip... actually, I wouldn't trust what state it's in. After erasing, it'll probably full of $FF which may not be what you want... after all, on power-up, your device will look in EEPROM to determine the state of your various I/O's, so when you design your device, when it's powered ON for the very first time, you will want it to come-up with the various I/O's and options in a default state, so in that instance you will use the DATA statements to preset the PICs EEPROM accordingly. Thereafter, their state can be altered by the equipments operation, but initially you will want your device to initialise a certain way. The DATA statements will ensure the EEROM is pre-set to those values at program-time and not to some random value.

Ah, that's something I missed. I missed the "first programmed" part of the DATA command reference description. Normal execution of the program thereafter disregards the DATA line??



You buy a brand-new TV set and plug it in the wall, you don't expect it to switch-on for the very first time with the factory default volume set to maximum.

It might get your attention {;-)

LOCATION is the address in EEPROM space.

So is each LOCATION one 8-bit byte long? If so, how can you store 16 bit words??



For example, the volume setting can be located at address 5 in EEPROM. It can be a value from 0 (minimum) to 255 (maximum) the default (brand-new, untampered out-of-the-box) setting is 75. You would ensure in your program that...

DATA @5,75

Got it. Thanks.

Jim ..........

[Melanie]

>Normal execution of the program thereafter disregards the DATA line??

Yes. The DATA statement simply presets the content of EEPROM at PROGRAM TIME - ie when you burn the PIC in your programmer. The DATA statement is not actually an 'executable' piece of code. It carries no program overhead. It is simply a directive to place values into EEPROM when the PIC is programmed. Thereafter, the content of EEPROM can be read (with the READ command) and altered (with the WRITE command) as often as you want during program execution. So to recap, DATA presets the EEPROM to an initial value at PROGRAM TIME - and at no other time thereafter (unless you reprogram the PIC in your programmer when the value will revert back to that specified by the DATA statement - unless of course you have a clever programmer in which you can specify if the EEPROM contents are to be programmed or not).

>>So is each LOCATION one 8-bit byte long?

Yes.

>>If so, how can you store 16 bit words??

You split the word into highbyte and lowbyte and use two EEPROM locations.

[weirdjim]

Many thanks fer yer help. The derivative of the learning curve is a large positive number today.

Two last questions and I'm pretty sure that I know the answers ... which is generally how I get bit on the hiney from time to time ...

1.) If I am in a particular section of the main program and I call out a subroutine called, for example getthis: and in getthis: it calculates a variable called rxp2 and gives it a value of 7 (i.e. somehow rxp2=7 is generated), when I RETURN to the main program and use rxp2, does it still have the value 7 if it otherwise hasn't been modified? I think the term for this is global variable, where it matters not where in the program something is calculated, it carries that value everywhere in the program until modified somewhere else.

2.) Does it take up any more program space to call a variable s2 or supercalafragialisticexpialidotious2 ??? And are we limited in length on variable names?

(Or is there a place online where I can go to look up information like this rather than bugging you all afternoon?)

Jim

[Melanie]

Actually, where I am now is pretty much midnight...

1. All variables in PICBasic are global.

2. Labels or variable names do not take up program space... make them meaningful, but if you go crazy with them, it makes your program look stupid (but then again, who cares, you're the one that's probably only going to read it and it's unlikely you're going to publish it for a wider audience to riddicule)...

If (PrimaryStallAlarmWarningFlag=1 and PrimaryWheelsUpFlag=1 and WheelsNotDownAndLockedFlag=0) then goto YoureGoingToBendYourPropellerVoiceMessageWarning

Try to make things fit on one line - it makes printouts and debugging so much easier.

With PBP - it's all in the manual and in the Datasheet for the PIC you're using.