The motors are working fine. But "better" is "good's" enemy. So some issues I'm dealing with:
1. I would like to add some further axis/channel specific data to each axis. First of all i would like to give a direction bit to be able to change turning direction via one bit. This cries for something like a table where pins and direction bit can be maintained in one place for every axis. Doesn't it?
2. I want to use some pushbuttons - there was not yet the time to search for an example
3. I tested the PWM functions in EXTEND.FTH some weeks ago - there is no possibility to give a different PWM for each channel isn't it?
4. Another thing i couldn't solve was setting a variable interactively
chan C@ . 25 ok
chan 26 C! ok
chan C@ . 25 ok
Is there a restriction of changing variables in interactive mode?
5. I remember that there have been some help functions/idioms like MATCH SD WORDS in this thread but I didn't get managed with it. Is there an documentation/explanation around? Short answer is enough although i feel the glossary is hard stuff for me.
6. a model car without a remote control is like soup without salt :-) I think one way would be to do some bluetooth with an android smartphone. I heard there are android projects which can do this. Is there a propeller even Tachyon based solution available? My 3 sons are waiting :-)
You have done well because you have it functioning, friendly, and you are having fun.
Later on you will see ways to make this more concise and efficient but that is more to do with coding than with programming. For example you could replace all the CH0..CH8 with a single CH and a table lookup and call with 0 CH to 8 CH. There's also redundant 0 + code in there too although you could define : CH+ ( index -- ) chan C@ + ; so FWD becomes 0 CH+ LOW 1 CH+ HIGH 2 CH+ HIGH for instance. Just as you have made it work first you can start to see repetitive patterns that can be optimized both for readability and compactness.
BTW, the CH table lookup method would be something like this:
Of course you won't be able to do the ALIAS in the same manner but you could say : DRIVE 0 CH ; etc
Now, simple answers...
1. Sounds simple enough but not quite sure what you are asking for with a "single bit". Could you give an example of how it would look interactively?
2. Reading the state of pin 6 for instance is simply 6 PIN@ which returns a TRUE or FALSE. Connect a pushbutton to ground and a pullup resistor to the pin and code like this:
: FWD? ( -- flg ) 6 PIN@ NOT ;
This is even simpler if you use the LOW? word:
: FWD? ( -- flg ) 6 LOW? ;
3. The PWM function in Tachyon is really very powerful, there are 32 independent channels running at up to 7.6kHz with 8-bit resolution. You can trade resolution on any channel for higher frequencies too. I will publish some more info on this in a subsequent "tips and tricks" thread I started but if you look at the EXTEND.fth code you will see examples around line 1380 including the SPLAT analyzer output with 20 channels running independently.
4. D.P answered that as you have it back to front! Your code was corrupting location 26 with the low byte of the chan address.
5. Help functions are limited in a 32k Prop but can be added if you have an SD card. BTW, the glossary is the absolute cut-down 101 basics, you need that even for question 4.
6. There are quite a few Bluetooth controller apps and besides the terminals such as Blueterm there is "Bluetooth Serial Controller" by NEXT PROTOTYPES which has a set of configurable buttons that you can label and assign commands to. I use this for some applications but there are others.
I'm glad you are having fun and not holding back. People have the habit of dipping their big toe in the water so to speak while others just dive in and after shivering briefly enjoy the swim. Come in they say to the other big toe dippers to which they reply "No, it's too cold, you're crazy"
Please keep us updated on your fire truck project, thanks for sharing!
The motors are working fine. But "better" is "good's" enemy. So some issues I'm dealing with:
1. I would like to add some further axis/channel specific data to each axis. First of all i would like to give a direction bit to be able to change turning direction via one bit. This cries for something like a table where pins and direction bit can be maintaine;d in one place for every axis. Doesn't it?
2. I want to use some pushbuttons - there was not yet the time to search for an example
3. I tested the PWM functions in EXTEND.FTH some weeks ago - there is no possibility to give a different PWM for each channel isn't it?
4. Another thing i couldn't solve was setting a variable interactively
chan C@ . 25 ok
chan 26 C! ok
chan C@ . 25 ok
Is there a restriction of changing variables in interactive mode?
5. I remember that there have been some help functions/idioms like MATCH SD WORDS in this thread but I didn't get managed with it. Is there an documentation/explanation around? Short answer is enough although i feel the glossary is hard stuff for me.
6. a model car without a remote control is like soup without salt :-) I think one way would be to do some bluetooth with an android smartphone. I heard there are android projects which can do this. Is there a propeller even Tachyon based solution available? My 3 sons are waiting :-)
Thank you all for your very welcomed responses and help! There are good news - the first demonstration yesterday in the evening was quite successful, i could switch motors, light on and off even blue light came without flashing to life :-)
Status:
1. fire truck propeller is running out of pins. Five L293D every one with 2 channels each controlled by 3 pins is too much for propeller 1 :-)))) I decided to continue until there is real a show stopper. I shortly thought over a possibility of i2c H-bridges but this detonates my time budget and i want to go forward the way of least resistance.
2. A PPDB is not the platform for a water resistant housing inside of a model car. This is a much bigger challenge for me because of my software background. Maybe I have to restrict usage of the pump this would gain 3 pins for bluetooth. Can someone give an advice which bluetooth chip I should use?
3. I'm trying to let the blue lights flash in background and use
pri FLASHTASK
\ usage: FLASHTASK via console or see FLASHON
chan C@ \ remember actual channel on stack - I'm a really forther :-)
BEGIN
LFTBLIGHT FWD 500 ms HLT
RGTBLIGHT FWD 500 ms HLT
ATN@ \ get command from controller task
0 > \ >0 then blinking off and quit loop
REPEAT
chan C! \ write remembered channel back
;
: FLASHON
\ usage: FLASHON
\ start blue light flashing in background
' FLASHTASK TASK? RUN
;
: FLASHOFF
\ usage: FLASHOFF
CR ." FIXME: FLASHOFF has to be implemented" CR
;
but there is an error
pri FLASHTASK
\
chan C@ \
BEGIN
LFTBLIGHT FWD 500 ms HLT
RGTBLIGHT FWD 500 ms HLT
ATN@ \
0 > \
REPEAT Structure mismatch! *error*
i could not yet resolve.
By the way - I'm not sure wether I understood the intertask communication - a extended Blinky example in the tutorial would be helpful (to finish blinking).
@Peter: I don't want to tell you again about tachyon what so many people around the world already did in a better way before. I'm really happy to work on this project and with such a tachyon powered effectiveness. If I could I would dive a lot more into this stuff.
I also enjoy to work in a world wide community this is new to me.
Thank you all for your very welcomed responses and help! There are good news - the first demonstration yesterday in the evening was quite successful, i could switch motors, light on and off even blue light came without flashing to life :-)
Status:
3. I'm trying to let the blue lights flash in background and use
I also enjoy to work in a world wide community this is new to me.
Thanks for every support,
proplem
Much easier is in any cog, let's say your light is connected to pin 12
12 APIN \ set pin 12 to the A pin of the timer in the current cog running this code
3 HZ \ set it blinking at 3 times per second
2000 ms \ wait for 2 seconds
MUTE \ stop it
This will run independently on the A timer in the cog, easy. Play with it on console to test it out.
Here is a great application note on the timers but Peter has already broken them down Tachyon style into simple words, constants and actions for us!
@Peter:
some details to my question 1:
I would like to have something that I can reference like an array of struct in C with an Index and access to the members of the struct.
Following information should be contained:
flag enable
direction (one bit)
PWM frequency (byte)
duty cycle (byte)
pinno1 (byte)
pinno2 (byte)
pinno3 (byte)
According to your last lesson :-) a table looks like this
FALSE == cw \ clock wise FIXME: mathematical positive angle is ccw better TRUE or FALSE ?
TRUE == ccw \ counter clock wise
: Hz 1 * ; \ just for readability and because it's possible
Is it possible to mix words and bytes and how can one access in such a 2-dimensional array?
Where does the interpreter know which size a column has? I checked: currently everything is a byte. But is there a possiblity to define a col as a word?
@Peter:
some details to my question 1:
I would like to have something that I can reference like an array of struct in C with an Index and access to the members of the struct.
Following information should be contained:
flag enable
direction (one bit)
PWM frequency (byte)
duty cycle (byte)
pinno1 (byte)
pinno2 (byte)
pinno3 (byte)
According to your last lesson :-) a table looks like this
FALSE == cw \ clock wise FIXME: mathematical positive angle is ccw better TRUE or FALSE ?
TRUE == ccw \ counter clock wise
: Hz 1 * ; \ just for readability and because it's possible
Is it possible to mix words and bytes and how can one access in such a 2-dimensional array?
Where does the interpreter know which size a column has? I checked: currently everything is a byte. But is there a possiblity to define a col as a word?
BTW: such a table looks really informative.
Thanks in advance,
proplem
Tables are bytes, words or longs. Just use a word table and move on. You can optimize later. Get those lights blinking with the counters/timers!
Thank you all for your very welcomed responses and help! There are good news - the first demonstration yesterday in the evening was quite successful, i could switch motors, light on and off even blue light came without flashing to life :-)
Status:
3. I'm trying to let the blue lights flash in background and use
I also enjoy to work in a world wide community this is new to me.
Thanks for every support,
proplem
Much easier is in any cog, let's say your light is connected to pin 12
12 APIN \ set pin 12 to the A pin of the timer in the current cog running this code
3 HZ \ set it blinking at 3 times per second
2000 ms \ wait for 2 seconds
MUTE \ stop it
This will run independently on the A timer in the cog, easy. Play with it on console to test it out.
Here is a great application note on the timers but Peter has already broken them down Tachyon style into simple words, constants and actions for us!
Thanks D.P. - maybe anywhere in EXTEND.fth there is a FITRUCTL word i have overseen?
(FIreTRUckConTroL in Peter Style) which does all with one pin and is of course water resistant :-)))
@Peter:
some details to my question 1:
I would like to have something that I can reference like an array of struct in C with an Index and access to the members of the struct.
Following information should be contained:
flag enable
direction (one bit)
PWM frequency (byte)
duty cycle (byte)
pinno1 (byte)
pinno2 (byte)
pinno3 (byte)
According to your last lesson :-) a table looks like this
FALSE == cw \ clock wise FIXME: mathematical positive angle is ccw better TRUE or FALSE ?
TRUE == ccw \ counter clock wise
: Hz 1 * ; \ just for readability and because it's possible
Is it possible to mix words and bytes and how can one access in such a 2-dimensional array?
Where does the interpreter know which size a column has? I checked: currently everything is a byte. But is there a possiblity to define a col as a word?
BTW: such a table looks really informative.
Thanks in advance,
proplem
1. yes - it's possible to mix bytes, words, longs in a table - BUT word and long access expect word/long alignment.
so here it would work like this:
pub Hz ; \ will do ;-)
TABLE mottbl ON | ccw | 500 Hz || 0 % | 25 | 26 | 27 |
note the || which compiles a word into the table.
Tables start LONG aligned. And it is good to make sure words/longs are correctly aligned.
The interpreter does NOT know about column/row sizes unless you tell it.
btw. if you set a variable rarely and read it in many places/often then it might be nice to define it as a CONSTANT.
And a constant can be modified ;-)
0 == chan
5 TO chan \ make it 5
chan .
pub chan! ( val -- ) TO chan ;
17 chan!
chan .
MJB, D.P. thanks for your prompt responses. MJB's answer is challenging for me :-) D.P. is driving me forward, so i will keep on him at first.
How Do i "declare" the data type for a word/long the table? I can't see it out of the sources (EXTEND.fth).
I will try your (D.P.) counter tip as soon as possible. I only had a malfunctioning spinneret at hand (without EXTEND.fth) so the counter things were not available.
Tomorrow we finish our holidays in France, i must go to bed now.
( started this reply hours ago, just getting around to sending )
Blinky in a cog is a waste and you could use two counters or use the timer cog, here are the ways:
BTW, can't see why you would need 293s to drive these, surely just a single i/o per led should do and these examples are based upon that assumption.
Using the counter:
A LFTBLIGHT APIN RGTBLIGHT BPIN 1 HZ DIFF
Should alternate in the background automatically, just use MUTE to stop them blinking.
Using the timer cog:
TIMER flashing
: FLASH LFTBLIGHT PIN@ IF LFTBLIGHT LOW RGTBLIGHT HIGH ELSE LFTBLIGHT HIGH RGTBLIGHT LOW THEN 500 flashing TIMEOUT ;
' FLASH flashing ALARM
use FLASH to activate the timer and 0 flashing TIMEOUT to stop that timer but you also need to turn off the leds.
btw, in the table method you used "500 HZ" which is not a value since HZ would compile and execute when the || symbol is emcountered, so just say 500.
MJB, D.P. thanks for your prompt responses. MJB's answer is challenging for me :-) D.P. is driving me forward, so i will keep on him at first.
you can do BOTH ;-)
How Do i "declare" the data type for a word/long the table? I can't see it out of the sources (EXTEND.fth).
Good night!
you DON'T declare data type. TABLE just creates a new word with the given name and makes sure it is LONG aligned. When executed it returns the address on he stack like any variable.
Then you just compile anything after it as you like. No additional logic there.
Just make sure the alignment fits for the W@ and @ operators otherwise you get garbage.
You can create more 'intelligent' data structures. e.g. see STRING, which stores size and length before the actual characters. Also the serial buffer is handled like this with rdptr and wrptr before the data.
We could define an ARRAY type in a similar way and then some accessors.
btw, in the table method you used "500 HZ" which is not a value since HZ would compile and execute when the || symbol is emcountered, so just say 500.
strange I had tried this before I posted it and it seamed to work.
pub Hz ; \ ok
TABLE mottbl ON | ccw | 500 Hz || 0 % | 25 | 26 | 27 | ok
pub FRQ@ ( row -- val ) 8 * mottbl + 2+ W@ ; ok
0 FRQ@ .S Data Stack (1)
$0000.01F4 - 500 ok
WCOMP alias || does a GRAB before so all should be fine.
There is already a HZ in the dictionary for setting a counter to generate a frequency but I didn't see that you had defined a dummy Hz instead. So on a GRAB it effectively executes any temporary compilation which would have been a problem if you had not defined Hz instead which I didn't see as I probably missed it as I was flat out on a hospital bed at the time of my reply
There is already a HZ in the dictionary for setting a counter to generate a frequency but I didn't see that you had defined a dummy Hz instead. So on a GRAB it effectively executes any temporary compilation which would have been a problem if you had not defined Hz instead which I didn't see as I probably missed it as I was flat out on a hospital bed at the time of my reply
sure I know the counter HZ :-)
I was just using @proplem's example code to show him, how it would work.
all the best for you !!
- the IoT5500 should be here next week - I hope.
Spinneret with your latest built seemed a bit unstable here, so I postponed testing to the IoT.
Makes no sense to start with changes on a shaky ground.
( started this reply hours ago, just getting around to sending )
Blinky in a cog is a waste and you could use two counters or use the timer cog, here are the ways:
BTW, can't see why you would need 293s to drive these, surely just a single i/o per led should do and these examples are based upon that assumption.
Using the counter:
A LFTBLIGHT APIN RGTBLIGHT BPIN 1 HZ DIFF
Should alternate in the background automatically, just use MUTE to stop them blinking.
Using the timer cog:
TIMER flashing
: FLASH LFTBLIGHT PIN@ IF LFTBLIGHT LOW RGTBLIGHT HIGH ELSE LFTBLIGHT HIGH RGTBLIGHT LOW THEN 500 flashing TIMEOUT ;
' FLASH flashing ALARM
use FLASH to activate the timer and 0 flashing TIMEOUT to stop that timer but you also need to turn off the leds.
btw, in the table method you used "500 HZ" which is not a value since HZ would compile and execute when the || symbol is emcountered, so just say 500.
Peter,
For explanation of the wasting use of 293s: The fire truck is already quite a few years old - it has old fashioned light bulbs 2 for front, 2 for rear and 2 for blue light. I use the 293s because they work although my 9V battery seems tu suffer the current waste if I let them on. I will replace the bulbs with LEDs in future although I love the taste of nostalgy - the bulbs create warm light :-)
Peter,
For explanation of the wasting use of 293s: The fire truck is already quite a few years old - it has old fashioned light bulbs 2 for front, 2 for rear and 2 for blue light. I use the 293s because they work although my 9V battery seems tu suffer the current waste if I let them on. I will replace the bulbs with LEDs in future although I love the taste of nostalgy - the bulbs create warm light :-)
Best wishes,
Heiko
Yes, well I suppose it is easy to use them as four independent drivers with enables wired on but a simple bjt would work just as well too and much cheaper. Those 9V batteries are the worst both in terms of value/energy and energy/volume. It's a pity you couldn't use a couple of AAs and step them up to the voltage you need as those batteries take about the same volume, deliver far more energy, are far cheaper, and with the step-up will maintain output until the batteries are almost exhausted. Many step-up chips have an enable pin and you could use this to cut power to the chips and even to the Prop or at least go into low-power mode.
Today I fixed some OEM toy quality hardware issues and made the blue lights blinking with a counter solution according to Peter's recommendation.
It appears that the fire truck is an energy sink. For real remote operation without wired power supply there have some things to be optimized. We'll see later.
There is also a packaging problem in front of me. With which propeller board am I able to fit the control into the housing? How can it be water resistant? Challenges to be solved in future.
The next milestone I'd like to reach is a bluetooth interface. This is a real show stopper - no remote control no real operation. This is a totally new task for me I'll be going to concentrate on. Unfortunately holidays are over.
Best regards - and again thanks a lot to all who helped me, yours
proplem
I just use the HC05/06 Bluetooth modules directly into P30/P31 but resistively coupled so that if I plug in an external USB "Prop plug" it can override the Bluetooth.
Most of the Parallax boards are designed for learning (built-in USB, linear regs, breadboard area etc) and not for embedding but if you take a few photos with some ruler in the shot for reference some of us might come up with some ideas. I have designed scores of boards myself and I'm sure that anyone of these would be a good solution, in fact a small Prop module plugged into a matrix board with your drivers would be the most obvious solution as the matrix board can be cut to any shape or size or even into sections.
Fire Truck project executive summary with respect to Tachyon
I want to spend some words to my experience made with this little project respecting Tachyon:
- as a user with basic hardware knowledge and strong software background Tachyon proved as a tool giving an enormous thrust for embedded development
- the already often mentioned advantages of this tool could be fully verified (according to the capabilties of the author)
- I unconditionally recommend working with Tachyon especially for people new to embedded stuff
- Forth as one aspect of Tachyon has great potential.
- I will definitely continue using Tachyon
- documentation should be collected, concentrated and moderated to unchain the potential
Peter,
Has anyone done a C3 board header with appropriate changes for the C3's SPI selection logic?
I know we have had the C3 SD card working but I will update the C3.H header file to include any additional methods although someone else will have to check it out.
Just checked and there is a method in SDCARD that checks the PCB id as $C3 to correctly select the SD card but the header was incomplete so I've updated it so far.
edit: changed that back to the product code of 32209 and update sdcard as well.
That board has an RS-232 interface and the usb-serial cable is also compatible RS-232 db9 so you should be able to plug it in and just load up Tachyon. But the board looks a little basic but big, it's almost better just to get the Prop onto your own matrix board so you can customize it a bit better.
Hi Peter,
after a longer search for a matching USB cable, I plugged everything together and it worked within minutes.
Another platform supported by tachyon :-D
I have to blow the dust away from the board and will give it a try in the fire truck. I have to buy some sockets for the L293D flood and I tend to order such a HC-06 Bluetooth module you mentioned earlier.
Testing new virtual full-duplex over half-duplex network driver
Question: Anyone using RS485 or similar half-duplex networks?
I'm testing out a very simple and powerful RS485 network protocol which I simply refer to as ping-pong since it communicates in a ping-pong fashion with remote slaves over RS485 or even just single I/O line networks. Currently I'm just cruising at 1Mbps while testing but the interesting thing is that the protocol has no extra overhead or cogs used and provides a virtual full-duplex console connection. So imagine that you want to plug your USB serial directly into a board on the network but it is at the other end of the plant or it only accessible over telnet remotely. What this ping-pong protocol does is allow you to connect to a network node and establish a full-duplex connection to the Tachyon Forth console exactly as if you plugged directly into the P30/31 serial port. From there you could even issue a COLD start and reload everything or else anything that you normally do over a terminal.
On my bench I have strung together about 14 boards over RS-485 and by sending an address code over the bus it deselects all units except the one I want to talk to and stays connected. I have a WS2812 RGB LED on each so that helps me to check that I'm talking to the right one. The address code is simply ASCII codes $80-$EF as these codes are normally unused over a text based console and other codes used for enhancing the protocol. The slave responds with the same address code then simply waits for a character from the port before passing that through and buffering it the same as and indistinguishable from a normal serial console receive. For every character it receives it also responds with something from its transmit register which then overwrites the transmit register with a null (and most of the time it's a null that it responds with). This is like the ball in ping pong that gets served and passed back but in this case each end "writes" a character at a time on it or returns it blank (null). If a ball gets "lost" then the master serves up a new ball. Since either end cannot send again until it has the ball this simplifies and regulates timing as well.
Example of selecting a unit and sending a simple CR over the RS485 line (master..slave): $81..$81.....$0D..$00.....$00..$00...~...$00..$20,.....$00..$6F......$00..$6B......$00..$0D......$00..$0A......$00..$00
This method is very good for doing what we do best in Forth, development, debugging, testing etc through a terminal. There is also an additional method for application runtime messages that don't need the full text string parsing dictionary search method but uses a look-up table which translates symbols/letters to a Forth word while all digits are rapidly processed and stacked. Instead of sending a verbose string such as "55 % FLOW<cr>" we instead in terse mode send "55%F" where both % and F index straight into a look-up table for the execute vector for % and FLOW. The latency from command to execute is extremely fast. The escape code can put us back into verbose mode easily or terse commands could be preceded with a special control character.
If I have multiple Propellers on the same board or chassis I don't need to use RS485 but I can connect them all together with a single I/O using only a resistor for safety.
So who has suitable networks that they would like to do some testing on? I know how I would use this but I'd like to see if there are any enhancements I could make to the protocol that may come to light in other applications. For sure there is more I have in mind for later and most are straight-forward simple things such as including using a 9-bit mode to allow for transparent data and also variable "ball" size so that we could send multiple characters before a response etc which might be even more suitable for wireless links and also for the terse mode. There is also a method for multiple masters (any node) but I don't have a need for that at present.
@Peter,
for my >50 1-Wire temp sensors I set up a 1-wire network with 4-wire phone cable around house and systems. So besides power, GND and 1Wire I have still 1 additional wire free in the cable. Using it to connect several props with a central IoT5500/P8 sounds great.
But since it is a simple low quality cable, an adjustable / LOW baud rate might be better than going MBits/s ... would this be possible with your driver or are you just using the 'as fast as possible' bit-bashing like for SPI ?
Comments
It's really fun. As Peter predicted one can input The motors are working fine. But "better" is "good's" enemy. So some issues I'm dealing with:
1. I would like to add some further axis/channel specific data to each axis. First of all i would like to give a direction bit to be able to change turning direction via one bit. This cries for something like a table where pins and direction bit can be maintained in one place for every axis. Doesn't it?
2. I want to use some pushbuttons - there was not yet the time to search for an example
3. I tested the PWM functions in EXTEND.FTH some weeks ago - there is no possibility to give a different PWM for each channel isn't it?
4. Another thing i couldn't solve was setting a variable interactively Is there a restriction of changing variables in interactive mode?
5. I remember that there have been some help functions/idioms like MATCH SD WORDS in this thread but I didn't get managed with it. Is there an documentation/explanation around? Short answer is enough although i feel the glossary is hard stuff for me.
6. a model car without a remote control is like soup without salt :-) I think one way would be to do some bluetooth with an android smartphone. I heard there are android projects which can do this. Is there a propeller even Tachyon based solution available? My 3 sons are waiting :-)
Thanks in advance - regards
Heiko
You have the stack backwards for the word C!
data address
Later on you will see ways to make this more concise and efficient but that is more to do with coding than with programming. For example you could replace all the CH0..CH8 with a single CH and a table lookup and call with 0 CH to 8 CH. There's also redundant 0 + code in there too although you could define : CH+ ( index -- ) chan C@ + ; so FWD becomes 0 CH+ LOW 1 CH+ HIGH 2 CH+ HIGH for instance. Just as you have made it work first you can start to see repetitive patterns that can be optimized both for readability and compactness.
BTW, the CH table lookup method would be something like this: Of course you won't be able to do the ALIAS in the same manner but you could say : DRIVE 0 CH ; etc
Now, simple answers...
1. Sounds simple enough but not quite sure what you are asking for with a "single bit". Could you give an example of how it would look interactively?
2. Reading the state of pin 6 for instance is simply 6 PIN@ which returns a TRUE or FALSE. Connect a pushbutton to ground and a pullup resistor to the pin and code like this:
: FWD? ( -- flg ) 6 PIN@ NOT ;
This is even simpler if you use the LOW? word:
: FWD? ( -- flg ) 6 LOW? ;
3. The PWM function in Tachyon is really very powerful, there are 32 independent channels running at up to 7.6kHz with 8-bit resolution. You can trade resolution on any channel for higher frequencies too. I will publish some more info on this in a subsequent "tips and tricks" thread I started but if you look at the EXTEND.fth code you will see examples around line 1380 including the SPLAT analyzer output with 20 channels running independently.
4. D.P answered that as you have it back to front! Your code was corrupting location 26 with the low byte of the chan address.
5. Help functions are limited in a 32k Prop but can be added if you have an SD card. BTW, the glossary is the absolute cut-down 101 basics, you need that even for question 4.
6. There are quite a few Bluetooth controller apps and besides the terminals such as Blueterm there is "Bluetooth Serial Controller" by NEXT PROTOTYPES which has a set of configurable buttons that you can label and assign commands to. I use this for some applications but there are others.
I'm glad you are having fun and not holding back. People have the habit of dipping their big toe in the water so to speak while others just dive in and after shivering briefly enjoy the swim. Come in they say to the other big toe dippers to which they reply "No, it's too cold, you're crazy"
Please keep us updated on your fire truck project, thanks for sharing!
Thank you all for your very welcomed responses and help! There are good news - the first demonstration yesterday in the evening was quite successful, i could switch motors, light on and off even blue light came without flashing to life :-)
Status:
1. fire truck propeller is running out of pins. Five L293D every one with 2 channels each controlled by 3 pins is too much for propeller 1 :-)))) I decided to continue until there is real a show stopper. I shortly thought over a possibility of i2c H-bridges but this detonates my time budget and i want to go forward the way of least resistance.
2. A PPDB is not the platform for a water resistant housing inside of a model car. This is a much bigger challenge for me because of my software background. Maybe I have to restrict usage of the pump this would gain 3 pins for bluetooth. Can someone give an advice which bluetooth chip I should use?
3. I'm trying to let the blue lights flash in background and use but there is an error i could not yet resolve.
By the way - I'm not sure wether I understood the intertask communication - a extended Blinky example in the tutorial would be helpful (to finish blinking).
@Peter: I don't want to tell you again about tachyon what so many people around the world already did in a better way before. I'm really happy to work on this project and with such a tachyon powered effectiveness. If I could I would dive a lot more into this stuff.
I also enjoy to work in a world wide community this is new to me.
Thanks for every support,
proplem
Much easier is in any cog, let's say your light is connected to pin 12
This will run independently on the A timer in the cog, easy. Play with it on console to test it out.
Here is a great application note on the timers but Peter has already broken them down Tachyon style into simple words, constants and actions for us!
some details to my question 1:
I would like to have something that I can reference like an array of struct in C with an Index and access to the members of the struct.
Following information should be contained:
flag enable
direction (one bit)
PWM frequency (byte)
duty cycle (byte)
pinno1 (byte)
pinno2 (byte)
pinno3 (byte)
According to your last lesson :-) a table looks like this
FALSE == cw \ clock wise FIXME: mathematical positive angle is ccw better TRUE or FALSE ?
TRUE == ccw \ counter clock wise
: Hz 1 * ; \ just for readability and because it's possible
TABLE mottbl ON | ccw | 500 Hz | 0 % | 25 | 26 | 27 |
ON | ccw | 500 Hz | 0 % | 22 | 23 | 24 |
ON | ccw | 500 Hz | 0 % | 19 | 20 | 21 |
ON | ccw | 500 Hz | 0 % | 16 | 17 | 18 |
ON | ccw | 500 Hz | 0 % | 13 | 14 | 15 |
ON | ccw | 500 Hz | 0 % | 10 | 11 | 12 |
OFF | ccw | 500 Hz | 0 % | 7 | 8 | 9 |
OFF | ccw | 500 Hz | 0 % | 4 | 5 | 6 |
OFF | ccw | 500 Hz | 0 % | 1 | 2 | 3 |
Is it possible to mix words and bytes and how can one access in such a 2-dimensional array?
Where does the interpreter know which size a column has? I checked: currently everything is a byte. But is there a possiblity to define a col as a word?
BTW: such a table looks really informative.
Thanks in advance,
proplem
Tables are bytes, words or longs. Just use a word table and move on. You can optimize later. Get those lights blinking with the counters/timers!
(FIreTRUckConTroL in Peter Style) which does all with one pin and is of course water resistant :-)))
Thank you - it's really funny finding help here.
1. yes - it's possible to mix bytes, words, longs in a table - BUT word and long access expect word/long alignment.
so here it would work like this: note the || which compiles a word into the table.
Tables start LONG aligned. And it is good to make sure words/longs are correctly aligned.
The interpreter does NOT know about column/row sizes unless you tell it. fetches the DIR or FRQ value
of course we factor out and row is your channel 0..n ??
And a constant can be modified ;-)
saves the @ each time BUT is only LONG
How Do i "declare" the data type for a word/long the table? I can't see it out of the sources (EXTEND.fth).
I will try your (D.P.) counter tip as soon as possible. I only had a malfunctioning spinneret at hand (without EXTEND.fth) so the counter things were not available.
Tomorrow we finish our holidays in France, i must go to bed now.
Good night!
( started this reply hours ago, just getting around to sending )
Blinky in a cog is a waste and you could use two counters or use the timer cog, here are the ways:
BTW, can't see why you would need 293s to drive these, surely just a single i/o per led should do and these examples are based upon that assumption.
Using the counter:
A LFTBLIGHT APIN RGTBLIGHT BPIN 1 HZ DIFF
Should alternate in the background automatically, just use MUTE to stop them blinking.
Using the timer cog:
TIMER flashing
: FLASH LFTBLIGHT PIN@ IF LFTBLIGHT LOW RGTBLIGHT HIGH ELSE LFTBLIGHT HIGH RGTBLIGHT LOW THEN 500 flashing TIMEOUT ;
' FLASH flashing ALARM
use FLASH to activate the timer and 0 flashing TIMEOUT to stop that timer but you also need to turn off the leds.
btw, in the table method you used "500 HZ" which is not a value since HZ would compile and execute when the || symbol is emcountered, so just say 500.
Then you just compile anything after it as you like. No additional logic there.
Just make sure the alignment fits for the W@ and @ operators otherwise you get garbage.
You can create more 'intelligent' data structures. e.g. see STRING, which stores size and length before the actual characters. Also the serial buffer is handled like this with rdptr and wrptr before the data.
We could define an ARRAY type in a similar way and then some accessors.
There is already a HZ in the dictionary for setting a counter to generate a frequency but I didn't see that you had defined a dummy Hz instead. So on a GRAB it effectively executes any temporary compilation which would have been a problem if you had not defined Hz instead which I didn't see as I probably missed it as I was flat out on a hospital bed at the time of my reply
I was just using @proplem's example code to show him, how it would work.
all the best for you !!
- the IoT5500 should be here next week - I hope.
Spinneret with your latest built seemed a bit unstable here, so I postponed testing to the IoT.
Makes no sense to start with changes on a shaky ground.
Peter,
For explanation of the wasting use of 293s: The fire truck is already quite a few years old - it has old fashioned light bulbs 2 for front, 2 for rear and 2 for blue light. I use the 293s because they work although my 9V battery seems tu suffer the current waste if I let them on. I will replace the bulbs with LEDs in future although I love the taste of nostalgy - the bulbs create warm light :-)
Best wishes,
Heiko
Today I fixed some OEM toy quality hardware issues and made the blue lights blinking with a counter solution according to Peter's recommendation.
It appears that the fire truck is an energy sink. For real remote operation without wired power supply there have some things to be optimized. We'll see later.
There is also a packaging problem in front of me. With which propeller board am I able to fit the control into the housing? How can it be water resistant? Challenges to be solved in future.
The next milestone I'd like to reach is a bluetooth interface. This is a real show stopper - no remote control no real operation. This is a totally new task for me I'll be going to concentrate on. Unfortunately holidays are over.
Best regards - and again thanks a lot to all who helped me, yours
proplem
Most of the Parallax boards are designed for learning (built-in USB, linear regs, breadboard area etc) and not for embedding but if you take a few photos with some ruler in the shot for reference some of us might come up with some ideas. I have designed scores of boards myself and I'm sure that anyone of these would be a good solution, in fact a small Prop module plugged into a matrix board with your drivers would be the most obvious solution as the matrix board can be cut to any shape or size or even into sections.
I want to spend some words to my experience made with this little project respecting Tachyon:
- as a user with basic hardware knowledge and strong software background Tachyon proved as a tool giving an enormous thrust for embedded development
- the already often mentioned advantages of this tool could be fully verified (according to the capabilties of the author)
- I unconditionally recommend working with Tachyon especially for people new to embedded stuff
- Forth as one aspect of Tachyon has great potential.
- I will definitely continue using Tachyon
- documentation should be collected, concentrated and moderated to unchain the potential
Best regards,
proplem
Has anyone done a C3 board header with appropriate changes for the C3's SPI selection logic?
I know we have had the C3 SD card working but I will update the C3.H header file to include any additional methods although someone else will have to check it out.
Just checked and there is a method in SDCARD that checks the PCB id as $C3 to correctly select the SD card but the header was incomplete so I've updated it so far.
edit: changed that back to the product code of 32209 and update sdcard as well.
after a longer search for a matching USB cable, I plugged everything together and it worked within minutes.
Another platform supported by tachyon :-D
I have to blow the dust away from the board and will give it a try in the fire truck. I have to buy some sockets for the L293D flood and I tend to order such a HC-06 Bluetooth module you mentioned earlier.
Question: Anyone using RS485 or similar half-duplex networks?
I'm testing out a very simple and powerful RS485 network protocol which I simply refer to as ping-pong since it communicates in a ping-pong fashion with remote slaves over RS485 or even just single I/O line networks. Currently I'm just cruising at 1Mbps while testing but the interesting thing is that the protocol has no extra overhead or cogs used and provides a virtual full-duplex console connection. So imagine that you want to plug your USB serial directly into a board on the network but it is at the other end of the plant or it only accessible over telnet remotely. What this ping-pong protocol does is allow you to connect to a network node and establish a full-duplex connection to the Tachyon Forth console exactly as if you plugged directly into the P30/31 serial port. From there you could even issue a COLD start and reload everything or else anything that you normally do over a terminal.
On my bench I have strung together about 14 boards over RS-485 and by sending an address code over the bus it deselects all units except the one I want to talk to and stays connected. I have a WS2812 RGB LED on each so that helps me to check that I'm talking to the right one. The address code is simply ASCII codes $80-$EF as these codes are normally unused over a text based console and other codes used for enhancing the protocol. The slave responds with the same address code then simply waits for a character from the port before passing that through and buffering it the same as and indistinguishable from a normal serial console receive. For every character it receives it also responds with something from its transmit register which then overwrites the transmit register with a null (and most of the time it's a null that it responds with). This is like the ball in ping pong that gets served and passed back but in this case each end "writes" a character at a time on it or returns it blank (null). If a ball gets "lost" then the master serves up a new ball. Since either end cannot send again until it has the ball this simplifies and regulates timing as well.
Example of selecting a unit and sending a simple CR over the RS485 line (master..slave):
$81..$81.....$0D..$00.....$00..$00...~...$00..$20,.....$00..$6F......$00..$6B......$00..$0D......$00..$0A......$00..$00
This method is very good for doing what we do best in Forth, development, debugging, testing etc through a terminal. There is also an additional method for application runtime messages that don't need the full text string parsing dictionary search method but uses a look-up table which translates symbols/letters to a Forth word while all digits are rapidly processed and stacked. Instead of sending a verbose string such as "55 % FLOW<cr>" we instead in terse mode send "55%F" where both % and F index straight into a look-up table for the execute vector for % and FLOW. The latency from command to execute is extremely fast. The escape code can put us back into verbose mode easily or terse commands could be preceded with a special control character.
If I have multiple Propellers on the same board or chassis I don't need to use RS485 but I can connect them all together with a single I/O using only a resistor for safety.
So who has suitable networks that they would like to do some testing on? I know how I would use this but I'd like to see if there are any enhancements I could make to the protocol that may come to light in other applications. For sure there is more I have in mind for later and most are straight-forward simple things such as including using a 9-bit mode to allow for transparent data and also variable "ball" size so that we could send multiple characters before a response etc which might be even more suitable for wireless links and also for the terse mode. There is also a method for multiple masters (any node) but I don't have a need for that at present.
for my >50 1-Wire temp sensors I set up a 1-wire network with 4-wire phone cable around house and systems. So besides power, GND and 1Wire I have still 1 additional wire free in the cable. Using it to connect several props with a central IoT5500/P8 sounds great.
But since it is a simple low quality cable, an adjustable / LOW baud rate might be better than going MBits/s ... would this be possible with your driver or are you just using the 'as fast as possible' bit-bashing like for SPI ?