Frank,
Yes I am new here, but if you look at my only few posts you will find that I only ask for help.
All i get from anyone is "Read the Data sheet". Or what I ask is "trivial"
I have looked at the DataSheets. Sometimes I don't understand them, and that's why I come here
asking for help. What may be trivial for some is hard for others. I am also new to the Propeller.
But if all I get is snickered at for being the dumb one, I will not ask for help anymore.
Thank you Frank ...and Peter
Actually I would encourage you to continue both with your prop projects and asking for help here. You have already had answers from two very heavy hitters on the forum. Not sure from one member to the next who has what background or reasons for being here, but after a time you begin to get a feel for the posters background experience and possibly their likely time constraints. Sometimes answers are prompt, sometimes a particular thread may cover days or even weeks depending on who has personal time for what. We have jobs, family obligations, employer/contract/projects all demanding our time. Being obtuse or snarky will only cause members to not help you out if they feel disrespected by a post such as that last. Review past posts to get a feel for the etiquette of the forums such as how to post code etc. Then keep asking when reasonable efforts still don'the get the expected behaviors. Can't tell you how often the wired or of the cog I/O has caused me problems. An extra eye may see it when your too close to the problem. So, experiment, rip up and retry. You can't really hurt anything (within reason), and come back for help when you need it. Patience will usually result in ideas, examples and on occasion, answers.
Best of luck
Peter, please forgive me the short detour to your thread.....
@Jammer7071 - either take your meds, or stop taking them. There is never any need to be paranoid about people snickering at you or ignoring you, at least not on this forum. We don't know you personally and therefore have no reason to treat you any different from anyone else. Please don't change our attitude in this regard. I noticed you asked about a Spin driver for this chip back in March, and I answered you within 24 hours, and you thanked me. I have therefore taken your thanks into consideration.
However, we all live in different time zones and when you posted it was a busy weekend. Notwithstanding, I remembered late on Saturday (after midnight) and started looking at what changes I needed to make to the universal RTC driver to accommodate the changes. I also happened to have a board and that chip loaded onto one of my RTC PCB modules, so I tested it out. Something wasn't right but at 2:30AM it was time for some sleep. Sunday morning I traveled into the city and had to put up with waves of selfish nasty me-first people, and then I read your post. How do you think I might feel??? Not even 24 hours after you first requested help.
As it is, I'm not a person to hold something against somebody although I might just avoid them for health reasons. Now it's Sunday night and I have found the bug and I am fixing it so that the Tachyon RTC driver supports chips like the PCF8563 that feel the need to have their timekeeping registers in a different place from other chips. When I get back to it later tonight I will have it all fixed and tested.
@"frank freedman" - thanks for keeping the peace, never any need to apologize for that.
Well, I'm late to the Tachyon party, blind or both. Peter is there an instruction, blog or thread describing what the add-ons and other materials on the download site are / do, and how to use them? I was able to get the base Tachyon V5.3 into the PPDB, but not sure what comes next. Also, the PPDB has an additional RS-232 port, is there a set of instructions related to the PPDB?
After EXTEND the main modules are EASYFILE and EASYNET. Practically everything else is in EXTEND but in the V5 folder for instance there are some demo apps such as BREAKOUT plus I'm updating SPLAT, my logic analyzer app.
As for RS-232 that is easy as you can either use the simple serial words SEROUT and SERIN which work fine up to over 200k baud or use one of the ROMs such as UART for full-duplex or HSUART for high auto-duplex. I find full-duplex is rarely needed though because other than the console all command/response communication tends to be half-duplex in nature.
If I wanted to load up five cogs with the HSUART ROM I would set them up this way:
" HSUART " 3 par1 12 5 LOADCOGS
Where I have a fixed length string with the name of the ROM to load in from cog 3 using the parameter table par1 and then because I am loading multiple cogs I specify the step size of 12 for the parameter table so that each of the 5 cogs can have its own parameters.
I will try to post some code to show you how to use it unless of course you mention how you want to use it, and then I can be more specific.
Thank you Peter, that is good to know. Guess I need to read through the files more. Not sure how to load extend if in 5.3 it is not already part of the initial download to the prop. Started poking around in my old Starting Forth, since I am grounded for a few more weeks. (Sucks, but beats going nuts on CT systems and everything else that gets thrown on my plate in a normal week).
Story for you, dates back to the 80s. Had a friend who worked at the coal terminals. Interesting problem. Cars would be run up the ramp in pairs, defrosted if need be (winter, coal traveled from West Va, through to the Virginia coast terminals) clamped, rotated and dumped onto ship loading conveyor belts. Then the fun starts..... The cars are pushed out onto a ramp, run up an incline, track switch thrown and off to the siding for pick up they would go. Well mostly. .. Seems as the cars would sometimes decouple at the top exiting dumper. So now imagine two cars, one coming back down the incline and the second which was supposed to be with it but is just now going down the exit ramp meeting at the bottom. Suddenly. Very suddenly. Solution was a monitoring system using Forth to monitor for decoupling at the exit to lock down the second car until the first cleared the switch. He was doing a lot of interesting things with Forth at the time, this one was a bit more memorable. .
Found the intro doc in your links so now to get the incantations right. Trying putty and hyperterm on a win 10 surface pro. Nah, did not help. Had to go with TeraTerm as described. All working so far. Maybe play with putty again when I think about it. Time to sally Forth!
Thank you Peter, that is good to know. Guess I need to read through the files more. Not sure how to load extend if in 5.3 it is not already part of the initial download to the prop. Started poking around in my old Starting Forth, since I am grounded for a few more weeks. (Sucks, but beats going nuts on CT systems and everything else that gets thrown on my plate in a normal week).
Story for you, dates back to the 80s. Had a friend who worked at the coal terminals. Interesting problem. Cars would be run up the ramp in pairs, defrosted if need be (winter, coal traveled from West Va, through to the Virginia coast terminals) clamped, rotated and dumped onto ship loading conveyor belts. Then the fun starts..... The cars are pushed out onto a ramp, run up an incline, track switch thrown and off to the siding for pick up they would go. Well mostly. .. Seems as the cars would sometimes decouple at the top exiting dumper. So now imagine two cars, one coming back down the incline and the second which was supposed to be with it but is just now going down the exit ramp meeting at the bottom. Suddenly. Very suddenly. Solution was a monitoring system using Forth to monitor for decoupling at the exit to lock down the second car until the first cleared the switch. He was doing a lot of interesting things with Forth at the time, this one was a bit more memorable. .
Thank you Peter, that is good to know. Guess I need to read through the files more. Not sure how to load extend if in 5.3 it is not already part of the initial download to the prop. Started poking around in my old Starting Forth, since I am grounded for a few more weeks. (Sucks, but beats going nuts on CT systems and everything else that gets thrown on my plate in a normal week).
Story for you, dates back to the 80s. Had a friend who worked at the coal terminals. Interesting problem. Cars would be run up the ramp in pairs, defrosted if need be (winter, coal traveled from West Va, through to the Virginia coast terminals) clamped, rotated and dumped onto ship loading conveyor belts. Then the fun starts..... The cars are pushed out onto a ramp, run up an incline, track switch thrown and off to the siding for pick up they would go. Well mostly. .. Seems as the cars would sometimes decouple at the top exiting dumper. So now imagine two cars, one coming back down the incline and the second which was supposed to be with it but is just now going down the exit ramp meeting at the bottom. Suddenly. Very suddenly. Solution was a monitoring system using Forth to monitor for decoupling at the exit to lock down the second car until the first cleared the switch. He was doing a lot of interesting things with Forth at the time, this one was a bit more memorable. .
Thanks for your time and reply.
Thanks for the story! I always find it interesting to hear the users people use forth for
I've redone the universal RTC driver and also done away with any specific chip name, instead using a similar convention I use for other hardware. In this case I have a SETRTC word which takes the 8-bit I2C address (why do they confuse it by using the 7 msbs?) and any options (normally 0) and setting internal constants at runtime. So for an MCP79410 system with RTC at $DE I simply say $DE SETRTC and then do a BACKUP. On every reset or at midnight it will read the hardware RTC and update the virtual RTC device. The virtual or soft RTC is maintained by the TIMERS cog and so any need for reading the time or fetching time-stamp doesn't need to access hardware directly, just a read from memory where the time is maintained in seconds per day with the date being updated directly from hardware at midnight so that there is no need for the virtual RTC to maintain a calendar.
Settings for different devices:
DS3231 $D0 SETRTC
DS1307 $D0 SETRTC
MCP79410 $DE SETRTC
PCF8563 $2A2 SETRTC ( the 2 is for the seconds register offset )[s][/s]
If you have a different RTC just use the 8-bit I2C address and see if that works. Let me know if it doesn't or you would like to use a different type of I2C RTC.
Whenever you set the time or date it will write to the selected hardware RTC as well as the virtual RTC.
One day they might even make a standard RTC chip that doesn't mix funny control bits in with the time and date. I quite like maintaining seconds per day and then having the standard date but an RTC could do with time zone registers which could hold the UTC offset and the time zone code. BTW, you can type " AEST" TZ for Australian Eastern Standard Time or whatever so that if you print the time and date using .DT it will appear in a standard format "Mon, 06 Aug 2018 14:14:07 AEST"
I chose to have case sensitivity although in some versions i have included autocase but that also caused issues. So now in V5 it is what it is, upper or lower but as a convention i avoid mixed case. In general lower case for variables and constants and most names are fairly short and concise. PC Forths don't operate in 32k RAM
This is the latest Tachyon 32k binary (no ROMs) which includes EASYFILE plus the latest RTC drivers. (hold that, this a 96MHz image, I will have to download another one for 80MHZ) <Click this link for the 80MHz version>
To configure an SD card just specify the 4 pins as a single ip notation long where every group of decimal digits represents a byte like this: &03.02.01.00 SDPINS
The format is &ce.miso.mosi.sck where mosi is the master out data to the card. Once the pins are configured it will automount at reset or you can manually MOUNT it.
That is a whole boat load of tools and utilities and drivers all built-in and I sometimes wonder myself how it can all fit into 32k RAM and still have room left over.
I'm also thinking of a method for loading ROMs in the same way we load source code so you can add custom ROMs to upper EEPROM. These ROMS are PASM code which can be loaded at run-time into assigned cogs.
EDIT: latest EXTEND now includes IR transmit routines. First one is for the NEC, just pass the code and pin to it.
IR.NEC ( code pin -- )
Sony and other modes may follow in which case I may have one common transmit routine and simply select the mode.
Terminal dump of system with PCF8563 RTC and SD card etc.
I have been changing the servo driver file that Brian Riley wrote sometime ago. It works a little but I don't know how to finish the loop without ATN? . Is the use of WAITX the same as DELTA?
I have been changing the servo driver file that Brian Riley wrote sometime ago. It works a little but I don't know how to finish the loop without ATN? . Is the use of WAITX the same as DELTA?
Thanks, Ken
Could you use the PWM module that's built-in that can handle up to 32 channels? @thej used this just the other day to get servos to move. It just seems a better way of handling servos.
To use the PWM module with say 8 servos on P0..P7:
256 longs pwms
$FF pwms 200 PWM.START
This will service up to 32 channels at up to 7.6kHz each channel
Pass an 8-bit value and a pin number to pass to PWM but for servos you would pick a suitable frequency and perhaps write your own SERVO word to so that you could say:
90 5 SERVO
to position the servo on P5 to 90'
I will look at what I may need to do however to off something similar to the PWM module that is better suited to servos. But it's not hard at all.
BTW, I looked at a 180's servo from Parallax and came up with a few lines of code to handle up to 32 servos where you specify the angle and pin to set the servo. Once the SERVOS task is running you can start up a new servo on P20 for instance set for 102' during runtime by typing "102 20 DEGREES". I will check this code out on the scope but it should work.
TACHYON
--- PARALLAX 180' SERVO =' 0.75–2.25 ms
180 longs servotbl
long servos
pri SERVOS
BEGIN
servos @ OUTSET 750 us
servotbl FROM 4 BY 180
FOR
I @ OUTCLR
NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP
NEXT
AGAIN
;
pub DEGREES ( degrees pin -- )
--- enable the output
MASK DUP servos @ OR servos !
--- reset the table entry for this servo
servotbl FROM 4 BY 180 FOR I @ OVER ANDN I ! NEXT
--- now set the cutoff point in the table
SWAP 4* servotbl + DUP @ ROT OR SWAP !
;
( to run - ' SERVOS 3 RUN )
END
BTW - tried out this servo code on a unit and it works really well. There's no need to assign any outputs beforehand, just on the fly as needed. Look for the latest SERVO32.FTH in the V5 folder.
Tried installing bin version of V5 and Prop tool froze, went back to compiled version and file send of EXTEND. Attched RTC to i2c bus and it is recognized on boot. attempted lcd re direct per instructions in intro, will not BACKUP SERBAUD did something wrong with LCDEMIT and defining new word LCD and when I typed LCD it would cause a reboot. Need to find some samples of FORTH code to get a better idea of what I am doing.
EDIT Also tried a filesend of EASYFILE and that ccrashed and burned.
Jim
Tried installing bin version of V5 and Prop tool froze, went back to compiled version and file send of EXTEND. Attched RTC to i2c bus and it is recognized on boot. attempted lcd re direct per instructions in intro, will not BACKUP SERBAUD did something wrong with LCDEMIT and defining new word LCD and when I typed LCD it would cause a reboot. Need to find some samples of FORTH code to get a better idea of what I am doing.
EDIT Also tried a filesend of EASYFILE and that ccrashed and burned.
Jim
Ohh, if only I could look over your shoulder
Any code or terminal dumps?
Which Prop tool and version? (use .binary files for PropTool).
Which particular instructions did you follow?
Doing a sendfile in TeraTerm should work fine with 15ms line delay as I tried all this the other day.
Could you zip up all the files you are using, including the config files for TeraTerm (TERATERM.INI) and post them. That should give me a better idea as it has got to be something so basic and simple, but what.
Peter,
Thank you for the update on the RTC.
I have reread what I wrote and see that I WAS being an A**hole
please accept my apology....
I know you guys are very busy and don't owe me any help at all.
Thanks again...
LOL, Actually that may be possible. I will study Tera Term and see how to create a log file.
I will have to go figure out how to do a zip as I have not done it in way too long. Easyfile is a low priority currently but just thought I would load it last night when I was on the system. I did a quick spin program to make sure that the LCD was working on Pin 6 (set it to 19200) and set SERBAUD to 19200. LCD was able to print hello world and turn its backlight on from spin. So I know, no issues there. File send from Tera Term seems to work OK as I am able send EXTEND and have it install and backup.
It may be a day or two before I get this all done as I have to work late tonight.
Thanks
Jim
Regarding TeraTerm; tried hyperterm, putty and TeraTerm. Of these three only TeraTerm seemed to work. It was also the only one to allow me to set the recommended line delay. Pre TeraTerm, behavior was all over the map with no good loads. Currently running v5.3 spin with extend.fth did not try binary. Loaded base using last released prop tool. Worked on the PPDB and activity board.
Peter,
Thank you for the update on the RTC.
I have reread what I wrote and see that I WAS being an A**hole
please accept my apology....
I know you guys are very busy and don't owe me any help at all.
Thanks again...
All's sweet then, water under the bridge. I've been on prednisone as part of my chemo and I know that sent me a bit loopy
The new servo module has been added to EXTEND and works in a similar way to the PWM modes except it is designed for 0..180' servos with up to 32 channels.
There are only two words to worry about, one to start up the servo cog with the correct settings, and the other to set any pin up as a servo control by specifying the angle.
Which will start up the next cog with defaults but using the memory at servotbl for up to 32 channels. Next to set any pin at any time up as a servo control, say P5 to 120':
120 5 DEGREES
The deadtime default is 256 us which will result in 400Hz servo update time for up to 32 servos. It makes no difference how many servos are used, the update frequency remains the same.
How do I determin what is the latest version of extend?
If you always refresh the Tachyon V5 Dropbox folder it will always be the very latest (click "the display as list" icon).
This is the terminal dump of the current version which I have just updated:
The new servo module has been added to EXTEND and works in a similar way to the PWM modes except it is designed for 0..180' servos with up to 32 channels.
There are only two words to worry about, one to start up the servo cog with the correct settings, and the other to set any pin up as a servo control by specifying the angle.
Which will start up the next cog with defaults but using the memory at servotbl for up to 32 channels. Next to set any pin at any time up as a servo control, say P5 to 120':
120 5 DEGREES
The deadtime default is 256 us which will result in 400Hz servo update time for up to 32 servos. It makes no difference how many servos are used, the update frequency remains the same.
I'm a little confused.
Since the "DEGREES" word adjusts the pulse width, what is the "delay" and "deadtime" representing?
Is the default of 400Hz, setting the full cycle time of the pulse? ...and don't servos generally all prefer a pulse of 50Hz?
I've never used servos before or written any software for them so this completely new.
The deadtime is necessary for full pulses but also helps to lower the frequency which can be as high as 400Hz for servos. Running servos at a lower frequency is useful if the servo driving is done in software on a single core cpu which needs time to do other things.
A higher frequency does allow a faster update rate and lower latency though and once we dedicate a cog to handle 32 channels we may as well run at 400Hz. More Hertz never hurts
The delay sets the maximum pulse width for 180 degree timing. You can trim this + or - if you want, otherwise just leave it.
Comments
Yes I am new here, but if you look at my only few posts you will find that I only ask for help.
All i get from anyone is "Read the Data sheet". Or what I ask is "trivial"
I have looked at the DataSheets. Sometimes I don't understand them, and that's why I come here
asking for help. What may be trivial for some is hard for others. I am also new to the Propeller.
But if all I get is snickered at for being the dumb one, I will not ask for help anymore.
Thank you Frank ...and Peter
Best of luck
Peter, please forgive me the short detour to your thread.....
However, we all live in different time zones and when you posted it was a busy weekend. Notwithstanding, I remembered late on Saturday (after midnight) and started looking at what changes I needed to make to the universal RTC driver to accommodate the changes. I also happened to have a board and that chip loaded onto one of my RTC PCB modules, so I tested it out. Something wasn't right but at 2:30AM it was time for some sleep. Sunday morning I traveled into the city and had to put up with waves of selfish nasty me-first people, and then I read your post. How do you think I might feel??? Not even 24 hours after you first requested help.
As it is, I'm not a person to hold something against somebody although I might just avoid them for health reasons. Now it's Sunday night and I have found the bug and I am fixing it so that the Tachyon RTC driver supports chips like the PCF8563 that feel the need to have their timekeeping registers in a different place from other chips. When I get back to it later tonight I will have it all fixed and tested.
@"frank freedman" - thanks for keeping the peace, never any need to apologize for that.
After EXTEND the main modules are EASYFILE and EASYNET. Practically everything else is in EXTEND but in the V5 folder for instance there are some demo apps such as BREAKOUT plus I'm updating SPLAT, my logic analyzer app.
As for RS-232 that is easy as you can either use the simple serial words SEROUT and SERIN which work fine up to over 200k baud or use one of the ROMs such as UART for full-duplex or HSUART for high auto-duplex. I find full-duplex is rarely needed though because other than the console all command/response communication tends to be half-duplex in nature.
If I wanted to load up five cogs with the HSUART ROM I would set them up this way: Where I have a fixed length string with the name of the ROM to load in from cog 3 using the parameter table par1 and then because I am loading multiple cogs I specify the step size of 12 for the parameter table so that each of the 5 cogs can have its own parameters.
I will try to post some code to show you how to use it unless of course you mention how you want to use it, and then I can be more specific.
Story for you, dates back to the 80s. Had a friend who worked at the coal terminals. Interesting problem. Cars would be run up the ramp in pairs, defrosted if need be (winter, coal traveled from West Va, through to the Virginia coast terminals) clamped, rotated and dumped onto ship loading conveyor belts. Then the fun starts..... The cars are pushed out onto a ramp, run up an incline, track switch thrown and off to the siding for pick up they would go. Well mostly. .. Seems as the cars would sometimes decouple at the top exiting dumper. So now imagine two cars, one coming back down the incline and the second which was supposed to be with it but is just now going down the exit ramp meeting at the bottom. Suddenly. Very suddenly. Solution was a monitoring system using Forth to monitor for decoupling at the exit to lock down the second car until the first cleared the switch. He was doing a lot of interesting things with Forth at the time, this one was a bit more memorable. .
Thanks for your time and reply.
Thanks for the story! I always find it interesting to hear the users people use forth for
I've redone the universal RTC driver and also done away with any specific chip name, instead using a similar convention I use for other hardware. In this case I have a SETRTC word which takes the 8-bit I2C address (why do they confuse it by using the 7 msbs?) and any options (normally 0) and setting internal constants at runtime. So for an MCP79410 system with RTC at $DE I simply say $DE SETRTC and then do a BACKUP. On every reset or at midnight it will read the hardware RTC and update the virtual RTC device. The virtual or soft RTC is maintained by the TIMERS cog and so any need for reading the time or fetching time-stamp doesn't need to access hardware directly, just a read from memory where the time is maintained in seconds per day with the date being updated directly from hardware at midnight so that there is no need for the virtual RTC to maintain a calendar.
Settings for different devices:
If you have a different RTC just use the 8-bit I2C address and see if that works. Let me know if it doesn't or you would like to use a different type of I2C RTC.
Whenever you set the time or date it will write to the selected hardware RTC as well as the virtual RTC.
One day they might even make a standard RTC chip that doesn't mix funny control bits in with the time and date. I quite like maintaining seconds per day and then having the standard date but an RTC could do with time zone registers which could hold the UTC offset and the time zone code. BTW, you can type " AEST" TZ for Australian Eastern Standard Time or whatever so that if you print the time and date using .DT it will appear in a standard format "Mon, 06 Aug 2018 14:14:07 AEST"
This is the latest Tachyon 32k binary (no ROMs) which includes EASYFILE plus the latest RTC drivers.
(hold that, this a 96MHz image, I will have to download another one for 80MHZ)
<Click this link for the 80MHz version>
To configure an SD card just specify the 4 pins as a single ip notation long where every group of decimal digits represents a byte like this: &03.02.01.00 SDPINS
The format is &ce.miso.mosi.sck where mosi is the master out data to the card. Once the pins are configured it will automount at reset or you can manually MOUNT it.
That is a whole boat load of tools and utilities and drivers all built-in and I sometimes wonder myself how it can all fit into 32k RAM and still have room left over.
I'm also thinking of a method for loading ROMs in the same way we load source code so you can add custom ROMs to upper EEPROM. These ROMS are PASM code which can be loaded at run-time into assigned cogs.
EDIT: latest EXTEND now includes IR transmit routines. First one is for the NEC, just pass the code and pin to it. Sony and other modes may follow in which case I may have one common transmit routine and simply select the mode.
Terminal dump of system with PCF8563 RTC and SD card etc.
I had to attach the WORDS listing as a file since it was too big to display inline in the forum.
Thanks, Ken
Could you use the PWM module that's built-in that can handle up to 32 channels? @thej used this just the other day to get servos to move. It just seems a better way of handling servos.
To use the PWM module with say 8 servos on P0..P7: This will service up to 32 channels at up to 7.6kHz each channel
Pass an 8-bit value and a pin number to pass to PWM but for servos you would pick a suitable frequency and perhaps write your own SERVO word to so that you could say: to position the servo on P5 to 90'
I will look at what I may need to do however to off something similar to the PWM module that is better suited to servos. But it's not hard at all.
BTW, I looked at a 180's servo from Parallax and came up with a few lines of code to handle up to 32 servos where you specify the angle and pin to set the servo. Once the SERVOS task is running you can start up a new servo on P20 for instance set for 102' during runtime by typing "102 20 DEGREES". I will check this code out on the scope but it should work.
BTW - tried out this servo code on a unit and it works really well. There's no need to assign any outputs beforehand, just on the fly as needed. Look for the latest SERVO32.FTH in the V5 folder.
EDIT Also tried a filesend of EASYFILE and that ccrashed and burned.
Jim
Ohh, if only I could look over your shoulder
Any code or terminal dumps?
Which Prop tool and version? (use .binary files for PropTool).
Which particular instructions did you follow?
Doing a sendfile in TeraTerm should work fine with 15ms line delay as I tried all this the other day.
Could you zip up all the files you are using, including the config files for TeraTerm (TERATERM.INI) and post them. That should give me a better idea as it has got to be something so basic and simple, but what.
Thank you for the update on the RTC.
I have reread what I wrote and see that I WAS being an A**hole
please accept my apology....
I know you guys are very busy and don't owe me any help at all.
Thanks again...
I will have to go figure out how to do a zip as I have not done it in way too long. Easyfile is a low priority currently but just thought I would load it last night when I was on the system. I did a quick spin program to make sure that the LCD was working on Pin 6 (set it to 19200) and set SERBAUD to 19200. LCD was able to print hello world and turn its backlight on from spin. So I know, no issues there. File send from Tera Term seems to work OK as I am able send EXTEND and have it install and backup.
It may be a day or two before I get this all done as I have to work late tonight.
Thanks
Jim
Jim
All's sweet then, water under the bridge. I've been on prednisone as part of my chemo and I know that sent me a bit loopy
I will have a look at that then but you could try 2 stop bits although it shouldn't be necessary to pace the characters a little.
The new servo module has been added to EXTEND and works in a similar way to the PWM modes except it is designed for 0..180' servos with up to 32 channels.
There are only two words to worry about, one to start up the servo cog with the correct settings, and the other to set any pin up as a servo control by specifying the angle.
SERVOS ( table +delay +deadtime cog - )
DEGREES ( degrees pin -- )
To start up a the servos task you could say:
Which will start up the next cog with defaults but using the memory at servotbl for up to 32 channels. Next to set any pin at any time up as a servo control, say P5 to 120':
The deadtime default is 256 us which will result in 400Hz servo update time for up to 32 servos. It makes no difference how many servos are used, the update frequency remains the same.
If you always refresh the Tachyon V5 Dropbox folder it will always be the very latest (click "the display as list" icon).
This is the terminal dump of the current version which I have just updated: I will add EASYFILE and save this as a .binary very shortly. <CLICK HERE>
KDewey
I'm a little confused.
Since the "DEGREES" word adjusts the pulse width, what is the "delay" and "deadtime" representing?
Is the default of 400Hz, setting the full cycle time of the pulse? ...and don't servos generally all prefer a pulse of 50Hz?
Jason
The deadtime is necessary for full pulses but also helps to lower the frequency which can be as high as 400Hz for servos. Running servos at a lower frequency is useful if the servo driving is done in software on a single core cpu which needs time to do other things.
A higher frequency does allow a faster update rate and lower latency though and once we dedicate a cog to handle 32 channels we may as well run at 400Hz. More Hertz never hurts
The delay sets the maximum pulse width for 180 degree timing. You can trim this + or - if you want, otherwise just leave it.