TACHYON and the C3 ?
Rsadeika
Posts: 3,824
in Propeller 1
Since I have been experimenting with the C3 using PropGCC, now I am wondering what can tachyon do with the C3 board? One of the things I did want to accomplish is to use the COGs in the XMMC space, can tachyon do something similar, or can tachyon use all of the resources that the C3 has? Putting it another way, is there a version of tachyon that is set up to use all the resources of the C3.
Since the C3 board has things like VGA, ADC, expanded memory, sound, just to name a few, if you wanted to set up a program to utilize all of that, I think you would probably need to use all the memory that is available. Not sure about that though, anyway, has anybody tried using tachyon with the C3 board?
Ray
Since the C3 board has things like VGA, ADC, expanded memory, sound, just to name a few, if you wanted to set up a program to utilize all of that, I think you would probably need to use all the memory that is available. Not sure about that though, anyway, has anybody tried using tachyon with the C3 board?
Ray
Comments
The C3's SPI interface has a less than desirable 4-bit counter to select an SPI device such as the microSD which has to step through the SPI selects until it reaches the microSD and the sad part is that there is no gating of it at all, if you want to deselect and reselect you have reset/step or step back around to do this. A one-of-eight mux needing only one extra line would have been much better at least. This awkward behaviour can be patched however into the SDCARD.fth source to accommodate this. I will look at creating a C3 binary with the FAT32 filesystem and VGA Explorer etc to simplify this but someone needs to test it.
Now it seems that I would probably have a better shot at trying to do something with the QS+HIB. To bad the HIB did not have a 40 pin header, so you could at least been able to attach a blank expansion board on top of the HIB. I know, now it will start looking like an unstable tower, and besides that I think the power distribution is a little on the light side for any major expansion.
The big question, is there a good base board for using tachyon, yes it would have to have a potential for some decent peripheral attachment. Something ready to go out of the box, no blank boards with a bag of parts that have to be soldered.
Ray
https://www.parallax.com/downloads/p8x32a-quickstart-proto-board-kit-documentation
To bad tachyon does not support the sht11 module, I have a couple of those laying around. Also, if I were to attach a TTL-USB cable to some pins on the HIB, could I get access to tachyon via a terminal program? Or can that only work by using the USB on the QS board? I think this has the makings for another experiment.
Ray
Tachyon supports the DHT22, and setting up the protocol for sht11 is a nice exercise ;-)
Best thing to do is to not worry too much, just load Tachyon on a board and explore. The serial comms is always active if you conect to it via a terminal, preferably a proper terminal like Teraterm or minicom etc.
[code]
0 == HDA --- SHT11 data
1 == HCL --- SHT11 clock
--- SHT11 transmission start seq. - remap pins and use I2C routines
pub TS
HDA HCL I2CPINS --- reassign pins for I2C routines
I2CSTART I2CSTOP SCL LOW --- TS
;
BYTE crc
pub TEMP@ ( -- data )
TS
3 I2C! --- measure temperature command
BEGIN HDA PIN@ 0= UNTIL --- wait for completion signal
0 I2C@ 8
As I mentioned, in another thread, I would like to try making the C3 into a Tachyon Propeller/sht11 data acquisition unit for an indoor environment. With the time and weather display on a VGA screen, that could be an interesting starting point where I could then have the time, inside temp/humidity, and the outside temp/humidity displayed(data acquired from my outside unit). Am I getting to ambitious?
Ray
Ray
The DHT22 only requires a single wire and a fairly easy protocol and they are cheap, is there a reason for the SHT11 as the DHT22 is supposed to replace that part? I did post some test code for the SHT11 but I can't really test it.
edit: I see adafruit have discontinued the SHT11.
The DHT22 only requires a single wire and a fairly easy protocol and they are cheap, is there a reason for the SHT11 as the DHT22 is supposed to replace that part? I did post some test code for the SHT11 but I can't really test it.
edit: I see adafruit have discontinued the SHT11.
I buy most of my stuff, like the sht11 module, from Parallax, this is a Parallax forum, so I try to support them in that way. Yes, I wish Parallax would sell some dht22 modules, some CO2 detectors and O modules, and assorted stuff. And Peter Jakacki could support some of the things, like boards and modules, that Parallax sells, as it pertains to Tachyon :-). But then that is just my opinion.
Ray
Trouble is, I don't sell Tachyon, it's free. Since it's free then I guess I am supporting Parallax in a way.
If Parallax felt like supplying such boards and devices to me for support in Tachyon then I would also do that for free, but I don't think that's going to happen.
Trouble is, I don't sell Tachyon, it's free. Since it's free then I guess I am supporting Parallax in a way.
If Parallax felt like supplying such boards and devices to me for support in Tachyon then I would also do that for free, but I don't think that's going to happen.
I think you are right about getting some free stuff to test out with Tachyon, that would open up a can of worms. Next thing you know they would have to provide PropForth with stuff, and then you would probably see other people raising there hands, where is my free stuff, I am developing things also.
Now I feel kind of guilty that I am not giving PropForth a chance, and supposedly PropBasic is supposed to be resurrected, so now I would have to give them a chance, since that will be supported by Parallax, or at least that was the indication as of, what, five months ago. This is enough to make your head spin.
Ray
Well as you can see anyway, Tachyon is about getting things done, as in the case of the simple VGA clock for instance and many other projects that I have featured on the pages of this forum. If I could get the same job done with other tools and as easily as I do in Tachyon then I probably would never have bothered to create it in the first place. I like Spin but it's too slow and every little bit of PASM needs to run in another cog as well. As for other Forths they are just too slow and not as compact as is also the trouble with C on the Prop, plus they all seem to be about "themselves" rather than getting an actual project done. The reason we use tools after all is to make things, isn't it?
Thanks again for your work time and effort!!!
I downloaded the Spin versions 2.4 - 2.7:
Using the Propeller Tool I ran ver 2.7 and I get: line 1043 -> address out of range error. Does not compile.
ver 2.6, when I type in '14 HIGH' and hit enter the program freezes.
ver 2.5 and 2.4, when I type in '14 HIGH' I get: --> HIGH <-- Not Found ????????
To be fair it does do the '*' example from your short tutorial. So at this point I am not sure what is going on. I am using Tera Term as the terminal program with 'flow control' set to NONE. I will use version 2.4 and see if I can get some of the other examples to work as expected, from your tutorial. These were downloaded from your 'DropBox' area.
Ray
and then --> RX <-- not found ???????? , --> A$ <-- not found ?????????, and that is it.
This does not look good for working with the C3, unless of course somebody else has it installed and got past the items I am having trouble with.
I might have to try out ver 2.4 - 2.7 on my QS board and see if that works any better.
Ray
start with s.th. big and see if it works then.
this delay is different from the normal one
30ms should do
However you should just download the BINARY to get you started.
I am getting the impression that you have to have special binaries if you want it with VGA, or if you want it to run in terminal mode, ..., etc. I thought I would just work with ver 2.7 Spin file and go from there. That way I could change a line of code, in the Spin file, and get the configuration that I would like. Is my reasoning about this the wrong way to look at this?
Ray
I'm still surprised though that you haven't loaded a binary to get you going as there is nothing special that you can do by compiling the source yourself and there is nothing special about getting it with VGA either, it's just built in.
As for your reasoning I can't follow you, it seems you believe for some reason that you have to invoke certain incantations to make it work for you. The reason for the binaries is it skips any steps to do with compiling the kernel source (mostly PASM and byte data) then loading in EXTEND.fth and in this case VGA.fth, that's all.
Tachyon always runs in terminal mode, that's part of being a Forth, that's built in ready to interact on the command line. In fact it needs that to compile EXTEND and other .fth files anyway.
Please, just try the binary. Then play around compiling later. At least you will get to see it work and understand it better.
Ray
You can run the clock by typing MAIN which will run in another cog so you are free to use the Tachyon console in the foreground. The RTC defaults to a standard I2C RTC and in this case I am using a 5-pin DS3231 module. Don't worry if there isn't an RTC or it's different, the display will still work although the time and data will be weird, but at least you can see it run.
If you do get your hands on a DHT22 you can connect it right up to +5V and use a 1K resistor from the data pin to an I/O. If your pin was 24 for instance you can change it with the command: 24 ' dhtpin 1+ ! which you should do before you run MAIN so you can do a BACKUP then if you like you can also tell it to run automatically on startup with: AUTORUN MAIN
type a ^C to reboot or just say "reboot"
I went and loaded the new ver 2.7 Spin file, and everything went as expected. I also did the copy/paste of extend.fth file, surprise, surprise, it took probably a half hour for that to accomplish. Not sure if I would want to make that common exercise. Also I did run 'BACKUP', and I am assuming that the upgraded kernel is now in the EEPROM? Have not tested that just yet by doing a reset.
Now I know that the word "fast" has been used to describe Tachyon, but as you start adding on the different .fth files, especially extend.fth, I would imagine that would make the kernel "bloated" and in turn start to run a "little" on the slow side, I would think.
So, to maximize the efficiency of Tachyon, you would have to be using the minimal amount of .fth updates, and those files would have to be some very tight code.
Something else I noticed, while the extend.fth file was being loaded, what pins is the uSD assigned too? At the end of the file it looks like 9,10,11,12 are being used. So, using different boards might conflict with the default pin assignments?
Now, the next thing I will try is the new VGA binary, as soon as I find a suitable VGA monitor.
Ray
Regarding the time it takes to load "extend", be sure that you only have an end of line delay in terraterm, not for each character. The first time I tried it I also had the chacter delay and it took forever to load extend (I eventually just exited it.) But when I tried with only end-of-line-delay, it went much faster and only took a couple of minutes.
Tom
How do you use the binary version (load it into the prop & start it)? I am a novice.
Thanks
Tom