Schedule Events - help needed :-)

computer guy

Hi there,

I am designing an Irrigation controller that can be programmed via the serial port and a program.
I am wanting as much information as I can get on how to use a "RTC IC"(Real Time Clock) with the propeller to run schedules.
The schedules will be stored in the spare space on the eeprom. <-- Need help here to.

Schedules will be like start at 10:30 run for 30min on area 2.

Does anyone have any suggestions or links to articles that might help.

Thank you

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my robot using the propeller RECONAUTOR

BTX

OK computer guy.

It's a bit older...but you can download examples for it in the parallax site...to use with the BS2's. then modify them for the propeller.

I'm refering to the DS1302... RTC.
Download the datasheet, read it ....read the parallax examples ...they are quiet easy.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

J. A. Streich

Here's the Datasheet for the chip BTX mentioned.
http://pdfserv.maxim-ic.com/en/ds/DS1302.pdf

As for storing the information about the schedule, I'd use a format similar to simple the Linux Cron Tab.

computer guy

Thank you.

Was just researching USB vendor id's for my controller, for if I decide to go big with them.
Turns out that a USB vendor id costs $2,000USD upwards. Now that isn't cheap.

The BS2 code confused me more than anything, It is code for an alarm but at no pint in the code does it even mention comparing a set time to the rtc time.
Will look into it some more, I might just have to use the DS1302 object from the object exchange and dedicate a cog to comparing the time with an array in the eeprom every 10 seconds.

Will also do some further research into writing to the spare space on the eeprom via the props serial interface.

Thank you

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my robot using the propeller RECONAUTOR

computer guy

Ok so if I wanted to store the schedules in EEProm in the format that "J. A. Streich" recommended which is say - "15, 30, 60, 2" to turn valve 2 on at 3:30 for 60min.
If I had more than one schedule say 5 of them it would look like this -

15, 30, 60, 2
2, 0, 30, 1
6, 15, 60, 2
13, 0, 60, 3
19, 30, 30, 1

How would I write this to the eeprom(every time the computer sends data) and read it when needed(every 10 seconds).


Thank you

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my robot using the propeller RECONAUTOR

StefanL38

Hello Anthony,

right on top if the forum there is a line
Locked Topic Propeller Announcement, FAQ and Thread Index stickies
that leads you to

http://forums.parallax.com/forums/default.aspx?f=25&m=148376

and there is a link to a thread

Storing Data in Propeller Boot EEPROM

http://forums.parallax.com/forums/default.aspx?f=25&m=162407

i think this can help you

greetings

Stefan

computer guy

Thank you will look at them now

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my robot using the propeller RECONAUTOR

Post Edited (computer guy) : 1/9/2008 11:32:21 AM GMT

computer guy

Ok I think I understand how to read from the eeprom using the i2c object.
How can I write to certain sections of the eeprom from the computer via the propeller, like the propeller IDE does?

Looks like I have a long road ahead of me, with lots of forks in it.

Oh and BTX, How is that large propeller powered display of yours coming? haven't heard much about it for a while.

Thank you

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my robot using the propeller RECONAUTOR

simonl

I think what you're looking for is all contained in the post mentioned above (http://forums.parallax.com/showthread.php?p=622841), specifically in Mike Green's post at 7/4/2007 9:37 AM (GMT -8)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon

---

www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style

computer guy

Mike describes how to read and write using the i2c object. whoever I want to write using the computer not the propeller.

Thank you

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my robot using the propeller RECONAUTOR

simonl

Hmm, not sure that's possible. Would undoubtedly need some interface hardware, which might as well be the Prop'! I'm not aware of any way to hook-up an EEPROM directly to (say) the PC COM port.

I'd suggest you accept the data from the PC (to the Prop') via the programming connection (maybe using 'simple_serial.spin'?), then use Mikes example to write to the EEPROM.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon

---

www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style

computer guy

Ok then, maybe you can explain to me the timing of serial data.
I have tried to do a similar relaying of data in the past however timing has always been an issue.
In the end I went with the untidy, "send multiple times and hope that the other end receives it at least once" method.

Other then the timing issue, that sounds like a great idea.

Thank you

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my robot using the propeller RECONAUTOR

simonl

Not entirely sure what you mean by 'timing issues'. So long as both PC & Prop' agree on baud-rate, it should just be a matter of getting the received bytes out of the serial object's input buffer before they get overwritten. If the input buffer is big enough to accept ALL bytes you send, then you shouldn't have any problems.

You should be aiming for something like:

1. Listen for incoming data (e.g. using simple_serial)

2. As data arrives, add it to a buffer (say dataIn[noparse][[/noparse]n], where 'n' starts at 0; so dataIn[noparse][[/noparse]0] is first byte received, dataIn is 2nd byte, etc)

3. Once all data has arrived, write it to EEPROM

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon

---

www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style

computer guy

I have never used a buffer before.
I usually read data in as a variable and then use it immediately.

like -

for i = 0 to 100 {
data = readCom();
Writeeeprom(data);
}

Sorry for the non spin code, was in a rush to respond.

