BS2P Newbie

msh5686 · 2012-04-24 12:25

Hi,

I switched out my BS2 I have been using for a project for the BS2P and immediately began having issues. For instance, I am using the Parallax 2x16 backlit LCD, which with the BS2 was displaying some variables I was measuring. Now, only gibberish is displayed. My question is, does the BS2P require some sort of different syntax that I have overlooked? I did switch the stamp mode from BS2 to BS2P when I changed chips. Thanks for the help!

Zoot · 2012-04-24 12:42

Is that the serial LCD or the parallel? If the former, you may have to adjust the SERIN/SEROUT values in your code. See the Pbasic Manual for the different baud settings for different Stamps. If you are using conditional compilation statements (again, see the Pbasic Manual) to set baud values then they should be OK. Posting your code and a circuit diagram or schematic would help.

msh5686 · 2012-04-24 13:33

Thanks, Zoot, that nailed it. One other question I've been fumbling with... I'm new to addressing the multiple eeproms, but have some of my code divided up amongst a few slots for space reasons. My program is working fine switching back and forth between the different eeproms, but whenever I go from my data logging routine (slot 1) back to my main routine (slot 0), it reinitializes the code. I am using the RUN command I found in regards to switching between eeproms, but am wondering if there is a different way to do this so I don't have the code reinitializing every time. I suppose I could make slot 0 just the initialization routine and run all the rest of the code off slots 1 and 2, but was just wondering if there is a simpler way around this. Thanks for the help!

Mike Green · 2012-04-24 13:55

There is no "return" to a slot. You have to do a RUN and that starts the slot program over from the beginning. The variables are only initialized when the Stamp is reset, so you can use a variable to indicate to a slot that it should GOTO somewhere in the code rather than start over from the beginning. The variable will be initialized to zero on a reset, so you could use various non-zero values in an ON <var> GOTO xxx, yyy, zzz statement where xxx is the label following the ON / GOTO (the zero choice).

Zoot · 2012-04-24 14:13

msh5686 -- what you said or what Mike said.

If you mostly have initialization stuff, then doing all that in slot0 and then never running it again is simple and tidy, e.g.,

'--- slot0 code ----

Reset:

' init a bunch of stuff here
' and so forth

Done:

   RUN 1 ' go to slot 1


'--- slot1 code ----

Main:

' do a bunch of stuff

Done:

   RUN 2 ' go to slot 2



'--- slot2 code ----

Main:

' do a bunch of stuff

Done:

   RUN 1 ' go to slot 1, and never run slot0 again

What Mike is talking about is a way to sort of use code in other slots as subroutines. It's very clever and can be appropriate in some circumstances. I have forgone that method (though I've often used it) as I find the execution time "hit" and extra variable space required is not necessarily worth it. Depends on the project, of course.

Tracy Allen has a really good write-up on that technique here: http://emesystems.com/BS2SX.htm#Crossbank

He discusses the BS2SX, but the technique is the same for all the multi-slot Stamps.

msh5686 · 2012-04-25 18:21

Thanks for all the help guys. I am trying to get things working using the technique Mike suggested along with Tracey Allen's write up. I will keep you guys posted, thanks again!

msh5686 · 2012-05-01 10:15

Ok, so I needed to have this running a little faster than I thought, so for now I am just going with the put all initialization in slot 0 and running my main routine in Slot 1 with data logging in Slot 2. My issue is my variables are not holding their values. I am making sure I specify variable according to size (WORDs 1st, then BYTEs, etc). Do I need to specify every variable used in the entire program in each Slot even if they are not being used in that Slot? If so, I am pretty sure I will be out of variable space so I am not sure what to do. Any more help you guys can offer would be great!

Zoot · 2012-05-01 10:27

Do I need to specify every variable used in the entire program in each Slot even if they are not being used in that Slot?

YES. All variable declarations must be identical in every slot's program -- that goes for order, names, everything.

If you are short on space, you are probably not taking advantage of SPRAM. For larger projects, I generally leave most of the regular "variables" to be work space, i.e., temporary space, and keep "real" values in SPRAM. Each slot or subroutine or chunk of code can then load up the regular variables with values from SPRAM, work on them, then save them back.

Mike Green · 2012-05-01 10:29

You need to declare the shared variables in each slot. Any variables unique to a slot get defined after the shared ones. This works if they're all the same size. Unfortunately, the Stamp Editor (and compiler) sorts the variables by size to minimize wasted space. You're better off using aliases (see the Stamp Manual for that) for the smaller variables. You can use aliases to the built-in variable names if you want (W0-W12, B0-B23, etc.)

If you let the compiler allocate space for variables, then you do have to specify all of them in each slot (except for aliases). Note that aliases are a common way to share variable space between different sections of a program and also works for sharing variable space between slots.

