Bernie, if you want to see what the different modes do then hook-up a scope and sit at the terminal and try the modes. It's very simple and all the words are there (in EXTEND.fth) to allow you to change things easily and of course interactively.
Hi Peter,
I had a look at the high level cog words like NCO and DUTY, but although I could get NCO mode working from the examples, I could see no way how to alter the duty in that mode .. and there is
no example of how to access DUTY mode either ..
Also, I see mention in the Kernel of the words PHSA/CTRA etc, but don't know how to access them to get finer control .. Is there some magic using COG@ and COG! to get to these registers?
Any help here appreciated ....
PS: I have my Prop board back now, so van have a play with the counters ..
PPS: How much kernel memory is available for me to write my own PASM functions?
I had a look at the high level cog words like NCO and DUTY, but although I could get NCO mode working from the examples, I could see no way how to alter the duty in that mode .. and there is
no example of how to access DUTY mode either ..
Also, I see mention in the Kernel of the words PHSA/CTRA etc, but don't know how to access them to get finer control .. Is there some magic using COG@ and COG! to get to these registers?
Any help here appreciated ....
PS: I have my Prop board back now, so van have a play with the counters ..
PPS: How much kernel memory is available for me to write my own PASM functions?
Cheers,
B.
Did you see the DAC! word in EXTEND.fth?
[SIZE=3][FONT=courier new]\ Write an 8-bit value to the pin as a duty cycle - filter output for a voltage
[/FONT][FONT=courier new]pub DAC! ( byte pin -- )
DUP PINCLR APIN DUTY #24 SHL FRQ
;
[/FONT][/SIZE]
As you can see the output voltage is set by varying the frequency of a fixed width pulse which is a square wave at 40MHz. As you can imagine that as the frequency goes higher than this that only the off time gets shorter hence the duty cycle increases, conversely as the frequency drops the off time gets longer and the duty cycle decreases.
There are two counters per cog which is why you see CTRA and CTRB for instance but I just select either one with an A or a B word which just sets the channel variable. When you type CTR or PHS then it will be the last selected channel. CTR is a pain to manipulate directly as it;s broken up in the CTRMODE, PLL, BPIN, and APIN fields. This is where Forth does the work for you:
CTRMODE ( n -- | Writes to the CTRMODE field of the current CTR channel without disturbing the other bits of the counter )
PLLDIV ( n -- )
APIN ( pin -- | Set the APIN of the current CTR )
BPIN ( pin -- | Set the BPIN of the current CTR )
Some CTR modes have also been predefined such as NCO, DUTY, and PLL as you can see in the DAC! word.
The words MHZ KHZ HZ and MUTE just scale and set the frequency and mode of the counter. MUTE just stops the counter. So to generate a 1kHz signal on pin 14 using CTRA all we need to type is "A #14 APIN 1 KHZ" and immediately pin 14 is outputting a 1kHz square wave! Type 5 MHZ and it's generating a 5MHZ signal then if you type #16 APIN it will appear on P16 instead.
So Forth really lets you play with the counters in an easy and intuitive and interactive way.
Have you had a look at the intro page at the section entitled? WARNING! INTERACTIVITY COUNTERS
[SIZE=3][FONT=courier new]\ Write an 8-bit value to the pin as a duty cycle - filter output for a voltage
[/FONT][FONT=courier new]pub DAC! ( byte pin -- )
DUP PINCLR APIN DUTY #24 SHL FRQ
;
[/FONT][/SIZE]
As you can see the output voltage is set by varying the frequency of a fixed width pulse which is a square wave at 40MHz. As you can imagine that as the frequency goes higher than this that only the off time gets shorter hence the duty cycle increases, conversely as the frequency drops the off time gets longer and the duty cycle decreases.
There are two counters per cog which is why you see CTRA and CTRB for instance but I just select either one with an A or a B word which just sets the channel variable. When you type CTR or PHS then it will be the last selected channel. CTR is a pain to manipulate directly as it;s broken up in the CTRMODE, PLL, BPIN, and APIN fields. This is where Forth does the work for you:
CTRMODE ( n -- | Writes to the CTRMODE field of the current CTR channel without disturbing the other bits of the counter )
PLLDIV ( n -- )
APIN ( pin -- | Set the APIN of the current CTR )
BPIN ( pin -- | Set the BPIN of the current CTR )
Some CTR modes have also been predefined such as NCO, DUTY, and PLL as you can see in the DAC! word.
The words MHZ KHZ HZ and MUTE just scale and set the frequency and mode of the counter. MUTE just stops the counter. So to generate a 1kHz signal on pin 14 using CTRA all we need to type is "A #14 APIN 1 KHZ" and immediately pin 14 is outputting a 1kHz square wave! Type 5 MHZ and it's generating a 5MHZ signal then if you type #16 APIN it will appear on P16 instead.
So Forth really lets you play with the counters in an easy and intuitive and interactive way.
Have you had a look at the intro page at the section entitled? WARNING! INTERACTIVITY COUNTERS
Yes, I understand all of the above Peter.
But I don't want to get a pseudo duty variation by varying the pulse frequency .... I want fixed frequency and variable duty, I don't see words to do that easily in your word set ...
Now, I have seen spin examples using the PHSA/FRQA registers directly to implement this ... so I want to do the same under Forth, you havn't given an answer to my original question of how to access these registers ..
SInce the post, I have managed to work out that you use the GOG! word to indirectly access these registers right?
For example to access the FRQA Register easily you implement:
: FRQ ( n -- ) FRQA ctr C@ + COG! ;
.. which is usable after you use A or B word to setup ctr ..
... so to access the PHSA register I must do something like this right?
: PHA ( n -- ) PHSA ctr C@ + COG! ;
However, when in NCO mode, using the PHA word above does nothing, that confuses me ... the SPIN example set FRQA to 1, and adjust PHSA to implement duty cycle variation in NCO mode ..
I am lacking something in my knowledge of the counters here I feel ..
I am NOT lacking in my Forth knowledge as you have been implying, I do understand HOW to use the words you have written, it is the counters I am lacking understanding in ... ...
But I don't want to get a pseudo duty variation by varying the pulse frequency .... I want fixed frequency and variable duty, I don't see words to do that easily in your word set ...
Now, I have seen spin examples using the PHSA/FRQA registers directly to implement this ... so I want to do the same under Forth, you havn't given an answer to my original question of how to access these registers ..
SInce the post, I have managed to work out that you use the GOG! word to indirectly access these registers right?
For example to access the FRQA Register easily you implement:
: FRQ ( n -- ) FRQA ctr C@ + COG! ;
.. which is usable after you use A or B word to setup ctr ..
... so to access the PHSA register I must do something like this right?
: PHA ( n -- ) PHSA ctr C@ + COG! ;
However, when in NCO mode, using the PHA word above does nothing, that confuses me ... the SPIN example set FRQA to 1, and adjust PHSA to implement duty cycle variation in NCO mode ..
I am lacking something in my knowledge of the counters here I feel ..
I am NOT lacking in my Forth knowledge as you have been implying, I do understand HOW to use the words you have written, it is the counters I am lacking understanding in ... ...
Thanks,
B.
Ah, I see, looking at your previous post I must remember you are speaking Kiwi
For instance: no example of how to access DUTY mode either ..
That was answered however if you meant how to use them rather than access them then that is a little different but DUTY mode is not the same thing as PWM which I have implemented using a dedicated cog as mentioned previously. I will have to get back to you later as Google translate doesn't handle Kiwi <-> Aussie
Ah, I see, looking at your previous post I must remember you are speaking Kiwi
For instance: no example of how to access DUTY mode either ..
That was answered however if you meant how to use them rather than access them then that is a little different but DUTY mode is not the same thing as PWM which I have implemented using a dedicated cog as mentioned previously. I will have to get back to you later as Google translate doesn't handle Kiwi <-> Aussie
Ok, I will do the translate ...
TRANSLATION ON
I have managed to work out that you use the GOG! word to indirectly access these registers right?
the "right?" above is asking you for confirmation, ... is my assumption correct? the "?" in Kiwi means a question , You respond with yes,no ... if no, details would be good ..
... so to access the PHSA register I must do something like this right?
the "right?" above is asking you for confirmation, ... is my assumption correct? the "?" in Kiwi means a question , You respond with yes,no ... if no, details would be good ..
the "right?" above is asking you for confirmation, ... is my assumption correct? the "?" in Kiwi means a question , You respond with yes,no ... if no, details would be good ..
the "right?" above is asking you for confirmation, ... is my assumption correct? the "?" in Kiwi means a question , You respond with yes,no ... if no, details would be good ..
He he ..
TRANSLATION OFF
It's hard to get you Kiwi's back, you know, as most of them are over here
As for the ? I've always wondered what that meant. Seeing you had already answered the question by your phrasing I take the point as moot and no need to discuss it further unless of course you didn't understand your own question. hehe
Okay, a little bit more seriously now (if you Kiwis can handle that) I will have to look into higher frequency PWM modes using the counters or even possibly the video register. Us Aussies don't always know the answer but when we see what you Kiwis are doing wrong we figure out a better way (sorry, couldn't help it). Hey Bernie, would you like me to do up a little bit of a section in the intro page about this? Maybe you could provide some material to add as well, that'll be good. Just about to have some lunch and then I'll take a look at the counters and take some screenshots of the waveforms and write this up this afternoon. It might be an ongoing article about experiments with the counters and video etc.
It's hard to get you Kiwi's back, you know, as most of them are over here
As for the ? I've always wondered what that meant. Seeing you had already answered the question by your phrasing I take the point as moot and no need to discuss it further unless of course you didn't understand your own question. hehe
Okay, a little bit more seriously now (if you Kiwis can handle that) I will have to look into higher frequency PWM modes using the counters or even possibly the video register. Us Aussies don't always know the answer but when we see what you Kiwis are doing wrong we figure out a better way (sorry, couldn't help it). Hey Bernie, would you like me to do up a little bit of a section in the intro page about this? Maybe you could provide some material to add as well, that'll be good. Just about to have some lunch and then I'll take a look at the counters and take some screenshots of the waveforms and write this up this afternoon. It might be an ongoing article about experiments with the counters and video etc.
Distillation of the video generators and advanced counter modes for mere mortals would be most welcome. Nothing beats hooking up a scope and issuing words to see the effects. Some can draw these traces in their heads by looking at the documents, not me. I'm very interested in BLDC motors and such.
Distillation of the video generators and advanced counter modes for mere mortals would be most welcome. Nothing beats hooking up a scope and issuing words to see the effects. Some can draw these traces in their heads by looking at the documents, not me. I'm very interested in BLDC motors and such.
Yes, I was just looking at the PWMx8 Spin/PASM module and that looks like it will do for my application (it uses the video hardware) ....
but I will need to port it into a Forth/PASM module ... understanding how it works would be awesome too ..
Peter, I guess I am coming back to my previous unanswered question: How much memory is left in the Kernel to for example, fit in the PASM code for the PWMx8 module I am referring too ... it would be good to know how we mere mortals can customize the kernel for our own needs .. e.g for the Sensorless BLDC motor control which I want to implement in Forth, I need the above PASM PWM code, some custom PASM code that implements a retriggerable monostable and the rest in high level Forth ..
So in summary some guidelines on:
1. How to incorporate my own PASM modules into the Kernel, and how to pass parameters to/from it from Forth ..
2. I need to understand what code runs in COG memory and how it is copied there (i.e what part of the Kernel is in COG, all of it?)..
3. Some tuition on the COG high speed timers and video ..
All the above will help tremendously in implementing a Sensorless BLDC controller in Forth .. which will then of course be returned back to you complete, for sharing with everyone ..
So in summary some guidelines on:
1. How to incorporate my own PASM modules into the Kernel, and how to pass parameters to/from it from Forth ..
2. I need to understand what code runs in COG memory and how it is copied there (i.e what part of the Kernel is in COG, all of it?)..
B.
in the Tachyon.spin file just search for RUNMOD and you will find Peter's reloadable PASM modules, which are great examples of how to do it.
Including passing parameters to them via COGREGS
The size of each module is restricted, but the comments about the max length vary from 16 to 24 longs / PASM inctructions.
But if you could live without some of the kernel features this could be made a little larger.
Problem is to understand what could be removed without breaking the kernel.
in the Tachyon.spin file just search for RUNMOD and you will find Peter's reloadable PASM modules, which are great examples of how to do it.
Including passing parameters to them via COGREGS
The size of each module is restricted, but the comments about the max length vary from 16 to 24 longs / PASM inctructions.
But if you could live without some of the kernel features this could be made a little larger.
Problem is to understand what could be removed without breaking the kernel.
I did see the RUNMOD and LOADMOD functions, but as they only allow PASM of 16 LONGS, I could not see how to use it to implement the PWMx8 module as that is more like 134 LONGS and 80 VARIABLE longs. (according to the BST tool)
As you say, we need guidance from Peter as to how to make room in the kernel, so we can add bigger PASM modules ..
[EDIT] Or do we have a Forth word that allows a custom (non Forth) COG to be loaded with PASM, that interfaces to other COG's running Forth?
PS: I looked up the word COGREGS in the kernel, it shows it in the WORDS list, but I see no code for it ......
I did see the RUNMOD and LOADMOD functions, but as they only allow PASM of 16 LONGS, I could not see how to use it to implement the PWMx8 module as that is more like 134 LONGS and 80 VARIABLE longs. (according to the BST tool)
As you say, we need guidance from Peter as to how to make room in the kernel, so we can add bigger PASM modules ..
[EDIT] Or do we have a Forth word that allows a custom (non Forth) COG to be loaded with PASM, that interfaces to other COG's running Forth?
PS: I looked up the word COGREGS in the kernel, it shows it in the WORDS list, but I see no code for it ......
I can hardly wait until you guys have 128K in the prop2 for the kernel.
I can hardly wait until you guys have 128K in the prop2 for the kernel.
dp
Well there will still only be 8 cogs and each cog is limited to 512 longs or RAM but at least I have the extra stack space and efficient method of writing to hub RAM. A lot of the stuff I'm doing with V3 where the dictionary is mostly held in Flash and objects included from the library held on SD as well as binary modules loaded directly into cogs will of course be of great benefit both now and when P2 is available (this year). Making a stand-alone system then is worthwhile for P2 whereas it is not what I am interested in with trying to make P1 into something it's not except maybe with another Prop handling the video at least.
I did see the RUNMOD and LOADMOD functions, but as they only allow PASM of 16 LONGS, I could not see how to use it to implement the PWMx8 module as that is more like 134 LONGS and 80 VARIABLE longs. (according to the BST tool)
As you say, we need guidance from Peter as to how to make room in the kernel, so we can add bigger PASM modules ..
I don't see this, since the kernel is packet very tight and little to remove to make such a big space.
But the question is if you need the COG to have a Tachyon VM at all, if you want to run specialized PASM anyhow.
[EDIT] Or do we have a Forth word that allows a custom (non Forth) COG to be loaded with PASM, that interfaces to other COG's running Forth?
there is no support currently to reload a complete COG from forth,
but have a look at VGA (commented out in tachyon.spin) to see how a PASM COG can be started from SPIN at startup
and how to communicate via HUB ram
PS: I looked up the word COGREGS in the kernel, it shows it in the WORDS list, but I see no code for it ......
I need your help -
I am getting frustrated, feeling alone in this Tachyon world and need somebody to talk to me ...
-- there are many C-People around that I could easily team up with ... but that is not what I want .. yet
I posted a number of messages here, to show what I am experimenting in the hope to get some feedback,
have some discussion or even find a fellow Tachyon / Forth / Propeller newcomer to share the learning curve,
but with little/no resonance. (thanks Peter for the fast response to nRF24L01)
So, what are you working / playing with Tachyon?
What are your interrests, your experiments, your findings?
I was thinking of a project thread like:
"The unofficial TACHYON documentation project"
since I am going through the Tachyon.spin and Extend.fth code for myself adding comments to better understand what Peter is doing there.
Maybe others would be interrested in s.th. like this as well.
But of course, since I am new to this world, maybe / surely some of my guesses are wrong.
collaborating on it could be a great learning experience.
Of course Peter could do this - but he probably better spends his time on V3 and all the big new stuff like FAT32 ...
as he does.
What makes it difficult though is the moving target, repeatedly merging new Tachyon versions with my commented previous version.
I also started to scan this big thread for gems and extract those to a separate document ...
Of course some of the posts are outdated and superceeded by new versions of Tachyon,
but sometimes still give valuable insight in how this system evolved to how it is now.
Hi.
I always read this thread.
BTW, how does TACHION install on Propeller board?
Where is install-procedure?
Hi caskaz, there is no special install procedure with Tachyon as the complete source for the kernel is on a single page, either the formatted Google document (or the webpage verison) which is always up-to-date (even as I am editing it) or the Dropbox folder version. If you use the Google document then just select all, copy and paste into your Spin tool and hit F11 to load into your board. There's only one section you might customize to suit and that's the clock and baudrate which is about 5% into the document here:
[SIZE=3][FONT=courier new][B]CON[/B]
[/FONT][/SIZE]
[SIZE=3][FONT=courier new]_clkmode = xtal1 + pll8x ' <---------------- change to suit[/FONT][/SIZE]
[SIZE=3][FONT=courier new]_xinfreq = 10_000_000 ' <---------------- change to suit your crystal
[/FONT][/SIZE]
[SIZE=3][FONT=courier new]
[/FONT][/SIZE][SIZE=3][FONT=courier new]baud = 230400 ' <-- change - tested from 300 baud to 3M baud
[/FONT][/SIZE]
Once you have the compiled kernel loaded onto your board it is talking but you should paste or send the EXTEND.fth file for all the standard extras. I use Minicom with a 12ms line delay as there is no handshaking. If you look at the bottom of the Intro page (links in my sig) it will point you to the links page. Here is the main Dropbox page which I try to keep up-to-date.
I need your help -
I am getting frustrated, feeling alone in this Tachyon world and need somebody to talk to me ...
-- there are many C-People around that I could easily team up with ... but that is not what I want .. yet
I posted a number of messages here, to show what I am experimenting in the hope to get some feedback,
have some discussion or even find a fellow Tachyon / Forth / Propeller newcomer to share the learning curve,
but with little/no resonance. (thanks Peter for the fast response to nRF24L01)
So, what are you working / playing with Tachyon?
What are your interrests, your experiments, your findings?
I was thinking of a project thread like:
"The unofficial TACHYON documentation project"
since I am going through the Tachyon.spin and Extend.fth code for myself adding comments to better understand what Peter is doing there.
Maybe others would be interrested in s.th. like this as well.
But of course, since I am new to this world, maybe / surely some of my guesses are wrong.
collaborating on it could be a great learning experience.
Of course Peter could do this - but he probably better spends his time on V3 and all the big new stuff like FAT32 ...
as he does.
What makes it difficult though is the moving target, repeatedly merging new Tachyon versions with my commented previous version.
I also started to scan this big thread for gems and extract those to a separate document ...
Of course some of the posts are outdated and superceeded by new versions of Tachyon,
but sometimes still give valuable insight in how this system evolved to how it is now.
I've tried to follow your post and I'm not quite sure where or what to reply to yet If it's one thing then I manage to gouge out the time to check it out and reply.
I originally wrote Tachyon because I liked using Forth and needed something that could run fast enough for me to use for real work projects. So Tachyon has not been standard in many respects and yet it's tailored for the Prop and it's peculiarities which makes it very non-standard for a non-standard processor chip (which we love). Now in saying this I'm just hoping to draw your attention to the "real work projects" phrase Yes, I have real work I need to get done and Tachyon has the speed and compactness as well as the productivity and fun that comes with it's interactive nature. So Tachyon is certainly not a test tube baby, born and bred and sheltered in a lab, sorry, it's a wild child that has to deal with the real world so what it lacks in social graces it makes up for in getting things done. When it comes across something it doesn't know how to handle then I train it, and so Tachyon grows in response, not to artificial academic stimuli but real-world needs.
So as much as I appreciate forum chat I just find my time is a little limited sometimes but I will attempt to address each of your questions, although maybe not all in one or two posts.
BTW, you are welcome to be a collaborator so you can edit and document the main Tachyon 2.1 document or any other document for that matter. At the very least you could write up your own document pages and simply link to them from the source code document.
But it takes very much time to display webpage( formatted Google document) under my PC.
So it seems it very very very much time to copy code.
I gave up to copy them on the way.
Maybe because my PC is old and internet is poor.
Cannot you upload TACHYON kerenel source as spin.file?
But it takes very much time to display webpage( formatted Google document) under my PC.
So it seems it very very very much time to copy code.
I gave up to copy them on the way.
Maybe because my PC is old and internet is poor.
Cannot you upload TACHYON kerenel source as spin.file?
Although Google docs works well it does need a decent internet connection and/or PC but as mentioned there are the plain text and Spin files in the dropbox section so just click on the link in my signature at the bottom of this post.
So, any chance of a Forth word that will load some PASM code into a Cog and then allow access via parameters ...
There is some clever PASM code out there I would like to interface Forth to, but the code is hundreds of longs ..
Cheers,
B.
PS. Thought I'd ask as the thread has gone a bit quite ..
So, any chance of a Forth word that will load some PASM code into a Cog and then allow access via parameters ...
There is some clever PASM code out there I would like to interface Forth to, but the code is hundreds of longs ..
Cheers,
B.
PS. Thought I'd ask as the thread has gone a bit quite ..
I may put a coginit instruction in there but you can also use the LOADMOD instruction but specify a count >24 and it will load into address 0 of the current cog and automatically run from there once loaded.Normally LOADMOD just loads into the reserved module area which is limited to 24 longs. Use the Google version for this though, it's also the one with the newer serial driver I'm still playing with that is optimized for 100% burst throughput at 2M baud (and counting).
Not too long ago Peter suggested that the DalSemi RTC, DS-3231, should work with his code for the Microchip MCP79410. Well ... he wasn't quite right .. but far more right than wrong ... first of all the DS-3231 has an I2C address of $D0 not $B0! When I notice this I remembered that the DS1307 had the same address and the register configuration looked the same. So I re-booted and loaded the RTC code for the DS1307 that I posted last December, with no changes of any kind! It all worked with no problems of any kind.
Now back to Peter's MCP79410 code ... I pulled the backup battery so I would be starting fresh and after replacing the battery I set Date and Time. When I went to print time and/or date it all blew up forcing a reboot and cyber-vomit on the console screen.
I checked a few things and I suspect what initially seemed like a terribly clever idea .... writing to the RTC buffer a long at a time rather than 4 byte write commands when setting hrs/mins/secs or yr/mon/day. I think that long write is getting caught up in that Little Endian / Big Endian byte order thingy. When I have more time this weekend, I'll look to confirm my suspicions.
Any way. I rewrote a lot of my DS1307 code borrowing liberally from some of Peter's code. This module will do either chip ... the venerable old DS1307 or the slick new DS3231.
The DS3231M at eight dollars plus in quantity 1-9 is not cheap but it has aTXCO resonator onboard and its rated 5 ppm accuracy. It will run on 2.9 to 5.5 v and tolerate 5v pull-ups even when Vcc is 3.3v . It comes in 8 or 16 pin SOIC. ( I soldered two them to Sparkfun 8 pin SOIC Breakout boards yesterday. It took me under 10 minutes for the two, including 2 4 pin male headers per board. If I can do that despite the shakes from Parkinson's most of you should be able to handle it.)
I have attached the code and the DS3231 Data Sheet
Not too long ago Peter suggested that the DalSemi RTC, DS-3231, should work with his code for the Microchip MCP79410. Well ... he wasn't quite right .. but far more right than wrong ... first of all the DS-3231 has an I2C address of $D0 not $B0! When I notice this I remembered that the DS1307 had the same address and the register configuration looked the same. So I re-booted and loaded the RTC code for the DS1307 that I posted last December, with no changes of any kind! It all worked with no problems of any kind.
Now back to Peter's MCP79410 code ... I pulled the backup battery so I would be starting fresh and after replacing the battery I set Date and Time. When I went to print time and/or date it all blew up forcing a reboot and cyber-vomit on the console screen.
I checked a few things and I suspect what initially seemed like a terribly clever idea .... writing to the RTC buffer a long at a time rather than 4 byte write commands when setting hrs/mins/secs or yr/mon/day. I think that long write is getting caught up in that Little Endian / Big Endian byte order thingy. When I have more time this weekend, I'll look to confirm my suspicions.
Any way. I rewrote a lot of my DS1307 code borrowing liberally from some of Peter's code. This module will do either chip ... the venerable old DS1307 or the slick new DS3231.
The DS3231M at eight dollars plus in quantity 1-9 is not cheap but it has aTXCO resonator onboard and its rated 5 ppm accuracy. It will run on 2.9 to 5.5 v and tolerate 5v pull-ups even when Vcc is 3.3v . It comes in 8 or 16 pin SOIC. ( I soldered two them to Sparkfun 8 pin SOIC Breakout boards yesterday. It took me under 10 minutes for the two, including 2 4 pin male headers per board. If I can do that despite the shakes from Parkinson's most of you should be able to handle it.)
I have attached the code and the DS3231 Data Sheet
The DS3231 is compatible enough with the MCP79410 that you should be able to use it as is, just change the device address. The first 7 registers are compatible although the 79410 does uses some of the otherwise unused bits for control purposes but that won't affect the 3231. Try it and let me know how is goes.
The device address can be changed either in the source code: $DE == @rtc
to
$B0 == @rtc
So I checked the datasheet again and it is supposed to be $D0 so I don't know why I typed $B0, I suppose just to get you to check the datasheet yourself I guess! BTW, an I2CBUS command would have revealed the device address anyway. There is no writing of longs, only a sequence of bytes which are acknowledged by the RTC after which it autoincrements its register pointer. I will order some of these chips and test them myself though.
What I like to see standardized between RTC chips is the read and write methods and formats for time and date. I like the BCD method as that is normally how RTC chips handle the data. So to set the time to 1:35PM it becomes $13:35:00 TIME! Printing the time and date become simple operations too.
Here's a project I just did for a local client that uses Tachyon. Since it's only a small and simple project I can share some details of it with the forum. Basically it's a pump control unit with large LCD screens mounted in a factory area where the operators can see the display from a distance as they move through the factory floor with a very long hose from machine to machine. Other monitors can be added easily without any configuration necessary. Tachyon is running on a small DIN rail control unit and communicating with the displays over RS485. Each display has a small Prop board (Pixie) plugged directly into the back of the monitor as shown and can have a keypad plugged directly into each monitor. The Pixies are interconnected via a multidrop 4-core phone cable which provides power for the Pixies as well. I tested multiple units over 100 metres of cable without a single hitch. This is connected back to a high-pressure pump unit where the master Prop resides and connects to encoders and pressure sensor and control valve solenoid.
The main application program is totally written in Tachyon Forth without any assembly and consumes less than 4K of code space despite the fact that I have a lot of diagnostic messaging built in over Bluetooth. Each monitor can have a keypad which the control application reads directly over RS485 and writes to the the Pixie's 512x384 tiled bitmap driver. A cog task continually checks the encoder inputs and processes these as well. There are also 12 bicolor LEDs via shift registers on the control unit that are continually updated from the main code, the write update time is 21us for 24 bits (12 LEDS).
What does the code look like? I'll just share one tiny snippet for the moment which updates the machine number when it's in the run mode (vs program mode):
[COLOR=#000000][FONT=Ubuntu Mono]pub [/FONT][/COLOR][COLOR=#000000][FONT=Ubuntu Mono][B].MACHINE[/B][/FONT][/COLOR][COLOR=#000000][FONT=Ubuntu Mono] ( n -- )[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] MSG ." MACHINE " DUP .DEC \ Echo diagnostics to console[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] YELLOW PEN BLACK PAPER 0 1 9 #10 PAINT \ paint tiles in machine number area x y xwidth ywidth[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] 9 #11 SIZE 0 0 @XY 1+ .DIGITS \ Large digits[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] NORMAL PRESSURE? IF GREEN ELSE RED THEN PEN BLACK PAPER \ Reflect pressure status in machine title[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] 0 #10 8 1 PAINT \ paint tiles for title[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] #50 #158 @XY ." MACHINE " \ display title[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] CON \ return I/O to console in case we run interactively[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] ;[/FONT][/COLOR]
Here's another where the keypad codes are processed:
[COLOR=#000000][FONT=Ubuntu Mono]pub [/FONT][/COLOR][COLOR=#000000][FONT=Ubuntu Mono][B][KEYPAD][/B][/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] >B SWITCH[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] $1B CASE step ~ [HOLD] BREAK \ HOLD START/STOP[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] "/" CASE [SET] BREAK[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] "*" CASE [RECALL] BREAK [/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] "-" CASE [STEP-] BREAK \ step down[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] "+" CASE [STEP+] BREAK \ step up[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] 8 CASE [CE] BREAK [/FONT][/COLOR][COLOR=#000000][FONT=Ubuntu Mono] \ clear entry[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] ^M CASE [ENTER] LIST_STATS BREAK[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] "." CASE [CLEAR] BREAK[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] BL CASE [STEP0] BREAK[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono]\ numeric key[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] SWITCH@ $30 $39 WITHIN IF SWITCH@ NUMERIC BREAK[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] ;[/FONT][/COLOR]
So I checked the datasheet again and it is supposed to be $D0 so I don't know why I typed $B0, I suppose just to get you to check the datasheet yourself I guess! BTW, an I2CBUS command would have revealed the device address anyway. There is no writing of longs, only a sequence of bytes which are acknowledged by the RTC after which it autoincrements its register pointer. I will order some of these chips and test them myself though.
I2CBUS was what tipped me off to the discrepancy.
Below is a snippet from MCP79410.fth from your webpage. TIME! and DATE! are your setting words ... they both look to me like they are writing a long to rtcbuf and the resulting write location was 'off'' by the 2 bytes shift of whatever-Endian byte order.
pub TIME! ( $hh.mm.ss -- ) \ write time in bcd format
$2000.0080 OR rtcbuf ! WRRTC
;
\ Usage: $130630 DATE! \ set the date to the 30th June 2013
pub DATE! ( $yy.mm.dd -- )
rtcbuf 4 + ! WRRTC
;
If I am wrong, please show me where. I would much rather use your "$110400 TIME!" than my "$11 $04 $00 TIME!"
Below is a snippet from MCP79410.fth from your webpage. TIME! and DATE! are your setting words ... they both look to me like they are writing a long to rtcbuf and the resulting write location was 'off'' by the 2 bytes shift of whatever-Endian byte order.
pub TIME! ( $hh.mm.ss -- ) \ write time in bcd format
$2000.0080 OR rtcbuf ! WRRTC
;
\ Usage: $130630 DATE! \ set the date to the 30th June 2013
pub DATE! ( $yy.mm.dd -- )
rtcbuf 4 + ! WRRTC
;
If I am wrong, please show me where. I would much rather use your "$110400 TIME!" than my "$11 $04 $00 TIME!"
Just because it is passed as a long doesn't mean it is written as a long or can be. Surely time should be a single parameter with each byte of the long representing hh mm ss. A simple L>W to split the long into two words and then W>B operations to extract the bytes which are then written sequentially using the chip's automatic register autoincrement.
P.S. remember that the DS32 doesn't have those other bit flags mixed up with the time.
I wish I knew what went wrong. Throughout this whole investigation the troubles came from a copy of Peter's file in which I made but a single change, @rtc, the chip address. Now it all works.
I moved over the TIME! and DATE! words of Peter's code and cleaned up a few things.
Comments
Hi Peter,
I had a look at the high level cog words like NCO and DUTY, but although I could get NCO mode working from the examples, I could see no way how to alter the duty in that mode .. and there is
no example of how to access DUTY mode either ..
Also, I see mention in the Kernel of the words PHSA/CTRA etc, but don't know how to access them to get finer control .. Is there some magic using COG@ and COG! to get to these registers?
Any help here appreciated ....
PS: I have my Prop board back now, so van have a play with the counters ..
PPS: How much kernel memory is available for me to write my own PASM functions?
Cheers,
B.
Did you see the DAC! word in EXTEND.fth?
[SIZE=3][FONT=courier new]\ Write an 8-bit value to the pin as a duty cycle - filter output for a voltage [/FONT][FONT=courier new]pub DAC! ( byte pin -- ) DUP PINCLR APIN DUTY #24 SHL FRQ ; [/FONT][/SIZE]As you can see the output voltage is set by varying the frequency of a fixed width pulse which is a square wave at 40MHz. As you can imagine that as the frequency goes higher than this that only the off time gets shorter hence the duty cycle increases, conversely as the frequency drops the off time gets longer and the duty cycle decreases.There are two counters per cog which is why you see CTRA and CTRB for instance but I just select either one with an A or a B word which just sets the channel variable. When you type CTR or PHS then it will be the last selected channel. CTR is a pain to manipulate directly as it;s broken up in the CTRMODE, PLL, BPIN, and APIN fields. This is where Forth does the work for you:
CTRMODE ( n -- | Writes to the CTRMODE field of the current CTR channel without disturbing the other bits of the counter )
PLLDIV ( n -- )
APIN ( pin -- | Set the APIN of the current CTR )
BPIN ( pin -- | Set the BPIN of the current CTR )
Some CTR modes have also been predefined such as NCO, DUTY, and PLL as you can see in the DAC! word.
The words MHZ KHZ HZ and MUTE just scale and set the frequency and mode of the counter. MUTE just stops the counter. So to generate a 1kHz signal on pin 14 using CTRA all we need to type is "A #14 APIN 1 KHZ" and immediately pin 14 is outputting a 1kHz square wave! Type 5 MHZ and it's generating a 5MHZ signal then if you type #16 APIN it will appear on P16 instead.
So Forth really lets you play with the counters in an easy and intuitive and interactive way.
Have you had a look at the intro page at the section entitled?
WARNING! INTERACTIVITY COUNTERS
Yes, I understand all of the above Peter.
But I don't want to get a pseudo duty variation by varying the pulse frequency .... I want fixed frequency and variable duty, I don't see words to do that easily in your word set ...
Now, I have seen spin examples using the PHSA/FRQA registers directly to implement this ... so I want to do the same under Forth, you havn't given an answer to my original question of how to access these registers ..
SInce the post, I have managed to work out that you use the GOG! word to indirectly access these registers right?
For example to access the FRQA Register easily you implement:
: FRQ ( n -- ) FRQA ctr C@ + COG! ;
.. which is usable after you use A or B word to setup ctr ..
... so to access the PHSA register I must do something like this right?
: PHA ( n -- ) PHSA ctr C@ + COG! ;
However, when in NCO mode, using the PHA word above does nothing, that confuses me ... the SPIN example set FRQA to 1, and adjust PHSA to implement duty cycle variation in NCO mode ..
I am lacking something in my knowledge of the counters here I feel ..
I am NOT lacking in my Forth knowledge as you have been implying, I do understand HOW to use the words you have written, it is the counters I am lacking understanding in ... ...
Thanks,
B.
Ah, I see, looking at your previous post I must remember you are speaking Kiwi
For instance: no example of how to access DUTY mode either ..
That was answered however if you meant how to use them rather than access them then that is a little different but DUTY mode is not the same thing as PWM which I have implemented using a dedicated cog as mentioned previously. I will have to get back to you later as Google translate doesn't handle Kiwi <-> Aussie
Ok, I will do the translate ...
TRANSLATION ON
the "right?" above is asking you for confirmation, ... is my assumption correct? the "?" in Kiwi means a question , You respond with yes,no ... if no, details would be good ..
the "right?" above is asking you for confirmation, ... is my assumption correct? the "?" in Kiwi means a question , You respond with yes,no ... if no, details would be good ..
He he ..
TRANSLATION OFF
It's hard to get you Kiwi's back, you know, as most of them are over here
As for the ? I've always wondered what that meant. Seeing you had already answered the question by your phrasing I take the point as moot and no need to discuss it further unless of course you didn't understand your own question. hehe
Okay, a little bit more seriously now (if you Kiwis can handle that) I will have to look into higher frequency PWM modes using the counters or even possibly the video register. Us Aussies don't always know the answer but when we see what you Kiwis are doing wrong we figure out a better way
That would be cool .. thanks Peter
Distillation of the video generators and advanced counter modes for mere mortals would be most welcome. Nothing beats hooking up a scope and issuing words to see the effects. Some can draw these traces in their heads by looking at the documents, not me. I'm very interested in BLDC motors and such.
Yes, I was just looking at the PWMx8 Spin/PASM module and that looks like it will do for my application (it uses the video hardware) ....
but I will need to port it into a Forth/PASM module ... understanding how it works would be awesome too ..
Peter, I guess I am coming back to my previous unanswered question: How much memory is left in the Kernel to for example, fit in the PASM code for the PWMx8 module I am referring too ... it would be good to know how we mere mortals can customize the kernel for our own needs .. e.g for the Sensorless BLDC motor control which I want to implement in Forth, I need the above PASM PWM code, some custom PASM code that implements a retriggerable monostable and the rest in high level Forth ..
So in summary some guidelines on:
1. How to incorporate my own PASM modules into the Kernel, and how to pass parameters to/from it from Forth ..
2. I need to understand what code runs in COG memory and how it is copied there (i.e what part of the Kernel is in COG, all of it?)..
3. Some tuition on the COG high speed timers and video ..
All the above will help tremendously in implementing a Sensorless BLDC controller in Forth .. which will then of course be returned back to you complete, for sharing with everyone ..
Cheers,
B.
Including passing parameters to them via COGREGS
The size of each module is restricted, but the comments about the max length vary from 16 to 24 longs / PASM inctructions.
But if you could live without some of the kernel features this could be made a little larger.
Problem is to understand what could be removed without breaking the kernel.
The following converts a " FF13BE3C" hex string literal to a byte string of length.
But when I want to convert it into a STRING it breaks ...
\ some extensions fur local variables pub X1! locals ! ; ok pub X2! 1 @X ! ; ok pub X3! 2 @X ! ; ok pub X4! 3 @X ! ; ok ok ok \ ======== Hex String to Byte String ================================== pub "2$ ( strPtr -- StrPtr size ) \ X1 = strAddr string pointer to original HEX string \ X2 = storeAddr pointer for writing the assembled bytes \ X3 = readAddr pointer to read the hex bytes from string DUP DUP 3 LOCAL \ store 3 stack elements to local vars X1..X3 BEGIN X3 C@ .S \ get first hex char DUP 0= IF 0 X2 C! \ write terminating null char X2 X1 - \ length of byte string X1 SWAP ( StrPtr size ) .S 3 RELEASE EXIT ELSE >DIGIT 0= IF ( handle error ) THEN 4 SHL X2 C! THEN X3 1+ X3! X3 C@ ?DUP 0= IF X1 3 RELEASE 0 EXIT ELSE >DIGIT 0= IF ( handle error ) THEN X2 C@ + X2 C! X3 1+ X3! X2 1+ X2! THEN AGAIN ; ok ok ok [B][SIZE=2]" FF1E34A1" "2$ .S DROP 5 DUMP[/SIZE][/B] STACK: 00000000 00000000 00000004 00000046 STACK: 00000000 00000000 00000004 00000031 STACK: 00000000 00000000 00000004 00000033 STACK: 00000000 00000000 00000004 00000041 STACK: 00000000 00000000 00000004 00000000 STACK: 00000004 00000000 00002E47 00000004 STACK: 00000004 00000000 00002E47 00000004 2E47: [B][SIZE=3]FF 1E 34 A1 00[/SIZE][/B] 34 41 31 00 BA D6 BA 20 0B 7A BA ..4..4A1.... .z. ok ok " FF1E34A1" "2$ .S STRING STACK: 00000000 00000004 00000000 00000046 STACK: 00000000 00000004 00000000 00000031 STACK: 00000000 00000004 00000000 00000033 STACK: 00000000 00000004 00000000 00000041 STACK: 00000000 00000004 00000000 00000000 STACK: 00000000 00000000 00002E47 00000004 STACK: 00000000 00000000 00002E47 00000004 fs ok fs 7 DUMP 2E4C: FF FF 31 00 B9 D6 78 BA 23 03 03 23 03 03 00 00 ..1...x.#..#.... ok ok " FF1E34A1" "2$ STRING fs STACK: 00000000 00000000 00000004 00000046 STACK: 00000000 00000000 00000004 00000031 STACK: 00000000 00000000 00000004 00000033 STACK: 00000000 00000000 00000004 00000041 STACK: 00000000 00000000 00000004 00000000 STACK: 00000004 00000000 00002E52 00000004 ok fs 7 DUMP 2E54: FF FF 00 34 BA D7 78 BA 23 03 03 00 00 00 00 00 ...4..x.#....... okI did see the RUNMOD and LOADMOD functions, but as they only allow PASM of 16 LONGS, I could not see how to use it to implement the PWMx8 module as that is more like 134 LONGS and 80 VARIABLE longs. (according to the BST tool)
As you say, we need guidance from Peter as to how to make room in the kernel, so we can add bigger PASM modules ..
[EDIT] Or do we have a Forth word that allows a custom (non Forth) COG to be loaded with PASM, that interfaces to other COG's running Forth?
PS: I looked up the word COGREGS in the kernel, it shows it in the WORDS list, but I see no code for it ......
I can hardly wait until you guys have 128K in the prop2 for the kernel.
dp
But the question is if you need the COG to have a Tachyon VM at all, if you want to run specialized PASM anyhow.
there is no support currently to reload a complete COG from forth,
but have a look at VGA (commented out in tachyon.spin) to see how a PASM COG can be started from SPIN at startup
and how to communicate via HUB ram
see EXTEND.fth
I need your help -
I am getting frustrated, feeling alone in this Tachyon world and need somebody to talk to me ...
-- there are many C-People around that I could easily team up with ... but that is not what I want .. yet
I posted a number of messages here, to show what I am experimenting in the hope to get some feedback,
have some discussion or even find a fellow Tachyon / Forth / Propeller newcomer to share the learning curve,
but with little/no resonance. (thanks Peter for the fast response to nRF24L01)
So, what are you working / playing with Tachyon?
What are your interrests, your experiments, your findings?
I was thinking of a project thread like:
"The unofficial TACHYON documentation project"
since I am going through the Tachyon.spin and Extend.fth code for myself adding comments to better understand what Peter is doing there.
Maybe others would be interrested in s.th. like this as well.
But of course, since I am new to this world, maybe / surely some of my guesses are wrong.
collaborating on it could be a great learning experience.
Of course Peter could do this - but he probably better spends his time on V3 and all the big new stuff like FAT32 ...
as he does.
What makes it difficult though is the moving target, repeatedly merging new Tachyon versions with my commented previous version.
I also started to scan this big thread for gems and extract those to a separate document ...
Of course some of the posts are outdated and superceeded by new versions of Tachyon,
but sometimes still give valuable insight in how this system evolved to how it is now.
so ... waiting for some response ...
Markus from Germany
here some of my experiments:
HEX Strings to byte strings
Re: Strings - COMMENTED
http://forums.parallax.com/showthread.php/141061-TACHYON-A-Fast-and-small-Forth-byte-code-VM-(source-code-available)-Web-pages?p=1197891#post1197891
TACHYON - circular byte buffer words
evaluate the FORTH sentence in a null-teminated string
http://forums.parallax.com/showthread.php/141061-TACHYON-A-Fast-and-small-Forth-byte-code-VM-(source-code-available)-Web-pages?p=1197527#post1197527
The nRF24L01 project will continue hopefully soon, when I am done with my relocation and the modules arrive.
http://forums.parallax.com/showthread.php/141061-TACHYON-A-Fast-and-small-Forth-byte-code-VM-(source-code-available)-Web-pages?p=1194837#post1194837
I always read this thread.
BTW, how does TACHION install on Propeller board?
Where is install-procedure?
Hi caskaz, there is no special install procedure with Tachyon as the complete source for the kernel is on a single page, either the formatted Google document (or the webpage verison) which is always up-to-date (even as I am editing it) or the Dropbox folder version. If you use the Google document then just select all, copy and paste into your Spin tool and hit F11 to load into your board. There's only one section you might customize to suit and that's the clock and baudrate which is about 5% into the document here: Once you have the compiled kernel loaded onto your board it is talking but you should paste or send the EXTEND.fth file for all the standard extras. I use Minicom with a 12ms line delay as there is no handshaking. If you look at the bottom of the Intro page (links in my sig) it will point you to the links page. Here is the main Dropbox page which I try to keep up-to-date.
Hi Markus,
I've tried to follow your post and I'm not quite sure where or what to reply to yet
I originally wrote Tachyon because I liked using Forth and needed something that could run fast enough for me to use for real work projects. So Tachyon has not been standard in many respects and yet it's tailored for the Prop and it's peculiarities which makes it very non-standard for a non-standard processor chip (which we love). Now in saying this I'm just hoping to draw your attention to the "real work projects" phrase
So as much as I appreciate forum chat I just find my time is a little limited sometimes but I will attempt to address each of your questions, although maybe not all in one or two posts.
BTW, you are welcome to be a collaborator so you can edit and document the main Tachyon 2.1 document or any other document for that matter. At the very least you could write up your own document pages and simply link to them from the source code document.
Thanks.
But it takes very much time to display webpage( formatted Google document) under my PC.
So it seems it very very very much time to copy code.
I gave up to copy them on the way.
Maybe because my PC is old and internet is poor.
Cannot you upload TACHYON kerenel source as spin.file?
Although Google docs works well it does need a decent internet connection and/or PC but as mentioned there are the plain text and Spin files in the dropbox section so just click on the link in my signature at the bottom of this post.
I downloaded TACHYON-V2.1.spin.
So, any chance of a Forth word that will load some PASM code into a Cog and then allow access via parameters ...
There is some clever PASM code out there I would like to interface Forth to, but the code is hundreds of longs ..
Cheers,
B.
PS. Thought I'd ask as the thread has gone a bit quite ..
I may put a coginit instruction in there but you can also use the LOADMOD instruction but specify a count >24 and it will load into address 0 of the current cog and automatically run from there once loaded.Normally LOADMOD just loads into the reserved module area which is limited to 24 longs. Use the Google version for this though, it's also the one with the newer serial driver I'm still playing with that is optimized for 100% burst throughput at 2M baud (and counting).
Now back to Peter's MCP79410 code ... I pulled the backup battery so I would be starting fresh and after replacing the battery I set Date and Time. When I went to print time and/or date it all blew up forcing a reboot and cyber-vomit on the console screen.
I checked a few things and I suspect what initially seemed like a terribly clever idea .... writing to the RTC buffer a long at a time rather than 4 byte write commands when setting hrs/mins/secs or yr/mon/day. I think that long write is getting caught up in that Little Endian / Big Endian byte order thingy. When I have more time this weekend, I'll look to confirm my suspicions.
Any way. I rewrote a lot of my DS1307 code borrowing liberally from some of Peter's code. This module will do either chip ... the venerable old DS1307 or the slick new DS3231.
The DS3231M at eight dollars plus in quantity 1-9 is not cheap but it has aTXCO resonator onboard and its rated 5 ppm accuracy. It will run on 2.9 to 5.5 v and tolerate 5v pull-ups even when Vcc is 3.3v . It comes in 8 or 16 pin SOIC. ( I soldered two them to Sparkfun 8 pin SOIC Breakout boards yesterday. It took me under 10 minutes for the two, including 2 4 pin male headers per board. If I can do that despite the shakes from Parkinson's most of you should be able to handle it.)
I have attached the code and the DS3231 Data Sheet
cheers .... BBR
The DS3231 is compatible enough with the MCP79410 that you should be able to use it as is, just change the device address. The first 7 registers are compatible although the 79410 does uses some of the otherwise unused bits for control purposes but that won't affect the 3231. Try it and let me know how is goes.
The device address can be changed either in the source code:
$DE == @rtc
to
$B0 == @rtc
So I checked the datasheet again and it is supposed to be $D0 so I don't know why I typed $B0, I suppose just to get you to check the datasheet yourself I guess!
What I like to see standardized between RTC chips is the read and write methods and formats for time and date. I like the BCD method as that is normally how RTC chips handle the data. So to set the time to 1:35PM it becomes $13:35:00 TIME! Printing the time and date become simple operations too.
The main application program is totally written in Tachyon Forth without any assembly and consumes less than 4K of code space despite the fact that I have a lot of diagnostic messaging built in over Bluetooth. Each monitor can have a keypad which the control application reads directly over RS485 and writes to the the Pixie's 512x384 tiled bitmap driver. A cog task continually checks the encoder inputs and processes these as well. There are also 12 bicolor LEDs via shift registers on the control unit that are continually updated from the main code, the write update time is 21us for 24 bits (12 LEDS).
What does the code look like? I'll just share one tiny snippet for the moment which updates the machine number when it's in the run mode (vs program mode): Here's another where the keypad codes are processed:
[COLOR=#000000][FONT=Ubuntu Mono]pub [/FONT][/COLOR][COLOR=#000000][FONT=Ubuntu Mono][B][KEYPAD][/B][/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono] >B SWITCH[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono] $1B CASE step ~ [HOLD] BREAK \ HOLD START/STOP[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono] "/" CASE [SET] BREAK[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono] "*" CASE [RECALL] BREAK [/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono] "-" CASE [STEP-] BREAK \ step down[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono] "+" CASE [STEP+] BREAK \ step up[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono] 8 CASE [CE] BREAK [/FONT][/COLOR][COLOR=#000000][FONT=Ubuntu Mono] \ clear entry[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono] ^M CASE [ENTER] LIST_STATS BREAK[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono] "." CASE [CLEAR] BREAK[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono] BL CASE [STEP0] BREAK[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono]\ numeric key[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono] SWITCH@ $30 $39 WITHIN IF SWITCH@ NUMERIC BREAK[/FONT][/COLOR] [COLOR=#000000][FONT=Ubuntu Mono] ;[/FONT][/COLOR]Bench shots (I/O module missing)I2CBUS was what tipped me off to the discrepancy.
Below is a snippet from MCP79410.fth from your webpage. TIME! and DATE! are your setting words ... they both look to me like they are writing a long to rtcbuf and the resulting write location was 'off'' by the 2 bytes shift of whatever-Endian byte order.
pub TIME! ( $hh.mm.ss -- ) \ write time in bcd format $2000.0080 OR rtcbuf ! WRRTC ; \ Usage: $130630 DATE! \ set the date to the 30th June 2013 pub DATE! ( $yy.mm.dd -- ) rtcbuf 4 + ! WRRTC ;If I am wrong, please show me where. I would much rather use your "$110400 TIME!" than my "$11 $04 $00 TIME!"
P.S. remember that the DS32 doesn't have those other bit flags mixed up with the time.
I moved over the TIME! and DATE! words of Peter's code and cleaned up a few things.