I've been seeing some weird traffic come through and some of the requests are invalid with really long urls. I don't know whether a request for //log0001.txt is valid though but I will add the code to handle it as it should be /log001.txt.
I notice in your Tachyon V2.3 code that cog 0 is left with only the serial receive PASM code.
Why not do receive and transmit in the same cog?
Thanks
rich
At the time I first wrote Tachyon I didn't want to be limited by these relatively slow speeds, even 115k is a push for the full-duplex object and I know that the bit timing at this speed is flakey. If you want precise bit timing at high speeds for full duplex you have to dedicate a cog to receive and one to transmit. But my kernel code didn't waste time trying to buffer anything for transmit because at high speeds you are far better off just bashing out the bits yourself (cog-wise speaking that is). So when I published Tachyon it was working at 3M baud and at this speed the Tachyon cog wastes little time transmitting. For a compromise, both for Bluetooth and for users who might be baud rate limited or were using PropForth I dropped the rate to it's present standard of 230,400 baud. Even my serial routines written in Tachyon Forth itself can handle these speeds too.
Now in saying all this I have been meaning to release a version where the high speed serial cog can switch to a slower speed but handle multiple full duplex buffered channels. At slower speeds it makes more sense to buffer transmit data so the system would switch it's emit vector over to the serial cog instead. This has uses in many applications where I don't need high speed but multiple serial ports.
I've been seeing some weird traffic come through and some of the requests are invalid with really long urls. I don't know whether a request for //log0001.txt is valid though but I will add the code to handle it as it should be /log001.txt.
Been trying to connect, sometimes I get part of the home page followed by garbled data and sometimes I get just a reset.
Probably between updates again.
Been trying to connect, sometimes I get part of the home page followed by garbled data and sometimes I get just a reset.
Probably between updates again.
Mac OSX 10.8.5 and I tried Safari, FF and Chrome
I think I need to adjust timeouts and I'm sure I have a bug in that I am disconnecting too early sometimes. Just haven't had time to check it properly, sorry. But once I fine tune it I will pile some real info onto the unit. Basically all the Tachyon support files etc. More than likely I will have more than one unit running and the RS232 and RS485 and Bluetooth ports running to some other Prop stuff. Since I have a couple of webcams floating around I could have one or two monitoring actual motor control, I'd like to do a robot arm --> pub THIRSTY REACH OPEN BEER GRASP SERVE ; . Anyway, whatever I hook up it will be educational and fun. (P.S. Parallax, C may be "educational" as in institutions, but it ain't fun).
Now in saying all this I have been meaning to release a version where the high speed serial cog can switch to a slower speed but handle multiple full duplex buffered channels. At slower speeds it makes more sense to buffer transmit data so the system would switch it's emit vector over to the serial cog instead. This has uses in many applications where I don't need high speed but multiple serial ports.
Howdy, I have been working with (learning) PropForth and have decided to try Tachyon. My first attempts at loading it have failed.
My process:
- load Tachyon V2.3.spin in the PropTool and press f11.
- kill PropTool.
- Load TerraTerm and connect to QuickStart board.
- Find nothing on screen, press CR several times
- note typical response: "
Tip: make sure you change your TeraTerm Setup->Port Transmit delay to around 23 msec/line, no char delay before you cut and pasted EXTEND.fth or you own code into the terminal for compilation.
.PINS
.INFO
Now back to your project (hardware, software, mechanical...) because a bunch of accidental complexity (compilers, linkers, sealed libraries, downloaders, separate terminal) has just been removed for you with this Tachyon / FORTH implementation, hat tip to PeterJ
I would recommend reading the Intro multiple times and doing each example multiple times, it can be very frustrating at first comming from a purely procedural programming background.
Howdy, I have been working with (learning) PropForth and have decided to try Tachyon. My first attempts at loading it have failed.
My process:
- load Tachyon V2.3.spin in the PropTool and press f11.
- kill PropTool.
- Load TerraTerm and connect to QuickStart board.
- Find nothing on screen, press CR several times
- note typical response: "
Thanks, Peter and D.P. Did what you said and it looks like I have a good beginning.
Over on PropForth I have a thread going "Learning Forth" where I was getting a lot of help from Loopy, who suggested I try Tachyon. Posted quite a bit about what I am doing.
I have some experience *long-ago* working with Forth on a New Micros Inc. board. I have a ways to go to wake all that up but it is now forward ho!
I am sure I will have more questions and I do thank your for responding so quickly.
Back again . . . I am using a QuickStart board - so after installing Tachyon and EXTEND.FTH I also attempted to install QS.FTH without success.
After ^C it does not show as a Module Loaded.
Do I need to edit the W5200 stuff out of the QS.FTH file?
Back again . . . I am using a QuickStart board - so after installing Tachyon and EXTEND.FTH I also attempted to install QS.FTH without success.
After ^C it does not show as a Module Loaded.
Do I need to edit the W5200 stuff out of the QS.FTH file?
The file in the drop box has a tick in it where it shouldn't it seems
\ ----- RTC has been tested
( S-35390A RTC )` \ <--- remove that tick
Also I had to increase my line delay to 40ms, maybe because, well let's just let Peter answer this.
00:00:10 End of source code, 0084 lines processed and 0000 errors found
Load time = 45,285ms
The file in the drop box has a tick in it where it shouldn't it seems
\ ----- RTC has been tested
( S-35390A RTC )` \ <--- remove that tick
Also I had to increase my line delay to 40ms, maybe because, well let's just let Peter answer this.
00:00:10 End of source code, 0084 lines processed and 0000 errors found
Load time = 45,285ms
I fired up a Win7 system with TeraTerm and a standard Parallax Prop demo board and cleaned up the tick in QS.FTH. Everything loaded fine with the standard Prop tool and with TeraTerm set to 20ms. Load time for QS.FTH was 4.2 secs so everything is fine so far. Since QS.fth does not automatically perform a BACKUP then any reset at this stage will lose QS.fth. I have just added the ?BACKUP word to the end of the document now so that it locks itself into EEPROM.
I can't see why there should be any other problems though. It doesn't matter if QS has the pin definitions for parts that haven't been loaded, it won't hurt.
EDIT: updated the versions and checked them though there seems to be an error in reporting the loading time, the actual time is much shorter, so I will check that but I think it is probably a temporary Forth register problem.
Note: It looks like extend.fth is not hte most current version as I removed QWORDS from the current version and extended WORDS with an optional control switch to modify the listing. Maybe I will change that back so that I still have one definition for WORDS but add QWORDS name to do the same thing as it did before.
Thanks you two. All good now. Time to start playing with the code.
BTW, I've noticed something strange when loading the *.fth files. The console echo of the loading process stops incrementing lines at the bottom of the page and just screen prints over and over on the same line. Any idea why?
Thanks you two. All good now. Time to start playing with the code.
BTW, I've noticed something strange when loading the *.fth files. The console echo of the loading process stops incrementing lines at the bottom of the page and just screen prints over and over on the same line. Any idea why?
Artifacts of the terminal session where [~ and ]~ suppress console "interaction", from extend.fth below. As long as you get 0000 errors every thing is nice.
\ start of load symbol - suppress console interaction
pub [~ OFF ECHO OFF OK ' LEMIT uemit W! ;
\ end of load symbol - reenable interactive console
pub ]~ ON ECHO ON OK 0 uemit W! ;
Thanks you two. All good now. Time to start playing with the code.
BTW, I've noticed something strange when loading the *.fth files. The console echo of the loading process stops incrementing lines at the bottom of the page and just screen prints over and over on the same line. Any idea why?
Not quite sure what you mean when you mean when you say it stop incrementing the lines etc as EXTEND.fth ends up processing 1615 lines but it doesn't count any comment blocks in there as the editor says that there are 2662 lines altogether. There are some words that echo even during a load and I suppose it would be really nice if they didn't maybe and that line numbers reflected the actual line itself and so on but normally these things aren't of great concern itself. Certainly if I was producing this Forth as a commercial product I would clean it up but the big emphasis in development is on actual use and runtime performance etc. That doesn't mean I won't tidy up some of these cosmetic details though as I would find them useful too, but there are only so many hours in a day to maintain and improve Tachyon and also to get my work done
But thanks for the feedback, I do take note and it's always good to get someone's first impressions, the hiccups they come across etc. I'm looking into a few of these things right at this moment.
EDIT: originally the tilde sequences [~ and ]~ were interpreted by the serial driver as well but these have since been removed. It may well be that I remove the requirement for tilde words altogether in updates and just have dummy words for them for legacy source.
EDIT: I see the bug with the load time report, I had introduced proper handling of nested braces a little while ago and that used the same spare location as the lap counter for counting the nesting levels. Fixed that up in the kernel so it's all good now.
I have been testing for output on a serial port I have set up on P27-Tx P26-Rx at 9600 baud. I have successfully made this test in PropForth.
I did the test shown under REDIRECTING OUTPUT.
I found that currently the correct entry is "9600 SERBAUD" by consulting the WORDS list.
Seemed to run okay on the Prop side but I received no output using an hp48 calculator as I have before.
I'm wondering if the fact I'm running with a 5 MHz clock and 16x PLL means I need to alter the parameter for SERBAUD.
An example of redirecting output is shown in the Intro where we need to define an EMIT or output word that the emit vector can point to and then we have an example of creating a word that sets that vector, in the case of a serial LCD we just say LCD ." whatever I tell you" CON and it will appear on the LCD. The 9600 SERBAUD only refers to setting the baudrate for the SEROUT word, nothing more. There are many many things in common between PropForth and Tachyon and perhaps many more differences, so consult the Intro as I try to cover the basics in this plus I just update it on the fly as required so it's always up-to-date as are all the Google webpage documents.
Say the HP calc is on P27 we can define the output as
: HPEMIT #P27 SEROUT ;
: HPKEY #P267 SERIN ;
: HP ' HPEMIT uemit W! ' HPKEY ukey W! ;
This may need some refinement and it's probably not as nice as having a proper multiport serial object running, but it's what I have used until now. There will be an upgrade soon to the serial cog to handle multiple serial ports.
A task which may be interesting to someone on this thread, the Forth skills for which I am currently lacking: DTMF decoding. There are chips which can perform this function, but they require 6 I/O pins (D0...D3, ENA#, Dataready). For the overall project I'm working on, I have a "spare cog" which could spend its time doing this if it's doable and reliable (1 pin certainly is nicer than 6).
For those not familiar with DTMF (Dual-tone Multi-frequency), it's the touch tones used in phone dialers, which is ubiquitous in Amateur radio control in addition to landline phones. It is a 4x4 matrix of non harmonically related tones between 697 and 1633 Hz mixed to create 16 sinusoidal waveforms. Thankfully, the tones were well thought out to avoid problems with harmonics and intermod, and the specs for tone accuracy are nice and tight (<1.8% deviation).
I have barely started thinking about how to determine frequency of a single-frequency square wave via Forth, let alone a dual tone sinusoidal wave. Anyone have any thoughts, or is it better to spend the 6 pins? I tend to jump in with both feet, and have done so with Forth, so easier to develop isn't necessarily better, if the end result is reliable with a smaller pin count. I'm definitely not looking for anyone to do it for me (where's the fun of learning in that?), but would be thankful for some pointers.
A task which may be interesting to someone on this thread, the Forth skills for which I am currently lacking: DTMF decoding. There are chips which can perform this function, but they require 6 I/O pins (D0...D3, ENA#, Dataready). For the overall project I'm working on, I have a "spare cog" which could spend its time doing this if it's doable and reliable (1 pin certainly is nicer than 6).
For those not familiar with DTMF (Dual-tone Multi-frequency), it's the touch tones used in phone dialers, which is ubiquitous in Amateur radio control in addition to landline phones. It is a 4x4 matrix of non harmonically related tones between 697 and 1633 Hz mixed to create 16 sinusoidal waveforms. Thankfully, the tones were well thought out to avoid problems with harmonics and intermod, and the specs for tone accuracy are nice and tight (<1.8% deviation).
I have barely started thinking about how to determine frequency of a single-frequency square wave via Forth, let alone a dual tone sinusoidal wave. Anyone have any thoughts, or is it better to spend the 6 pins? I tend to jump in with both feet, and have done so with Forth, so easier to develop isn't necessarily better, if the end result is reliable with a smaller pin count. I'm definitely not looking for anyone to do it for me (where's the fun of learning in that?), but would be thankful for some pointers.
A task which may be interesting to someone on this thread, the Forth skills for which I am currently lacking: DTMF decoding. There are chips which can perform this function, but they require 6 I/O pins (D0...D3, ENA#, Dataready). For the overall project I'm working on, I have a "spare cog" which could spend its time doing this if it's doable and reliable (1 pin certainly is nicer than 6).
For those not familiar with DTMF (Dual-tone Multi-frequency), it's the touch tones used in phone dialers, which is ubiquitous in Amateur radio control in addition to landline phones. It is a 4x4 matrix of non harmonically related tones between 697 and 1633 Hz mixed to create 16 sinusoidal waveforms. Thankfully, the tones were well thought out to avoid problems with harmonics and intermod, and the specs for tone accuracy are nice and tight (<1.8% deviation).
I have barely started thinking about how to determine frequency of a single-frequency square wave via Forth, let alone a dual tone sinusoidal wave. Anyone have any thoughts, or is it better to spend the 6 pins? I tend to jump in with both feet, and have done so with Forth, so easier to develop isn't necessarily better, if the end result is reliable with a smaller pin count. I'm definitely not looking for anyone to do it for me (where's the fun of learning in that?), but would be thankful for some pointers.
I asked about fixed point math operators in Tachyon because I'm having difficulty with an approach to translate some of my spin code.
UPDATE: Let's just forget this I'm gonna implement a table lookup method with smoothing, for the Buck method below I probably should use an off board MCU
{{
Calculate the relative humidity from a dry buld and wet bulb pair using the calculated staturation
vapor pressure at each bulb.
}}
CON
_CLKMODE = XTAL1 + PLL16X
_XINFREQ = 5_000_000
OBJ
f32 : "F32"
VAR
Long VPa 'Actual Vapor Pressure
Long Sd 'Saturation VP at dry bulb
Long Sw 'Saturation VP at wet bulb
Long Dryc 'Dry bulb temp in C
Long Wetc 'Wet bulb temp in C
Long Atm 'Atmospheric pressure in millibars
Long PerHum 'Percent Humidity
PUB CalcHumidity
'Saturation Vapour Pressure at Dry Temp in millibars
Sd := 6.112 * f32.Exp(f32.FDiv(f32.FMul(17.67, Dryc), f32.FAdd(243.5, Dryc)))
'Saturation Vapour Pressure at Wet Bulb in millibars
Sw := 6.112 * f32.Exp(f32.FDiv(f32.FMul(17.67, Wetc), f32.FAdd(243.5, Wetc)))
'Actual Vapour Pressure in millibars
VPa := f32.FSub(Sw, f32.FMul(0.00066, f32.FMul(f32.FAdd(1.0, f32.FMul(0.00115,Wetc)), f32.FMul(f32.FSub(Dryc, Wetc),Atm))))
'Humidity Percentage
PerHum := f32.FMul(100.0, f32.FDiv(VPa, Sd))
I sell a kit for the MT8870 chip for $5 plus $2 S&H ... it includes the chip, crystal, socket and three 1% precision resistors and two caps. You can find it here at my website.
I see what I did - omitted the "#P" in front of the port numbers. I guess that is a holdover from PF.
A multiple serial object sounds great. I am going to be running three serial peripherals. If you could include support for 7 bit with 2 stop bits that would be sweet. I know that stuff is oooold but I am building a kludge that needs it, maybe. The 7 bits would be for a Protek 506 DMM. I had run successful tests with the DMM and the hp48 using 8 bits on the calculator and just clearing the hi bit of data received. I expected the same to work on the Propeller but I couldn't get it going with PropForth even with very extensive experimentation which I believe eliminated all other possible causes. I'm hoping Tachyon is different in that respect.
I asked about fixed point math operators in Tachyon because I'm having difficulty with an approach to translate some of my spin code.
UPDATE: Let's just forget this I'm gonna implement a table lookup method with smoothing, for the Buck method below I probably should use an off board MCU
Would something like this be okay, assuming I had it ready to release?
I see what I did - omitted the "#P" in front of the port numbers. I guess that is a holdover from PF.
A multiple serial object sounds great. I am going to be running three serial peripherals. If you could include support for 7 bit with 2 stop bits that would be sweet. I know that stuff is oooold but I am building a kludge that needs it, maybe. The 7 bits would be for a Protek 506 DMM. I had run successful tests with the DMM and the hp48 using 8 bits on the calculator and just clearing the hi bit of data received. I expected the same to work on the Propeller but I couldn't get it going with PropForth even with very extensive experimentation which I believe eliminated all other possible causes. I'm hoping Tachyon is different in that respect.
Cheers . . .
The # forces the number to decimal and the P is ignored as these prefix number modes allow symbols to be intermixed in a number, writing #P6 just helps us to see it is P6, the port pin.
There is really no problem with running this at the moment using SERIN and SEROUT with the SERIN as part of a little buffer code running in their own cogs. I got some code I've used in other applications that I will post back up on the Intro page, so have a look back there soon. It's very easy to custom craft your own serial I/O in this fashion as it is all high level Forth, no PASM, and their are plenty of cogs available.
This is one way of doing it so you wouldn't need all those variables and that basically looks right I think.
Absolutely, I was looking at how many table entries I had to input and it's enormous. The problem gets real tricky around 95-100% consending RH, the saturation vapor equations become the most accurate.
Also your code makes perfect sense, I'm feeling the procedural syntax parasite leaving this host finally. One thing though is I don't see the DONATE button. [8>}
Comments
Normal remote connect to tachyonforth.com
I notice in your Tachyon V2.3 code that cog 0 is left with only the serial receive PASM code.
Why not do receive and transmit in the same cog?
Thanks
rich
Now in saying all this I have been meaning to release a version where the high speed serial cog can switch to a slower speed but handle multiple full duplex buffered channels. At slower speeds it makes more sense to buffer transmit data so the system would switch it's emit vector over to the serial cog instead. This has uses in many applications where I don't need high speed but multiple serial ports.
Been trying to connect, sometimes I get part of the home page followed by garbled data and sometimes I get just a reset.
Probably between updates again.
Mac OSX 10.8.5 and I tried Safari, FF and Chrome
That would be a great addition...
My process:
- load Tachyon V2.3.spin in the PropTool and press f11.
- kill PropTool.
- Load TerraTerm and connect to QuickStart board.
- Find nothing on screen, press CR several times
- note typical response: "
.PINS
.INFO
Now back to your project (hardware, software, mechanical...) because a bunch of accidental complexity (compilers, linkers, sealed libraries, downloaders, separate terminal) has just been removed for you with this Tachyon / FORTH implementation, hat tip to PeterJ
I would recommend reading the Intro multiple times and doing each example multiple times, it can be very frustrating at first comming from a purely procedural programming background.
I can help with basic questions.
Enjoy, welcome to the fun side.
Over on PropForth I have a thread going "Learning Forth" where I was getting a lot of help from Loopy, who suggested I try Tachyon. Posted quite a bit about what I am doing.
I have some experience *long-ago* working with Forth on a New Micros Inc. board. I have a ways to go to wake all that up but it is now forward ho!
I am sure I will have more questions and I do thank your for responding so quickly.
After ^C it does not show as a Module Loaded.
Do I need to edit the W5200 stuff out of the QS.FTH file?
The file in the drop box has a tick in it where it shouldn't it seems
Also I had to increase my line delay to 40ms, maybe because, well let's just let Peter answer this.
I fired up a Win7 system with TeraTerm and a standard Parallax Prop demo board and cleaned up the tick in QS.FTH. Everything loaded fine with the standard Prop tool and with TeraTerm set to 20ms. Load time for QS.FTH was 4.2 secs so everything is fine so far. Since QS.fth does not automatically perform a BACKUP then any reset at this stage will lose QS.fth. I have just added the ?BACKUP word to the end of the document now so that it locks itself into EEPROM.
I can't see why there should be any other problems though. It doesn't matter if QS has the pin definitions for parts that haven't been loaded, it won't hurt.
EDIT: updated the versions and checked them though there seems to be an error in reporting the loading time, the actual time is much shorter, so I will check that but I think it is probably a temporary Forth register problem.
Note: It looks like extend.fth is not hte most current version as I removed QWORDS from the current version and extended WORDS with an optional control switch to modify the listing. Maybe I will change that back so that I still have one definition for WORDS but add QWORDS name to do the same thing as it did before.
BTW, I've noticed something strange when loading the *.fth files. The console echo of the loading process stops incrementing lines at the bottom of the page and just screen prints over and over on the same line. Any idea why?
Artifacts of the terminal session where [~ and ]~ suppress console "interaction", from extend.fth below. As long as you get 0000 errors every thing is nice.
Not quite sure what you mean when you mean when you say it stop incrementing the lines etc as EXTEND.fth ends up processing 1615 lines but it doesn't count any comment blocks in there as the editor says that there are 2662 lines altogether. There are some words that echo even during a load and I suppose it would be really nice if they didn't maybe and that line numbers reflected the actual line itself and so on but normally these things aren't of great concern itself. Certainly if I was producing this Forth as a commercial product I would clean it up but the big emphasis in development is on actual use and runtime performance etc. That doesn't mean I won't tidy up some of these cosmetic details though as I would find them useful too, but there are only so many hours in a day to maintain and improve Tachyon and also to get my work done
But thanks for the feedback, I do take note and it's always good to get someone's first impressions, the hiccups they come across etc. I'm looking into a few of these things right at this moment.
EDIT: originally the tilde sequences [~ and ]~ were interpreted by the serial driver as well but these have since been removed. It may well be that I remove the requirement for tilde words altogether in updates and just have dummy words for them for legacy source.
EDIT: I see the bug with the load time report, I had introduced proper handling of nested braces a little while ago and that used the same spare location as the lap counter for counting the nesting levels. Fixed that up in the kernel so it's all good now.
I did the test shown under REDIRECTING OUTPUT.
I found that currently the correct entry is "9600 SERBAUD" by consulting the WORDS list.
Seemed to run okay on the Prop side but I received no output using an hp48 calculator as I have before.
I'm wondering if the fact I'm running with a 5 MHz clock and 16x PLL means I need to alter the parameter for SERBAUD.
An example of redirecting output is shown in the Intro where we need to define an EMIT or output word that the emit vector can point to and then we have an example of creating a word that sets that vector, in the case of a serial LCD we just say LCD ." whatever I tell you" CON and it will appear on the LCD. The 9600 SERBAUD only refers to setting the baudrate for the SEROUT word, nothing more. There are many many things in common between PropForth and Tachyon and perhaps many more differences, so consult the Intro as I try to cover the basics in this plus I just update it on the fly as required so it's always up-to-date as are all the Google webpage documents.
Say the HP calc is on P27 we can define the output as
: HPEMIT #P27 SEROUT ;
: HPKEY #P267 SERIN ;
: HP ' HPEMIT uemit W! ' HPKEY ukey W! ;
This may need some refinement and it's probably not as nice as having a proper multiport serial object running, but it's what I have used until now. There will be an upgrade soon to the serial cog to handle multiple serial ports.
OH HOLY COW you really cleaned up the loader in the lastest kernel, really nice.
For those not familiar with DTMF (Dual-tone Multi-frequency), it's the touch tones used in phone dialers, which is ubiquitous in Amateur radio control in addition to landline phones. It is a 4x4 matrix of non harmonically related tones between 697 and 1633 Hz mixed to create 16 sinusoidal waveforms. Thankfully, the tones were well thought out to avoid problems with harmonics and intermod, and the specs for tone accuracy are nice and tight (<1.8% deviation).
I have barely started thinking about how to determine frequency of a single-frequency square wave via Forth, let alone a dual tone sinusoidal wave. Anyone have any thoughts, or is it better to spend the 6 pins? I tend to jump in with both feet, and have done so with Forth, so easier to develop isn't necessarily better, if the end result is reliable with a smaller pin count. I'm definitely not looking for anyone to do it for me (where's the fun of learning in that?), but would be thankful for some pointers.
BTW: if you need any of those 8870 and 8880 (I think) DTMF chips I think I still have tubes of them from years back.
For the HT9170B at 2.45 a chip and 4 IOs not counting ENB or PWRdn (both could be held static)
http://www.ebay.com/itm/HT9170B-HT9170-Holtek-DTMF-Receiver-/200494796632
UPDATE: Let's just forget this I'm gonna implement a table lookup method with smoothing, for the Buck method below I probably should use an off board MCU
{{ Calculate the relative humidity from a dry buld and wet bulb pair using the calculated staturation vapor pressure at each bulb. }} CON _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 OBJ f32 : "F32" VAR Long VPa 'Actual Vapor Pressure Long Sd 'Saturation VP at dry bulb Long Sw 'Saturation VP at wet bulb Long Dryc 'Dry bulb temp in C Long Wetc 'Wet bulb temp in C Long Atm 'Atmospheric pressure in millibars Long PerHum 'Percent Humidity PUB CalcHumidity 'Saturation Vapour Pressure at Dry Temp in millibars Sd := 6.112 * f32.Exp(f32.FDiv(f32.FMul(17.67, Dryc), f32.FAdd(243.5, Dryc))) 'Saturation Vapour Pressure at Wet Bulb in millibars Sw := 6.112 * f32.Exp(f32.FDiv(f32.FMul(17.67, Wetc), f32.FAdd(243.5, Wetc))) 'Actual Vapour Pressure in millibars VPa := f32.FSub(Sw, f32.FMul(0.00066, f32.FMul(f32.FAdd(1.0, f32.FMul(0.00115,Wetc)), f32.FMul(f32.FSub(Dryc, Wetc),Atm)))) 'Humidity Percentage PerHum := f32.FMul(100.0, f32.FDiv(VPa, Sd))A multiple serial object sounds great. I am going to be running three serial peripherals. If you could include support for 7 bit with 2 stop bits that would be sweet. I know that stuff is oooold but I am building a kludge that needs it, maybe. The 7 bits would be for a Protek 506 DMM. I had run successful tests with the DMM and the hp48 using 8 bits on the calculator and just clearing the hi bit of data received. I expected the same to work on the Propeller but I couldn't get it going with PropForth even with very extensive experimentation which I believe eliminated all other possible causes. I'm hoping Tachyon is different in that respect.
Cheers . . .
Would something like this be okay, assuming I had it ready to release?
[FONT=courier new] pub SatVP ( temp -- satVP ) F32 17.67 OVER F* OVER 243.5 F+ F/ FExp ; pub CalcHumidity ( Atm Dryc Wetc -- rh ) F32 3 LOCAL '' Select F32 notation and save inputs as locals (X1=Wetc) X2 SatVp '' dry bulb satVP X1 SatVp '' wet bulb satVP X2 X1 F- X3 F* 0.00115 X1 F* 1.0 F+ ROT F* 0.00066 F* F- '' VPa SWAP F/ 100.0 F* 3 RELEASE ;[/FONT][FONT=courier new] [/FONT]This is one way of doing it so you wouldn't need all those variables and that basically looks right I think.
The # forces the number to decimal and the P is ignored as these prefix number modes allow symbols to be intermixed in a number, writing #P6 just helps us to see it is P6, the port pin.
There is really no problem with running this at the moment using SERIN and SEROUT with the SERIN as part of a little buffer code running in their own cogs. I got some code I've used in other applications that I will post back up on the Intro page, so have a look back there soon. It's very easy to custom craft your own serial I/O in this fashion as it is all high level Forth, no PASM, and their are plenty of cogs available.
Absolutely, I was looking at how many table entries I had to input and it's enormous. The problem gets real tricky around 95-100% consending RH, the saturation vapor equations become the most accurate.
Also your code makes perfect sense, I'm feeling the procedural syntax parasite leaving this host finally. One thing though is I don't see the DONATE button. [8>}