Hey Peter,
Fantastic work - got it running at 104MHz (6.5MHz xtal)
Now for the SD card
BTW Here are my brief instructions...
TACHYON FORTH Instructions
--------------------------
RR20150309
Modify "TACHYON V2.4.spin" for correct xtal, pllx and baud.
Compile and download to eeprom with PropTool or equiv.
Download TeraTerm V4.86 (or later)
Setup Serial to 115,200 or 230,400 baud 8N1 and 20ms delay/line (and save)
TeraTerm should show the Tachyon startup screen.
^C {will reset the propeller/tachyon}
<cr> {should give an ok message}
<esc> {will cancel a current line input}
CREATE EXPLORER<cr> {sets up lshw and a few other extensions}
Copy "EXTEND.FTH" text (from WinWord or equiv)
Use TeraTerm Edit/Paste<cr> to insert the "EXTEND.FTH" extensions text.
Tachyon will respond as it goes...
words<cr> {will display the Tachyon Dictionary}
lshw<cr> {will display the hardware info}
Hey Peter,
Fantastic work - got it running at 104MHz (6.5MHz xtal)
Now for the SD card
BTW Here are my brief instructions...
Good, finally! Of course the instructions are mainly for non-standard crystal frequencies though plus there are prebuilt EXPLORER binaries that automatically adjust for 5 or 10MHz crystals too.
Thanks Peter.
Yesterday I drew out my RamBlade3 circuit (most of my stuff is packed away as we have had our daughter and twin 10 mth old boys with us for 7 weeks - they return home to S.Korea with hubby at the end of the week )
The SD card shared the data bus on the SRAM, and P27 (with pullup) goes to the /CE of the SDRAM and is inverted to an additional enable to the /CS of the SDcard. P28 & P29 are shared with the SRAM /OE and /WE.
So by default, the SD card can be driven with just P20..23 as DO,CLK,DI,/CS which is easily done.
&ce.do.di.clk SDPINS
&23.20.22.21 SDPINS
Just checking... this is not the same as the usual SD pins which are ordered low to high as DO, CLK, DI, /CE ???
SDPINS and MOUNT are not found.
I presume I need to load an SD.FTH or similar. Where might I find this?
Is there a similar DIR command?
Is there any way to list a subset of the dictionary? Or else to see if a dictionary word exists?
You will need to load in SDCARD.fth and EASYFILE.fth but if you have a header file for your board you can load this in beforehand and it will use the definitions from that file.
Now there have been quite a number of times that I wanted to list just part of the dictionary or a single word. There have been some attempts at doing so such as:
But I'm not happy with this and I want to implement a something a little more flexible. There is a HELP word that is being implemented which will list the word and if stack comments or help comments are found on file it will list these if selected, but I haven't gotten "a round tuit" yet. Watch this space!
Should I presume the latest are in dropbox? and the documents in google docs?
BTW What are the files marked P2212T's conflicted copy? ie should I just ignore these?
I have also been looking at creating a header file for my board(s)... I will post what I have shortly and ask q's.
Thanks for your help. Looking good!
I have a pasm driver with spin support for a 128*128 color LCD with ILI9163 (often described as Nokia 5110 color although there is really no similarity). Has this been done? If not, I might give it a go at converting to Tachyon.
Should I presume the latest are in dropbox? and the documents in google docs?
BTW What are the files marked P2212T's conflicted copy? ie should I just ignore these?
I have also been looking at creating a header file for my board(s)... I will post what I have shortly and ask q's.
Thanks for your help. Looking good!
I have a pasm driver with spin support for a 128*128 color LCD with ILI9163 (often described as Nokia 5110 color although there is really no similarity). Has this been done? If not, I might give it a go at converting to Tachyon.
Alright then, just had a look at the Dropbox files and saw all the conflicts due to my misbehaving tablet PC which had slipped out and hit the floor in one of those hurried !^&#! airport security checks leaving the delete and backspace key with a mind of their own! Have now cleaned up the Dropbox files.
The google docs are the masters and always the most current and you will find that if you select all and copy then only the text will be pasted into the terminal, very handy. There are some big block comments in there which slows down compilation time a little but not overly so.
You can use one of the header files as a reference for your board like the P8 doc here. The SD card driver allows for two LEDs to indicate busy and error but if you don't define these then it won't use them.
If you have mistakenly used a pullup resistor on your SD chip select then you will have to define your card detect method otherwise the card detect uses the SD card's internal pullup to sense the card rather than the switch which is in accordance with the official SD card specification document.
Thanks Peter.
Yes I have a pullup on /CS only. Unfortunately it is a RN4 so its not easy to remove/cut.
Anyway, now that I have seen your reference, I can dispense with the pullup for new designs. None of my existing designs were meant to have the SD card removed.
Thanks Peter.
Yes I have a pullup on /CS only. Unfortunately it is a RN4 so its not easy to remove/cut.
Anyway, now that I have seen your reference, I can dispense with the pullup for new designs. None of my existing designs were meant to have the SD card removed.
I don't think I've seen any circuits that utilize this internal pull-up for card detect, they all seem to copy one another and use a pull-up for "safety" and then use the card detect switch instead. Section 1.12.3 of Rev 2.2 of the SD Card product manual states
An internal pull-up resistor on the DAT3 line may be used for card detection (insertion/removal). The resistor can be disconnected during data transfer (using ACMD42). Additional practical card detection methods can be found in SD Physical Specifications application notes given by the SDA.
I think you will have fun with the file system and the virtual memory layer that it's built on. It's quite possible to treat the SD card as one big 4GB memory array if you want or read and write to multiple files with ease. At present the virtual memory layer only accesses the first 4GB of the card but I am putting other virtual memory access words in that treat each file as a virtual memory up to 4GB each.
FYI Peter, I bought a SanDisk 8GB Ultra (equiv Class 10) at OfficeWorks for <$8.00 and it works fine with Kye's FAT Engine.
At this price point, why would anyone buy anything less!
I will try it out with Tachyon and let you know how it goes.
FYI Peter, I bought a SanDisk 8GB Ultra (equiv Class 10) at OfficeWorks for <$8.00 and it works fine with Kye's FAT Engine.
At this price point, why would anyone buy anything less!
I will try it out with Tachyon and let you know how it goes.
Yes, the 4GB limit is only with virtual memory addressing as I have tested 32GB cards fine and besides I can't buy anything less than 8GB but you don't need anything fancy as we only ever do slow SPI on the Propeller and even the slowest cards are faster than that. I picked up some 32GB microSD with adapter for around $16 locally.
I've had serial Flash devices designed into quite a few products as options but it's only now that I am starting to get into using them. The P8 module on the IoT5500 uses a Spansion S25FL127S 128Mbit device which is capable of quad-SPI although I just run this in single I/O mode. So I have been playing with the commands in general and wrote a little utility to dump some of the information from the device. Next I will be interfacing to this as virtual memory similar to how the SD memory works in Tachyon.
So as a matter of curiosity has anyone had much to do with these types of devices with the Prop?
I wrote XMM drivers for a number of these serial flash chips for PropGCC but never this particular one. I will write one as soon as I'm able to pick up one of your modules though. :-)
I've been playing a bit more with these serial Flash devices but the size of the erase block means it's not an easy thing to go and change something that has already been written. SD cards are a lot easier, that's for sure.
While I was playing I wrote a value of 4000 to the status and configuration register (done sequentially) to set it for 512 byte pages rather than 256, only problem was that I didn't prefix the 4000 with my hex $ symbol and the system was in decimal so the config got written with a $0F instead, and guess what? bits 2 and 3 are OTP bits, arggh! Now some blocks are protected etc so I will play with this chip some more before I desolder it and replace it.
Here is a link to my source code document if you happen to have something similar. A few forumistas will be getting their IoT5500 modules soon so they could play with it then.
I have a whole pile of ebay goodies that I have to chew through and interface to the Prop eventually and one of the first ones I tackled is the DHT22 humidity and temperature sensor. This uses a single wire and can be used over long line lengths.
TACHYON [~
FORGET DHT22.fth
pub DHT22.fth PRINT" DHT22/AM2302 TEMPERATURE & HUMIDITY SENSOR - 150407.2200 " ;
{ NOTES
To use this source code just select all, copy, then paste into Tachyon via serial terminal
Tachyon is a Forth O/S for the Parallax Propeller multicore CPU.
Report problems to pbjtech@gmail.com
NOTE: this is just the initial test code - compensation and other enhancements are yet to be added
CHANGELOG:
150408
Rename RHT@ to DHT@ to match device naming etc.
Latched last valid readings - returns with these on checksum error or polled too soon
DESCRIPTION:
The DHT22 or AM2302 is a simple sensor that reports humidity and temperature via a simple serial I/O.
}
--- Define DHTPIN - to change at runtime just <mypin> ' DHTPIN 1+ !
#P14 == DHTPIN
LONG httime --- last time DHT was polled
WORD htref,rh,dht --- timing reference and last valid readings
BYTE htck --- checksum
pri DHTBIT ( -- cnt )
(WAITPEQ) --- wait for it to go high
0 COGREG@ --- get captured CNT
(WAITPNE) --- until it goes low
0 COGREG@ SWAP - --- calculate timing of high period
;
pri DHTBYTE ( -- byte )
0 8 FOR 2* DHTBIT htref W@ > 1 AND OR NEXT
DUP htck C+!
;
{HELP DHT@ ( -- rh temp | -1 )
Read the relative humidity and temperature from the DHT22
Return with rh and temp in Celsius
If an error occurred in the checksum then return last valid reading
If the sensor is polled more than once every 2 seconds then use last valid readings
Typical acquisition time ~6ms
}
pub DHT@ ( -- rh temp )
runtime @ httime @ - 2000 => --- don't poll more than once every 2 seconds
IF
runtime @ httime ! --- mark runtime when this was polled
htck C~
DHTPIN MASK 3 COGREG!
DHTPIN LOW 1 ms DHTPIN FLOAT --- Generate reset pulse
DHTBIT DROP --- wait for start of response
DHTBIT 3 / 2* htref W! --- use start bit as reference
DHTBYTE 8 SHL DHTBYTE + --- 2 bytes humidity reading
DHTBYTE 8 SHL DHTBYTE + --- 2 bytes temperature reading
htck C@ DHTBYTE = --- if checksum does not match then use last reading
IF dht W! rh W! ELSE 2DROP THEN --- latch readings if valid
THEN
rh W@ dht W@ --- return with latest valid result
;
{ Optional demonstration
pri .DECIMAL <# # "." HOLD #S #> PRINT$ ;
pub DEMO
CR
BEGIN
DHT@
<CR> PRINT" DHT22: " .DECIMAL PRINT" 'C @ " .DECIMAL PRINT" %RH"
2 seconds
ESC?
UNTIL
;
}
{ Usage:
DEMO
TEMPERATURE = 24.4'C RH = 51.7%
}
]~
END
I have a whole pile of ebay goodies that I have to chew through and interface to the Prop eventually and one of the first ones I tackled is the DHT22 humidity and temperature sensor. This uses a single wire and can be used over long line lengths.
TACHYON [~
FORGET DHT22.fth
pub DHT22.fth ." DHT22/AM2302 TEMPERATURE & HUMIDITY SENSOR - 150407.2200 " ;
#P14 == DHTPIN
WORD htref
BYTE htck
pub DHTBIT ( -- cnt )
(WAITPEQ) --- wait for it to go high
0 COGREG@ --- get captured CNT
(WAITPNE) --- until it goes low
0 COGREG@ SWAP - --- calculate timing
;
pub DHTBYTE ( -- byte )
0 8 FOR 2* DHTBIT htref W@ > 1 AND OR NEXT
DUP htck C+!
;
{HELP RHT@ ( -- rh temp | -1 )
Read the relative humidity and temperature from the DHT22
Return with rh and temp in Celsius if there were no errors
If an error occurred in the checksum then return with a single -1
}
pub RHT@ ( -- rh temp | -1 )
htck C~
DHTPIN MASK 3 COGREG!
DHTPIN LOW 1 ms DHTPIN FLOAT --- Generate reset pulse
DHTBIT DROP --- wait for start of response
DHTBIT 3 / 2* htref W! --- use start bit as reference
DHTBYTE 8 SHL DHTBYTE + --- 2 bytes temperature reading
DHTBYTE 8 SHL DHTBYTE + --- 2 bytes humidity reading
htck C@ DHTBYTE <> IF 2DROP -1 THEN --- if checksum does not match then error
;
{ Optional demonstration
pri .DECIMAL <# # "." HOLD #S #> PRINT$ ;
pub DEMO
CR
BEGIN
RHT@
<CR>
PRINT" TEMPERATURE = " .DECIMAL
PRINT" 'C RH = " .DECIMAL
PRINT" % "
2 seconds
ESC?
UNTIL
;
}
{ Usage:
DEMO
TEMPERATURE = 24.4'C RH = 51.7%
}
]~
END
Great Peter,
was so quiet here lately ...
I have this sensor also in my box waiting ...
The web document and the code here are a little different - which is ok ;-)
AND I think the comment first reading temp then rh is not consistent with the code.
So when the code works maybe correct the comment to avoid further confisuon (should be confusion ... ).
The web document and the code here are a little different - which is ok ;-)
AND I think the comment first reading temp then rh is not consistent with the code.
So when the code works maybe correct the comment to avoid further confisuon (should be confusion ... ).
Markus
Comments comments, as if they could affect the way the code works
I had to look carefully to find what you were talking about so you must have looked carefully to find it in the first place!
I've updated the code from the Google doc page (which was correct). The newer version latches the data and uses this reading if there are any communications checksum errors or if the sensor is polled sooner than 2 seconds although I didn't find any problems with polling this twice a second initially.
I plan to try these sensors in a commercial HVAC as I am looking at algorithms that can calculate/predict a better comfort setting as human perception of cold or warmth is not just dependant upon temperature but it seems other variables such as humidity, wind, light, O2/CO2, barometric pressure, etc and hormones. Except for the last variable I think I can have a Prop sense all the others
Comments comments, as if they could affect the way the code works
I had to look carefully to find what you were talking about so you must have looked carefully to find it in the first place!
I've updated the code from the Google doc page (which was correct). The newer version latches the data and uses this reading if there are any communications checksum errors or if the sensor is polled sooner than 2 seconds although I didn't find any problems with polling this twice a second initially.
I plan to try these sensors in a commercial HVAC as I am looking at algorithms that can calculate/predict a better comfort setting as human perception of cold or warmth is not just dependant upon temperature but it seems other variables such as humidity, wind, light, O2/CO2, barometric pressure, etc and hormones. Except for the last variable I think I can have a Prop sense all the others
' WAITPNE Wait until input is low - REG3 = mask, REG0 = CNT
_WAITPNE waitpne reg3,reg3 ' use COGREG3 as the mask
mov reg0,cnt ' capture count in COGREG0
jmp unext
' WAITPEQ Wait until input is high - REG3 = mask, REG1 = CNT
_WAITPEQ waitpeq reg3,reg3
mov reg1,cnt ' capture count in COGREG1
jmp unext
pri DHTBIT ( -- cnt )
(WAITPEQ) 0 COGREG@ --- wait for it to go high and get captured CNT
(WAITPNE) 0 COGREG@ --- until it goes low and get captured CNT
SWAP - --- calculate timing of high period
;
Shouldn't the code above be using 1 COGREG@ and 0 COGREG@ respectively? Aren't the results of each instruction stored in a different REG?
' WAITPNE Wait until input is low - REG3 = mask, REG0 = CNT
_WAITPNE waitpne reg3,reg3 ' use COGREG3 as the mask
mov reg0,cnt ' capture count in COGREG0
jmp unext
' WAITPEQ Wait until input is high - REG3 = mask, REG1 = CNT
_WAITPEQ waitpeq reg3,reg3
mov reg1,cnt ' capture count in COGREG1
jmp unext
pri DHTBIT ( -- cnt )
(WAITPEQ) 0 COGREG@ --- wait for it to go high and get captured CNT
(WAITPNE) 0 COGREG@ --- until it goes low and get captured CNT
SWAP - --- calculate timing of high period
;
Shouldn't the code above be using 1 COGREG@ and 0 COGREG@ respectively? Aren't the results of each instruction stored in a different REG?
See what happens when you make mistakes with Tachyon, it's so smart it still works!
You're right, I've stuffed that up and it is measuring the pulse cycle rather the the high period but it still works. I thought the values that I read weren't quite right as a zero worked out as 80us ($1DFC at 96Mhz) rather than 28us which it should be. Perhaps it was late (as usual) and I forgot how my own code works, which I often do anyway.
I will post an updated version but as you can see it still works fine as it is.
See what happens when you make mistakes with Tachyon, it's so smart it still works!
You're right, I've stuffed that up and it is measuring the pulse cycle rather the the high period but it still works. I thought the values that I read weren't quite right as a zero worked out as 80us ($1DFC at 96Mhz) rather than 28us which it should be. Perhaps it was late (as usual) and I forgot how my own code works, which I often do anyway.
I will post an updated version but as you can see it still works fine as it is.
just read the DHT11 and DHT22 datasheets I have.
DATA=8 bit integral RH data+8 bit decimal RH data+8 bit integral T data+8 bit decimal T data+8 bit checksum
pri .DECIMAL <# # "." HOLD #S #> PRINT$ ;
if I interpret this correctly (which I might not) ...
then a binary number is expected on the stack.
I do not see base set so it is probably #10.
so <# resets the pad
# write the lower digit correctly as the remainder of DIVMOD base
then we add a "." before.
then process the rest, which is the 16 bit number divided by 10,
but should be the upper byte.
But here we have 2 byte encoded BCD.
Do I miss something?
maybe this would work? ... yes it does
pri .DECIMAL2 DUP >B <# # DROP 8 SHR "." HOLD #S #> PRINT$ ;
&24:6 .DECIMAL2 24.6 ok
if I interpret this correctly (which I might not) ...
then a binary number is expected on the stack.
I do not see base set so it is probably #10.
so <# resets the pad
# write the lower digit correctly as the remainder of DIVMOD base
then we add a "." before.
then process the rest, which is the 16 bit number divided by 10,
but should be the upper byte.
But here we have 2 byte encoded BCD.
Do I miss something?
maybe this would work? ... yes it does
pri .DECIMAL2 DUP >B <# # DROP 8 SHR "." HOLD #S #> PRINT$ ;
&24:6 .DECIMAL2 24.6 ok
&24:6 creates a byte encoded decimal
&24:6 .S Data Stack (4)
$0000.1806 - 6150
The datasheets may be a bit confusing as to how to refer to lsb and msb but it is not BCD. I convert directly from 16-bit binary and the readings I get are correct. The data from the sensor is simply scaled by 10 and so the print routine and any other conversion just needs to take that into account.
The local airport weather reports 25.7'C and 49%RH while the DHT22 reads:
DHT22: 25.0'C @ 49.0%RH
So I think I have it set correctly as it is a fraction cooler here anyway. The .DECIMAL routine is just a patch and I need to make some enhancements to my .NUM or PRINTNUM routine to allow for decimal places.
The datasheets may be a bit confusing as to how to refer to lsb and msb but it is not BCD. I convert directly from 16-bit binary and the readings I get are correct. The data from the sensor is simply scaled by 10 and so the print routine and any other conversion just needs to take that into account.
The local airport weather reports 25.7'C and 49%RH while the DHT22 reads:
DHT22: 25.0'C @ 49.0%RH
So I think I have it set correctly as it is a fraction cooler here anyway. The .DECIMAL routine is just a patch and I need to make some enhancements to my .NUM or PRINTNUM routine to allow for decimal places.
makes sense - since you would have noticed the problem had it been there
datasheet is probably a bad translation from chinese.
at least I learnt something about the internals of the print formatter.
being very curious ...
what else is in the easter package ;-) ???
maybe time to order some new toys ...
so they are here, when the code is ready ... ;-)
Lots of sensor goodies but also the popular ping sensors which admittedly I have never used before, till now. Here is my take on driving these and converting the reading to distance in millimetres. Note that this does not use a PASM cog, just whatever cog Tachyon is running in.
[font=courier]#P14 == TRIG
#P15 == ECHO
: PING@ ( -- us )
ECHO MASK 3 COGREG! --- setup WAITPxx mask
TRIG HIGH TRIG HIGH TRIG LOW --- 10us trigger (dummy cycles)
(WAITPEQ) (WAITPNE) --- detect high period
0 COGREG@ 1 COGREG@ - --- calculate high period
CLKFREQ #1,000,000 / / --- convert cycles to us
;
: RANGE@ ( -- distance.mm ) PING@ 170145 * #1,000 / 954 * 1,000,000 / ;
[/font]
The 170145 is the speed of sound at sea level in mm/sec divided by 2 while the 954 is my fudge figure I needed to adjust the reading. The sequence of divide and multiply is just to keep it in range as an integer but the process is simple enough.
Lots of sensor goodies but also the popular ping sensors which admittedly I have never used before, till now. Here is my take on driving these and converting the reading to distance in millimetres. Note that this does not use a PASM cog, just whatever cog Tachyon is running in.
[font=courier]#P14 == TRIG
#P15 == ECHO
: PING@ ( -- us )
ECHO MASK 3 COGREG! --- setup WAITPxx mask
TRIG HIGH TRIG HIGH TRIG LOW --- 10us trigger (dummy cycles)
(WAITPEQ) (WAITPNE) --- detect high period
0 COGREG@ 1 COGREG@ - --- calculate high period
CLKFREQ #1,000,000 / / --- convert cycles to us
;
: RANGE@ ( -- distance.mm ) PING@ 170145 * #1,000 / 954 * 1,000,000 / ;
[/font]
The 170145 is the speed of sound at sea level in mm/sec divided by 2 while the 954 is my fudge figure I needed to adjust the reading. The sequence of divide and multiply is just to keep it in range as an integer but the process is simple enough.
I had used Brian Rileys code for the PING, which is a little more verbose.
TACHYON
{ PING.fth - PING))) ultrasonic range finder unit
UPDATED: 120818.1800 - bBR - complete overhaul
CREATED: 120817.1500 - Brian Riley - Underhill Center, VT, USA
BASEDON: 060508.0000 - Chris Savage/Jeff Martin, - Parallax
- pin 5 to SIG on prop with 1K resistor
- prop pins should be edited to your needs
PING))) Ultrasonic Distance Sensor (#28015)
┌───────────────────┐
│┌───┐ ┌───┐│ Connection To Propeller
││ ‣ │ PING))) │ ‣ ││ Remember PING))) Requires
│└───┘ └───┘│ +5V Power Supply
│ GND +5V SIG │
└─────┬───┬───┬─────┘
│ │  1K
 └┘ └ Pin
