Into my AUTORUN "word" and it still doesn't boot without the USB cable and as a bonus ^A doesn't abort the AUTORUN either so know I need to rebuild the world to get back in.
I've had this issue with everyboard I use, I could really use a simple example of a booting tachyon system that does not rely on a USB connection.
I'm doing something wrong obviously.
I have an old Parallax demo board I could try it on, if you send me your code and I will see what is happening.
I've always had to have my tachyon boards tethered, POE, PPDB, Quickstart. There must be something fundamentally I'm missing here. But here are the modules loaded.
I have used the VGA bitmap object directly but since that is just PASM that runs in it's own cog there wasn't anything much to change whereas most of the objects available have Spin wrappers which can't be used. In many instances I find that much of this Spin code is redundant anyway. I will take a look at SIDcog though to see if there is a possibility or using it.
I have started to write the SIDcog interface for this and it looks fairly complete, now I only have to graft in the the PASM binary and the waveform table to start testing, but I probably won't have time to do anymore on this for at least a day or two. I have simplified the functions so that they can be combined easily and interactively from the serial terminal so it's very easy to experiment with SIDcog. It "sounds" like it will be a lot of fun once I can get back to finishing it.
Example of interacting with SIDcog (in one line)
0 CHAN 8 3 4 2 ADSR ON HP ON BP OFF LP ON SAWTOOTH #1000 NOTE
What that was about:
0 CHAN \ select channel 0
8 3 4 2 ADSR \ Set attack, decay, sustain, release (ADSR(
OFF HP \ Turn off highPass filter
ON BP \ Turn on bandpass filter
OFF LP \ Turn off lowpass filter
ON SAWTOOTH \ Select SAWTOOTH waveform
#1000 NOTE \ Play a note
Of course if that was a sound effect (no idea what it sounds like yet) you could just then define it as a new word.
Dang dude... do you ever sleep? I didn't mean for you to write the "whole dang thing" for me but I'll have loads of fun playing with it. I take it from the process you've indicated here that PASM parts of OBEX items will work unchanged with Tachyon but Spin parts have to be re-written. That's fair... I'm an old-time forth fan anyway so I'm up for a change of perspective. I won't be in front of a Propeller until tonight but will certainly fire up Tachyon tonight and get my bearings so I can start testing/contributing.
Dang dude... do you ever sleep? I didn't mean for you to write the "whole dang thing" for me but I'll have loads of fun playing with it. I take it from the process you've indicated here that PASM parts of OBEX items will work unchanged with Tachyon but Spin parts have to be re-written. That's fair... I'm an old-time forth fan anyway so I'm up for a change of perspective. I won't be in front of a Propeller until tonight but will certainly fire up Tachyon tonight and get my bearings so I can start testing/contributing.
Thanks again!
Uh oh, you will not believe the treat you are in for. You may not be sleeping much yourself! While some of the syntax has very slightly changed in the Introduction to Tachyon webpage it is still a great way to get started and understand the layout. Look forward to your contributions.
Could it be the FTDI resetting? There are many discussion about that, and the symptoms are the same.
Massimo
Excuse me for arriving late to this thread ... this BOE Tetherless Startup is old news ... as Massimo has stated it has already generated reams of discussion elsewhere in the Prop Forums and I don't know if any solution was ever reached ... perhaps @PhiPi knows ...
One step at a time, I have basic setup with only TACHYON and EXTEND.fth loaded on a quickstart REV A board with the Wiznet Quickstart Board attached so I have an external power connector to power the quickstart board sans USB cable.
Here is/are the only word/s I have added:
: BLINKY BEGIN #P17 PINSET 100d ms #P17 PINCLR 100d ms KEY? AND UNTIL ;
AUTORUN BLINKY
\ then executed a backup
Everything works fine, the system boots and blinks until I hit a key and even ^A aborts BLINKY after boot! But that is a KEY? so I don't think this counts.
When I unplug the USB cable (still have power from the wiznet board) the system doesn't blink any longer even after a power cycle.
Let's see if we can figure out this very simple example of my "failure to understand".
One step at a time, I have basic setup with only TACHYON and EXTEND.fth loaded on a quickstart REV A board with the Wiznet Quickstart Board attached so I have an external power connector to power the quickstart board sans USB cable.
Here is/are the only word/s I have added:
: BLINKY BEGIN #P17 PINSET 100d ms #P17 PINCLR 100d ms KEY? AND UNTIL ;
AUTORUN BLINKY
\ then executed a backup
Everything works fine, the system boots and blinks until I hit a key and even ^A aborts BLINKY after boot! But that is a KEY? so I don't think this counts.
When I unplug the USB cable (still have power from the wiznet board) the system doesn't blink any longer even after a power cycle.
Let's see if we can figure out this very simple example of my "failure to understand".
Thanks
Well that's a bit of a silly test now isn't it? It's accepts anything at all on the serial to abort the BLINKY, even a bit of noise from a misdriven (FT232 phantom power) receive line. How about using ESC? instead which will wait until it sees a valid escape character before aborting the loop.
Just to be on the safe side can you modify your TF kernel with this, at the "frmerror" label just insert a "jmp #receive" instruction to get it to ignore any break conditions.
There is the other possibility that the FT232 chip is resetting the Prop, but that's a hardware problem, isn't it? Why hasn't Parallax addressed this problem in it's Prop products? You could try keeping the transmit pin low so that it won't phantom power the FT232 chip, but you need to insert a "#P30 PINCLR" in your startup code but that mightn't work because the Prop might get reset before then. A quick fix is to place a load on the FT232 power rail by adding a 1K (or better still a 220R) or so resistor which should stop the supply rail from floating up high enough. The other thing is to insert a 10K series resistor in the transmit line to the FT232.
Well that's a bit of a silly test now isn't it? It's accepts anything at all on the serial to abort the BLINKY, even a bit of noise from a misdriven (FT232 phantom power) receive line. How about using ESC? instead which will wait until it sees a valid escape character before aborting the loop.
Just to be on the safe side can you modify your TF kernel with this, at the "frmerror" label just insert a "jmp #receive" instruction to get it to ignore any break conditions.
There is the other possibility that the FT232 chip is resetting the Prop, but that's a hardware problem, isn't it? Why hasn't Parallax addressed this problem in it's Prop products? You could try keeping the transmit pin low so that it won't phantom power the FT232 chip, but you need to insert a "#P30 PINCLR" in your startup code but that mightn't work because the Prop might get reset before then. A quick fix is to place a load on the FT232 power rail by adding a 1K (or better still a 220R) or so resistor which should stop the supply rail from floating up high enough. The other thing is to insert a 10K series resistor in the transmit line to the FT232.
Desperate times breed trouble, what I love about Tachyon is that is took < 60 seconds to make the change and test, including getting some water to drink.
The ESC? is in place and it works at expected, yes ^A does abort the AUTORUN as advertised.
Now about the FT232, that's a tiny thing and I'm sure I could short every pin trying to "hack" at it. Can I cut a usb cable, re-wire it and fake the chip that way. And yes for all the commercial stuff parallax wants to get going you don't get there unless you address your own products first. If the hardware implementation was/is "wrong", fix it, your customers will appreciate you for it and reward you.
And oh help them if David Carrier releases his new board with the same FT232 "bug" becuase it's the schematic they have always used.
Desperate times breed trouble, what I love about Tachyon is that is took < 60 seconds to make the change and test, including getting some water to drink.
The ESC? is in place and it works at expected, yes ^A does abort the AUTORUN as advertised.
Now about the FT232, that's a tiny thing and I'm sure I could short every pin trying to "hack" at it. Can I cut a usb cable, re-wire it and fake the chip that way. And yes for all the commercial stuff parallax wants to get going you don't get there unless you address your own products first. If the hardware implementation was/is "wrong", fix it, your customers will appreciate you for it and reward you.
And oh help them if David Carrier releases his new board with the same FT232 "bug" becuase it's the schematic they have always used.
See any stray "Puppys" looking for a good home?
Just looking at a typical Parallax product such as the Activity Board and it uses a FT231 chip with a gate to disable "garbage" on the receive line to the Prop but why there as the problem is that the Prop's TX if activated will idle high and still phantom power the chip. All it needed was a series resistor to limit the current so the FT231 can't power-up, that's all.
Just looking at a typical Parallax product such as the Activity Board and it uses a FT231 chip with a gate to disable "garbage" on the receive line to the Prop but why there as the problem is that the Prop's TX if activated will idle high and still phantom power the chip. All it needed was a series resistor to limit the current so the FT231 can't power-up, that's all.
Not to mention running with the C rowd, don't get me going here. It seems that with my laptop sleeping and the usb plugged in the board behaves the way I want it to so I should be able to do something with a cut USB cable no? Grab one of the bare lines and tie it low or high on the quickstart?
I've got sharp things and feeling like cutting something right now.
Not to mention running with the C rowd, don't get me going here. It seems that with my laptop sleeping and the usb plugged in the board behaves the way I want it to so I should be able to do something with a cut USB cable no? Grab one of the bare lines and tie it low or high on the quickstart?
I've got sharp things and feeling like cutting something right now.
I just tie VBUS to VCC as I normally run it off USB power or external power but then again, I haven't had any problems with it that way either. The bonus is that when you are developing you don't need any external supply.
I just tie VBUS to VCC as I normally run it off USB power or external power but then again, I haven't had any problems with it that way either. The bonus is that when you are developing you don't need any external supply.
Well it cost me a quickstart board because I made a pinout mistake. But your solution works on the BOE and the PPDB and I'm sure the quickstart as soon as I purchase another (if I do) thanks for all the patience Peter. This whole experience has not won any good feelings from me toward Parallax. Hey David Carrier: don't use the FT232 design that is broken on the quickstart board, the PPDB and the BOE board on your new Spinnerette design okay. No one in the field it seems has implemented the FT232 the way parallax has on these boards.
Now back to Tachyon and my project since this accidental complexity is gone, thanks again Peter.
As an alternative to FTDI modding consider a BT of wifly module. It costs 2 pins, but worth the experience!
In this case you set the serial console pins to the wireless module, p30 and p31 are left alone, and no spurious reset occurs.
OT: If you program with spin there is a pst dummy object to simplify debugging
Massimo
As an alternative to FTDI modding consider a BT of wifly module. It costs 2 pins, but worth the experience!
In this case you set the serial console pins to the wireless module, p30 and p31 are left alone, and no spurious reset occurs.
OT: If you program with spin there is a pst dummy object to simplify debugging
Massimo
Most of my boards don't have USB embedded in them as I simply have a 4x2 PropPlug compatible header instead. The second set of 4 pins include +5V and I2C signals so it is possible to power any adaptor that is plugged in such as my own Bluetooth modules or in the case of USB allowing it to power the board. The I2C lines are handy too as I can directly access the EEPROM and this allows for field programming where I have a little module that plugs in, blinks, and reprograms boards. The I2C can also be used as an expansion header to a peripheral board.
These modules can be plugged in as required or left in permanently.
@Max: A Bluetooth module does not allow for normal program download via the Spin tool so there is no need for it to reset the Prop anyway although my Bluetooth module does include remote programming support.
With some boards the reset happens when you have a serial stream to the ftdi chip, and the usb cable is not connected.
If you send tachyon console message to other pins you avoid the issue.
a cheap option is to get the bluetooth modules, attach one to a couple of spare pins, reload tachyon after changing the console pins (not 30 and 31 but your wireless module pins) and wirelessly connect using your pc's bluetooth or your android tablet. Not ipad/iphone. With ipad there are the wifly serial to wifi modules. More expensive and a little bit more complex to use.
Anyway with a little expense you have the possibility to remotely connect to the tachyon console and avoid the reset issue.
Check the forum for threads about the cheap bluetooth modules, or propforth wiki. They are sold also by obc on propellerpowered.
Peter discussed about them too.
connecting to a remote console, even if 5 cm away, is truly a great experience offered by forth on the propeller.
Sorry Peter, I wasn't clear.
My approach is to program the propeller using the "traditional", tethered way, and then remotely connect.
Your modules are very cool!
Thanks for sharing.
Massimo
Running this code in a separate COG does not "blink the lights" at 3 Hz but at ~164KHz?
Do I have a COGREGS issue?
Propeller .:.:--TACHYON--:.:. Forth V23131230.0000
MODULES LOADED:
1800: EXTEND.fth Primary extensions to TACHYON kernel - 131212-1200
: TOG A #15 APIN #14 BPIN 3 Hz 5 CTRMODE #10000 ms MUTE ;
TOG / RUNS AT 3 HZ and quits after 10 seconds
' TOG 4 RUN / RUNS AT ~164 KHz and quits after 10 secs
Running this code in a separate COG does not "blink the lights" at 3 Hz but at ~164KHz?
Do I have a COGREGS issue?
Propeller .:.:--TACHYON--:.:. Forth V23131230.0000
MODULES LOADED:
1800: EXTEND.fth Primary extensions to TACHYON kernel - 131212-1200
: TOG A #15 APIN #14 BPIN 3 Hz 5 CTRMODE #10000 ms MUTE ;
TOG / RUNS AT 3 HZ and quits after 10 seconds
' TOG 4 RUN / RUNS AT ~164 KHz and quits after 10 secs
Remember that if you test this out in the console cog first that it will set the pins to outputs for that cog so you either have to avoid doing this or reset the pins back to inputs with #15 PININP etc. Also each cog only has a 4 level stack now which might need to be expanded with an external stack, just as the console cog does at startup. This is certainly the case here as there are some calculations made to setup these modes and it looks like the internal stack is overflowing and returning the wrong result.
To avoid an external stack you could optimize the CTRMODE calculation by replacing the $1F #26 SHL with $7C.00.00.00 which should keep your task to within 4 levels In fact I might do this to the source code anyway.
Remember that if you test this out in the console cog first that it will set the pins to outputs for that cog so you either have to avoid doing this or reset the pins back to inputs with #15 PININP etc. Also each cog only has a 4 level stack now which might need to be expanded with an external stack, just as the console cog does at startup. This is certainly the case here as there are some calculations made to setup these modes and it looks like the internal stack is overflowing and returning the wrong result.
To avoid an external stack you could optimize the CTRMODE calculation by replacing the $1F #26 SHL with $7C.00.00.00 which should keep your task to within 4 levels In fact I might do this to the source code anyway.
I was in the code digesting your message and now I find out you have already changed it!
Tested, working. Moving right along. BTW very nice modules, your puppy's have bones it seems. Thanks for sharing.
I am using a Parallax Propeller Quick Start running TACHYON FORTH.
I would like to do this:
1. Pin 16 and Pin 17 are both LOW
2. At time t=0, pin 16 goes HIGH
3. 5 u-sec elapse
4. Pin 16 goes LOW
5. 2 u-sec elapse
6. Pin 17 goes HIGH
7. 3 u-sec elapse
8. Pin 17 goes LOW
9. At this point, a total of 10 u-sec have elapsed
10. Now 990 u-sec elapse, and the process repeats
Thus the two pulses are given 1000 times each second.
I have successfully used the PWMs to create signals of various frequency and duty-cycle, but I can not figure out how to implement the process described above.
Is it possible to start counters A and B at the same time? Is it possible to introduce a phase-shift between one and the other? What is the best way to achieve the process I have described?
I am using a Parallax Propeller Quick Start running TACHYON FORTH.
I would like to do this:
1. Pin 16 and Pin 17 are both LOW
2. At time t=0, pin 16 goes HIGH
3. 5 u-sec elapse
4. Pin 16 goes LOW
5. 2 u-sec elapse
6. Pin 17 goes HIGH
7. 3 u-sec elapse
8. Pin 17 goes LOW
9. At this point, a total of 10 u-sec have elapsed
10. Now 990 u-sec elapse, and the process repeats
Thus the two pulses are given 1000 times each second.
I have successfully used the PWMs to create signals of various frequency and duty-cycle, but I can not figure out how to implement the process described above.
Is it possible to start counters A and B at the same time? Is it possible to introduce a phase-shift between one and the other? What is the best way to achieve the process I have described?
I like FORTH very much Thank you Peter!
I wouldn't say that this is the best way to do it but I couldn't resist just converting your steps into Forth code. Obviously you have some small delays of a few microseconds and these would need to be trimmed to account for the instruction timing etc but it gives you an idea. What I would probably be more inclined to do is to have a small PASM module that gets LOADMOD'd just for the fast pulse sequences and then use the WAITCNT loop but try replacing some of the delays with NOPs instead to get your timing. I don't know how critical the timing should be but if it is very critical then a PASM module might be the way to go. When I get to sit down in front of a board I might try some other methods including counter methods.
[FONT=courier new]( 1. Pin 16 and Pin 17 are both LOW )
#P16 PINCLR #P17 PINCLR
#80,000 DELTA \ 1 ms WAITCNT @80MHz
( 2. At time t=0, pin 16 goes HIGH )
BEGIN
#P16 PINSET
( 3. 5 u-sec elapse )
5 us
( 4. Pin 16 goes LOW )
#P16 PINCLR
( 5. 2 u-sec elapse )
2 us
( 6. Pin 17 goes HIGH )
#P17 PINSET
( 7. 3 u-sec elapse )
3 us
( 8. Pin 17 goes LOW )
#P17 PINCLR
( 9. At this point, a total of 10 u-sec have elapsed )
WAITCNT \ synchronized to 1ms interval for precise 1kHz operation
10. Now 990 u-sec elapse, and the process repeats
[FONT=courier new] AGAIN
[/FONT]
[/FONT]
I understand the code you posted, but I could not get it to work correctly.
I believe that the "us" word messes up WAITCNT.
I was able to achieve what I wanted to do by using only WAITCNT several times.
Here is a simplified version of the code you posted:
Propeller .:.:--TACHYON--:.:. Forth V23131230.0000
AUTORUN BOOT
MODULES LOADED:
306B: sean4th.fth Some FORTH for Sean 01/13/13
1800: EXTEND.fth Primary extensions to TACHYON kernel - 131212-1200
----------------------------------------------------------------
: FT
#16 PINCLR
#80,000 DELTA
BEGIN
#16 PINSET
#100 us
#16 PINCLR
WAITCNT
AGAIN
;
' FT 3 RUN
When I run the above code, I get a 50% duty cycle square wave which is 4.621 kHz. That is, a square wave which is ON for 100 us, then OFF for 100 us.
It appears that the "us" word is resetting the value of DELTA.
If I change "#100 us" to "#750 us" I still get a 50% duty cycle square wave, but it is ON and OFF for 750 us.
The following code gives a wave which is 1.000 kHz; it is on for 250 us and off for 750 us:
: FT
#16 PINCLR
#20,000 DELTA
BEGIN
#16 PINSET
WAITCNT
#16 PINCLR
WAITCNT
WAITCNT
WAITCNT
AGAIN
;
I understand the code you posted, but I could not get it to work correctly.
I believe that the "us" word messes up WAITCNT.
I was able to achieve what I wanted to do by using only WAITCNT several times.
Here is a simplified version of the code you posted:
Propeller .:.:--TACHYON--:.:. Forth V23131230.0000
AUTORUN BOOT
MODULES LOADED:
306B: sean4th.fth Some FORTH for Sean 01/13/13
1800: EXTEND.fth Primary extensions to TACHYON kernel - 131212-1200
----------------------------------------------------------------
: FT
#16 PINCLR
#80,000 DELTA
BEGIN
#16 PINSET
#100 us
#16 PINCLR
WAITCNT
AGAIN
;
' FT 3 RUN
When I run the above code, I get a 50% duty cycle square wave which is 4.621 kHz. That is, a square wave which is ON for 100 us, then OFF for 100 us.
It appears that the "us" word is resetting the value of DELTA.
If I change "#100 us" to "#750 us" I still get a 50% duty cycle square wave, but it is ON and OFF for 750 us.
The following code gives a wave which is 1.000 kHz; it is on for 250 us and off for 750 us:
: FT
#16 PINCLR
#20,000 DELTA
BEGIN
#16 PINSET
WAITCNT
#16 PINCLR
WAITCNT
WAITCNT
WAITCNT
AGAIN
;
My bad, I did this away from my system so I just did a quick code of it but yes, the us and ms both use DELTA so that won't work just like that. Sometimes for small delays it's better just to use some dummy instructions instead of the small delays and then just use WAITCNT for the 1kHz timing.
COGSTOP only stops the cog itself and effectively freezes the process so this can still show up in the task list. Normally once a task is started it is left to run unless it exits back to the IDLE loop.I may do some more work on this at least to make the TASK list reflect what's going on a bit better, it's just a simple listing really.
This code will produce two 1 us pulses, once every milisecond.
When I make just one pulse this way, it appears to be 1 us (or less) on the scope.
This code makes two pulses with a short delay between them. Together, they seem to fit within a 2 us division on the scope.
: FOUNTAIN
$FFFF_FFFF $1F6 COG! \ set pins as outputs
#80_000 DELTA \ WAITCNT every 1 ms
BEGIN
$0000_0000 $1F4
$00FF_0000 $1F4
COG! COG!
$0000_0000 $1F4
$00FF_0000 $1F4
COG! COG!
WAITCNT
AGAIN
;
If you want longer pulses, you can put some NOP's between the two COG!
If you want longer delay between the two pulses, put some NOP's after the first two COG!
I hope this is useful to someone (like me) who needs to do some precise timing
That code looks all wrong as you are setting ALL the port pins to outputs plus you don't have to explicitly set any pins as outputs as the OUTSET and OUTCLR instructions already take a mask for this purpose, set or clear those pins and make sure the pin is an output. Even so the timing is much longer than 2us as a literal pushed to the stack plus just one OUTxxx instruction can take from 2.4us (fast literal) to 4.8us (user constant).
Writing directly to the DIR and OUT registers using cog addresses is slow and inefficient and unnecessary. I will look at some code that will give you precise timing (measured) and let you know.
EDIT: Here's some tested code that produces 5us high then a 2.4us gap then 3us high at 1kHz
[FONT=courier new]#P16 |< == P16
#P17 |< == P17
P16 P17 OR == P1617
: FOUNTAIN
P1617 OUTCLR
#80,000 DELTA
P16 P17 \ setup port masks on stack for faster access
BEGIN
OVER OUTSET 8 DROP OVER OUTCLR \ 5us hi
\ 2.4us gap
DUP OUTSET NOP ?DUP OUTCLR \ 3us hi
ESC? IF EXIT THEN \ allow an escape back to the console
WAITCNT
AGAIN
;
[/FONT]
Some of you may have been using the countdown timers that are built into EXTEND.fth that run in their own cog. Some changes have been made to improve integration with modules as previously a fixed table of 8 counters were assigned and a module would be assigned one or more manually. I then tried a dynamic assignment method a week ago but I wasn't all that happy with it so I have now scrapped the fixed table approach and introduced a linked timer method. Initially no timers are assigned but as soon as a "timer" address is passed to TIMEOUT then this is linked into the timer list and maintained accordingly. Normally these timers are simple countdown to zero and execute an ALARM condition if set or else do nothing style counters but they can now also be set to up-count as well.
As with before there are 8 bytes required for each timer and they are:
timer value (4)
alarm (2)
link (2)
DOUBLE timer1
To startup (and link) a timer it is the same as retriggering it:
#1000 timer1 TIMEOUT
So there is no need to specially link in the new timer as TIMEOUT will check this. You can use as many timers as would be practical.but now you specify the variable/address to use, that's it.
Here's a quick test of it in operation:
[FONT=courier new][B]DOUBLE timer1[/B] ok
[B]DOUBLE timer2[/B] ok
ok
[B]-1 timer1 TIMEOUT[/B] ok
[B]-1 2/ timer2 TIMEOUT[/B] ok
[B]TIMERS?[/B] ticks = 1/1000
30B4: timer2 =7FFF.FFEC L30A8
30A8: timer1 =FFFF.FFD0 L0001 ok
[B]DOUBLE lockout[/B] ok
[B]#10,000 lockout TIMEOUT[/B] ok
ok
[B]TIMERS?[/B] ticks = 1/1000
30C0: lockout =0000.02C0 L30B4
30B4: timer2 =7FFF.DB66 L30A8
30A8: timer1 =FFFF.DB49 L0001 ok
[/FONT]
Comments
I have an old Parallax demo board I could try it on, if you send me your code and I will see what is happening.
And I just sent you Relay8.fth by PM
Massimo
I have started to write the SIDcog interface for this and it looks fairly complete, now I only have to graft in the the PASM binary and the waveform table to start testing, but I probably won't have time to do anymore on this for at least a day or two. I have simplified the functions so that they can be combined easily and interactively from the serial terminal so it's very easy to experiment with SIDcog. It "sounds" like it will be a lot of fun once I can get back to finishing it.
Example of interacting with SIDcog (in one line)
0 CHAN 8 3 4 2 ADSR ON HP ON BP OFF LP ON SAWTOOTH #1000 NOTE
What that was about:
0 CHAN \ select channel 0
8 3 4 2 ADSR \ Set attack, decay, sustain, release (ADSR(
OFF HP \ Turn off highPass filter
ON BP \ Turn on bandpass filter
OFF LP \ Turn off lowpass filter
ON SAWTOOTH \ Select SAWTOOTH waveform
#1000 NOTE \ Play a note
Of course if that was a sound effect (no idea what it sounds like yet) you could just then define it as a new word.
Here's the link to the Tachyon Google webpage document for the SIDcog module.
Thanks again!
Uh oh, you will not believe the treat you are in for. You may not be sleeping much yourself! While some of the syntax has very slightly changed in the Introduction to Tachyon webpage it is still a great way to get started and understand the layout. Look forward to your contributions.
Excuse me for arriving late to this thread ... this BOE Tetherless Startup is old news ... as Massimo has stated it has already generated reams of discussion elsewhere in the Prop Forums and I don't know if any solution was ever reached ... perhaps @PhiPi knows ...
One step at a time, I have basic setup with only TACHYON and EXTEND.fth loaded on a quickstart REV A board with the Wiznet Quickstart Board attached so I have an external power connector to power the quickstart board sans USB cable.
Here is/are the only word/s I have added: Everything works fine, the system boots and blinks until I hit a key and even ^A aborts BLINKY after boot! But that is a KEY? so I don't think this counts.
When I unplug the USB cable (still have power from the wiznet board) the system doesn't blink any longer even after a power cycle.
Let's see if we can figure out this very simple example of my "failure to understand".
Thanks
Well that's a bit of a silly test now isn't it? It's accepts anything at all on the serial to abort the BLINKY, even a bit of noise from a misdriven (FT232 phantom power) receive line. How about using ESC? instead which will wait until it sees a valid escape character before aborting the loop.
Just to be on the safe side can you modify your TF kernel with this, at the "frmerror" label just insert a "jmp #receive" instruction to get it to ignore any break conditions.
There is the other possibility that the FT232 chip is resetting the Prop, but that's a hardware problem, isn't it? Why hasn't Parallax addressed this problem in it's Prop products? You could try keeping the transmit pin low so that it won't phantom power the FT232 chip, but you need to insert a "#P30 PINCLR" in your startup code but that mightn't work because the Prop might get reset before then. A quick fix is to place a load on the FT232 power rail by adding a 1K (or better still a 220R) or so resistor which should stop the supply rail from floating up high enough. The other thing is to insert a 10K series resistor in the transmit line to the FT232.
Desperate times breed trouble, what I love about Tachyon is that is took < 60 seconds to make the change and test, including getting some water to drink.
The ESC? is in place and it works at expected, yes ^A does abort the AUTORUN as advertised.
Now about the FT232, that's a tiny thing and I'm sure I could short every pin trying to "hack" at it. Can I cut a usb cable, re-wire it and fake the chip that way. And yes for all the commercial stuff parallax wants to get going you don't get there unless you address your own products first. If the hardware implementation was/is "wrong", fix it, your customers will appreciate you for it and reward you.
And oh help them if David Carrier releases his new board with the same FT232 "bug" becuase it's the schematic they have always used.
See any stray "Puppys" looking for a good home?
Just looking at a typical Parallax product such as the Activity Board and it uses a FT231 chip with a gate to disable "garbage" on the receive line to the Prop but why there as the problem is that the Prop's TX if activated will idle high and still phantom power the chip. All it needed was a series resistor to limit the current so the FT231 can't power-up, that's all.
Not to mention running with the C rowd, don't get me going here. It seems that with my laptop sleeping and the usb plugged in the board behaves the way I want it to so I should be able to do something with a cut USB cable no? Grab one of the bare lines and tie it low or high on the quickstart?
I've got sharp things and feeling like cutting something right now.
Well it cost me a quickstart board because I made a pinout mistake. But your solution works on the BOE and the PPDB and I'm sure the quickstart as soon as I purchase another (if I do) thanks for all the patience Peter. This whole experience has not won any good feelings from me toward Parallax. Hey David Carrier: don't use the FT232 design that is broken on the quickstart board, the PPDB and the BOE board on your new Spinnerette design okay. No one in the field it seems has implemented the FT232 the way parallax has on these boards.
Now back to Tachyon and my project since this accidental complexity is gone, thanks again Peter.
dp
In this case you set the serial console pins to the wireless module, p30 and p31 are left alone, and no spurious reset occurs.
OT: If you program with spin there is a pst dummy object to simplify debugging
Massimo
Most of my boards don't have USB embedded in them as I simply have a 4x2 PropPlug compatible header instead. The second set of 4 pins include +5V and I2C signals so it is possible to power any adaptor that is plugged in such as my own Bluetooth modules or in the case of USB allowing it to power the board. The I2C lines are handy too as I can directly access the EEPROM and this allows for field programming where I have a little module that plugs in, blinks, and reprograms boards. The I2C can also be used as an expansion header to a peripheral board.
These modules can be plugged in as required or left in permanently.
@Max: A Bluetooth module does not allow for normal program download via the Spin tool so there is no need for it to reset the Prop anyway although my Bluetooth module does include remote programming support.
If you send tachyon console message to other pins you avoid the issue.
a cheap option is to get the bluetooth modules, attach one to a couple of spare pins, reload tachyon after changing the console pins (not 30 and 31 but your wireless module pins) and wirelessly connect using your pc's bluetooth or your android tablet. Not ipad/iphone. With ipad there are the wifly serial to wifi modules. More expensive and a little bit more complex to use.
Anyway with a little expense you have the possibility to remotely connect to the tachyon console and avoid the reset issue.
Check the forum for threads about the cheap bluetooth modules, or propforth wiki. They are sold also by obc on propellerpowered.
Peter discussed about them too.
connecting to a remote console, even if 5 cm away, is truly a great experience offered by forth on the propeller.
My approach is to program the propeller using the "traditional", tethered way, and then remotely connect.
Your modules are very cool!
Thanks for sharing.
Massimo
Do I have a COGREGS issue?
To avoid an external stack you could optimize the CTRMODE calculation by replacing the $1F #26 SHL with $7C.00.00.00 which should keep your task to within 4 levels In fact I might do this to the source code anyway.
I was in the code digesting your message and now I find out you have already changed it!
Tested, working. Moving right along. BTW very nice modules, your puppy's have bones it seems. Thanks for sharing.
I am using a Parallax Propeller Quick Start running TACHYON FORTH.
I would like to do this:
1. Pin 16 and Pin 17 are both LOW
2. At time t=0, pin 16 goes HIGH
3. 5 u-sec elapse
4. Pin 16 goes LOW
5. 2 u-sec elapse
6. Pin 17 goes HIGH
7. 3 u-sec elapse
8. Pin 17 goes LOW
9. At this point, a total of 10 u-sec have elapsed
10. Now 990 u-sec elapse, and the process repeats
Thus the two pulses are given 1000 times each second.
I have successfully used the PWMs to create signals of various frequency and duty-cycle, but I can not figure out how to implement the process described above.
Is it possible to start counters A and B at the same time? Is it possible to introduce a phase-shift between one and the other? What is the best way to achieve the process I have described?
I like FORTH very much
I wouldn't say that this is the best way to do it but I couldn't resist just converting your steps into Forth code. Obviously you have some small delays of a few microseconds and these would need to be trimmed to account for the instruction timing etc but it gives you an idea. What I would probably be more inclined to do is to have a small PASM module that gets LOADMOD'd just for the fast pulse sequences and then use the WAITCNT loop but try replacing some of the delays with NOPs instead to get your timing. I don't know how critical the timing should be but if it is very critical then a PASM module might be the way to go. When I get to sit down in front of a board I might try some other methods including counter methods.
[FONT=courier new]( 1. Pin 16 and Pin 17 are both LOW ) #P16 PINCLR #P17 PINCLR #80,000 DELTA \ 1 ms WAITCNT @80MHz ( 2. At time t=0, pin 16 goes HIGH ) BEGIN #P16 PINSET ( 3. 5 u-sec elapse ) 5 us ( 4. Pin 16 goes LOW ) #P16 PINCLR ( 5. 2 u-sec elapse ) 2 us ( 6. Pin 17 goes HIGH ) #P17 PINSET ( 7. 3 u-sec elapse ) 3 us ( 8. Pin 17 goes LOW ) #P17 PINCLR ( 9. At this point, a total of 10 u-sec have elapsed ) WAITCNT \ synchronized to 1ms interval for precise 1kHz operation 10. Now 990 u-sec elapse, and the process repeats [FONT=courier new] AGAIN [/FONT] [/FONT]I understand the code you posted, but I could not get it to work correctly.
I believe that the "us" word messes up WAITCNT.
I was able to achieve what I wanted to do by using only WAITCNT several times.
Here is a simplified version of the code you posted:
Propeller .:.:--TACHYON--:.:. Forth V23131230.0000 AUTORUN BOOT MODULES LOADED: 306B: sean4th.fth Some FORTH for Sean 01/13/13 1800: EXTEND.fth Primary extensions to TACHYON kernel - 131212-1200 ---------------------------------------------------------------- : FT #16 PINCLR #80,000 DELTA BEGIN #16 PINSET #100 us #16 PINCLR WAITCNT AGAIN ; ' FT 3 RUNWhen I run the above code, I get a 50% duty cycle square wave which is 4.621 kHz. That is, a square wave which is ON for 100 us, then OFF for 100 us.
It appears that the "us" word is resetting the value of DELTA.
If I change "#100 us" to "#750 us" I still get a 50% duty cycle square wave, but it is ON and OFF for 750 us.
The following code gives a wave which is 1.000 kHz; it is on for 250 us and off for 750 us:
: FT #16 PINCLR #20,000 DELTA BEGIN #16 PINSET WAITCNT #16 PINCLR WAITCNT WAITCNT WAITCNT AGAIN ;Also COGSTOP does not seem to work.
My bad, I did this away from my system so I just did a quick code of it but yes, the us and ms both use DELTA so that won't work just like that. Sometimes for small delays it's better just to use some dummy instructions instead of the small delays and then just use WAITCNT for the 1kHz timing.
COGSTOP only stops the cog itself and effectively freezes the process so this can still show up in the task list. Normally once a task is started it is left to run unless it exits back to the IDLE loop.I may do some more work on this at least to make the TASK list reflect what's going on a bit better, it's just a simple listing really.
This code will produce two 1 us pulses, once every milisecond.
When I make just one pulse this way, it appears to be 1 us (or less) on the scope.
This code makes two pulses with a short delay between them. Together, they seem to fit within a 2 us division on the scope.
If you want longer pulses, you can put some NOP's between the two COG!
If you want longer delay between the two pulses, put some NOP's after the first two COG!
I hope this is useful to someone (like me) who needs to do some precise timing
That code looks all wrong as you are setting ALL the port pins to outputs plus you don't have to explicitly set any pins as outputs as the OUTSET and OUTCLR instructions already take a mask for this purpose, set or clear those pins and make sure the pin is an output. Even so the timing is much longer than 2us as a literal pushed to the stack plus just one OUTxxx instruction can take from 2.4us (fast literal) to 4.8us (user constant).
Writing directly to the DIR and OUT registers using cog addresses is slow and inefficient and unnecessary. I will look at some code that will give you precise timing (measured) and let you know.
EDIT: Here's some tested code that produces 5us high then a 2.4us gap then 3us high at 1kHz
[FONT=courier new]#P16 |< == P16 #P17 |< == P17 P16 P17 OR == P1617 : FOUNTAIN P1617 OUTCLR #80,000 DELTA P16 P17 \ setup port masks on stack for faster access BEGIN OVER OUTSET 8 DROP OVER OUTCLR \ 5us hi \ 2.4us gap DUP OUTSET NOP ?DUP OUTCLR \ 3us hi ESC? IF EXIT THEN \ allow an escape back to the console WAITCNT AGAIN ; [/FONT]As with before there are 8 bytes required for each timer and they are:
timer value (4)
alarm (2)
link (2)
DOUBLE timer1
To startup (and link) a timer it is the same as retriggering it:
#1000 timer1 TIMEOUT
So there is no need to specially link in the new timer as TIMEOUT will check this. You can use as many timers as would be practical.but now you specify the variable/address to use, that's it.
Here's a quick test of it in operation:
pub BOEPAB.fth ." TACHYON Robot Control for BOE Platform & Prop Activity Board " ; { Motor drivers and utilities. } #P12 2 MASKS == pwmpins #1495 #80 * == ld0 \ sets zero position of left servo #1504 #80 * == rd0 \ sets zero position of right servo LONG lduty, rduty pub .duty ( -- ) \ displays current right & left duties lduty @ . SPACE rduty @ . CR ; pub M1 ( duty -- ) \ sets left servo duty: -1000 - 1000 #10 * ld0 + lduty ! ; pub M2 ( duty -- ) \ sets right servo duty: -1000 - 1000 NEGATE #10 * rd0 + rduty ! ; pub S ( -- ) \ abruptly stops bot motion 0 M1 0 M2 ; pub D1 ( -- ) \ toggles left wheel direction lduty @ ld0 - NEGATE ld0 + lduty ! ; pub D2 ( -- ) \ toggles right wheel direction rduty @ rd0 - NEGATE rd0 + rduty ! ; pri rc_motors ( -- ) \ left and right servo pwm drivers pwmpins OUTCLR S A NCO #P12 APIN 1 FRQ 0 PHSA COG! B NCO #P13 APIN 1 FRQ 0 PHSB COG! BEGIN lduty @ NEGATE PHSA COG! rduty @ NEGATE PHSB COG! 20 ms 0 UNTIL ; pub MSTART ( -- ) \ executes servo drivers in a cog ' rc_motors TASK? RUN 50 ms ; { Encoders record current total counts per wheel. } #P14 2 MASKS == encpins LONG lenc, renc, xl, xr pub .enc ( -- ) \ lists current encoder counter values lenc @ . SPACE renc @ . CR ; pub zenc ( -- ) \ set left and right encoder counters to 0 0 lenc ! 0 renc ! ; pri rc_enc ( -- ) \ simple encoder drivers based on basic stamp boebot program TRUE xl ! TRUE xr ! encpins INPUTS zenc BEGIN #P14 PIN@ DUP xl @ = IF DROP ELSE xl ! lenc ++ THEN #P15 PIN@ DUP xr @ = IF DROP ELSE xr ! renc ++ THEN 0 UNTIL ; pub ESTART ( -- ) \ executes encoder drivers in a cog ' rc_enc TASK? RUN 50 ms ; { Ping ultrasonic distance measurement (inches). } #1400 == p0 \ sets standard servo 0 position #8 == dist? \ sets ping stop condition in inches LONG (dist), pos pub !pos ( angle -- ) \ where angle is -90 - 90 degrees (right to left) #10 * p0 + #80 * pos ! ; pub dist ( -- value ) \ places current ping value (inches) on stack (dist) @ ; pub .dist ( -- ) \ displaces current ping value (inches) dist . CR ; BYTE (stp) \ stores stop flag pub restp ( -- ) \ resets stop flag to TRUE TRUE (stp) C! ; pub stp ( -- flag ) \ places stop flag on stack (stp) C@ ; pri rc_ping ( -- ) \ ping driver - automatic stop condition #P17 PINCLR 0 !pos B #P17 APIN NCO 1 FRQ A 1 FRQ BEGIN #P16 PINCLR A #P16 APIN NCO #400 NEGATE PHSA COG! #1000 CTRMODE 0 PHSA COG! #P16 PININP pos @ NEGATE PHSB COG! 50 ms PHSA COG@ #11800 / DUP (dist) ! dist? < stp AND IF FALSE (stp) C! S THEN 0 UNTIL ; : PSTART ( -- ) \ executes ping driver in a cog restp ' rc_ping TASK? RUN 50 ms ; { User parameters. } \ user constants - 2.625 inch wheel diameter 4.312 inch between wheels #8 == wcirc \ wheel circumference in inches #64 == counts \ number of counts per wheel rotation #8 == ctin \ counts per inch #136 == rcirc \ rotation circumfirence in 0.1 inch units #271 == tcirc \ turn circumfirence in 0.1 inches pub R ( -- ) \ hardware reset - execute START to continue #P9 PINCLR ; pub START MSTART ESTART PSTART DECIMAL ; { ******************************************************************************** This completes the RCL Core. Simple (indefinite) motion commands, which use indexed tables to select duties. }NickL