Hi Peter
I am looking to update an ADC/DAC project that is working well with T3; it is built into an electron gun controller crate. It uses clock stretched I2C, which one of us wrote
...
The T5.4 I2C codes seem very different ... would the current stretching codes still work?
did you try ??
Would changing the I2C speed get the same result?
did you try?
Very concerned about breaking something that seems to work ...
Thanks!
if you find out it does NOT work any more it is time to have a closer look ...
That is where the fear of breaking a working research system comes in, and I was wondering if I should anticipate upgrade issues ... but OK.
I can have a look at integrating the pause while clock low part in with the CLKIN and CLKOUT words so that all the I2C routines will automatically adapt to clock stretching. I will have some time tomorrow to have a look at it and that way there is no need to change any of the I2C words themselves.
Thank you Peter, I very much appreciate it. Getting back into this project, the flexibility of T is even more impressive, and the changes made since T3 look great.
Peter,
I want to setup a data link using two 918 MHZ tranceivers. The included code for test works but the code will not self start on boot when I add RUN: word .
TACHYON V5
{
Transmitter
}
pub SETUP 57600 SERBAUD EMIT: 1 SEROUT ; \ transmit from mailbox and ascii value
pub ts SETUP BEGIN #88 EMIT CR 200 ms AGAIN ;
}
' ts +INIT
BACKUP
END
TACHYON
{
Receiver
}
pub SETUP 57600 SERBAUD ;
pub GET-VALUE SETUP BEGIN 1 SERIN 88 = IF 26 BLINK THEN AGAIN ; \ receive a ascii value for status
Ken, most RF communications include a preamble to stabilize the receiver etc and the other thing is that if asynch characters start off with noise and they are transmitted back to back without gaps then a data bit could be confused with a start bit, especially when you are repeating the same character 88. Just think of 88 as 0-00011010-1 but repeating continually. So try sending some preamble that might end in $FF just so that no databits can be seen as start bits and then the 88. However you really need a delay after sending because the receiver could very well be resetting the blink fast enough that you don't ever see it blink. Perhaps even just toggle P26 or flash briefly.
Peter,
Thanks for your help. Most of the time I can work through the problem without bugging you but I hit a wall. The code below will work by running TEST after loading with no backup. When I do
a backup the code locks minicom . I want to autostart this demo app .
Ken
TACHYON V5
{
Transmitter
}
128 bytes regs
pub SETUP 57600 SERBAUD EMIT: 1 SEROUT ; \ transmit from mailbox and ascii value
pub TEST 5 RUN: regs 8 COG! SETUP BEGIN 5 us 'X' EMIT 5 CR 500 ms AGAIN ;
' TEST +INIT
END
\ BACKUP
Ken, you have a combination of delays at the start and end of your loop when you only need one and besides the us delay word cannot delay less than about 9us anyway plus 5us on top of 500ms is redundant anyway.
I noticed that 5 us actually takes longer than 10 us due to a bug in the way the word is implemented which I will fix. But if you ever wanted to delay exactly 5us you can use dummy sequences such as 2 FOR NEXT or 0 0 DUP 3DROP etc. Remember that you can time code by enclosing them in LAP words and then using .LAP to report the results like this:
... LAP 0 0 DUP 3DROP LAP .LAP 400 cycles = 5.000us ok
... LAP 5 us LAP .LAP 1,056 cycles = 13.200us ok
... LAP 10 us LAP .LAP 816 cycles = 10.200us ok
Peter,
Thanks for the info. On another note I must be missing the boat as I can't get even the smallest word to autostart. I have tryed a total reinstall, different VM and extend no go. The code below works as long as I just use TEST to run.
Ken
TACHYON
{
Transmitter
}
pub TEST 2 RUN: BEGIN 200 ms 3 HIGH 200 ms 3 LOW AGAIN ;
' TEST +INIT
END
BACKUP
Peter,
I am totally struggling with converting the altimeter from spin to Tachyon:
mb := ((_umultdiv(mb, constant(SEA_PRESS_STA << 2), sea_press) >> 1 + 1) >> 1) <# $1_f7ff #> $800
PUB in_from_mb(mb)
{{ Convert pressure in millibars to inches of Hg (or from hundredths of millibars
to hundredths of inches).
''
'' `Parameters:
''
'' `mb: Value in millibars to be converted.
''
'' `Return: The equivalent value in inches of Hg.
''
'' `Example: inches := alt.in_from_mb(101345)
''
'' Convert 1013.45 millibars to hundredths of inches.
}}
return (_umultdiv(mb, constant(10000000 * 2), 338637526) + 1) >> 1
PRI _umultdiv(x, num, denom) | producth, productl
{{ Multiply `x and `num, then divide the resulting unsigned, 64-bit product by
`denom to yield a 32-bit unsigned result. `x ** `num must be less than (unsigned) `denom.
}}
_umult(@producth, x, num)
return _udiv(producth, productl, denom)
PRI _umult(productaddr, mplr, mpld) | producth, productl
{{ Multiply `mplr by `mpld and store the unsigned 64-bit product at `productaddr.
}}
producth := (mplr & $7fff_ffff) ** (mpld & $7fff_ffff)
productl := (mplr & $7fff_ffff) * (mpld & $7fff_ffff)
if (mplr < 0)
_dadd(@producth, mpld >> 1, mpld << 31)
if (mpld < 0)
_dadd(@producth, mplr << 1 >> 2, mplr << 31)
longmove(productaddr, @producth, 2)
PRI _udiv(dvndh, dvndl, dvsr) | carry, quotient
{{ Divide the unsigned 64-bit number `dvndh:`dvndl by `dvsr, returning an unsigned 32-bit quotient.
Saturate result to $ffff_ffff if it's too big to fit 32 bits.
}}
quotient~
ifnot (_ult(dvndh, dvsr))
return $ffff_ffff
repeat 32
carry := dvndh < 0
dvndh := (dvndh << 1) + (dvndl >> 31)
dvndl <<= 1
quotient <<= 1
if (not _ult(dvndh, dvsr) or carry)
quotient++
dvndh -= dvsr
return quotient
I have drilled down on the spin to find what I think are the necessary steps in doing the calculations but no joy.
I was having problems in setting up some constants, but studying your "BALLS" led me to see what I was doing wrong. I have the altimeter module installed on a QS board and I am talking to it with your MSCMD suggestion. I need to modify it slightly after studing balls. I really only need to send the altitude to it to set the sea level pressure and the conversion resolution. I guess that one of my issues is assigning math results to a var that I can use in other steps.
Jim
addit: how do I capture and measure an incoming PWM pulse?
Peter,
Small steps, I load the small program below and it works as expected. Here's the problem, when I power the BOE, or any other board by any other means the program will not auto start. I tried a battery and external power supply. All voltages are good. I unplugged the tx line and the rx/tx lines flash and off it goes. All the boards are good . Any ideas?
Thank Ken
TACHYON
{
Transmitter
}
7 COGSTOP
pub GO 7 RUN: BEGIN 2 HIGH 200 ms 2 LOW 200 ms AGAIN ;
' GO +INIT
END
BACKUP
Peter,
Guilty as charged, trying to run before I can walk. Found the book for learning Forth in Drop Box, Installed the APP and am working through the exercises. Hope I learn to walk soon!
Thanks for your help, very interested in your tests on the P2.
Jim
Ken - Tachyon has a break detect feature on the receive line that reboots the Prop and is really useful when testing code that may lock up the console. However many Parallax boards have USB serial built in that affects the receive line when the port is unplugged.
The easiest way to get around this problem is to disable break detection in Tachyon and recompile. Find this section around line 3880:
stopins waitcnt rxcnt,rxticks ' check stop bit early (need to detect errors and breaks)
test rxpin,ina wc ' sample stop bit
if_c wrword rxwr,rxwrP ' update hub index for code reading the buffer if all good
if_c mov breakcnt,#100 ' reset break count
if_c jmp #receive
and remove the if_c in the last line so that it never continues on to handle frame errors and breaks.
A quick fix though if you are using 5.4 is to directly modify this instruction in the EEPROM so that after the next reset it will be using an unconditional jmp. Just do this:
$7C $7516 EC!
then reset it and it will now ignore breaks.
Most of my boards do not bother with dedicated USB serial since they are designed to be embedded in a product and the ones that do have USB serial are also powered in such a way that the USB serial can power the board and also be powered when USB is unplugged so that I don't have any spurious signals on the receive and transmit. Parallax boards though in general are designed for education, not for embedding in a final product. That is why they may be battery powered and only use linear regulators etc.
Jim - the trouble with "converting" code is that you end up hobbling Tachyon with baggage rather than letting it run its own way. The Altimeter code is actually very simple but you need to write a few basic words that simply access the registers first then add the conversion layer after you have established raw access.
Now for the conversion code just follow the maths which shows that instead of trying to do floating point that they are scaling the amount by multiplying by 20,000,000 (10,000,000*2) so that when you divide by the divisor then you will end up with a 32-bit integer scaled result. For instance try dividing 1 by 98 like this:
... 1 98 / . 0 ok
Well, that's the result you get from using integer maths and the easy way out is to use floating point. But floating point can introduce errors and is not natively or easily supported on the Prop, although neither are multiply and divide, but floating point would be quite slow. On a calculator the result would be 0.0102040816327
But this is where knowing the scales and limits involved we simply scale the input and then divide resulting in a scaled result like this:
... 1,000,000,000 98 / . 10204081 ok
This is where the multiply and the divide word */ in Forth is useful since it will multiply or scale a number to a 64-bit intermediate result and then divide that 64-bits with the second parameter like this:
... 1 1,000,000,000 98 */ . 10204081 ok
To convert millibars to inches of mercury, multiply the millibar value by 0.0295301 or divide by 33.8637526 (rounded).
But as you can see from the original formula you can multiply by the more accurate 0.0295301. Lets try that in Forth but divide down the result so that it still has two decimal places in the integer ( 12.34 is 1234 ):
... 1,000 0.0295301 100000 */ . 2953 ok
BTW - commas and decimal points in Tachyon numbers are only for readability, they are still normal integer numbers.
Create a word for that:
: mb>in ( mb -- in.xx ) 0.0295301 100000 */ ;
Super easy and way better I think. So mb>in could use a scaled result so that when printing it reports two decimal places like this using Tachyon's formatted number word:
... 1,000 mb>in .AS" *|.## inches " 29.53 inches ok
Create a new word just for printing out in this format and try it out immediately:
EDIT: I decided that I would add a delineation to Tachyon so that when you hit the enter it delineates the result from the input which makes it easier to distinguish what is what when we paste console text onto the forum. Like this:
... 1,000 0.0295301 100000 */ . --> 2953 ok
So I use --> as the delineation which is also becomes one of the comment control words so we could just copy and paste the whole line back into a terminal.
@"Peter Jakacki" it is even worse with Parallax and the build in USB combined with the Parallax reset circuit on a lot of their board offerings.
The problem occurs when you send out serial data to the USB chip while not connected to a Host. Thru parasitic feeding the USB-chip wakes up and, guess, resets the Propeller.
The problem is known for a long time, even @mpark checked it at he beginning of Spinx. The solution is to see if P31(P30? I forgot) is high or else not to send serial data.
I argued a lot here in the forum, trying to keep at least the ProtoBoard w/o USB alive, but I failed.
@"Ken Gracey" stated that all future boards will have USB build in and the Spinneret was the only board where they at least put a jumper between USB reset and the real reset.
The USB on board might be useful for education, but I really prefer a PropPlug to avoid the whole problem.
Peter,
Wow, thanks for the very informative reply. Last night, as I was going to bed, it struck me that i needed to go back and find the actual conversion formulas and plug those into Tachyon without going through trying to understand what was happening in Spin. One very useful piece of information in your reply is that Tachyon ignores decimal points so that I would not have to go through a convoluted multiply then divide down to get the answer. Yesterday, I spent most of the day reading "Starting Forth" and I came away with a much better understanding as to what I was trying to do.
Thanks again for all you do and taking time out from P2 testing to reply.
Jim
Propeller .:.:--TACHYON--:.:. Forth V5r´ÄON 540180811.0000
*** MODULES *** Propeller .:.:--TACHYON--:.:. Forth V5r´ÄON 540180811.0000
2E4A: TOOLS DEV TOOLS
1980: EXTEND Primary extensions to TACHYON V5 kernel - 18104-0900
FREQ = 80.00MHZ
*** INITS ***
CLOCK 3A28
NO ROMS
*** I2C ***
$A0 EE/RTC
$D0 RTC
I/O = 31 :UHUU 27 :~~~~ 23 :~~~~ 19 :~~~~ 15 :~~~~ 11 :~~~~ 7 :U~~~ 3 :~~D~
INTERCOM:
CODE:$3A62 = 14434 bytes
NAME:$5CDE = 5922 bytes
DATA:$7664 = 340 bytes
FREE: = 8828 bytes
Data Stack (0)
Thu, 10 Oct 2018 15:59:24 MST
--------------------------------------------------------------------------------
... A 1 APIN POS ??? EDGE DETECT ok
... A 1 APIN POS ??? EDGE DETECT ok
... B 1 APIN POS ??? EDGE DETECT ok
... B 1 APIN NEG ??? EDGE DETECT ok
--------------------------------------------------------------------------------
... A 1 APIN POS ??? EDGE DETECT ok
As you can see from the screen shot whenever I enter the POS EDGE DETECT I get ???. I have learned how to create constants and Vars and see where I can strip the math in the altimeter down to its basics and plug that into Tachyon words Was trying to set up some tests on the rain gauge when I ran into the Edge detect problem. This will effect the rain gauge and the wind speed. Both depend upon the edge detection as I have a flag passing through an optical sensor.
So what am I doing wrong? I downloaded the latest version of EXTEND that I found in the Dropbox, you can see the version info in the screen shot I patched in.
POS and NEG are simple constants but it could be that they were created with the PRIVATE attribute and were thus inadvertently stripped during the RECLAIM at the end of load. I've now made them PUBLIC so they will be retained (sorry about that) but of course you could paste them in or just use the constants for the moment.
I need to write a couple of ROMs for my tachyon system to drive ADC/DAC peripherals at (more) speed. My question is, what are the best support tools/workflow to test and debug pasm code in order to minimise the number of bh.py/SAVEROM iterations I'll need to do? I note that the GEAR Propeller emulator exists (https://sourceforge.net/projects/gear-emu/), is there anything else?
I want to be able to do a binary search on the table by taking the starting address of the table, adding 1/2 the length of the table (65 entries) then compare the stored value with the value I am looking up. I will divide the table in half and use a new upper limit or lower limit depending upon the results of the comparison. I have tried setting this up as a CSV , or || separated values but have not been successful. I have been looking for code examples but those seem to be few and far between.
Thanks for the help.
Jim
I want to be able to do a binary search on the table by taking the starting address of the table, adding 1/2 the length of the table (65 entries) then compare the stored value with the value I am looking up. I will divide the table in half and use a new upper limit or lower limit depending upon the results of the comparison. I have tried setting this up as a CSV , or || separated values but have not been successful. I have been looking for code examples but those seem to be few and far between.
Thanks for the help.
Jim
Comments
I am sure you keep the previous working version ready to load in again
if s.th. will not work with the experiment - don't you ?
I can have a look at integrating the pause while clock low part in with the CLKIN and CLKOUT words so that all the I2C routines will automatically adapt to clock stretching. I will have some time tomorrow to have a look at it and that way there is no need to change any of the I2C words themselves.
I want to setup a data link using two 918 MHZ tranceivers. The included code for test works but the code will not self start on boot when I add RUN: word .
TACHYON V5
{
Transmitter
}
pub SETUP 57600 SERBAUD EMIT: 1 SEROUT ; \ transmit from mailbox and ascii value
pub ts SETUP BEGIN #88 EMIT CR 200 ms AGAIN ;
}
' ts +INIT
BACKUP
END
TACHYON
{
Receiver
}
pub SETUP 57600 SERBAUD ;
pub GET-VALUE SETUP BEGIN 1 SERIN 88 = IF 26 BLINK THEN AGAIN ; \ receive a ascii value for status
' GET-VALUE +INIT
BACKUP
END
kdewey
Thanks for your help. Most of the time I can work through the problem without bugging you but I hit a wall. The code below will work by running TEST after loading with no backup. When I do
a backup the code locks minicom . I want to autostart this demo app .
Ken
TACHYON V5 { Transmitter } 128 bytes regs pub SETUP 57600 SERBAUD EMIT: 1 SEROUT ; \ transmit from mailbox and ascii value pub TEST 5 RUN: regs 8 COG! SETUP BEGIN 5 us 'X' EMIT 5 CR 500 ms AGAIN ; ' TEST +INIT END \ BACKUPI noticed that 5 us actually takes longer than 10 us due to a bug in the way the word is implemented which I will fix. But if you ever wanted to delay exactly 5us you can use dummy sequences such as 2 FOR NEXT or 0 0 DUP 3DROP etc. Remember that you can time code by enclosing them in LAP words and then using .LAP to report the results like this:
Thanks for the info. On another note I must be missing the boat as I can't get even the smallest word to autostart. I have tryed a total reinstall, different VM and extend no go. The code below works as long as I just use TEST to run.
Ken
TACHYON { Transmitter } pub TEST 2 RUN: BEGIN 200 ms 3 HIGH 200 ms 3 LOW AGAIN ; ' TEST +INIT END BACKUPThe BOOT word which looks after all the INITS also starts up TIMERS in cog 2
COG 0 MAIN TACHYON CONSOLE
COG 1 SERIAL RECEIVER
COG 2 TIMERS (via EXTEND)
The TIMERS word handles all TIMEOUTS, ALARMS, WDT, and maintains runtime and soft RTC etc.
I am totally struggling with converting the altimeter from spin to Tachyon:
mb := ((_umultdiv(mb, constant(SEA_PRESS_STA << 2), sea_press) >> 1 + 1) >> 1) <# $1_f7ff #> $800 PUB in_from_mb(mb) {{ Convert pressure in millibars to inches of Hg (or from hundredths of millibars to hundredths of inches). '' '' `Parameters: '' '' `mb: Value in millibars to be converted. '' '' `Return: The equivalent value in inches of Hg. '' '' `Example: inches := alt.in_from_mb(101345) '' '' Convert 1013.45 millibars to hundredths of inches. }} return (_umultdiv(mb, constant(10000000 * 2), 338637526) + 1) >> 1 PRI _umultdiv(x, num, denom) | producth, productl {{ Multiply `x and `num, then divide the resulting unsigned, 64-bit product by `denom to yield a 32-bit unsigned result. `x ** `num must be less than (unsigned) `denom. }} _umult(@producth, x, num) return _udiv(producth, productl, denom) PRI _umult(productaddr, mplr, mpld) | producth, productl {{ Multiply `mplr by `mpld and store the unsigned 64-bit product at `productaddr. }} producth := (mplr & $7fff_ffff) ** (mpld & $7fff_ffff) productl := (mplr & $7fff_ffff) * (mpld & $7fff_ffff) if (mplr < 0) _dadd(@producth, mpld >> 1, mpld << 31) if (mpld < 0) _dadd(@producth, mplr << 1 >> 2, mplr << 31) longmove(productaddr, @producth, 2) PRI _udiv(dvndh, dvndl, dvsr) | carry, quotient {{ Divide the unsigned 64-bit number `dvndh:`dvndl by `dvsr, returning an unsigned 32-bit quotient. Saturate result to $ffff_ffff if it's too big to fit 32 bits. }} quotient~ ifnot (_ult(dvndh, dvsr)) return $ffff_ffff repeat 32 carry := dvndh < 0 dvndh := (dvndh << 1) + (dvndl >> 31) dvndl <<= 1 quotient <<= 1 if (not _ult(dvndh, dvsr) or carry) quotient++ dvndh -= dvsr return quotientI have drilled down on the spin to find what I think are the necessary steps in doing the calculations but no joy.I was having problems in setting up some constants, but studying your "BALLS" led me to see what I was doing wrong. I have the altimeter module installed on a QS board and I am talking to it with your MSCMD suggestion. I need to modify it slightly after studing balls. I really only need to send the altitude to it to set the sea level pressure and the conversion resolution. I guess that one of my issues is assigning math results to a var that I can use in other steps.
Jim
addit: how do I capture and measure an incoming PWM pulse?
Small steps, I load the small program below and it works as expected. Here's the problem, when I power the BOE, or any other board by any other means the program will not auto start. I tried a battery and external power supply. All voltages are good. I unplugged the tx line and the rx/tx lines flash and off it goes. All the boards are good . Any ideas?
Thank Ken
TACHYON { Transmitter } 7 COGSTOP pub GO 7 RUN: BEGIN 2 HIGH 200 ms 2 LOW 200 ms AGAIN ; ' GO +INIT END BACKUPAfter more research the USB link needs to be plugged in to AUTO run the program. What am I doing wrong?
Thanks Ken
Guilty as charged, trying to run before I can walk. Found the book for learning Forth in Drop Box, Installed the APP and am working through the exercises. Hope I learn to walk soon!
Thanks for your help, very interested in your tests on the P2.
Jim
The easiest way to get around this problem is to disable break detection in Tachyon and recompile. Find this section around line 3880:
stopins waitcnt rxcnt,rxticks ' check stop bit early (need to detect errors and breaks) test rxpin,ina wc ' sample stop bit if_c wrword rxwr,rxwrP ' update hub index for code reading the buffer if all good if_c mov breakcnt,#100 ' reset break count if_c jmp #receiveand remove the if_c in the last line so that it never continues on to handle frame errors and breaks.A quick fix though if you are using 5.4 is to directly modify this instruction in the EEPROM so that after the next reset it will be using an unconditional jmp. Just do this: then reset it and it will now ignore breaks.
Most of my boards do not bother with dedicated USB serial since they are designed to be embedded in a product and the ones that do have USB serial are also powered in such a way that the USB serial can power the board and also be powered when USB is unplugged so that I don't have any spurious signals on the receive and transmit. Parallax boards though in general are designed for education, not for embedding in a final product. That is why they may be battery powered and only use linear regulators etc.
Now for the conversion code just follow the maths which shows that instead of trying to do floating point that they are scaling the amount by multiplying by 20,000,000 (10,000,000*2) so that when you divide by the divisor then you will end up with a 32-bit integer scaled result. For instance try dividing 1 by 98 like this:
... 1 98 / . 0 ok
Well, that's the result you get from using integer maths and the easy way out is to use floating point. But floating point can introduce errors and is not natively or easily supported on the Prop, although neither are multiply and divide, but floating point would be quite slow. On a calculator the result would be 0.0102040816327
But this is where knowing the scales and limits involved we simply scale the input and then divide resulting in a scaled result like this: This is where the multiply and the divide word */ in Forth is useful since it will multiply or scale a number to a 64-bit intermediate result and then divide that 64-bits with the second parameter like this:
... 1 1,000,000,000 98 */ . 10204081 ok
To convert millibars to inches of mercury, multiply the millibar value by 0.0295301 or divide by 33.8637526 (rounded).
So this function in Spin:
Where we take mb and then multiply it by 10,000,000 shifted left one bit (*2), round the last bit with +1 and shift it right one to compensate.
Becomes this in Forth: Try that out:
HOWEVER
But as you can see from the original formula you can multiply by the more accurate 0.0295301. Lets try that in Forth but divide down the result so that it still has two decimal places in the integer ( 12.34 is 1234 ): BTW - commas and decimal points in Tachyon numbers are only for readability, they are still normal integer numbers.
Create a word for that: Super easy and way better I think. So mb>in could use a scaled result so that when printing it reports two decimal places like this using Tachyon's formatted number word:
Create a new word just for printing out in this format and try it out immediately:
EDIT: I decided that I would add a delineation to Tachyon so that when you hit the enter it delineates the result from the input which makes it easier to distinguish what is what when we paste console text onto the forum. Like this: So I use --> as the delineation which is also becomes one of the comment control words so we could just copy and paste the whole line back into a terminal.
The problem occurs when you send out serial data to the USB chip while not connected to a Host. Thru parasitic feeding the USB-chip wakes up and, guess, resets the Propeller.
The problem is known for a long time, even @mpark checked it at he beginning of Spinx. The solution is to see if P31(P30? I forgot) is high or else not to send serial data.
I argued a lot here in the forum, trying to keep at least the ProtoBoard w/o USB alive, but I failed.
@"Ken Gracey" stated that all future boards will have USB build in and the Spinneret was the only board where they at least put a jumper between USB reset and the real reset.
The USB on board might be useful for education, but I really prefer a PropPlug to avoid the whole problem.
Enjoy!
Mike
Wow, thanks for the very informative reply. Last night, as I was going to bed, it struck me that i needed to go back and find the actual conversion formulas and plug those into Tachyon without going through trying to understand what was happening in Spin. One very useful piece of information in your reply is that Tachyon ignores decimal points so that I would not have to go through a convoluted multiply then divide down to get the answer. Yesterday, I spent most of the day reading "Starting Forth" and I came away with a much better understanding as to what I was trying to do.
Thanks again for all you do and taking time out from P2 testing to reply.
Jim
I am not having success with edge detect: As you can see from the screen shot whenever I enter the POS EDGE DETECT I get ???. I have learned how to create constants and Vars and see where I can strip the math in the altimeter down to its basics and plug that into Tachyon words Was trying to set up some tests on the rain gauge when I ran into the Edge detect problem. This will effect the rain gauge and the wind speed. Both depend upon the edge detection as I have a flag passing through an optical sensor.
So what am I doing wrong? I downloaded the latest version of EXTEND that I found in the Dropbox, you can see the version info in the screen shot I patched in.
Thanks for the help.
Jim
For now adding thé constants will work better than reloading extend. Does COUNTS@ reload or clear PHSA if not what does?
Thanks,
Jim
So COUNT@ only fetches the contents of the currently select A or B PHSx counter. You need to use !COUNT to initialize the PHSx counter.
I need to write a couple of ROMs for my tachyon system to drive ADC/DAC peripherals at (more) speed. My question is, what are the best support tools/workflow to test and debug pasm code in order to minimise the number of bh.py/SAVEROM iterations I'll need to do? I note that the GEAR Propeller emulator exists (https://sourceforge.net/projects/gear-emu/), is there anything else?
Cheers
For the last three days I have been trying to figure out how to do the following. Store this table as long value's I want to be able to do a binary search on the table by taking the starting address of the table, adding 1/2 the length of the table (65 entries) then compare the stored value with the value I am looking up. I will divide the table in half and use a new upper limit or lower limit depending upon the results of the comparison. I have tried setting this up as a CSV , or || separated values but have not been successful. I have been looking for code examples but those seem to be few and far between.
Thanks for the help.
Jim
this looks like longs