PDA

View Full Version : basic question (eeprom)



roberto
04-27-2006, 02:11 AM
Lets say if i use the write command to log data to the eeprom while a program is running.

DO i have to write a separate program to retrieve the DATA stored using read commad?

when i retrive the data the initial program will be lost?

So i have to rerun the main program once again? so my logging continues?

I cant seem to get the answers to these questions in anything i read....


i know its basic but have to figure this out before i continue thanks


·

SSteve
04-27-2006, 02:46 AM
If you're storing the data in the Stamp's onboard EEPROM then, yes, it will get erased when you upload a new program. You would either need to make your retrieval routine part of the same program as the logger or store the data on an external EEPROM.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows

Chris Savage
04-27-2006, 02:56 AM
If the data is at the lower memory addresses and your new program doesn't over-write that part of the EEPROM then you should have no problem getting that data from the BASIC Stamp EEPROM.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com (mailto:csavage@parallax.com)

SSteve
04-27-2006, 03:05 AM
Oops. Sorry. I thought the entire EEPROM was erased every time a new program was downloaded. My apologies for the bad info.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows

Chris Savage
04-27-2006, 03:19 AM
Steve,

·· It's possible...I just wanted to confirm that the areas not used by the program are still intact.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com (mailto:csavage@parallax.com)

Tracy Allen
04-27-2006, 04:13 AM
Your ealier "real time clock" post said you are using a BS2pe, and if that is the case you have 32kbytes total memory for your program and data. If you use the first 2k slot for the program, sans data, then there won't be any worries about over writing.

To store a byte in a location from 2048 up to 32767, you need to use the STORE command to select the bank.

writeByte: 'enter with addressPointer from 0 to 30720
STORE addressPointer + 2048 / 2048
WRITE addressPointer // 2048, myByte
RETURN

and the same to read

readByte: 'enter with addressPointer from 0 to 30720
STORE addressPointer + 2048 / 2048
READ addressPointer // 2048, myByte
RETURN