msh5686 · 2012-05-01 12:09

Okay, I'm looking at learning both methods because I know I need to learn to use the SPRAM eventually and I've come across Aliasing a few times as well. Mike, when using Aliases, can all variables and their aliases be defined say in Slot 0, then just use the aliases for the other Slots? I do let the compiler do the space allocating for me. I haven't had the confidence yet to try to do all the addressing my self, but maybe now is the time. Thanks again guys!

Mike Green · 2012-05-01 12:11

Although the slot programs are compiled together, they're processed as if they were compiled separately, so the variable definitions for each slot program have to be complete.

msh5686 · 2012-05-01 13:40

Thanks, Mike. I'm thinking I'm going to have to use the aliases in conjunction with figuring out the SPRAM. The RAM space issue comes from one of my slots running the Memory Stick Data Logger, which is taking up all the RAM space. Thanks for all the input and I'll get working on learning to address the SPRAM.

msh5686 · 2012-05-11 06:35

Hi guys. I figured out the SPRAM and got my project running, but have run into a little snag I have never come across before. I'm doing all my initialization in Slot 0, my main routine in Slot 1, and data logging in Slot 2. Basically, I only go to Slot 0 upon start up, then go to the main routine for some data monitoring and feedback processes ( no issues here ), then store those variables to SPRAM and go on to data logging. In short, I monitor some data for several loops, then go to data logging and just keep going back and forth. The issue that has cropped up is when I restart the project (i.e. power off the system, then power it back on) the program initializes, runs through the main routine like it should, then gets stuck on the initialization for the data logger. The data logging initialization I am using is taken straight from the demo program on the Parallax site. The only way I can get the system to work properly again after a restart is to first download a clearing program to the BS2P and all the slots I have used prior to re-downloading my project routine. I have never come across this before and was wondering if it has to do with variables being stored in SPRAM prior to powering the system off that are still hanging around and messing up the data logger initialization. If that is the case, is there a way I can clear all Slots in my Slot 0 initialization routine upon start up? Thanks again for the help.

Mike

Mike Green · 2012-05-11 08:09

The SPRAM does not maintain its contents over a power cycle, but like most SRAM, may come up with random contents after powering up. I don't think the PBasic interpreter clears it on a reset.

Unless you use a WRITE statement to write to the EEPROM, you should not have to reinitialize the slots. All the variables get cleared to zero on a reset.

How are you resetting the system and how is the datalogger powered? I don't remember how much of a delay there is in the initialization code for the datalogger before the Stamp tries to talk to it. Perhaps it's not quite enough to let the datalogger finish initializing itself before the Stamp tries to talk to it. Try adding a 1/2 second or 1 second pause.

msh5686 · 2012-05-11 08:17

Hi, Mike.

I am not writing anything to EEPROM so I guess that is out of the question. I am resetting my system simply by turning power to the unit off then on. I just upped the pause from the time TX is pulled high and RTS low to 2 seconds and it appears to be working a bit better. Maybe I will put that as part of my initialization Slot so the data logger can settle while I am running Slot 1. As always, thanks for all the help!

Mike

msh5686 · 2012-05-15 09:15

I have made some good progress with the SPRAM and getting this project working. The whole reason I started this thread was because of difficulty I was having with the space issues related to the memory stick data logger, which I to some extent solved by making use of the SPRAM, but still need to trim things down a bit. From reading the documentation and some of the sample programs I have found on the product page as well as programs posted in the forums, I was wondering how I can reduce the size of the buffer variable. Beyond the trivial just make it a smaller number than the standard 15byte array, what things do I need to consider when looking at how small I can make the buffer? Maybe I'm missing something clear in the documentation, but I am not understanding that aspect well enough to know what goes into choosing the buffer size. Thanks again!

Mike

Zoot · 2012-05-15 09:19

How much data to you need to pull into the buffer? 3 bytes? 5? 10? That would help determine the size.

msh5686 · 2012-05-15 09:24

When I am writing all the variables in one SEROUT, I am sending 20 bytes. Using SPRAM and one standard word variable, I think I can reduce that to 5 or less bytes by just issuing multiple SEROUT commands after GETting each datum from the SPRAM... unless I'm barking up the wrong tree with this approach!

Zoot · 2012-05-15 10:39

Do it in chunks w/as much variable space as you care to use, e.g.

BUFFERADDR  CON 10  ' SPRAM location of start of 20 bytes to send, can be anywhere 20 bytes below end of SPRAM


buffer VAR BYTE(5) ' using 5 byte buffer
i VAR NIB