How would I write and read to the buffer?

Thank you

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my robot using the propeller RECONAUTOR

simonl

OK, I'm typing this off the top of my head (neat trick huh?!), and it's in pseudo code too:

'Assuming you are going to receive 100 bytes

' Read serial data stream.
for i = 0 to 100
{
    data[noparse][[/noparse] i ] := readComm()
}

' Write data to EEPROM
for i = 0 to 100
{
    I2C.WriteLong(I2C#BootPin,I2C#EEPROM,$7FF4,@data[noparse][[/noparse] i ]) ' Not sure about syntax here...
    waitcnt(clkfreq/100 + cnt)  ' Wait 10ms for write to finish
}

I think part of your 'timing issues' may be down to the EEPROM needing ~10ms to write data; your loop's probably not giving it enough time?

HTH

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon

---

www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style

StefanL38

Hello Anthony,

first at all a question back

what are your programming-skills?

beginner

some experience in another language like "C", Visual Basic, Pascal, Delphi

much experience in another language


especially with microcontrollers?

beginner

some experience with (what kind of controller?)

if you answer ti this questions the forum can adapt the answers to your skill-level.

some advice from me:

Make your development modular. This means
start with a very very simple program that receives ONE byte and sends back this one byte
to the PC. Save this program with a name like Serial1ByteDemo.spin

If this is working make a small program only receiving and sending back a string.


If this is working create a small program that just is writing and reading back some bytes to the EEPROM
Save it as ReadWriteEEPROM-Demo.spin

make every function like "receiving one serial byte", "receiving a schedule-string", "readEEPROM-Byte", "save-EEPROM-Byte", "save ONE Schedule-Dataset to EEPROM"
their own PUB-procedure

This makes it possible to test every function itself
If the function is tested and OK you are sure this part works properly

Then it will be much easier to find bugs in your code

If this is working bring together 10 Byte receiving and read/write to EEPROM
etc. etc.


Now to SPIN-Code examples:

There are some propeller-objects you can use

in the propeller-tool-folder there is a file fullduplexserian.spin
the code of this objects manages the details of the serial communication

It has a buffer of 16 bytes. It is possible to change this value up to 256 bytes.
(but you have to change values in the ASM-Code too !)

This buffer is managed by the object itself. Only if you send more than 16 bytes
the oldest bytes were overwritten.

So as long as you need not more than 16 bytes for one schedule-entry you don't need to code a second buffer
in your program.

To make it more secure you could create a simple software-handshaking by sending back an acknowledge-byte
to say the PC "OK i (the prop) stored the last byte you can send me (the prop) the next byte


in the object-exchange

http://obex.parallax.com/

there is an object

Extended Full Duplex Serial

it has functions that work similar to your example "readCom()"

But be aware of: the propeller manages directly only longs, strings are managed like in "C" as zero-terminatet strings handled by pointers

So one easy solution could be receiving one byte of the schedule-data and then store it into the eeprom then the next byte an so on

If you hurry up throwing all functions "receive serial byte", "readEEPROM-Byte", "save-EEPROM-Byte" into two big loops trying to save time
you will loose three times more time for debugging that mess of code.

Every function its own PUB-procedure is much more effective.

greetings

Stefan

Ken Peterson

@computer guy: What type of software are you using on the PC to send the information to the Prop? Can you customize that?

I would set up the communication as a message, with a beginning, a data portion, and an end. The beginning would be some value that the Prop uses to identify the start of a message,and an indicator of the message length. The end would be an "end of message" indicator, perhaps preceded by a checksum of some sort. In between is your data. Once you have identified your maximum message length, set up a buffer (array) in the Prop into which you can easily dump the message directly from the serial object with a small loop (then you don't need to worry about the size of the receive buffer in the serial object). Use your message length indicator as a counter for your loop. After you have received the entire message, check your checksum (if implemented), save it to eeprom and send an acknowledgement message back to the PC to confirm success.

I have not had much luck with the SimpleSerial object (at least at 9600 baud) because I didn't have enough time between received bytes to do anything with the data. I suggest using FullDuplexSerial because the critical areas are written in ASM and it has a buffer.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


The more I know, the more I know I don't know.· Is this what they call Wisdom?

computer guy

Ken,
I am writing my own program in c#.
I am new to this language but have had success with getting the basics for my program started and am currently in the process if writing the serial part of it.
Thank you for sharing your thoughts on SimpleSerial and FullDuplexSerial.

Stefan,
Ok, I have done about 6months playing around with C++ about 5 years ago.
I am learning C# now and only started a few weeks ago.
I have done a bit of programming in spin, just general pwm and reading inputs setting outputs and pausing, still learning as I go.
I used the BS2 for a few months, learnt the general language and then moved on to the propeller for my robot project (in my signature below).
Thank you I will definitely start with a few small programs to test the functionality of the individual functions before going big.

Simonl,
Thank you, along with the code sample you provided and allot of code that... Mike Green (I think) Provided a while ago I think I am on the right track.

Thank you all

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my robot using the propeller RECONAUTOR