Maybe capacitance inside LED is very small. So capacitance of lead-lines ia bigger.
I re-connected directly resister and LED on QS-bard's connector. It finely operated.
Hey! thanks for that! I've been meaning to get around to this forever!
If you put a 0.1uf capacitor by the LED, would it permit longer wires?
demo4 operated finely.
demo4 use forth-word"drive_LED_bar".
I re-wrote drive_LED_bar to assembler-word.
But not operate.
Please teach me where is wrong in asm-code.
I'm not familiar with this assembler but why can you access cnt directly but can't do the same for phsx & Co, e.g. you use __phsa instead of phsa? That doesn't feel right.
FWIW, I think the unwillingness of the assembler to accept these names is due to the fact that they are defined as constants at the top of the file. You could use ctrb & Co to see if there is a difference.
Hi.
I'm confused about relation dira output and NCO/PWM mode's bit31 output.
I modified "drive_LED_bar".
1. P0-P23 Output All bits=HI --> When executing "LED_bar_test1", output is still high level. Lo of NCO/PWM mode's bit31 is not output.
2. P0-P23 Output All bits=Lo --> When executing "LED_bar_test1", Hi of NCO/PWM mode's bit31 is output.
Where is wrong?
: drive_LED_bar
1msec d64 u/ dT L!
1 frqa COG!
0 phsa COG!
pwm d23 0 do dup dup pinout pinhi 1+ loop drop \ P0-P23 Output All bits=HI
\ pwm d23 0 do dup pinout 1+ loop drop \ P0-P23 Output All bits=Lo
cnt COG@ 1msec +
swap
begin
\ Run 24-element
d24 0 do
\ dup i + pinout ¥ Set target-port to output
dup i + h10000000 or ctra COG! ¥ PWM/NCO mode on LED pin
i LED_level + C@ ¥ Get level for target LED
dT L@ u*
negate phsa COG!
swap
1msec waitcnt ¥ Wait until cnt+1msec
swap
\ dup i + pinin ¥ Set target-port to input
0 ctra COG! ¥ Reset counter
loop
\ 0 until
fkey? swap drop until
2drop
;
kuroneko-san
I don't know how to define constants at the top of the file.
And what is "ctrb & Co"?
I assume this is confusing the assembler. So I suggest you use ctrb, frqb and phsb instead to see if this is the case (conflict) so that you could avoid using hex numbers for special registers in the assembler.
I'm confused about relation dira output and NCO/PWM mode's bit31 output.
I modified "drive_LED_bar".
1. P0-P23 Output All bits=HI --> When executing "LED_bar_test1", output is still high level. Lo of NCO/PWM mode's bit31 is not output.
2. P0-P23 Output All bits=Lo --> When executing "LED_bar_test1", Hi of NCO/PWM mode's bit31 is output.
Where is wrong?
So you're setting all 24 bits to output and high (dira := outa := $00FFFFFF). In that case outa will hide the counter output (counter, video h/w and outa are all OR'd together to form the final output state). With all bits being outputs but low the counter output will become visible. This is expected behaviour.
Thanks kuroneko-san.
I understand it.
I have mistakes.
Reversing direction(P&N) of LED-bar, code become simple.
Signal wave also is simple.
Overhead-time also become shorter.
I must re-make pdf and code.
Been swamped the last couple weeks.
I'm still learning about time calibration, logging to SD, thermistor calibration.
- Time calibration: with no drift correction, the time tends to drift slow, maybe a second per day at room temperature. But since the temperature is not constant, we don't know how much to correct at any given time. So to properly correct for drift, we might be able to dynamically adjust for temperature if the temperature were known.
- Thermister calibration: the cheapest way to track temperature seems to be using a thermistor. I got 50 for arround a buck-twenty from Thailand. The are rated 10k at room temperature, which means some can be 8K and some can be 12K. We put the thermistor and a capacitor in series between 3.3V and ground, and connect a prop input pin to the junction. The capaciptor gets charged, and we time the period until the cap discharges. By recording the time fo several temperatures, we can make a table of discharge times that corespond to degrees C. Using the thermistor that was characterized gives a tmeperature very close to the multimeter probe I'm using as a reference (mostly spot on, however, when one flickes between two temperatures, the other doesn't all the time). The thermistors take significantly longer to stablize than the multimeter probe, but its less than two minutes. Also, using different thermisters from the same batch yields temps that are off by 1 degree plus or minus (so far).
LittleRobot - There have been several inquiries regarding more sessions at local librraries. There have been two inquires from maker/hacker spaces to have this workshop as a "higher complexity" offering. But all these are still in the discussion phase, so I'm not holding my breath yet.
I've been getting into PropForth, and it is really an impressive language and environment. Thanks to all who are contributing to this. Hope I can find a way to do my part.
A couple of questions:
1. What is the best way to communicate between processes running in separate cogs? For instance, if I use cogx to start some processing in cog A, and want to send cog A a message from cog B, what is the recommended way to do this? Can there be "shared" variables in hub memory?
2. Sometimes when I'm loading a .f file to PropForth from TeraTerm, the paste freezes, and I have to press [Enter] to get it moving again. The .f file has the "fl" command at the beginning. I'm not sure what's going wrong.
1.
I translated Single Pin Sigma Delta ADC Driver v1 to Propforth.
Refer #234 in this thread.
Cog0 operate "result d4095 6 a_1pin_sigma_delta_A/D".
Cog6 read result.
2.
When file is loaded by using 'Send meny' on TeraTerm, such a thing occur.
To prevent;
[ code]
fl
: sample
.
forth statements
.
;
<-- need no character line
[/code]
Hi.
I try to install propforth to spinneret.
I'm reading "tutorial-5.1 IP+Telnet.txt".
1 I installed SD-kernel.
2 I changed setting of boot.f
3 I did copy-paste ipserver1.f
4 I did copy-paste ipserverdebug.f
5 I did copy-paste boot.f
Of course, it cannot load because boot.f include 'fswrite'.
'fswrite' is word inside eeprom-kernel.
Which does I install kernel?
SD-kernel,eeprom-kernel,both?
If both, how does they install?
There is procedure?
Inside Currentrelease directory;
PropForth directory -- Devkernel without SD and eeprom and IP
PropForthEEprom -- Kernel with eeprom Not DevKernel
PropForthEEpromIP -- Kernel with eeprom and IP Not DevKernel
I don't know if kernel-body same as PropForthEEprom.
PropForthIp -- Kernel with IP without eeprom and SD
I don't know if kernel-body same as PropForthEEprom.
I edited IP-address and gateway and macaddress on IPKernel.spin.
Installing IPKernel.spin, use-LED is blinking.
I connected spinneret and PC by cross-cable.
I started TeraTerm in TCP/IP.
I recognized connecting PC and spinneret by telnet on TCP/IP.
PropForthSD -- Kernel with SD without eeprom
I don't know if kernel-body same as PropForthEEprom.
I don't know if with IP.
Now, thers is no forth source-list for PropForth5.5.
I checked below;
DevKernel without IP and SD and eeprom
EEpromKernel without IP and SD
EEpromIPKernel without SD
IPKernel without SD and eeprom
SDKernel without IP and eeprom
Maybe none can write code using W5100 except for Sal.
1. What is the best way to communicate between processes running in separate cogs? For instance, if I use cogx to start some processing in cog A, and want to send cog A a message from cog B, what is the recommended way to do this? Can there be "shared" variables in hub memory?
2. Sometimes when I'm loading a .f file to PropForth from TeraTerm, the paste freezes, and I have to press [Enter] to get it moving again. The .f file has the "fl" command at the beginning. I'm not sure what's going wrong.
Hi Earl Welcome to the fun!
There's a couple ways for cogs to talk to each other. cogx can send a string to anotherr cog's input, as you have seen. In addition to doing this from the command line, this can also do this in a forth word. Of course tha recieving cog has to be available to listen to its input buffer, or input will just sit there (forever).
When the message is a single value (this is quite frequently a good way to go), the value can be saved in a variable. Any cog can read the dictionary, so any cog can see the variable. Typically the driver routine on a dedicated cog (for example the SR04 driver) will read the sensor and store the value ( e.g. in variable _sr04_reading). The display routine (on the terminal cog6) will read the most recent value from the variable and dispaly it on the terminal ( _sr04_reading W@ . ) . This can be done for as many values as needed using one variable for each value.
If there are larger chunks of data, these can be saved to EEprom or SD card, (see logger1simple for SD). Another cog can read the EEprom or SD at the same time new data is being written by the other cog. In fact each cog can have its own currently open file, I've only had one reading and one writing so far.
As caskaz says, the teraterm paste can frees if there is no CR at the end of the last pasted line. Typically this happens when copy paste from a browser window. I haven't figred out how to make the browser display a final blank line in a source code listing. Another cause for this can be an erro in the source code being pasted, and (rarely) the communications will get garbled if you use Windows and and your hardware is less than most expensive.
PropForth directory -- Devkernel without SD and eeprom and IP
PropForthEEprom -- Kernel with eeprom Not DevKernel
PropForthEEpromIP -- Kernel with eeprom and IP Not DevKernel
PropForthIp -- Kernel with IP without eeprom and SD
PropForthSD -- Kernel with SD without eeprom
Now, thers is no forth source-list for PropForth5.5.
The source is still in there, its in the
2013FEB23mygo V5.5 RC1.zip
archive, which is another archive inside the regular download. This is the same old download from before 5.5, but few folks are interested in or capable of wading through the source. So its there for completeness, but place out of the way of new users. Once you find the mygo, to use it we have to set up Go-Language support to run the build and test automation. Building the kernel from source is way too time consuming and boring to do by hand anymore. The automation builds the new kernel from scratch (from source code) in about an hour and a half(?) and the test autmation execute every last possible function in the entire kernel in abbout another hour(?). Doing this process by hand would take about two weeks if you did everything perfect and made no typos.
It takes a bit of effort to set up the Go support, so we are planning to make this a little easier in the next release, which has not been formally anounced yet but Sal says its pretty much done except for the 6 month stability testing which is already underway. If possible wait til the next release and the build and test *might* be less arduous.
Hi.
I try to install propforth to spinneret.
I'm reading "tutorial-5.1 IP+Telnet.txt".
1 I installed SD-kernel.
2 I changed setting of boot.f
3 I did copy-paste ipserver1.f
4 I did copy-paste ipserverdebug.f
5 I did copy-paste boot.f
Of course, it cannot load because boot.f include 'fswrite'.
'fswrite' is word inside eeprom-kernel.
Which does I install kernel?
SD-kernel,eeprom-kernel,both?
If both, how does they install?
There is procedure?
Spinerette is still included in the sources and test automation, since it is already working and complete. But, we don't use it much. Spinerette is ideal for only limited situations since IP support takes so much room leave little for an actual application, so we are not planning any further development on Spinerette.
RaspberryPi is cheaper and more powerful. Going forward, Prop + RPi is the planned recommendation for adding ethernet to a propforth applications.
That being said, the most straight forward way to get Spinerette running is to run the automation, and run the IP/HTTP scripts. Once those scripts run, you have the example of how to correctly set up and use the IP/HTTP support for spinerette. But, its kind of a lot of effort. Last time I ran it was before v5.5 release, it is completely stable and repeatable once its set up. But is take a bunch of effort as we have to set up the PC OS environment varailbes etc as well as the testbed hardware.
Sal has started on a NEW HARDWARE TESTBED for PF6.0 onward, so all the old stuff is likely going to change anyway.
Comments
Solved LED_sensor.
I made curcuit(resister and LED) on breadboard and connected P0/P1 of QS-bard and breadboard by lead-lines(10cm).
Maybe capacitance inside LED is very small.
So capacitance of lead-lines ia bigger.
I re-connected directly resister and LED on QS-bard's connector.
It finely operated.
http://youtu.be/McOvpVOwYeU
Hey! thanks for that! I've been meaning to get around to this forever!
If you put a 0.1uf capacitor by the LED, would it permit longer wires?
You mean LED and 0.1uF is parallel-connection?
I think this don't operate.
I mean cap in series
P0 --- 0.1uf --- LED --- 220ohm --- P1
Just off the top of my head
Or do we want the decrease the capacitance?
I'll try t ask about this later today at my meeting
LED is not on because capacitor can't flow DC.
I made summary about LED_sensor.
I wrote simple demo about pwm.
demo4 --> http://youtu.be/sbJSoumdNJw
demo4 operated finely.
demo4 use forth-word"drive_LED_bar".
I re-wrote drive_LED_bar to assembler-word.
But not operate.
Please teach me where is wrong in asm-code.
demo4 below;
http://youtu.be/HtA-5D9Ut40
¥ ( n1 n2 n3 -- ) n1:address of LED_bar array n2:number of leds n3:first led $C_treg1 - counter for lednum $C_treg2 - index for LED_bar array $C_treg3 - pin number $C_treg4 - counter to multiple $C_treg5 - result for multiple $C_treg6 - $C_treg5's negative value $C_stTOS - pin mask fl build_BootOpt :rasm ¥ Get first_pin-number mov __pin , $C_stTOS spop ¥ Get number of leds mov __lednum , $C_stTOS spop ¥ Get address of LED_bar array mov __array , $C_stTOS mov __frqa , # 1 mov __phsa , # 0 mov cnt , __1msec add cnt , cnt ¥ initial __1 mov $C_treg1 , __lednum mov $C_treg2 , __array ¥ pin_mask mov $C_stTOS , # 1 shl $C_stTOS , __pin mov $C_treg3 , __pin __2 mov dira , $C_stTOS or __ctra , $C_treg3 or __ctra , __pwm rdbyte __bright , $C_treg2 jmpret __multi_ret , # __multi neg $C_treg6 , $C_treg5 mov __phsa , $C_treg6 waitcnt cnt , __1msec andn dira , $C_stTOS mov __ctra , # 0 ¥ next pin add $C_treg2 , # 1 shl $C_stTOS , # 1 add $C_treg3 , # 1 djnz $C_treg1 , # __2 jmp # __1 ¥ multiple __bright by __dT __multi mov $C_treg4 , __dT mov $C_treg5 , # 0 __3 add $C_treg5 , __bright djnz $C_treg4 , # __3 __multi_ret ret ¥ variables __pin 0 __lednum 0 __array 0 __bright 0 ¥ constants __1msec d80000 __dT d1250 __pwm h10000000 __ctra h1F8 __frqa h1FA __phsa h1FC ;asm a_drive_LED_barAll LEDs are on.Chcking P0-P23 by oscilloscope, program(part of loop) operate.
But PWM don't operate.
ctra,phsa,frqa cannot use in assembler code. When assembled, "? phsa" is printed out.
__ctra -> h1F8
__frqa -> h1FA
__phsa -> h1FC
It works finely.
I'm confused about relation dira output and NCO/PWM mode's bit31 output.
I modified "drive_LED_bar".
1. P0-P23 Output All bits=HI --> When executing "LED_bar_test1", output is still high level. Lo of NCO/PWM mode's bit31 is not output.
2. P0-P23 Output All bits=Lo --> When executing "LED_bar_test1", Hi of NCO/PWM mode's bit31 is output.
Where is wrong?
: drive_LED_bar 1msec d64 u/ dT L! 1 frqa COG! 0 phsa COG! pwm d23 0 do dup dup pinout pinhi 1+ loop drop \ P0-P23 Output All bits=HI \ pwm d23 0 do dup pinout 1+ loop drop \ P0-P23 Output All bits=Lo cnt COG@ 1msec + swap begin \ Run 24-element d24 0 do \ dup i + pinout ¥ Set target-port to output dup i + h10000000 or ctra COG! ¥ PWM/NCO mode on LED pin i LED_level + C@ ¥ Get level for target LED dT L@ u* negate phsa COG! swap 1msec waitcnt ¥ Wait until cnt+1msec swap \ dup i + pinin ¥ Set target-port to input 0 ctra COG! ¥ Reset counter loop \ 0 until fkey? swap drop until 2drop ;kuroneko-san
I don't know how to define constants at the top of the file.
And what is "ctrb & Co"?
I understand it.
I have mistakes.
Reversing direction(P&N) of LED-bar, code become simple.
Signal wave also is simple.
Overhead-time also become shorter.
I must re-make pdf and code.
Been swamped the last couple weeks.
I'm still learning about time calibration, logging to SD, thermistor calibration.
- Time calibration: with no drift correction, the time tends to drift slow, maybe a second per day at room temperature. But since the temperature is not constant, we don't know how much to correct at any given time. So to properly correct for drift, we might be able to dynamically adjust for temperature if the temperature were known.
- Thermister calibration: the cheapest way to track temperature seems to be using a thermistor. I got 50 for arround a buck-twenty from Thailand. The are rated 10k at room temperature, which means some can be 8K and some can be 12K. We put the thermistor and a capacitor in series between 3.3V and ground, and connect a prop input pin to the junction. The capaciptor gets charged, and we time the period until the cap discharges. By recording the time fo several temperatures, we can make a table of discharge times that corespond to degrees C. Using the thermistor that was characterized gives a tmeperature very close to the multimeter probe I'm using as a reference (mostly spot on, however, when one flickes between two temperatures, the other doesn't all the time). The thermistors take significantly longer to stablize than the multimeter probe, but its less than two minutes. Also, using different thermisters from the same batch yields temps that are off by 1 degree plus or minus (so far).
LittleRobot - There have been several inquiries regarding more sessions at local librraries. There have been two inquires from maker/hacker spaces to have this workshop as a "higher complexity" offering. But all these are still in the discussion phase, so I'm not holding my breath yet.
I updated.
This is my memorandum.
If wrong, teach me please.
http://youtu.be/eUV9bSILReU
A couple of questions:
1. What is the best way to communicate between processes running in separate cogs? For instance, if I use cogx to start some processing in cog A, and want to send cog A a message from cog B, what is the recommended way to do this? Can there be "shared" variables in hub memory?
2. Sometimes when I'm loading a .f file to PropForth from TeraTerm, the paste freezes, and I have to press [Enter] to get it moving again. The .f file has the "fl" command at the beginning. I'm not sure what's going wrong.
Thanks! This is fun.
- Earl
1.
I translated Single Pin Sigma Delta ADC Driver v1 to Propforth.
Refer #234 in this thread.
Cog0 operate "result d4095 6 a_1pin_sigma_delta_A/D".
Cog6 read result.
2.
When file is loaded by using 'Send meny' on TeraTerm, such a thing occur.
To prevent;
[ code]
fl
: sample
.
forth statements
.
;
<-- need no character line
[/code]
I try to install propforth to spinneret.
I'm reading "tutorial-5.1 IP+Telnet.txt".
1 I installed SD-kernel.
2 I changed setting of boot.f
3 I did copy-paste ipserver1.f
4 I did copy-paste ipserverdebug.f
5 I did copy-paste boot.f
Of course, it cannot load because boot.f include 'fswrite'.
'fswrite' is word inside eeprom-kernel.
Which does I install kernel?
SD-kernel,eeprom-kernel,both?
If both, how does they install?
There is procedure?
Now.tutorials is old and they should not refer.
Inside Currentrelease directory;
PropForth directory -- Devkernel without SD and eeprom and IP
PropForthEEprom -- Kernel with eeprom Not DevKernel
PropForthEEpromIP -- Kernel with eeprom and IP Not DevKernel
I don't know if kernel-body same as PropForthEEprom.
PropForthIp -- Kernel with IP without eeprom and SD
I don't know if kernel-body same as PropForthEEprom.
I edited IP-address and gateway and macaddress on IPKernel.spin.
Installing IPKernel.spin, use-LED is blinking.
I connected spinneret and PC by cross-cable.
I started TeraTerm in TCP/IP.
I recognized connecting PC and spinneret by telnet on TCP/IP.
PropForthSD -- Kernel with SD without eeprom
I don't know if kernel-body same as PropForthEEprom.
I don't know if with IP.
Now, thers is no forth source-list for PropForth5.5.
I checked below;
DevKernel without IP and SD and eeprom
EEpromKernel without IP and SD
EEpromIPKernel without SD
IPKernel without SD and eeprom
SDKernel without IP and eeprom
Maybe none can write code using W5100 except for Sal.
This can connect to telnet/http on TCP?
How?
Where is procedure?
There's a couple ways for cogs to talk to each other. cogx can send a string to anotherr cog's input, as you have seen. In addition to doing this from the command line, this can also do this in a forth word. Of course tha recieving cog has to be available to listen to its input buffer, or input will just sit there (forever).
When the message is a single value (this is quite frequently a good way to go), the value can be saved in a variable. Any cog can read the dictionary, so any cog can see the variable. Typically the driver routine on a dedicated cog (for example the SR04 driver) will read the sensor and store the value ( e.g. in variable _sr04_reading). The display routine (on the terminal cog6) will read the most recent value from the variable and dispaly it on the terminal ( _sr04_reading W@ . ) . This can be done for as many values as needed using one variable for each value.
If there are larger chunks of data, these can be saved to EEprom or SD card, (see logger1simple for SD). Another cog can read the EEprom or SD at the same time new data is being written by the other cog. In fact each cog can have its own currently open file, I've only had one reading and one writing so far.
As caskaz says, the teraterm paste can frees if there is no CR at the end of the last pasted line. Typically this happens when copy paste from a browser window. I haven't figred out how to make the browser display a final blank line in a source code listing. Another cause for this can be an erro in the source code being pasted, and (rarely) the communications will get garbled if you use Windows and and your hardware is less than most expensive.
Cheers!
The source is still in there, its in the
archive, which is another archive inside the regular download. This is the same old download from before 5.5, but few folks are interested in or capable of wading through the source. So its there for completeness, but place out of the way of new users. Once you find the mygo, to use it we have to set up Go-Language support to run the build and test automation. Building the kernel from source is way too time consuming and boring to do by hand anymore. The automation builds the new kernel from scratch (from source code) in about an hour and a half(?) and the test autmation execute every last possible function in the entire kernel in abbout another hour(?). Doing this process by hand would take about two weeks if you did everything perfect and made no typos.
It takes a bit of effort to set up the Go support, so we are planning to make this a little easier in the next release, which has not been formally anounced yet but Sal says its pretty much done except for the 6 month stability testing which is already underway. If possible wait til the next release and the build and test *might* be less arduous.
Spinerette is still included in the sources and test automation, since it is already working and complete. But, we don't use it much. Spinerette is ideal for only limited situations since IP support takes so much room leave little for an actual application, so we are not planning any further development on Spinerette.
RaspberryPi is cheaper and more powerful. Going forward, Prop + RPi is the planned recommendation for adding ethernet to a propforth applications.
That being said, the most straight forward way to get Spinerette running is to run the automation, and run the IP/HTTP scripts. Once those scripts run, you have the example of how to correctly set up and use the IP/HTTP support for spinerette. But, its kind of a lot of effort. Last time I ran it was before v5.5 release, it is completely stable and repeatable once its set up. But is take a bunch of effort as we have to set up the PC OS environment varailbes etc as well as the testbed hardware.
Sal has started on a NEW HARDWARE TESTBED for PF6.0 onward, so all the old stuff is likely going to change anyway.