FOR i = 0 TO 3 ' four iterations * five bytes = 20 bytes total
   GET i*5 + BUFFERADDR, buffer(0), buffer(1), buffer(2), buffer(3), buffer(4) ' load up the buffer
   SEROUT Pin, Baud, [ STR buffer\5 ] ' send 5 bytes
NEXT

msh5686 · 2012-05-15 11:09

Thanks, Zoot. That makes a lot more sense and I think the example finally has me understanding the buffer better. If I am sending out WORD size variables, I would just need to modify the GET statement slightly so I would be picking up every other address in the SPRAM, correct? Thanks a ton!

Zoot · 2012-05-15 11:17

msh5686 wrote: »

If I am sending out WORD size variables, I would just need to modify the GET statement slightly so I would be picking up every other address in the SPRAM, correct?

Correct. But it doesn't really matter, it's all bytes -- even if you had "5 words" to send, that's still 10 bytes. And using the STR formatter in the SEROUT saves a lot of code space.

msh5686 · 2012-05-15 12:22

Ok, Zoot. Here is what I have for sending out 5 bytes at a time. Is it ok to put the STR Buffer\5 in the middle of the "WRF" the way I have it?

FOR i = 0 TO 3
GET i * 5 + BfrAdrs, Buffer(0), Buffer (1), Buffer(2), Buffer (3), Buffer(4)
SEROUT TX\CTS, Baud, ["WRF", $00, $00, $00, $14, CR,
STR Buffer\5]
GOSUB Get_Serial_Bytes
NEXT

Zoot · 2012-05-15 12:40

I don't see why not. If it tokenizes (no syntax errors) it should be fine.

msh5686 · 2012-05-15 12:45

Yeah I didn't see why not either, but it isn't writing a file now. Not quite sure why, just commented out the old write step and put that in. When I check the flash drive there is no file written to it.

Zoot · 2012-05-15 12:52

Well, I don't know about you're sending. Do you need to send the control characters during every packet of the write? I.E., do the control characters just need to be sent once?

And I don't know if your "get_serial_bytes" should be called for every packet either. And *if* get_serial_bytes fills the spram locations, you could just suck that info into your buffer before sending. Maybe post more code than just the fragment.

SEROUT TX\CTS, Baud, ["WRF", $00, $00, $00, $14, CR]
FOR i = 0 TO 3
   GET i * 5 + BfrAdrs, Buffer(0), Buffer (1), Buffer(2), Buffer (3), Buffer(4)
   SEROUT TX\CTS, Baud, [STR Buffer\5]
 '  GOSUB Get_Serial_Bytes ' here?
NEXT
'GOSUB Get_Serial_Bytes ' or here?

And what control character needs to be sent to close the file from writing? That would need to be sent after the for/next loop runs. Here is the flow:

'SEND HEADER (control characters to start a write cycle)
'FOR startByte TO endByte
   'GET Byte FROM somewhere
   'SEND Byte  -- sending data only via serial
'NEXT
SEND CLOSE (control character(s) indicating write is finished

msh5686 · 2012-05-15 18:45

Hey Zoot. Sorry, I really should have posted this a long time ago. Here is my routine for the data logging. As you can see it is largely a modified version of the test program that comes with the logger documentation on the product page. This is my first experience with the logger so I didn't want to go too far off on my own. Thanks again!

Mike

Data_Log_V04.bsp

Zoot · 2012-05-16 10:21

It's hard to know what's going on without the whole application (code in other slots?) and even rudimentary documentation about the serial peripherals you are using (I re-read earlier posts and it's not clear what products you are using, at least not to my eyes).

msh5686 · 2012-05-17 05:59

Here is a copy of the full program. All the first slot is is general initialization upon power up. Slot one compares current oxygen content (VO2) of a system to a preset desired oxygen content (TargetO2). Slot one also contains a subroutine for displaying this information on an lcd screen. Slot two is called after 10 iterations through slot one to data log the variables in slot one so I can track oxygen changes over a period of time. I hope this helps paint a clearer picture for you.

The only issues I am having still pertain to the data logging routine now that I'm trying to use a smaller buffer size and send the bytes out in bunches.

Zoot · 2012-05-17 08:12

I don't see anything attached to your post? Should I check out the code you sent via PM?

Also, docs/reference on the sensor and the data logger?

msh5686 · 2012-05-17 08:27

Sorry, Zoot. Thought I had attached this earlier. The sensor I have no documentation for (no issue with this part, just supplies a voltage depending on oxygen content), but the data logger is the parallax memory stick data logger #27937. Anyway, here is the program. Slot 2 is the real issue with regards to the data logging write portion.

Mike

Zoot · 2012-05-17 21:16

I'll try to take a look at this later tonight ... might be Friday afternoon, though -- a bit slammed work-wise here right now.

BS2P Newbie

Comments