Within one program bank, the editor writes out code tokens in blocks of 16 bytes. There are 128 blocks of 16 bytes in each slot, total=2048 bytes per slot. If you have a program that occupies 525 bytes, the editor will send out 33 blocks, that will overwrite locations 1520 to 2047 in the Stamp memory (528 bytes). And ithe editor will leave bytes 0 to 1519 just as they were. Unnless you have also defined specific DATA in the program. Then that data too will over write data that was already there, in blocks of 16 bytes. While that is a bigger issue with the BS2, which only has one single slot, it is not much of an issue with the BS2pe, which has 16 slots.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com (http://www.emesystems.com)

Chris Savage
04-27-2006, 07:55 AM
I didn't even catch that originally Tracy...This message probably should've been in his original thread instead of starting a new one.· This way we'd have more information.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com (mailto:csavage@parallax.com)

Chris Savage
04-27-2006, 08:14 AM
It was already mentioned above that the new program will only over-write the area it uses...The data can be in other slots and won't be affected.· Or you could just write your program so that changing a jumper and hitting reset starts dumping what was logged back into the computer without having to re-program it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com (mailto:csavage@parallax.com)

roberto
04-27-2006, 08:19 AM
is there examples on how to do that?

Chris Savage
04-27-2006, 08:25 AM
roberto,

·· I think you better take smaller chunks.· Tracy has provided an excellent example of how to store data across banks on your BS2pe...I would start with some simple data logging and learn how to read data back from the EEPROM before trying to make a full-blown project since you are still having trouble grasping some of the simpler tasks.· There are a few Nuts & Volts articles that might help you.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com (mailto:csavage@parallax.com)

roberto
04-27-2006, 08:28 AM
true
thanks a much

allanlane5
04-27-2006, 09:17 PM
1. Yes, when you re-program your BS2, ALL EEPROM IS ERASED, before your new program is downloaded.

2. When you 'RESET' your BS2, it leaves the eeprom entirely alone.

3. So yes, if you are storing stuff in the BS2 eeprom, you must also program in a way for the BS2 to output that data.

Typically this is done by putting a time-outed SERIN command at the start of your program. During the time period (like one second) you can enter a character on some attached PC. This should trigger a routine to output the 'saved' data from the EEPROM.

If the SERIN time-outs (because you DON'T have an attached PC, because the BS2 is in the field TAKING data) then the data collection part of your program runs.

So, when you're ready to get the data from your BS2, you connect it (on a BOE board or whatever) to the PC, do a RESET on the BS2, and enter a character before the time-out expires. Then the PC should capture the data from the BS2.

Paul Sr.
04-27-2006, 09:49 PM
allanlane5 said...
1. Yes, when you re-program your BS2, ALL EEPROM IS ERASED, before your new program is downloaded.




Quote:

If the data is at the lower memory addresses and your new program doesn't over-write that part of the EEPROM then you should have no problem getting that data from the BASIC Stamp EEPROM.

Chris Savage
Parallax Tech Support
csavage@parallax.com

allanlane5
04-27-2006, 09:55 PM
So, what you are saying Chris, is that if you HAD a program, that used the "WRITE 0, someval" statement, and THEN you re-programmed the BS2 with another program, then that program could do READ 0, myval:SEROUT 16, baudmode, [dec myval], and you'd actually output what had been written before?

That sounds awfully risky. But I'll take your word for it. Why couldn't people use this to write a tiny little 'dump' program, and use that to 'dump' the rest of programmed eeprom?

Chris Savage
04-27-2006, 10:04 PM
Allan,
···The area of the EEPROM over-written when you download a new program is only that space actually used by the program.· If your data exists at the lower memory addresses and the new program doesn't over-write those then there is no problem.· If you don't believe this, run the following program to store 4 values in EEPROM, then run the second program to dispaly them all back.


' {$STAMP BS2}
' {$PBASIC 2.5}
WRITE 0, 123
WRITE 1, 4
WRITE 2, 27
WRITE 3, 6




' {$STAMP BS2}
' {$PBASIC 2.5}
ioByte VAR Byte
READ 0, ioByte
DEBUG DEC iobyte, CR
READ 1, ioByte
DEBUG DEC ioByte, CR
READ 2, ioByte
DEBUG DEC ioByte, CR
READ 3, ioByte
DEBUG DEC ioByte, CR

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com (mailto:csavage@parallax.com)


Post Edited (Chris Savage (Parallax)) : 4/27/2006 5:00:26 PM GMT

Bruce Bates
04-27-2006, 10:16 PM
Chris -

I think the crux of the problem may lie here:

"a new program is only that space actually used by the program. If your data exists at the lower memory addresses"

The comparative term "lower" can be very deceiving based on how you're used to thinking about Stamp program memory, Stamp EEPROM memory, or reading a Stamp Memory Map. I KNOW it was confusing for me at first.

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->

Chris Savage
04-27-2006, 10:19 PM
Okay, I think what's missing here is in a thread (perhaps not this one) I mentioned checking the memory map to see how large the program is to determine how much data you could store.· From the memory map you can see that the program starts at the highest addresses and builds downward.· Data is typically stored at lower addresses building upward.· So, if your main program is larger than your data reading program there is no change of your data getting over-written.·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com (mailto:csavage@parallax.com)

Tom Walker
04-27-2006, 11:13 PM
Chris,
I think allanlane5 is actually thinking that your explanation would seem to make the Stamp less secure. In the situation that a tiny EEPROM dump program is loaded over a larger program, a user could conceivably dump the majority of the tokens from the larger program and reverse Parallax's intellectual property.

If I am incorrect in my interpretation of your concern allanlane5, I apologize. I don't intend to put words in your mouth...(I apparently just have too many of my own today...)

:^)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Truly Understand the Fundamentals and the Path will be so much easier...

Post Edited (Tom Walker) : 4/27/2006 3:18:51 PM GMT

Ryan Clarke
04-27-2006, 11:21 PM
Tom,

You can see tokenized code with much less effort. This does not make the interpreter any more/less reverse engineerable.


Ryan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ryan Clarke
Parallax Tech Support

RClarke@Parallax.com (mailto:RClarke@Parallax.com)

allanlane5
04-27-2006, 11:22 PM
Nope, that's my concern alright. I don't want to "argue" with Chris over this point. The only reason I mentioned it at all was that I thought I had a very complete understanding of this aspect of the BS2 -- and what Chris was saying contradicted that understanding. Not Chris's fault, but when that happens I like to have it confirmed two or three times.

Also, if some person moved forward on that information, without testing it, and it turns out that their hard-logged data got erased when they programmed the BS2 with their 'download' program, well that would be a shame.

But his point is completely valid. A comparatively simple test, implementing the scenario I outlined above, should provide a quick verification. And that 'some person' mentioned above absolutely should bench-test this scenario before depending on it. So there's no real reason to argue about it. I don't have a BS2 handy at the moment, or I'd do it now.

Ryan Clarke
04-27-2006, 11:25 PM
Consider that if stored data was completely erased upon the load of a new program, then the ability to store 'calibrations' would not be possible.


Ryan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ryan Clarke
Parallax Tech Support

RClarke@Parallax.com (mailto:RClarke@Parallax.com)

roberto
04-27-2006, 11:44 PM
thanks much guys eventhough its kind off confusing what your discussing i am trying not move very fast,

yesterday was able for the first time to log my data to the eeprom while the program was running and then retrive it using chris method was wondering allanlane if you have any links on where the dump to the debug screen using the the reset button has been in use. because it seems the way to go for my type off program it will be much help to me
thanks ahead

Thanks Chiris for slowing me down little bit off reading and was able to do it.

Bruce Bates
04-27-2006, 11:52 PM
Gents -

Just one more caveat or observation which caused some of my initial confusion. I spent more than 30 years troubleshooting problems based on memory maps and system dumps. Let me just say that old habits die HARD, and this is just such a recitation!

Before I "met" the PBASIC Stamp Memory Map, every memory map or system dump I'd ever encountered began with the lowest address in the dump or map, at the top right of the listing or display, and ended with the highest address at the lower right of the listing or display. The PBASIC Stamp Memory Map displays all of the Stamp Memory in exactly the same way, or so it would seem at first glance.

So too, in general, the earlier user and system programs were loaded into the lowest memory location(s) available to them, unless there was some over-riding condition. Thus, to my earlier way of thinking, the memory map or system dump was in some sort of ascending, logical sequence throughout memory. Here's where the rub comes in.

The PBASIC Stamp has two basic types of defined memory. The two types are RAM and user EEPROM memory. Within the PBASIC Program Memory Map, both are shown. However, user EEPROM is shown at the top left (the lowest memory location) and proceeds towards higher memory addresses, as the display proceeds down and to the right. RAM, which contains your program, is shown at the OPPOSITE end of this Memory Map, at the HIGHEST memory location. The program is loaded from the highest location in memory, down towards the lowest that it requires. It is loaded in memory RIGHT to LEFT as well. All of this latter memory format takes a bit of getting used to, or it did for me.

If the thought comes to mind that these separate memory areas might ... meet in the middle, that is entirely possible and is a condition to be avoided. Checking the Memory Map from time to time, while you are programming, is an important part of the programming process.

Last is the matter of what memory can get over-written, and what can not, along with when it may happen. The PBASIC Manual says it best as follows:

"An important distinction between RAM and EEPROM is this:

· RAM loses its contents when the BASIC Stamp loses power; when power returns, all RAM locations are cleared to 0's.

· EEPROM retains the contents of memory, with or without power, until it is overwritten (such as during the program-downloading process or with a WRITE instruction.)"

I hope that helps to clear things up, and doesn't confuse them more.

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->

allanlane5
04-28-2006, 12:46 AM
Bruce has it right. All I can add is that the BS2 doesn't really have any "RAM", as such. What it USES for "RAM" are internal data registers on the PIC 16C57 chip inside the BS2. Since that chip has 26 bytes of register space, that's why a BS2 only has 26 bytes of "RAM".

Now, the "Program EEPROM" is loaded just as Bruce says. In the "Memory Map", the part you first see (address zero) is where the stuff you define in your program with DATA statements is stored, from address zero on up. If you scroll all the way down to the bottom (address 7F0) that's where your program tokens are loaded, from address $7FF on down.

Chris Savage
04-28-2006, 12:49 AM
Bruce Bates said...(trimmed)
The PBASIC Stamp has two basic types of defined memory. The two types are RAM and user EEPROM memory. Within the PBASIC Program Memory Map, both are shown. However, user EEPROM is shown at the top left (the lowest memory location) and proceeds towards higher memory addresses, as the display proceeds down and to the right. RAM, which contains your program, is shown at the OPPOSITE end of this Memory Map, at the HIGHEST memory location. The program is loaded from the highest location in memory, down towards the lowest that it requires. It is loaded in memory RIGHT to LEFT as well. All of this latter memory format takes a bit of getting used to, or it did for me.

RAM loses its contents when the BASIC Stamp loses power; when power returns, all RAM locations are cleared to 0's.
Bruce,

·· I think you have the RAM and EEPROM backward.· By that explanation the last sentence would indicate that your program is lost when you power off the Stamp.· Just a slip I know, but I thought I would mention it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com (mailto:csavage@parallax.com)

Paul Sr.
04-28-2006, 01:09 AM
Affirmation of an incorrect assumption does not make it correct......

Tracy Allen
04-28-2006, 01:40 AM
Roberto,

When your program starts, it can display a menu and prompt for user input, something like this:



top:
DEBUG "1) Log data 2) Offload data 3) Erase data 3) Set clock",CR,LF,"enter 1,2,3,4> "
DEBUGIN DEC1 response
DEBUG CR,LF
ON response GOTO top, datalogging, dataoffloading, dataErasing, clocksetting
GOTO top

dataLogging:
DO
GOSUB whatever2acquireData ' by time or by event
gosub getRecordPointer
GOSUB writeData
recordPointer=recordPointer+1 MAX 32720 ' using slots 1 to 15 in BS2pe
GOSUB saveRecordPointer
LOOP

dataOffLoading:
GOSUB getRecordPointer
IF recordPointer=0 THEN top ' no data
FOR idx = 0 to recordPointer-1
GOSUB readData
GOSUB showDecimalData
NEXT
GOTO top



The first thing you have to ask is, "where do I store the recordPointer"? The answer to that is, if you have the DS1302 real time clock, you store the address pointer in the extra battery backed memory that it provides. To "erase" the data, you reset recordPointer to zero. Where does the menu appear? You can use the Stamp Debug screen, or you can use a program like Hyperterminal or StampPlot to capture the data. There is no need to reload the program, because the program itself provides all the functionality. Thre are a lot of refinements you can make, but that is BASICally it.

In the separate thread on the real time clock, I pointed to URLs that take the above approach.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com (http://www.emesystems.com)

roberto
04-28-2006, 10:53 PM
first thanks for all the support i get in this thread its much appreciated

i have been playing much with the eeprom at home would like to make sure·to restart from a clean stamp
how do i go about clearing the entire eprom from any data logged
would this work?

address var·word
eeprom_data var byte

for address = 0 to 2048
eeprom_data = $00
write address, eeprom_data
next

How do i go about erasing total eeprom for the bs2pe?

P.S Thanks tracy

Post Edited (roberto) : 4/28/2006 3:54:40 PM GMT

Tracy Allen
04-28-2006, 11:27 PM
The program idea is correct. The address needs to be a WORD variable, not a BYTE, in order to hold addresses up to 2047. "data" is a key word, so you have to use a different name. Your program will overwrite itself and crash. But that is not a big deal, because your objective is to zap the memory anyway. For the whole BS2pe:



address VAR WORD
char VAR BYTE
char = $00
DEBUG REP "_"\64,CR ' progress bar
FOR address = 32767 TO 0 ' entire BS2pe, start at the top
STORE address/2048 ' select slot
WRITE 2047- (address//2048), char ' address within slot (from 0 up to 2047)
IF address//512 =0 THEN DEBUG "*" ' progress indicator
NEXT

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com (http://www.emesystems.com)

roberto
04-29-2006, 12:07 AM
i am at work right now tracy
i dont understand the line

IF address//512 =0 THEN DEBUG "*"

SSteve
04-29-2006, 12:51 AM
// is the mod operator. It's the remainder that's left after the division. address//512 will be zero whenever address is evenly divisible by 512. So that line will print a "*" in your debug window after every 512th address is cleared.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows

SSteve
05-02-2006, 12:55 AM
keylog:
addressPointer = 0
mybyte = key
FOR addressPointer = 0 TO 10
WRITE addressPointer, myByte
NEXT


The only thing in your FOR/NEXT loop is the statement that writes the byte to the EEPROM. You need to collect data between writes. Take a look again at the code Terry posted on Apr 27.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows

PJ Allen
05-02-2006, 01:34 AM
You have:

push:
IF db = 1 THEN done' Already responded to this press, so done.
db = 1: press = 1 ' Set debounce and keypress flags.
key = (key-1)+(row*4) ' Add column (0-3) to row x 4 (0,4,8,12).
LOOKUP key,[13,15,0,14,12,9,8,7,11,6,5,4,10,3,2,1],key

done:
INPUT row ' Disconnect output on row.
RETURN ' Return to program.


This· is wrong -- db = 1: press = 1.·· It needs to be two lines:


db = 1
press = 1

You are GOSUBing to "done" -- is that REALLY what you want to do?· Because it RETURNs, of course to "push", when what I think you want to do (??) is get out of "push" (??) and return to the top and get another key-press (??).

Maybe I'm being picky, but I think that you need to re-work this --

key = (key-1)+(row*4) ' Add column (0-3) to row x 4 (0,4,8,12) --
to be:

key = key - 1
row = row * 4
key = key + row



·

SSteve
05-02-2006, 02:15 AM
PJ Allen said...
This is wrong -- db = 1: press = 1. It needs to be two lines

It isn't wrong. The colon is the same as starting a new line. "db = 1: press = 1" is equivalent to

db = 1
press = 1


It's generally avoided as bad coding practice, however. Two statements on one line are harder to read.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows

allanlane5
05-02-2006, 03:22 AM
Yes, you must be very careful when using GOSUB's and RETURNS to insure that for each GOSUB there's a matching RETURN. Typically you do this by NOT using a 'GOTO' that leaves the subroutine entirely -- especially not a GOTO that goes to a 'caller' of the subroutine.

See the fixed file.

Oh, and "IF xxx THEN DoLabel" -- is an implied "GOTO DoLabel", not a gosub. P.J. Allen was mistaken about this.

Note I'm not sure if the attached file is completely fixed.· It just has the major GOSUB -- GOTO faults fixed.

PJ Allen
05-02-2006, 03:54 AM
· Well, this one had gone for a while and then the Originator re-posted -- so, I figured the best way to get loads of help/input would be for me to stick my neck out.· http://forums.parallax.com/images/smilies/lol.gif
· But, honestly, I'm befuddled with/by the Originator's intentions,·hence my generous use of (??).· If others can say, then more power to them; it's not clear to me sometimes whether the difference between GOTO and GOSUB·is clear to others (no offense.)
· So, roberto, SSteve and allanlane5 "got your back".· Adíos, hombrés.

roberto
05-02-2006, 04:20 AM
allanlane
the file is still loggin 10 times the same last key presed
likr bfore
how do i go around that

this is what i get when i read after pressing 1234 on the keypad ( i am reading 0 to 20)

444444444440000000000

Post Edited (roberto) : 5/1/2006 8:24:13 PM GMT

SSteve
05-02-2006, 07:38 AM
again:
GOSUB writeByte
press= 0

writeByte:
press= 0
GOSUB keyscan
IF press = 0 THEN again
DEBUG HEX key
GOSUB keylog
RETURN


The above code won't work because you GOSUB to "writeByte", but it calls "again" with a GOTO ("IF press = 0 THEN again"). That's going to cause your GOSUB/RETURN stack to overflow. Try something like this instead:



press= 0

DO
again:
GOSUB keyscan
IF press = 0 THEN again
DEBUG HEX key
GOSUB keylog
press = 0
LOOP



Note that this requires the keyscan routine to set the variable "press" to a non-zero value when a key is pressed. Your current keyscan doesn't do that.

There are a few problems with this subroutine:



keylog:
addressPointer = 0
mybyte = key
FOR addressPointer = 0 TO 10
WRITE addressPointer, myByte
NEXT


First off, it doesn't end with RETURN, so the program flow will fall through to keyscan when it's through. The FOR/NEXT loop simply writes the value in "mybyte" to the first 11 locations in EEPROM because addressPointer is going from 0 to 10. The "mybyte" variable is superfluous. Try something like this:



keylog:
GOSUB getAddressPointer
WRITE addressPointer, key
addressPointer = addressPointer + 1 MAX 32720
GOSUB saveAddressPointer
RETURN


The subroutines getAddressPointer/saveAddressPointer need to read/write the current addressPointer value to a fixed location in the EEPROM.

The trick to successful programming is to put yourself in the mindset of the processor and meticulously follow the effects of each line of code. Write down the name of each variable at the top of a column and write down its initial value. Every time that variable is changed, cross out the old value and write down the new value. Keep careful track of program flow (GOTO, GOSUB/RETURN, DO/LOOP etc.). When you're a beginner this is a slow and arduous process--there's no way around it. But it's a lot faster than just trying to cobble together bits of code from disparate sources and hoping it will work. Once you have a more intuitive grasp of how it works the process will be much faster and you'll be able to more easily incorporate 3rd-party code.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows

roberto
05-02-2006, 10:25 PM
i keep getting the same eerors (logs key entry 11 times)
even if i play around with the code maybe i should get a keypad encoder instead off trying to log the keys from this program ?
i think its because the press is always = 0.
someone have any 4x4 matrix keypad scanner where it would be much easier from me to log keystoke to the eeprom ?
this is what i have has hardware bs2, bs2pe, 4x4 matrix keypad, all the resistors needed will buy.
in future thinking of logging the time (also have the ds1302) for specific key press thats why the bs2pe.



Post Edited (roberto) : 5/2/2006 2:31:49 PM GMT

PJ Allen
05-02-2006, 11:10 PM
· Maybe you should start over and take a step-by-step approach.· Instead of a 4x4, you might consider a 2x2 (using 4 push-button switches), something more manageable,·and get your key concept straight.· When you consistently get the result with DEBUG (1 gets a "1", 2 gets a "2", etc.) then you can move on to expanding it to a 4x4, and then to writing/reading everything in the eeprom.· The one-felled-swoop approach isn't working.·

· Q:· How do you eat an elephant?
· A:· One mouthful at a time.

Chris Savage
05-02-2006, 11:20 PM
Perhaps I am missing something elsewhere because I have seen several message reagrding the same key being logged several times, yet your routine seems to be setup to do this very thing.

keylog:
addressPointer = 0
mybyte = key
FOR addressPointer = 0 TO 10
WRITE addressPointer, myByte ' BAD -- you're writeing eeprom WAY too often
NEXT


I think this was already pointed out too.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com (mailto:csavage@parallax.com)

roberto
05-02-2006, 11:30 PM
how could i make this log one key at a time chris

Chris Savage
05-02-2006, 11:31 PM
Perhaps by removing the section of the routine that causes 11 writes?· That's what I don't understand...Why do you have that in there?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com (mailto:csavage@parallax.com)

roberto
05-02-2006, 11:55 PM
like this

keylog:
addressPointer = 0
mybyte = key
WRITE addressPointer, myByte
Return

where would i go about incrementing the addressPointer so it does not rewrite to the same location


i wanted this
for addressPointer = 0 to 10
because i wanted to try to log·fist ten keys
i guess thats not how i do that·either


Post Edited (roberto) : 5/2/2006 3:58:59 PM GMT

Chris Savage
05-02-2006, 11:57 PM
Why can't you put an "AddressPointer = AddressPointer·+ 1" after the WRITE command?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com (mailto:csavage@parallax.com)

roberto
05-03-2006, 12:07 AM
hey chris could you have a look at the main program up to the top i made some changes tell me what you think
does this works better ?

Chris Savage
05-03-2006, 12:12 AM
Have you run the program?· Does it run and give you the results you expected?·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com (mailto:csavage@parallax.com)

roberto
05-03-2006, 12:27 AM
i know i still have to go home and check it.

I know i am getting ahead of myself but i saw your template for the ds1302
do you think i would be able to use that code to log time when a specific key if pressed? in the bspe2

PJ Allen
05-03-2006, 12:37 AM
I can't help myself.
Given:


keylog:
addressPointer = 0
mybyte = key
WRITE addressPointer, myByte
addressPointer = addressPointer + 1
Return

Everytime it goes to "keylog", it is going to Reset addressPointer (to zero)· Is that desired?

Another matter: How many keylogs do you want to do/make?

I think you need to make addressPointer = 0 at the beginning, before joining the DO...LOOP and then increment it from there.

Let's say your limit is 16 keypresses (0 through 15), then:



addressPointer VAR Word
myByte VAR Byte
db VAR Bit ' Debounce bit for use by keyScan.
press VAR Bit ' Flag to indicate keypress.
key VAR Nib ' Key number 0-15.
row VAR Nib ' Counter used in scanning keys.
cols VAR INB ' Input states of pins P4-P7.

press= 0
addressPointer = 0

DO
again:
GOSUB keyscan
IF press = 0 THEN again
DEBUG HEX key
GOSUB keylog
press = 0
LOOP


keylog:
IF addressPointer = 16 THEN pointerReset
mybyte = key
WRITE addressPointer, myByte
addressPointer = addressPointer + 1
Return

pointerReset:
addressPointer = 0
GOTO keylog

Chris Savage
05-03-2006, 01:14 AM
It's possible to use that code with yours to log the time, but first you need to get the current code working before adding anything.· You need to run the code before asking for help.· In order to run your code I would need to build your circuits as well, so I am focusing on the obvious, as well as on program flow, which, at this point is not easy to follow because the code jumps around a lot.· You have a lot of sub routines calling other subroutines, and you had conditionals in there.·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com (mailto:csavage@parallax.com)

roberto
05-03-2006, 04:45 AM
I just Got Home couldnt wait to try
and yes it works Chris
logs every key one after the other

thanks a bunch

PJ Allen
05-03-2006, 08:30 AM
roberto has deleted a number of his posts.· On the second page there was one with his whole program on· it --·and it is gone.· Why did you Delete your previous posts, roberto?· That is not cricket.

Chris Savage
05-03-2006, 11:32 AM
It definately messes up the flow of the thread for those who haven't read those messages yet.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com (mailto:csavage@parallax.com)

roberto
05-03-2006, 11:50 AM
oups i will upload tommorrow the complete working logger chris
i though i deleted the ones where i though i was repeating myself for no reason
sorry

roberto
05-03-2006, 10:28 PM
format it got so much shorter and easier to read with all ur help guys thanks.

there is noway to·put it back where it was?

The Ds1302 template that you posted here ·http://forums.parallax.com/showthread.php?p=531080

i think there is something wrong because the debug screen keeps repeating the time over and over i dont think that was intented. But the demo versions works fine. Has you know i am trying to log the time with the keylog when a specific key is pressed· do you have any hints to give me on that? i think i am starting to grasp the programming aspect of PBASIC gradually so is there· any links where it shows how to·link·two programs together ?






Post Edited (roberto) : 5/4/2006 5:18:06 PM GMT

Chris Savage
05-03-2006, 10:40 PM
Roberto,

·· Well if you're going to learn PBASIC by writing a complex application then you will need to do a lot of imperical testing and experimenting.· Otherwise we would be basically writing the software for you over the course of the thread.· I'm not opposed to helping out as you can see from all the help I have given, but there is a point where you will have learn the necessary material to be able to accomplish this.

·· If I were in your shoes I would've learned how to use the DS1302 completely, making changes to the code and seeing how that affects the results.· Then I would've learned about storing data in the EEPROM and finally how to log data.· Once you have all of that then you can start merging the concepts together into a working program.

·· On the same token it's hard to offer help and examples if the recipient doesn't understand the material given.· We have a tutorial on the BASIC Stamp called, "What's A Microcontroller?" which is a free download in PDF format from our website.· By any chance have you read through this?· If not I would highly recommend downloading it and going through it.· A link is provided below (bottom of each page).· And remember, both the Editor Help File and the BASIC Stamp Syntax & Reference Manual are excellent references for the commands and examples of how they work.

http://www.parallax.com/detail.asp?product_id=28123

http://www.parallax.com/detail.asp?product_id=27218

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com (mailto:csavage@parallax.com)

PJ Allen
05-04-2006, 03:23 AM
In keylog.txt, I see that you have the addressPointer = 0, that I recommended, before you start your DO...LOOP.· Good -- but, as it stands: if you push buttons enough, eventually you will start over-writing (corrupting) the program area of the EEPROM.· Is there some way you're preventing this that I cannot see?· If not, you may want to add the pointerReset feature which I also suggested a couple of (my) posts ago.