- Prop pin is fed in on the stack, it is MASKed for use by OUTxxx, IN, WAITPxx, etc
- The pinmask value on the top of the stack is DUPed before each I/O to preserve it
- The OUTxxx words set pin for output themselves, WAITPxx do not and require the INPUTS
- NEWCNT places current value of CNT on the top of the loop stack
- LAPCNT returns via the normal stack, the number of usecs since the NEWCNT was issued.
LAPCNT takes its name because the running CNT time can continued to be checked until
a new NEWCNT is issued
- *** NOTA BENE *** If you specify the wrong pin for the ping connection to the Prop
the code will hangup _HARD_ at the WAITPEQ. If so I hope you have a working
RESET button!
}
\ conversion constants for room temperature
\ for temperature compensation see Ping Manual
#73_746 CONSTANT toinches
#29_034 CONSTANT tocms
: PTICKS ( pin -- usecs )
MASK
DUP OUTCLR 1 ms \ clear signal pin
DUP OUTSET 3 us \ send >2 us pulse
DUP OUTCLR
DUP INPUTS \ turn pin around to listen
DUP WAITPEQ \ await PING sets line HIGH
NEWCNT \ store cnt
WAITPNE \ await PING sets line LOW
LAPCNT \ returns usecs since NEWCNT
;
\ ***************************************************************
: PINGMM ( pin -- distmm )
PTICKS
#10_000 * tocms / \ convert usecs to millimeters
;
: PINGCM ( pin -- distcm )
PINGMM 10 / \ convert millimeters to centimeters
;
: PINGIN ( pin -- distin )
PTICKS
#1_000 * toinches / \ convert usecs to inches
;
END
Did anybody see/hear from Brian recently?
I did not see him on the forums for a long time - hope he is well.
On his Underhill web site he has a lot of Forth goodies.
I had used Brian Rileys code for the PING, which is a little more verbose.
Did anybody see/hear from Brian recently?
I did not see him on the forums for a long time - hope he is well.
On his Underhill web site he has a lot of Forth goodies.
That code won't work anymore and NEWCNT and LAPCNT were replaced with LAP. The (WAITPNE) and (WAITPEQ) were changed to capture the CNT to a COGREG as well as to use an I/O mask from COGREG 3.
But the thing is that this PING code couldn't even be called an object, there are just a 5 lines of code, 64 bytes of code space, and it is simply called when needed without consuming a cog. This is just a snippet compared to any other PING implementations I've seen.
Looks like Brian's last visit was on the 10th but he hasn't posted anything for over a year. Hey Brian! give us a wave!
That code won't work anymore and NEWCNT and LAPCNT were replaced with LAP. The (WAITPNE) and (WAITPEQ) were changed to capture the CNT to a COGREG as well as to use an I/O mask from COGREG 3.
But the thing is that this PING code couldn't even be called an object, there are just a 5 lines of code, 64 bytes of code space, and it is simply called when needed without consuming a cog. This is just a snippet compared to any other PING implementations I've seen.
Looks like Brian's last visit was on the 10th but he hasn't posted anything for over a year. Hey Brian! give us a wave!
OK ... " a WAVE " ... amplitude ??? how many Hertz???
To make a long story short, as I said to Peter in a p.m. a couple of months ago I have been long and seemingly endless merry-go-round working with my neurologist to get my Parkinson's medications adjusted right. Every time we think we've got it, couple of months go by all okay, and then go back in the fog again. But, dare I utter it?? This time there is light at the end of the tunnel ... four months and still pumping on all cylinders. For now Parkinson's is an annoyance and an inconvenience. When it comes time to solder, my shaky hands quiet right down ... but my Apple Magic Mouse and Logitech trackball give me grief so I've gotten rather good using Mac OS X speech to text.
I am working with one of my boards that has two one megabit EEproms on it. I was wondering if the print$ code would be easy to point to the upper EEprom and maybe even expand it from 32k to 64k.
OK ... " a WAVE " ... amplitude ??? how many Hertz???
To make a long story short, as I said to Peter in a p.m. a couple of months ago I have been long and seemingly endless merry-go-round working with my neurologist to get my Parkinson's medications adjusted right. Every time we think we've got it, couple of months go by all okay, and then go back in the fog again. But, dare I utter it?? This time there is light at the end of the tunnel ... four months and still pumping on all cylinders. For now Parkinson's is an annoyance and an inconvenience. When it comes time to solder, my shaky hands quiet right down ... but my Apple Magic Mouse and Logitech trackball give me grief so I've gotten rather good using Mac OS X speech to text.
I am working with one of my boards that has two one megabit EEproms on it. I was wondering if the print$ code would be easy to point to the upper EEprom and maybe even expand it from 32k to 64k.
Okay then, amplitude is fine, if it Hertz then maybe you have a "sawtooth"
Talk about shaky hands, I was having that problem too with the prednisone which I was taking for the past 7 months, only just come off it a couple of weeks ago. Good to hear there's light at the end of the tunnel (as long as it's not a train!).
Have you had a look at EEWORDS? It compacts the dictionary into upper EEPROM and frees up a ton of space. Because of this I deprecated the use of EPRINT as that only saved about 1 or 2k usually. Just load EEWORDS before or after, run COMPACT when you are ready and BACKUP if you are happy. Any words created after a COMPACT are stored normally but can also be compacted again just by running COMPACT. The search routine uses a 6-bit hashing technique to index 1 of 64 blocks which is read in where the word will be found. This is then added to a dictionary cache which is really just a part of the normal RAM dictionary. When it searches for a word it first searches any dictionary in RAM which will "fall through" to the dictionary cache and if it's not found there then it does the hash lookup thing. If the word is found in cache or EEPROM it is always added or moved to the top of the cache to keep it fresh. You'd think that this might be slow but it runs pretty fast because of the cache as it tends to find the most common words very quickly.
Comments
Fantastic work - got it running at 104MHz (6.5MHz xtal)
Now for the SD card
BTW Here are my brief instructions...
TACHYON FORTH Instructions -------------------------- RR20150309 Modify "TACHYON V2.4.spin" for correct xtal, pllx and baud. Compile and download to eeprom with PropTool or equiv. Download TeraTerm V4.86 (or later) Setup Serial to 115,200 or 230,400 baud 8N1 and 20ms delay/line (and save) TeraTerm should show the Tachyon startup screen. ^C {will reset the propeller/tachyon} <cr> {should give an ok message} <esc> {will cancel a current line input} CREATE EXPLORER<cr> {sets up lshw and a few other extensions} Copy "EXTEND.FTH" text (from WinWord or equiv) Use TeraTerm Edit/Paste<cr> to insert the "EXTEND.FTH" extensions text. Tachyon will respond as it goes... words<cr> {will display the Tachyon Dictionary} lshw<cr> {will display the hardware info}Good, finally! Of course the instructions are mainly for non-standard crystal frequencies though plus there are prebuilt EXPLORER binaries that automatically adjust for 5 or 10MHz crystals too.
For your SD card setup there are two different ways to handle this. One is that you create a header file like P8.H[/url[ or else pass the pin parameters to SDPINS at runtime with the pins encoded as a long. To help encode bytes represented in decimal form as in IP notation there is the & prefix available so this makes it easy to enter and see which pins you are using even though it's packed as a long.
To setup pins at runtime use the SDPINS word:
SDPINS ( ce-miso-mosi-clk -- )
So if your CE were P26 and CLK happened to be the same as I2C at P28 and MOSI (data to DI of card) were P24 and MISO (data from card) were P25 you would run this:
&26.25.24.28 SDPINS
After which you can type MOUNT and proceed from there.
Have lots of fun!
Yesterday I drew out my RamBlade3 circuit (most of my stuff is packed away as we have had our daughter and twin 10 mth old boys with us for 7 weeks - they return home to S.Korea with hubby at the end of the week
The SD card shared the data bus on the SRAM, and P27 (with pullup) goes to the /CE of the SDRAM and is inverted to an additional enable to the /CS of the SDcard. P28 & P29 are shared with the SRAM /OE and /WE.
So by default, the SD card can be driven with just P20..23 as DO,CLK,DI,/CS which is easily done.
&ce.do.di.clk SDPINS
&23.20.22.21 SDPINS
Just checking... this is not the same as the usual SD pins which are ordered low to high as DO, CLK, DI, /CE ???
I presume I need to load an SD.FTH or similar. Where might I find this?
Is there a similar DIR command?
Is there any way to list a subset of the dictionary? Or else to see if a dictionary word exists?
You will need to load in SDCARD.fth and EASYFILE.fth but if you have a header file for your board you can load this in beforehand and it will use the definitions from that file.
Now there have been quite a number of times that I wanted to list just part of the dictionary or a single word. There have been some attempts at doing so such as:
[B]MATCH SD WORDS[/B] NFA CODE EXT ATRS def NAME ---------------------------------------- 0001: 6000 2E23 YCALL F6 h.....x. SDA ok [B]MATCH SP WORDS[/B] NFA CODE EXT ATRS def NAME ---------------------------------------- 0001: 63AA 2344 YCALL C4 h.....x. SPIPINS 0002: 66C7 1EDB YCALL 89 h.....x. SPR 0003: 675C 1DD8 YCALL 76 h.....x. SPACES 0004: 6F18 0EDE XCALL 96 h.....x. SP! 0005: 71BC 10BE XCALL 2B h.....x. SPACE 0006: 71D3 10D0 XCALL 2F h.....x. SPINNER ok [B]ANY & WORDS[/B] NFA CODE EXT ATRS def NAME ---------------------------------------- 0001: 59DA 3CF7 ZCALL 4D h.....x. &SDCS 0002: 59E3 3CEF VCALL 4C h.....x. &SDDI 0003: 59EC 3CE7 ZCALL 4C h.....x. &SDCK 0004: 59F5 3CDF VCALL 4B h.....x. &SDDO okBut I'm not happy with this and I want to implement a something a little more flexible. There is a HELP word that is being implemented which will list the word and if stack comments or help comments are found on file it will list these if selected, but I haven't gotten "a round tuit" yet. Watch this space!
I am not sure where to get the extra fth files from...
There are some files on Dropbox
https://www.dropbox.com/sh/yzrczasnorqp5i9/aWhAMPWt0T
There are some files here on google docs
https://docs.google.com/document/d/1kjfVx5Ig39VX0AGpUjxfDv_wCCrqoSmj_fvBRhku8QY/pub
https://docs.google.com/document/d/1kSBU6iT3kbPau8QQoxGs7gbkc5fGYiJIJjSOU0aDs2k/pub
The second set have documents included.
Should I presume the latest are in dropbox? and the documents in google docs?
BTW What are the files marked P2212T's conflicted copy? ie should I just ignore these?
I have also been looking at creating a header file for my board(s)... I will post what I have shortly and ask q's.
Thanks for your help. Looking good!
I have a pasm driver with spin support for a 128*128 color LCD with ILI9163 (often described as Nokia 5110 color although there is really no similarity). Has this been done? If not, I might give it a go at converting to Tachyon.
Alright then, just had a look at the Dropbox files and saw all the conflicts due to my misbehaving tablet PC which had slipped out and hit the floor in one of those hurried !^&#! airport security checks leaving the delete and backspace key with a mind of their own! Have now cleaned up the Dropbox files.
The google docs are the masters and always the most current and you will find that if you select all and copy then only the text will be pasted into the terminal, very handy. There are some big block comments in there which slows down compilation time a little but not overly so.
You can use one of the header files as a reference for your board like the P8 doc here. The SD card driver allows for two LEDs to indicate busy and error but if you don't define these then it won't use them.
If you have mistakenly
Yes I have a pullup on /CS only. Unfortunately it is a RN4 so its not easy to remove/cut.
Anyway, now that I have seen your reference, I can dispense with the pullup for new designs. None of my existing designs were meant to have the SD card removed.
I don't think I've seen any circuits that utilize this internal pull-up for card detect, they all seem to copy one another and use a pull-up for "safety" and then use the card detect switch instead. Section 1.12.3 of Rev 2.2 of the SD Card product manual states
I think you will have fun with the file system and the virtual memory layer that it's built on. It's quite possible to treat the SD card as one big 4GB memory array if you want or read and write to multiple files with ease. At present the virtual memory layer only accesses the first 4GB of the card but I am putting other virtual memory access words in that treat each file as a virtual memory up to 4GB each.
At this price point, why would anyone buy anything less!
I will try it out with Tachyon and let you know how it goes.
Yes, the 4GB limit is only with virtual memory addressing as I have tested 32GB cards fine and besides I can't buy anything less than 8GB but you don't need anything fancy as we only ever do slow SPI on the Propeller and even the slowest cards are faster than that. I picked up some 32GB microSD with adapter for around $16 locally.
So as a matter of curiosity has anyone had much to do with these types of devices with the Prop?
Not that one, but I did see Microchip have just released some same-area parts
http://www.microchip.com/pagehandler/en-us/press-release/3v-16-mbit-32-mbit-and-64-mbit.html
While I was playing I wrote a value of 4000 to the status and configuration register (done sequentially) to set it for 512 byte pages rather than 256, only problem was that I didn't prefix the 4000 with my hex $ symbol and the system was in decimal so the config got written with a $0F instead, and guess what? bits 2 and 3 are OTP bits, arggh! Now some blocks are protected etc so I will play with this chip some more before I desolder it and replace it.
Here is a link to my source code document if you happen to have something similar. A few forumistas will be getting their IoT5500 modules soon so they could play with it then.
Google source code document
TACHYON [~ FORGET DHT22.fth pub DHT22.fth PRINT" DHT22/AM2302 TEMPERATURE & HUMIDITY SENSOR - 150407.2200 " ; { NOTES To use this source code just select all, copy, then paste into Tachyon via serial terminal Tachyon is a Forth O/S for the Parallax Propeller multicore CPU. Report problems to pbjtech@gmail.com NOTE: this is just the initial test code - compensation and other enhancements are yet to be added CHANGELOG: 150408 Rename RHT@ to DHT@ to match device naming etc. Latched last valid readings - returns with these on checksum error or polled too soon DESCRIPTION: The DHT22 or AM2302 is a simple sensor that reports humidity and temperature via a simple serial I/O. } --- Define DHTPIN - to change at runtime just <mypin> ' DHTPIN 1+ ! #P14 == DHTPIN LONG httime --- last time DHT was polled WORD htref,rh,dht --- timing reference and last valid readings BYTE htck --- checksum pri DHTBIT ( -- cnt ) (WAITPEQ) --- wait for it to go high 0 COGREG@ --- get captured CNT (WAITPNE) --- until it goes low 0 COGREG@ SWAP - --- calculate timing of high period ; pri DHTBYTE ( -- byte ) 0 8 FOR 2* DHTBIT htref W@ > 1 AND OR NEXT DUP htck C+! ; {HELP DHT@ ( -- rh temp | -1 ) Read the relative humidity and temperature from the DHT22 Return with rh and temp in Celsius If an error occurred in the checksum then return last valid reading If the sensor is polled more than once every 2 seconds then use last valid readings Typical acquisition time ~6ms } pub DHT@ ( -- rh temp ) runtime @ httime @ - 2000 => --- don't poll more than once every 2 seconds IF runtime @ httime ! --- mark runtime when this was polled htck C~ DHTPIN MASK 3 COGREG! DHTPIN LOW 1 ms DHTPIN FLOAT --- Generate reset pulse DHTBIT DROP --- wait for start of response DHTBIT 3 / 2* htref W! --- use start bit as reference DHTBYTE 8 SHL DHTBYTE + --- 2 bytes humidity reading DHTBYTE 8 SHL DHTBYTE + --- 2 bytes temperature reading htck C@ DHTBYTE = --- if checksum does not match then use last reading IF dht W! rh W! ELSE 2DROP THEN --- latch readings if valid THEN rh W@ dht W@ --- return with latest valid result ; { Optional demonstration pri .DECIMAL <# # "." HOLD #S #> PRINT$ ; pub DEMO CR BEGIN DHT@ <CR> PRINT" DHT22: " .DECIMAL PRINT" 'C @ " .DECIMAL PRINT" %RH" 2 seconds ESC? UNTIL ; } { Usage: DEMO TEMPERATURE = 24.4'C RH = 51.7% } ]~ ENDwas so quiet here lately ...
I have this sensor also in my box waiting ...
The web document and the code here are a little different - which is ok ;-)
AND I think the comment first reading temp then rh is not consistent with the code.
So when the code works maybe correct the comment to avoid further confisuon (should be confusion ... ).
Markus
Comments comments, as if they could affect the way the code works
I had to look carefully to find what you were talking about so you must have looked carefully to find it in the first place!
I've updated the code from the Google doc page (which was correct). The newer version latches the data and uses this reading if there are any communications checksum errors or if the sensor is polled sooner than 2 seconds although I didn't find any problems with polling this twice a second initially.
I plan to try these sensors in a commercial HVAC as I am looking at algorithms that can calculate/predict a better comfort setting as human perception of cold or warmth is not just dependant upon temperature but it seems other variables such as humidity, wind, light, O2/CO2, barometric pressure, etc and hormones. Except for the last variable I think I can have a Prop sense all the others
' WAITPNE Wait until input is low - REG3 = mask, REG0 = CNT _WAITPNE waitpne reg3,reg3 ' use COGREG3 as the mask mov reg0,cnt ' capture count in COGREG0 jmp unext ' WAITPEQ Wait until input is high - REG3 = mask, REG1 = CNT _WAITPEQ waitpeq reg3,reg3 mov reg1,cnt ' capture count in COGREG1 jmp unext pri DHTBIT ( -- cnt ) (WAITPEQ) 0 COGREG@ --- wait for it to go high and get captured CNT (WAITPNE) 0 COGREG@ --- until it goes low and get captured CNT SWAP - --- calculate timing of high period ;Shouldn't the code above be using 1 COGREG@ and 0 COGREG@ respectively? Aren't the results of each instruction stored in a different REG?
See what happens when you make mistakes with Tachyon, it's so smart it still works!
You're right, I've stuffed that up and it is measuring the pulse cycle rather the the high period but it still works. I thought the values that I read weren't quite right as a zero worked out as 80us ($1DFC at 96Mhz) rather than 28us which it should be. Perhaps it was late (as usual) and I forgot how my own code works, which I often do anyway.
I will post an updated version but as you can see it still works fine as it is.
This statement is usually reserved for C and pointer math I believe
then a binary number is expected on the stack.
I do not see base set so it is probably #10.
so <# resets the pad
# write the lower digit correctly as the remainder of DIVMOD base
then we add a "." before.
then process the rest, which is the 16 bit number divided by 10,
but should be the upper byte.
But here we have 2 byte encoded BCD.
Do I miss something?
maybe this would work? ... yes it does
&24:6 creates a byte encoded decimal
The datasheets may be a bit confusing as to how to refer to lsb and msb but it is not BCD. I convert directly from 16-bit binary and the readings I get are correct. The data from the sensor is simply scaled by 10 and so the print routine and any other conversion just needs to take that into account.
The local airport weather reports 25.7'C and 49%RH while the DHT22 reads:
DHT22: 25.0'C @ 49.0%RH
So I think I have it set correctly as it is a fraction cooler here anyway. The .DECIMAL routine is just a patch and I need to make some enhancements to my .NUM or PRINTNUM routine to allow for decimal places.
makes sense - since you would have noticed the problem had it been there
datasheet is probably a bad translation from chinese.
at least I learnt something about the internals of the print formatter.
what else is in the easter package ;-) ???
maybe time to order some new toys ...
so they are here, when the code is ready ... ;-)
Lots of sensor goodies but also the popular ping sensors which admittedly I have never used before, till now. Here is my take on driving these and converting the reading to distance in millimetres. Note that this does not use a PASM cog, just whatever cog Tachyon is running in.
[font=courier]#P14 == TRIG #P15 == ECHO : PING@ ( -- us ) ECHO MASK 3 COGREG! --- setup WAITPxx mask TRIG HIGH TRIG HIGH TRIG LOW --- 10us trigger (dummy cycles) (WAITPEQ) (WAITPNE) --- detect high period 0 COGREG@ 1 COGREG@ - --- calculate high period CLKFREQ #1,000,000 / / --- convert cycles to us ; : RANGE@ ( -- distance.mm ) PING@ 170145 * #1,000 / 954 * 1,000,000 / ; [/font]The 170145 is the speed of sound at sea level in mm/sec divided by 2 while the 954 is my fudge figure I needed to adjust the reading. The sequence of divide and multiply is just to keep it in range as an integer but the process is simple enough.
TACHYON { PING.fth - PING))) ultrasonic range finder unit UPDATED: 120818.1800 - bBR - complete overhaul CREATED: 120817.1500 - Brian Riley - Underhill Center, VT, USA BASEDON: 060508.0000 - Chris Savage/Jeff Martin, - Parallax - pin 5 to SIG on prop with 1K resistor - prop pins should be edited to your needs PING))) Ultrasonic Distance Sensor (#28015) ┌───────────────────┐ │┌───┐ ┌───┐│ Connection To Propeller ││ ‣ │ PING))) │ ‣ ││ Remember PING))) Requires │└───┘ └───┘│ +5V Power Supply │ GND +5V SIG │ └─────┬───┬───┬─────┘ │ │  1K  └┘ └ Pin - Prop pin is fed in on the stack, it is MASKed for use by OUTxxx, IN, WAITPxx, etc - The pinmask value on the top of the stack is DUPed before each I/O to preserve it - The OUTxxx words set pin for output themselves, WAITPxx do not and require the INPUTS - NEWCNT places current value of CNT on the top of the loop stack - LAPCNT returns via the normal stack, the number of usecs since the NEWCNT was issued. LAPCNT takes its name because the running CNT time can continued to be checked until a new NEWCNT is issued - *** NOTA BENE *** If you specify the wrong pin for the ping connection to the Prop the code will hangup _HARD_ at the WAITPEQ. If so I hope you have a working RESET button! } \ conversion constants for room temperature \ for temperature compensation see Ping Manual #73_746 CONSTANT toinches #29_034 CONSTANT tocms : PTICKS ( pin -- usecs ) MASK DUP OUTCLR 1 ms \ clear signal pin DUP OUTSET 3 us \ send >2 us pulse DUP OUTCLR DUP INPUTS \ turn pin around to listen DUP WAITPEQ \ await PING sets line HIGH NEWCNT \ store cnt WAITPNE \ await PING sets line LOW LAPCNT \ returns usecs since NEWCNT ; \ *************************************************************** : PINGMM ( pin -- distmm ) PTICKS #10_000 * tocms / \ convert usecs to millimeters ; : PINGCM ( pin -- distcm ) PINGMM 10 / \ convert millimeters to centimeters ; : PINGIN ( pin -- distin ) PTICKS #1_000 * toinches / \ convert usecs to inches ; ENDDid anybody see/hear from Brian recently?
I did not see him on the forums for a long time - hope he is well.
On his Underhill web site he has a lot of Forth goodies.
That code won't work anymore and NEWCNT and LAPCNT were replaced with LAP. The (WAITPNE) and (WAITPEQ) were changed to capture the CNT to a COGREG as well as to use an I/O mask from COGREG 3.
But the thing is that this PING code couldn't even be called an object, there are just a 5 lines of code, 64 bytes of code space, and it is simply called when needed without consuming a cog. This is just a snippet compared to any other PING implementations I've seen.
Looks like Brian's last visit was on the 10th but he hasn't posted anything for over a year. Hey Brian! give us a wave!
OK ... " a WAVE " ... amplitude ??? how many Hertz???
To make a long story short, as I said to Peter in a p.m. a couple of months ago I have been long and seemingly endless merry-go-round working with my neurologist to get my Parkinson's medications adjusted right. Every time we think we've got it, couple of months go by all okay, and then go back in the fog again. But, dare I utter it?? This time there is light at the end of the tunnel ... four months and still pumping on all cylinders. For now Parkinson's is an annoyance and an inconvenience. When it comes time to solder, my shaky hands quiet right down ... but my Apple Magic Mouse and Logitech trackball give me grief so I've gotten rather good using Mac OS X speech to text.
I am working with one of my boards that has two one megabit EEproms on it. I was wondering if the print$ code would be easy to point to the upper EEprom and maybe even expand it from 32k to 64k.
Okay then, amplitude is fine, if it Hertz then maybe you have a "sawtooth"
Talk about shaky hands, I was having that problem too with the prednisone which I was taking for the past 7 months, only just come off it a couple of weeks ago. Good to hear there's light at the end of the tunnel (as long as it's not a train!).
Have you had a look at EEWORDS? It compacts the dictionary into upper EEPROM and frees up a ton of space. Because of this I deprecated the use of EPRINT as that only saved about 1 or 2k usually. Just load EEWORDS before or after, run COMPACT when you are ready and BACKUP if you are happy. Any words created after a COMPACT are stored normally but can also be compacted again just by running COMPACT. The search routine uses a 6-bit hashing technique to index 1 of 64 blocks which is read in where the word will be found. This is then added to a dictionary cache which is really just a part of the normal RAM dictionary. When it searches for a word it first searches any dictionary in RAM which will "fall through" to the dictionary cache and if it's not found there then it does the hash lookup thing. If the word is found in cache or EEPROM it is always added or moved to the top of the cache to keep it fresh. You'd think that this might be slow but it runs pretty fast because of the cache as it tends to find the most common words very quickly.