... control(PWM)
It takes 6mseconds to get cog number. Not good on 5mseconds.
Is this normal?
Sal is starting examples on PWM for servo and stepper motor control. There may be some impact from the timing alternative used, I haven't played with it yet. Also, I don't have an LCD test rig set up.
Sal doesn't usually read the forum, please gmail him directly.
The key is Clearly Defined Requirements:
High Level Requirements - What is the end function of the final device in high level terms
System level Requirements - what systems are need to fulfill the high level requirements
Implementations Requirements - What functions do you need to implement to achieve the system described
This applies to any project, but seems more obvious when using forth.
ALSO - defining requirements is in itself an iterative process, as you define the next level, you get more insight into the previous level, and should go back and make adjustments. Generally, one does not want to start coding until all requirements are defined to the extent that you know what you have to code. This is "the easy way". Of course few do it this way, which is ok, it just takes longer to do it the hard way.
That being said you have a good start on your requirements.
1. Exactly what sensors/inputs do you have in mind right now specifically? Do no include "possibly.." and "maybe someday..." items, you will have enough work with today's specifics, and you can add new stuff later.
More in details:
- Values from a thermocouple module via I2C
- Values from displacement sensors addressable over a RS485 network
- Values from ADCs (all SPI bus)
- Values from a balance (RS232)
- Switching some relays
a lot of stuff, but all things are quite slow (cycle time > 1s)
2. "Intelligent I/O processor" does not sound specific, do you mean the prop is to be I/O interface and pre-processor to the ARM? If so, this should not be a problem.
simple communication between the OMAP and the PropForth via RS232 is already running.....
3. Propforth can easily be extended to have drivers for reading and controlling each sensor, we just need the specific parts you are targeting. ok...
4. There are many choices for serial interface. If there are less than 28 or so, it is easy to have one line for each part. If there are more than that, the parts that are accessed less often can be place on a SPI bus and accesses with a shift register. The method used on the C3 board may be useful. Again, the specific parts will dictate which need a dedicated I/O line, which can be multiplexed, and what baud rate for a given throughput is needed.
Not more then 4 or 5 (maximum)
5. Usually you can leave the regular forth interface (Rx/TX on line 30&31) as the serial interface, and use the other pins for inter-device communication. Its easier and much more convenient, and its nice to leave something just in case you get to load up every last pin later on.
ok
6. As of 4.x, Sal runs his DEVELOPMENT for days at a time. The 3.x stuff was less stable in development, needed to reboot once a day, but the final apps ran indefinitely. Final apps on 4.x are (so far) completely stable (Sal has not found any evidence of instability yet).
stability is extremely important.
7. We expect Next week or so to have a public release of v4.5. This should be fast enough for any application you have in mind; if it isn't, the bottlenecks can be optimized in assembler.
I think speed is not the main bottleneck, i think.
8. If you have specifics on the I2C and SPI we can look are implementing the drivers. I haven't played with I2C and SPI myself, but Caskaz and Sal have SD support nearly complete.
So the first step in getting stated is to state very specifically what sensor you want to monitor and define the data you wish to collect. Everything else is built on that.
** i think for me to implement a driver in the right way is the biggest problem. A good I2C pasm driver is already in OBEX. I have used it already in SPIN. So what i like to know how to interface such a peace of software to FORTH.
** SPI can be done directly in FORTH , i think.
** whats the best way for an add. serial interface beneath the 30-31 user interface?
Also, if you are working on an ARM and are interested in FORTH, please check out Frank Sargents Pygmy Forth. http://pygmy.utoh.org/ ** thats a good hint. I am thinking about talking ARMFORTH to PROPFORTH an the low level.
If you have any requirements/specifications that you can't discuss on the thread, PM me and I will try to help properly define them. This step is critical for success. You should be able to finish defining requirements by the time V4.5 is released.
The encoding for those two jmprets is wrong. The hex value represents a jmpret __delayret, #__delayret, i.e. src and dst fields are the same ($2A552 = %101010010_101010010). As the ret starts out as a jmp #0 this is likely to go wrong. I assume there is some 3rd party assembly involved so that's the first place I'd look for the address mismatch. FWIW, $5CFEA550 would be the correct value.
Hi.
I did SPI-communication between protoboard(forth_master_0.1.f) and demoboard(slave_SPI_0.1.spin).
This is very slow since using forth-word and SPIN.
I think assembler need.
Connected resistor(220ohm) on pins between protoboard and demoboard.
Loaded forth_master_0.1 on protoboard.
Loaded slave_SPI_0.1to ram or eeprom on demoboard.
Executed WORD"demo" on protoboard.
Hi.
I did SPI-communication between protoboard(forth_master_0.1.f) and demoboard(slave_SPI_0.1.spin).
This is very slow since using forth-word and SPIN.
I think assembler need.
Connected resistesr(220ohm) on pins between protoboard and demoboard.
Loaded forth_master_0.1 on protoboard.
Loaded slave_SPI_0.1to ram or eeprom on demoboard.
Executed WORD"demo" on protoboard.
Nice work! I'll try and set this up and do some tests, but it will have to wait till after testing on Sal's new servo control code is finished.
My comment on this is to mention the convention for "print words".
The tradition is to designate words that print character to the display by prefixing them with a period. So the "traditional" form for your words would be to change:
: msg c" May the FORTH be with you" ;
: kb c" Keyboard is " ;
: ms c" Mouse is " ;
: msg1 c" not connected" ;
: msg2 c" connected" ;
: mouse1 c" 2-button mouse" ;
: mouse2 c" 3-button mouse" ;
: mouse3 c" 5-button mouse" ;
: button c" button status" ;
: mouse4 c" left center right" ;
: mouse5 c" deltax deltay deltaz" ;
: on c" ON " ;
: off c" OFF" ;
to:
: .msg c" May the FORTH be with you" ;
: .kb c" Keyboard is " ;
: .ms c" Mouse is " ;
: .msg1 c" not connected" ;
: .msg2 c" connected" ;
: .mouse1 c" 2-button mouse" ;
: .mouse2 c" 3-button mouse" ;
: .mouse3 c" 5-button mouse" ;
: .button c" button status" ;
: .mouse4 c" left center right" ;
: .mouse5 c" deltax deltay deltaz" ;
: .on c" ON " ;
: .off c" OFF" ;
Prof_Braino:
Could you recommend any good forth tutorials? I have very little experience with forth, to the point of being almost a noob in the area of the Forth language.
Prof_Braino:
Could you recommend any good forth tutorials? I have very little experience with forth, to the point of being almost a noob in the area of the Forth language.
Google Leo Brodie. PM me if you have specific questions. Once I get started, I can go on and on, its best not to babble in public.
Is Propforth 4.0 compatible with the Demo Board? If not, which version is the most recent? Thanks.
All versions of propforth will run on any prop chip. There are some configurations that look for specific hardware, for example the JupiterACE configuation expects the demobpard pinout for VGA and keyboard, and the Hive configuration expects the Hive pinout for VGA and keyboard.
The EEPROM filesystem expects a 64k EEPROM, which I belive is on all prop boards EXCEPT the demoboard, but you don't have to load it, and if you do load, you don;t have to execute those words. (Don't ask me why, but folks do this. OK ask me why, I'll tell you: they want to see if it breaks)
I usually use the demoboard when I use VGA, and I usually DON'T use the EEPROM file system on the other boards, except in testing.
I usually load working code into RAM and do a saveforth, which over-writes the low 32K EEPROM with the current dictionary.
I load code under test into a freshly booted prop which has my working code saveforth'd.
Version 4.0 is the lastest release from the author, the 4.0a version was an attempt by me to better organize, but this attempt had limited success.
Next version targeted is version 4.5 next month which will have spineret specific functionality: Ethernet, telnet server, HTML5 server, forth execution in HTML pages, Time over internet. Also may have RAW SD support, block access, FAT comaptibility NOT implemented.
Final development version (may be) verison 5 in august, with support for minimum permanent kernal (about 4k?), on the fly compilation from SD, and auto-forget, to allow unlimited application and data size (with a 32k max size at any given time, of course).
Okay, I downloaded PF4.0, and did the following...
a) loaded the .spin file into eeprom
b) loded PropForthCore.f via Tera Term
c) ran saveforth
Where does that leave me? I'm guessing with a minimal system? Do I need anything else to work with the demo board?
Also, how do I view the Prop and Version info? I tried running the commands, but I must be missing something.
Thanks.
The comments in the readme are supposed to indicate that the spin file is just the minimal system.
PropForthxxx.f addes various development extensions. ONE file is for recreatingthe minimmal kernel, the other is for development.
If you did it correctly, when you type "words" your should get a display of all the words, thefunctions present in the dictionaqry.
Now you can access any functionality of the prop hardware using the command line. The most commlonly used are defined as FROTH words, the less commonly used are accessed thru assembler.
Try to follow the examples, at one time they were sufficient; PM me if you find errors and I will make correction.
Also try the Brodie books, the PC oriented material needs modification, but the basic material should still be the same.
seems not to work, because the serilacog seems to stuck port 4
The most clean way would be , to realize it in the serial driver stuff, i think. Any ideas
Markus
(i have cross posted this question in the German Hive forum)
I have now modified the startserialcog or better said the serentyPFA routine a little bit,
if a special sign (now ASCI 7C) is handled a 32bit high signal is clocked out.
I would like to take another AsCI code like $00 but i dpn't understand how to
make something like
4 5 9600 2 startserialcog
c" $00 " 2 cogx
the 2nd line didn't work (its sending $ 0 0 ).
Any idea how to make string out of any ASCII character(s) ?
I didn't check, but I think that
" 7 emit 0 emit 4F emit 4B emit "
gets put into cog 2's input buffer, andit executes just as if you typed it from the command line.
I looked at some of the docs on the google code site.
The Polish notation is a bit quirky...be hard to get used
to it I imagine. Is there a free Forth book for idiots somewhere?
... docs on the google code site. The Polish notation is a bit quirky...be hard to get used to it I imagine. Is there a free Forth book for idiots somewhere?
The documentation on google docs is weak since I haven't gotten a lot of feedback. If you see anything the needs fixing let me know.
The reverse polish notation is actually easy, it's just like the plate stacker in the diner, if you ever had to bus tables. Its no harder than infix notation, but it is different.
Google Leo Brodie and you can find the free PDF's for "Starting Forth" and "Thinking Forth". These predate the "for dummies" series if I remember. These were the starting texts for almost everyone except Charles Moore.
All this talk of Forth has made me nostalgic. Back in the second half of the 80s I wrote the first commercial MIDI voice librarian program for DOS. It was all in Forth. I haven't had time to explore Propforth yet, but this has got me to install gforth on my Mac and play around with it a little.
Comments
I added control(PWM) for brightness&contrast to 3-wire_LCDcircuit.
I found out strange.
Executing WORD"set_bright" on cog5 inside WORD"lcd_init". It takes 6mseconds to get cog number. Not good on 5mseconds.
Is this normal?
Sal is starting examples on PWM for servo and stepper motor control. There may be some impact from the timing alternative used, I haven't played with it yet. Also, I don't have an LCD test rig set up.
Sal doesn't usually read the forum, please gmail him directly.
Sorry my citation went totally wrong, i guess.
Best Regards
Markus
Maybe i will send another PM
But no pulse.
What is wrong?
fl : variable lockdict create $C_a_dovarl w, 0 l, forthentry freedict ; 0 wconstant _clk 153 asmlabel a_pulse_out 14F wconstant v_clk lockdict variable def_014F 015A l, 014F l, 0 l, A0FE1B00 l, E4FE1B51 l, 5C7C0000 l, 68BFE94F l, 5CFEA552 l, 64BFE94F l, 5CFEA552 l, E4FE1153 l, 5CFDF0F1 l, 5C7C0075 l, freedict 1 _clk lshift constant _clkm : _clk_out _clk pinout ; \ : _clk_out_l _clkm _maskoutlo ; \ : _clk_out_h _clkm _maskouthi ; : test _clkm v_clk COG! v_clk COG@ . _clk_out begin 1000 a_pulse_out drop 0 until ; { fl :asm v_clk 0 __delay mov _treg5 , # 100 __C djnz _treg5 , # __C __delayret ret a_pulse_out __1 or outa , v_clk jmpret __delayret , # __delay andn outa , v_clk jmpret __delayret , # __delay djnz _sttos , # __1 spop jnext ;asm }There is "_clk_out" inside WORD"test.
Regards
Markus
After uploaded ipg, I'm aware spell mistake too.
lockdict variable def_014F 015A l, 014F l, 0 l, A0FE1B00 l, E4FE1B51 l, 5C7C0000 l, 68BFE94F l, [COLOR="red"]5CFEA552[/COLOR] l, 64BFE94F l, [COLOR="red"]5CFEA552[/COLOR] l, E4FE1153 l, 5CFDF0F1 l, 5C7C0075 l, { fl :asm v_clk 0 __delay mov _treg5 , # 100 __C djnz _treg5 , # __C __delayret ret a_pulse_out __1 or outa , v_clk [COLOR="red"]jmpret __delayret , # __delay[/COLOR] andn outa , v_clk [COLOR="red"]jmpret __delayret , # __delay[/COLOR] djnz _sttos , # __1 spop jnext ;asm }The encoding for those two jmprets is wrong. The hex value represents a jmpret __delayret, #__delayret, i.e. src and dst fields are the same ($2A552 = %101010010_101010010). As the ret starts out as a jmp #0 this is likely to go wrong. I assume there is some 3rd party assembly involved so that's the first place I'd look for the address mismatch. FWIW, $5CFEA550 would be the correct value.Sal gave me advice.
Mistake is no "def_014F lasm" and incorrect label-name"__delay __delayret".
Correct code is below;
fl : variable lockdict create $C_a_dovarl w, 0 l, forthentry freedict ; : aallot coghere W+! coghere W@ par >= if 8005 ERR then ; : cog, coghere W@ COG! 1 aallot ; : lasm 4+ dup L@ swap 4+ swap over L@ dup coghere W! do 4+ dup L@ cog, loop drop ; 0 wconstant _clk 153 asmlabel a_pulse_out 14F wconstant v_clk lockdict variable def_014F 015A l, 014F l, 0 l, A0FE1B00 l, E4FE1B51 l, 5C7C0000 l, 68BFE94F l, 5CFEA550 l, 64BFE94F l, 5CFEA550 l, E4FE1153 l, 5CFDF0F1 l, 5C7C0075 l, freedict 1 _clk lshift constant _clkm : _clk_out _clk pinout ; \ : _clk_out_l _clkm _maskoutlo ; \ : _clk_out_h _clkm _maskouthi ; : test def_014F lasm _clkm v_clk COG! v_clk COG@ . _clk_out begin 1000 a_pulse_out 0 until ; { fl :asm v_clk 0 __Ddelay mov _treg5 , # 100 __C djnz _treg5 , # __C __Edelayret ret a_pulse_out __1 or outa , v_clk jmpret __Edelayret , # __Ddelay andn outa , v_clk jmpret __Edelayret , # __Ddelay djnz _sttos , # __1 spop jnext ;asm }Loading
1 2-wire_LCD_1.0.f
2 extra_LCD_1.0.f (Control for brightness&Contrast)
3 LCD_demo.f
I check display-time(not including lcd_init) by demo2(moving Wave).
Normal driver(E RS D4-D7:6-wire) 10.7sec(32E845F0ticks)
3-wire LCD driver(latch clk data:3-wire) 17.9sec(5596AC70ticks)
2-wire LCD driver(latch clk :2-wire) 8.7sec(2985D9A0ticks)
I modified Dynamic Drive 7SEG-LED driver by using 3-wires.
There is dd-LEDcircuit at #113 in this thread.
Display cannot do at 1093Hz.
When digits(inside 3-wire_dd7SEG) is 2 (Hardware is 3-digits), third digit may display number.
Because this is pullup to 3.3V on SRCLR.
I updated 2-wire_LCD.
Searching free cog for controlling LCD's contrast & brightnes.
Displaying ROM-font on 16x16DotMatrix(2pcs).
I did SPI-communication between protoboard(forth_master_0.1.f) and demoboard(slave_SPI_0.1.spin).
This is very slow since using forth-word and SPIN.
I think assembler need.
Connected resistor(220ohm) on pins between protoboard and demoboard.
Loaded forth_master_0.1 on protoboard.
Loaded slave_SPI_0.1to ram or eeprom on demoboard.
Executed WORD"demo" on protoboard.
Last indication was a hardware issue. Can we confirm that this is the case?
Otherwise we will consider this issue closed until more information is available.
Nice work! I'll try and set this up and do some tests, but it will have to wait till after testing on Sal's new servo control code is finished.
My comment on this is to mention the convention for "print words".
The tradition is to designate words that print character to the display by prefixing them with a period. So the "traditional" form for your words would be to change:
to:
Could you recommend any good forth tutorials? I have very little experience with forth, to the point of being almost a noob in the area of the Forth language.
Google Leo Brodie. PM me if you have specific questions. Once I get started, I can go on and on, its best not to babble in public.
All versions of propforth will run on any prop chip. There are some configurations that look for specific hardware, for example the JupiterACE configuation expects the demobpard pinout for VGA and keyboard, and the Hive configuration expects the Hive pinout for VGA and keyboard.
The EEPROM filesystem expects a 64k EEPROM, which I belive is on all prop boards EXCEPT the demoboard, but you don't have to load it, and if you do load, you don;t have to execute those words. (Don't ask me why, but folks do this. OK ask me why, I'll tell you: they want to see if it breaks)
I usually use the demoboard when I use VGA, and I usually DON'T use the EEPROM file system on the other boards, except in testing.
I usually load working code into RAM and do a saveforth, which over-writes the low 32K EEPROM with the current dictionary.
I load code under test into a freshly booted prop which has my working code saveforth'd.
Version 4.0 is the lastest release from the author, the 4.0a version was an attempt by me to better organize, but this attempt had limited success.
Next version targeted is version 4.5 next month which will have spineret specific functionality: Ethernet, telnet server, HTML5 server, forth execution in HTML pages, Time over internet. Also may have RAW SD support, block access, FAT comaptibility NOT implemented.
Final development version (may be) verison 5 in august, with support for minimum permanent kernal (about 4k?), on the fly compilation from SD, and auto-forget, to allow unlimited application and data size (with a 32k max size at any given time, of course).
a) loaded the .spin file into eeprom
b) loded PropForthCore.f via Tera Term
c) ran saveforth
Where does that leave me? I'm guessing with a minimal system? Do I need anything else to work with the demo board?
Also, how do I view the Prop and Version info? I tried running the commands, but I must be missing something.
Thanks.
The comments in the readme are supposed to indicate that the spin file is just the minimal system.
PropForthxxx.f addes various development extensions. ONE file is for recreatingthe minimmal kernel, the other is for development.
If you did it correctly, when you type "words" your should get a display of all the words, thefunctions present in the dictionaqry.
Now you can access any functionality of the prop hardware using the command line. The most commlonly used are defined as FROTH words, the less commonly used are accessed thru assembler.
Try to follow the examples, at one time they were sufficient; PM me if you find errors and I will make correction.
Also try the Brodie books, the PC oriented material needs modification, but the basic material should still be the same.
A simple idea:
2 cogstop
4 5 9600 2 startserialcog
c" teststring sending " 2 cogx
\this works fine
\now i will try to send a break on TxD
4 pinlo
2 delms
4 pinhi
seems not to work, because the serilacog seems to stuck port 4
The most clean way would be , to realize it in the serial driver stuff, i think. Any ideas
Markus
(i have cross posted this question in the German Hive forum)
I have idea.
But I don't test it.
This code might be wrong.
: break_out io 2+ W@ swap cogio io 2+ W! cnt COG@ begin 0 cr dup cnt COG@ swap 27100 > / wait 2msec if drop 1 else 0 then until io 2+ W! ; 2 break_out \ send 2msec-break to cog2's serialSorry, I had misunderstanding break-signal.
Break-signal don't has start-bit/stop-bit. Still low.
I think above code send 0x00.
My idea:
1 stop serial on cog2
2 pin4 to low
3 wait 2msec
4 start serial on cog2
if a special sign (now ASCI 7C) is handled a 32bit high signal is clocked out.
I would like to take another AsCI code like $00 but i dpn't understand how to
make something like
4 5 9600 2 startserialcog
c" $00 " 2 cogx
the 2nd line didn't work (its sending $ 0 0 ).
Any idea how to make string out of any ASCII character(s) ?
Markus
P.S. I will post my code tomorrow
The construct is the text handling mechanism
The construct is for outputing numerical values off the stack
Did you try:
I didn't check, but I think that
" 7 emit 0 emit 4F emit 4B emit "
gets put into cog 2's input buffer, andit executes just as if you typed it from the command line.
The Polish notation is a bit quirky...be hard to get used
to it I imagine. Is there a free Forth book for idiots somewhere?
Two and two, multiply.... four you will have!
The documentation on google docs is weak since I haven't gotten a lot of feedback. If you see anything the needs fixing let me know.
The reverse polish notation is actually easy, it's just like the plate stacker in the diner, if you ever had to bus tables. Its no harder than infix notation, but it is different.
Google Leo Brodie and you can find the free PDF's for "Starting Forth" and "Thinking Forth". These predate the "for dummies" series if I remember. These were the starting texts for almost everyone except Charles Moore.
Starting Forth is the bible for Forth beginners. It is available online at http://www.forth.com/starting-forth but I haven't been able to find a PDF version. There is a PDF version of Thinking Forth at http://prdownloads.sourceforge.net/thinking-forth/thinking-forth-color.pdf?download. Thinking Forth isn't so much a Forth beginner's book as a general programming practices book using Forth for examples. It's a great book, but Starting Forth is the one to start with.
All this talk of Forth has made me nostalgic. Back in the second half of the 80s I wrote the first commercial MIDI voice librarian program for DOS. It was all in Forth. I haven't had time to explore Propforth yet, but this has got me to install gforth on my Mac and play around with it a little.