caskaz - You have to think how the processor handles logic. You set a timer to 3000 ms then you test for a timeout microseconds later which will not have occurred. You run the test again, and again it sets up the timer for 3000 ms and so on. Also you can run a lot of these little tests straight from the console input without having to make a new word.
Try this straight from the console:
3000 mytimer TIMEOUT BEGIN mytimer TIMEOUT? UNTIL #P16 HIGH
caskaz - IF ELSE THEN are good for deciding what to do rather than passing that decision on in the form of flags. The encoder can actually be reduced to a couple of lines or so of easy to read code if you think about how the encoder works. Translating from other languages or even other Forths is almost invariably inefficient and hard to read.
The TIMER task runs in its own cog and besides maintaining runtime and soft RTC always scans a linked list of user timers every 1ms. All you need to do is to create a timer variable, an optional do something vector on ALARM. If you want your code to run repeatedly then all you do is simply reload the timer.
Create a timer variable
TIMER mytimer
Load that timer with a large enough value
1000000 mytimer TIMEOUT
and you can watch it count down
mytimer @ .
When it counts down to zero it will stop but if an ALARM vector is set it will execute that. Also, when TIMEOUT is first executed the timer variable is added to the linked list so you can have as many timers as you like, even ones that count up etc. Have a look at that section in EXTEND.
Something is "stuck". I had to enter 2 returns to get the prompt back after initializing the TIMER var?
And no count down using CTRL x to execute the last line?
If the timers aren't working it can only mean that autorun has been disabled. In V4 only BOOT in EXTEND is called by AUTORUN and any other user autoruns are taken care of by BOOT by scanning and calling all those user vectors. If you have an application that you want to run automatically at startup it used to be that we made *that* the autorun but in V4 we simply add its vector to the init table with +INIT like this:
' MyStartUp +INIT
When we do a BACKUP the vector will be locked in and BOOT will execute these init vectors in the order they were added but it does check to see if it is still valid by comparing the vector address against the code pointer HERE in case the you FORGET the code and backup.
If the timers are unresponsive try again after typing BOOT.
btw, the lack of a prompt after some actions that involve GETWORD which is expecting an enter is a minor bug that I will fix up.
If the timers aren't working it can only mean that autorun has been disabled. In V4 only BOOT in EXTEND is called by AUTORUN and any other user autoruns are taken care of by BOOT by scanning and calling all those user vectors. If you have an application that you want to run automatically at startup it used to be that we made *that* the autorun but in V4 we simply add its vector to the init table with +INIT like this:
' MyStartUp +INIT
When we do a BACKUP the vector will be locked in and BOOT will execute these init vectors in the order they were added but it does check to see if it is still valid by comparing the vector address against the code pointer HERE in case the you FORGET the code and backup.
If the timers are unresponsive try again after typing BOOT.
btw, the lack of a prompt after some actions that involve GETWORD which is expecting an enter is a minor bug that I will fix up.
Bad load, loaded all again and it works. Hum, also no hang during TIMER declaration this time also
I think I need to look at my EEPROM/I2C routines to make sure they are within spec and get back. My 64kB EEPROM didn't save the ROMS and there have been a few funnies in there that it would pay for me to check up on.
I think I need to look at my EEPROM/I2C routines to make sure they are within spec and get back. My 64kB EEPROM didn't save the ROMS and there have been a few funnies in there that it would pay for me to check up on.
Can you add these to EXTEND please to help V3 to 4 migrations. And WW! didn't seem to work for the *SDA *SDC constants. I see EEPROM is just a stub currently.
ALIAS <I2C I2CSTART
ALIAS I2C> I2CSTOP
--- write a new value to a programmble constant ( 1234 ' mycon WW! ) simply writes a 15-bit constant to word
pub WW! ( newcon 'oldcon -- ) SWAP 15 MASK OR SWAP W! ;
pub EEPROM
28 ' *SCL WW!
29 ' *SDA WW!
;
Sorry, I always started up TEraTerm after power-on Propeller-board.
So I didn't check messages on boot-up.
When power on, boot-message is not printed.
When executing boot, TIMER operate.
< --- Power On Propeller-board
Propeller .:.:--TACHYON--:.:. Forth V4.4 DAWN 440170616.2330
--------------------------------------------------------------------------------
( 0001 $344E ok ) TIMER mytimer
( 0002 $344E ok ) 1000000 mytimer TIMEOUT
( 0003 $344E ok ) mytimer @ .
1000000
( 0004 $344E ok ) mytimer @ .
1000000
( 0005 $344E ok ) boot
MODULES LOADED:
1AC0: EXTEND.fth Primary extensions to TACHYON V4.4 kernel - 170612-0130
AUTORUN <OFF>
FREQ = 80.0MHz
*** INITS ***
NO ROMS
*** I2C ***
A0 EEPROM
PPNET: &00.00.00.00 @2,000,000
CODE:$344E =12878 bytes NAME:$5AA4 =6492 bytes DATA:$76F8 =232 bytes =9814 bytes free Data Stack (1)
$0000.76D8 - 30424
( 0006 $344E ok ) TIMER mytimer
( 0007 $344E ok ) 1000000 mytimer TIMEOUT
( 0008 $344E ok ) mytimer @ .
991845
( 0009 $344E ok ) mytimer @ .
987442
( 0010 $344E ok )
I think I need to look at my EEPROM/I2C routines to make sure they are within spec and get back. My 64kB EEPROM didn't save the ROMS and there have been a few funnies in there that it would pay for me to check up on.
Can you add these to EXTEND please to help V3 to 4 migrations. And WW! didn't seem to work for the *SDA *SDC constants. I see EEPROM is just a stub currently.
ALIAS <I2C I2CSTART
ALIAS I2C> I2CSTOP
--- write a new value to a programmble constant ( 1234 ' mycon WW! ) simply writes a 15-bit constant to word
pub WW! ( newcon 'oldcon -- ) SWAP 15 MASK OR SWAP W! ;
pub EEPROM
28 ' *SCL WW!
29 ' *SDA WW!
;
No worries, I'm still trying to remember why I used <I2C and I2C> .....
Ok, I had a look at I2C but I realized that I have been caught out by my own devices. I was using Tachyon V4.4.spin rather than the latest simpler form of the name TACHYON.SPIN. The old one didn't have the clkdly register that I can use for I2C so not only was it overwriting the initial MOV IP,PAR but the I2C bus was running too fast which really messed things up when it came to BACKUP. Anyway, I've sorted that out and double checked the speeds and they all look good (as they should). Make sure you use TACHYON.SPIN or else you'll be caught off guard like me
@D.P - I couldn't implement EEPROM the way you specifed since those constants are not called, they are written as is at compile time and changing them afterwards does not have the same effect it did in V3. However it was simple enough to create simple definitions to encapsulate the pin constants *SCL and *SDA so that they can be called, and so therefore updated dynamically.
Here are the I2C400 400kHz timings for a single EEPROM byte write.The newer 1MHz EEPROMs are good for I2CFAST for even better performance. I may tune this further.
$12 $7FF0 EC!
Full transfer Start and device address Clock rate (spot on 400kHz) Stop
Just found a problem during loading of EXTEND where it goes to save the ROMs if the EEPROM is >32k. The ECOPY routine ends up overflowing the DOFOR LOOP stack and aborting the ECOPY which is why I had a strange "NO ROMS" message. Fortunately with my recent work I had some room in the kernel to allocate some more memory to the loop and branch stack. Looks good now.
Can you fix this up for V4 the rest of the way when you get a chance.
Thanks
pub .TASKS ( -- \ List tasks )
8 0 1 DOFOR
I TASK 2+ C@ DUP
IF .INDEX I TASK W@ ?DUP
IF >NAME DUP PRINT$ BL SWAP LEN$ - SPACES
ELSE PRINT" IDLE" #28 SPACES
THEN
THEN
I COGID = DUP
IF .INDEX PRINT" CONSOLE" #25 SPACES THEN
OR IF I TASK DUP W@ .WORD SPACE 2+ 6 1 DOFOR I C@ .BYTE SPACE LOOP THEN
LOOP
;
Hi there - after building iot5500 I had an issue regarding the following
&17.1.19.18 WIZPINS
which didn't seem to work.
Investigating ... ah there is a variable wizpins and a word WIZPINS.
This works:
OFF ANYCASE
&17.1.19.18 WIZPINS
Hmm. I would recommend to always use
OFF ANYCASE
which I will do since now.
Edit:
There is definitely something wrong with interactive setting via WIZPINS. Now as I know there could be a problem I'm no more able to write the WIZnet pin configuration and get a running socket.
Comments
Try this straight from the console:
It don't operate.
Something is "stuck". I had to enter 2 returns to get the prompt back after initializing the TIMER var?
And no count down using CTRL x to execute the last line?
If the timers are unresponsive try again after typing BOOT.
btw, the lack of a prompt after some actions that involve GETWORD which is expecting an enter is a minor bug that I will fix up.
Bad load, loaded all again and it works. Hum, also no hang during TIMER declaration this time also
TIMER don't operate.
I downloaded TachyonV4.4.spin and EXTEND.fth at 6/17 and installed them.
I had to reload the kernel and extend, the first time I didn't get AUTORUN BOOT ?
Sorry, I always started up TEraTerm after power-on Propeller-board.
So I didn't check messages on boot-up.
When power on, boot-message is not printed.
When executing boot, TIMER operate.
No worries, I'm still trying to remember why I used <I2C and I2C> .....
@D.P - I couldn't implement EEPROM the way you specifed since those constants are not called, they are written as is at compile time and changing them afterwards does not have the same effect it did in V3. However it was simple enough to create simple definitions to encapsulate the pin constants *SCL and *SDA so that they can be called, and so therefore updated dynamically.
Full transfer
Start and device address
Clock rate (spot on 400kHz)
Stop
On a new load what will be the default I2C rate for the EEPROM?
I assume using the I2C400... scalier words will lock in I2C rate?
Can you fix this up for V4 the rest of the way when you get a chance.
Thanks
Thanks, proplem
Yes I confirm this hang
ROR in any combination seems to hang
But there are no instances of ROR in EXTEND or EASYFILE or EASYNET. Reboot, ROL works, well it doesn't hang but the results are not correct.
The kernel says rarely used
That bit of LMM code had a bug in it, it was returning via EXIT plus there was another bug (DROP,LMM). All fixed now.
Looks like you also fixed up .TASKS in the new extend, thanks Peter.
Peter could you add again? I think you had added it in one recent V3 version.
Best regards,
proplem
Investigating ... ah there is a variable wizpins and a word WIZPINS.
This works: Hmm. I would recommend to always use which I will do since now.
Edit:
There is definitely something wrong with interactive setting via WIZPINS. Now as I know there could be a problem I'm no more able to write the WIZnet pin configuration and get a running socket.
And what does this do?
Shouldn't that emit &1.2.3.4 ?
I could understand &4.3.2.1 being and in-addr-arpa form, I don't know this one.
Yes it should! And it does :-) I downloaded TACHYON.SPIN and EXTEND.FTH only a few hours ago. Even .TASKS you mentioned works
Thanks,
dp
I'm having a little weirdness between reboots. Look at this output compared to yours. I have the same version as you now.
The "weirdness" is the weird character in my output or what?