QuickStart board + RPi = ?
Rsadeika
Posts: 3,837
I gave up on the Propeller IDE, and I am now using the Propeller Tool, since I work on a Windows box. I am doing more tests with the mentioned prototype setup which consists of a QuickStart board, Raspberry Pi 2, and an XBee module. I will be adding a sht11 module, and possibly multiple DS18B20 doodads, and other doodads if I have enough COGs left. And of course the QS is a stand in for a Propeller HAT.
The intention is to have the Propeller drive the modules and sensors, while the RPi can do the data logging and other heavy lifting, like providing date and time, as an example. On the Propeller side, so far the RAM usage is minimal, but should increase, quite a bit, when I add the sht11 object to the mix.
So, the way this works, you need an XBee module connected to your PC, with a terminal program that logs into the XBee, then you will have a UI session with the Propeller program. Of course on the RPi side, I am using a freeBasic terminal program, which will be able to be run from an ssh login or an xrdp login. The command structure will be similar to what you get on the XBee side. The final goal, be able to get things like temperature readings from the placed sensors, set up specific data logging requirements, data log(s) will be saved on the RPI, ..., etc. Hope all this works as imagined, but then you never know what will happen, probably run out of COGS, or is memory come first?
As an aside, I noticed that PIMORONI sells some kind of mobile pi power thing. Now if you can mount that, and then mount a Propeller HAT on top of that, Hmm, could be an interesting setup.
Ray
The intention is to have the Propeller drive the modules and sensors, while the RPi can do the data logging and other heavy lifting, like providing date and time, as an example. On the Propeller side, so far the RAM usage is minimal, but should increase, quite a bit, when I add the sht11 object to the mix.
So, the way this works, you need an XBee module connected to your PC, with a terminal program that logs into the XBee, then you will have a UI session with the Propeller program. Of course on the RPi side, I am using a freeBasic terminal program, which will be able to be run from an ssh login or an xrdp login. The command structure will be similar to what you get on the XBee side. The final goal, be able to get things like temperature readings from the placed sensors, set up specific data logging requirements, data log(s) will be saved on the RPI, ..., etc. Hope all this works as imagined, but then you never know what will happen, probably run out of COGS, or is memory come first?
As an aside, I noticed that PIMORONI sells some kind of mobile pi power thing. Now if you can mount that, and then mount a Propeller HAT on top of that, Hmm, could be an interesting setup.
Ray
' Xsensor2.spin ' June 10, 2015 ' Using the Propeller Tool ' UI on XBee and RPi CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 OBJ term : "Extended_FDSerial" rpi : "Extended_FDSerial" misc : "tools" VAR long oneStack[100] PUB Start ' Rx Tx On QS board term.start(26,24,0,9600) ' Connect to XBee module rpi.start(27,25,0,115200) ' Connect to RPi /dev/ttyAMA0 cognew(talkRPI, @oneStack) ' COG for RPi connection main PUB main | inSbyte,inAbyte,workbyte term.str(string("Press CR to continue",10,13)) repeat inSbyte := term.Rx ' Waiting for a CR. if inSbyte == 13 term.str(string("Welcome",10,13)) repeat term.Tx("#") term.RxStr(@inStrg) if strcomp(@inStrg, @stopProg) ' If Quit term.str(@inStrg) CRLF term.str(string("Program Stopped!",10,13)) abort elseif strcomp(@inStrg, @onLED16) ' Turn on P16 LED hLED elseif strcomp(@inStrg, @offLED16) ' Turn off P16 LED lLED elseif strcomp(@inStrg, @teststrg) ' Get the date from RPi. rpi.str(string("date",10,13)) rpi.RxStr(@inStrg) term.str(@inStrg) ' Print on terminal screen. elseif strcomp(@inStrg, @teststrg1) ' Get the time from RPi. rpi.str(string("time",10,13)) rpi.RxStr(@inStrg) term.str(@inStrg) ' Print on terminal screen. else term.str(string("Invalid Command!",10,13)) PUB CRLF term.Tx(10) term.Tx(13) PUB hLED misc.high(16) PUB lLED misc.low(16) '' Cog is started for comm with the Raspberry Pi. '' For test, turns on/off P16 LED, from a RPi login. '' PUB talkRPI | inSbyte,inAbyte rpi.start(27,25,0,115200) misc.waitms(500) rpi.str(string("Press CR to continue",10,13)) repeat inSbyte := rpi.Rx if inSbyte == 13 rpi.str(string("Welcome",10,13)) repeat rpi.Tx("%") rpi.RxStr(@inStrg) if strcomp(@inStrg, @onLED16) hLED elseif strcomp(@inStrg, @offLED16) lLED else rpi.str(string("Invalid Command!",10,13)) DAT inStrg byte " ",0 stopProg byte "Quit",0 onLED16 byte "on16",0 offLED16 byte "off16",0 teststrg byte "date",0 teststrg1 byte "time",0
Comments
Ray
Ray
The address in RTemp is set by the cog running the Sensirion method. Specifically, it is set by the instruction "Rtemp := fp.FloatToFormat(rawTemp, 5, 0)". I've never used this object, but I assume it is converting a floating point number to a formatted string. FloatToFormat probably contains only one string buffer, so when you call it multiple times in the repeat loop you are over writing it with other formatted numbers.
You should copy the string to a unique buffer for each instance that you call FloatToFormat so they don't get overwritten.
I kind of like this new concept, saves a COG, with a slight drawback on some hesitation for showing a "#" symbol.
Ray
Since I will be adding a comm with the RPi, I need to have a continuous update of the Sensirion data, plus a continuous update will also help in the main pub. I will also implement the global 'Rtemp := fp.FloatToFormat(rawTemp, 5, 0)' and deal with the buffer overwrite, if there is such a occurrence, when I make a command request from the RPi program. If there is no solution using this strategy then I guess I will have to go back to putting the Sensirion code back into its own COG.
Ray
The C Sensirion sht11 code, that I am using, was developed by tdlivings, which has not been around lately,the program is working as expected. I will have to study the code some more to see what other sht11 data I can extract and use. After I do some more testing and add some more functionality, I will attach a "zip project".
To switch over to a Propeller HAT, a few problems have to be worked out. The PropellerIDE 0.9.45 version for the Raspberry Pi, does not have the cog_run() functionality, does not work with /dev/ttyAMA0 properly, and ...
The Propeller HAT itself will have to have an EEPROM available, cannot see loading the program every time. This should not be to big of a problem since the breadboard has enough room for the EEPROM, sht11 module, and an XBee module, I think. Now onto adding some functionality like talking to the RPi to get real time and date values.
Ray
A trade off with the program below, I am using sprintf(), which has pushed the program size to 18,792 bytes. Maybe somebody knows of a smaller code size solution for this.
At this point I am very pleased that the sht11 code is behaving when it is running in its own COG. This program is probably not for beginners, since I did have to use the Project Manager portion of SimpleIDE for some aspects of this project.
So far, as a Proof-of-Concept trial, it is working as expected. We shall see what happens when other devices/sensors get added to the mix. Will the Propeller be up to the job, from a memory/ COG availability aspect.
Ray
This is the freeBasic code that is used on the Raspberry Pi.
It seems that a small bug has crept in with the xbeeTalk() COG, these two lines are not showing up on the terminal screen at start up of the COG, the rest of the code runs fine. I have not the slightest idea as to why that is occurring. Anybody have an idea?
The next to-do is start adding code for the DS18B20 temperature sensor, I did find some C code for that module in the OBEX, now it is a matter of getting the code to work within this program.
I have my eye on adding a Parallax Gas Sensor board, but Parallax does not sell a CO2 or O sensors, plus I did not see any C code to work with the board. Anybody have any leads on where to get something like that? Actually I will want to be able to capture the sensor data, and not just set alarm positions.
So far Code Size is 23,584 bytes.
Ray
If you are only working with integers you can use sprinti () instead of sprintf (). That would save about 10k memory.
Tom
I am still undecided as to what accuracy I want my sht11 data to be, so I am still looking into the C driver code for the sht11 module. After a quick look see I noticed that all the variables were designated as 'long' type, now I am not so sure that it would be an easy fix to get 'float' data, without a major rewrite. I guess if one of the professional C coders would look at the program it would be much appreciated.
So where is all this heading, I still have to do more proofing, before I make a final decision. I started out with the QuickStart board and have switched over to the DNA-RTC board. It seems that the voltage distribution problems have disappeared. I am still thinking about a Propeller HAT type solution, but there are still some problems to overcome, my perception of course. I am making a mental note, but I get the impression that everybody thinks I am bashing the product(s), when I list them all. In my opinion, these products are no longer in Alpha state, or at least I thought so, I will just have to work around the obstacles to get too where I need to be.
Now that I tried both Spin and C, for the same program solution, I feel more confidant with using C to get what I want in a timely fashion. I am sure that some Spin coders are shaking there heads in disagreement, but I like to go with what I think I know, this not a slam against Spin. I think that if I had something like a freeBasic program for the Propeller, I would probably go with that instead of C, more heads shaking. No flame wars please.
Ray