Sal completed enough investigation of the P1V on BeMicro Cyclone V to come to some decisions on how to move forward.
The PF6 build automation worked fine on the FPGA, as expected; all we have to do is document it, as before.
Here's whats different: The FPGA changes things. Originally, SpinFORTH was an attempt to take advantage of forth and SPIN at the same time. It turns out, there isn't enough room and we have to choose one or the other. But we used SPIN in the build process, as the SPIN tools exist and are very stable. So we used FORTH to generate inittial SPIN files when rebuilding the kernel; rather than directly use FORTH to generate a new FORTH kernel.
Now, we can change the design of the prop chip itself. The video drivers, the counters, ROM tables and a couple other things went unused in the PropFORTH environment. We generally only use the Prop to bit bang and preprocess/prefilter datastreams, really fast. We use android devices for user interface, and external processing where it is needed. So Sal has removed the video drivers, unused counters, ROM tables, SPIN, and other things; and increased the clock speed (160Mhz), added more cores (16) RAM 128k, i/o (how ever many are on the board) and is making a PropFORTH only CPU on FPGA. The FPGA chip is still compatible with the physical chip. That is, PropFORTH 6 will also run on the physical chip, just slower due to the lower clock and smaller memory. PropFORTH 6 on the FPGA will include a dummy call to SPIN, which just loads FORTH on the physical chip. But, PropFORTH will now generate the new forth kernel directly, as normally done in forth systems. We shouldn't need SPIN or SPIN tools at all (unless some new person is starting out with a physical chip).
So the new direction is a FORTH-only CPU architecture on FPGA. This is kind of (what I imagined to be) the original idea Chuck Moore had, before he did the GA144. The difference is PropFORTH is for bit banging, low level stuff; not large systems. If we want a database or user interface, we would not do it in FORTH, we would use any existing solution, like LINUX or Android, depending on the need.
Sal obtained some smaller FPGA's, and some larger FPGA's. The idea is to demonstrate that the FORTH CPU architecture is scalable, and we can add what ever peripherals we need using FPGA logic. We can even get an ARM core on the same FPGA, and have our (non-deterministic) LINUX node on the same chip, with no impact to our deterministic execution in the FORTH application.
Every additional minute spent in planning saves between a day and a week of fixing stuff due to insufficient planning.
The Propforth5.5 material on google http://code.google.com/p/propforth/ will be left intact. Its kind of a mess, and we don't have bandwidth or energy to clean it up at this point. But it is complete, so we'll leave this be until such time as we have a reason to do otherwise.
This week, Sal will endeavor to release PropForth 6 and the build automation for Prop 1 physical chip and P1V FPGA.
PropForth 6 will be on a hosted DOKU-WIKI https://www.dokuwiki.org/dokuwiki
The doku wiki pages are already drafted, we just have go over them and ensure the instructions are complete before they are made public.
PropForth 6 will no longer use SPIN. When generating a new kernel, Propforth 6 will produce a binary image, just as most forths tend to do. The primary kernel will contain only the functions required for the kernel itself. Any additional Prop 1 features (video gnerator, counters, timers, ROM tables, etc) can be added as extensions, but will not included in the primary kernel to save space, since they are seldom used (by us) in propforth applications.
We will use the new tools (propeller loader) in prop GCC to load our binary image the first time. After a virgin prop is loaded with propforth, we should never have to load it again. (Unless we do something fun and completely trash the image, which can happen but is generally rare.
So releasing propforth 6 is the next milestone. Afterwards, we will move towards a stand-alone build system using DIR505/Raspberry Pi plus prop board. This will be our model for future projects, where the prop handles the realtime/deterministic execution portion, and the linux node handles the crunching/workstation services.
We breifly discussed Inertial Measurement Unit and Kalman filter. Turns out that while we could do Kalman using fixed point math on the prop, it would be a bunch of work; and would be expensive in terms of computing time, even using the faster clock and larger memory of the P1V FPGA. Another option would be to do the Kalman in float on the RPi (read the sensor and do some pre-processing on the prop, and stream the data to the RPi for the actual Kalman's float and matrix operations). The fastest option might be to do the whole thing on the FPGA, and do optionized float in hardware on the FPGA. This last part is WAY out of my league at the moment, but Sal will look at it as a PF6 FPGA demo when we get to that point, if I can get my head around it between now and then.
Thats pretty cool! How much memory does this consume, how much do you have left? It looks quite compact based on counting the L, in the assembler loading word.
What about a goload to load binary files to the propeller, I put some pieces together in January and have not looked at it since. I have thought it could be combined together with goterm, so it would be one program. Maybe Sal could do that? Interested? As I remember it runs at 19200 to 115200 baud. I could not get it to work on raspi, go uses all power, but on odroid and my pc it go well.
I am now converting some propforth v5.5 programs to v6.0.
HalfDuplexSerial code(assembler) modified Sal's original code.
Anybody use this?
I have questions.
I tried to print reverse-mode,updown-mode,emphasized-mode,deleteline-mode by charactercommant[ESC_ !].
But font don't change.
Not also bold font by [ESC E].
Also cannot receive printer-status.
ThermalPrinter don't transmit signal(checked by oscilloscope), although I transmit command[ESC v].
Not yet operate reverse printing mode.
I checked code(hdserialRx/hdserialTx). These operate finely.
Cannot get printer status[ESC v].
It should send [ESC v]. but printer don't reply.
I have no idea.
FontB are printing under testprintmode.
But I don't know how to print these fonts.
Hi.
I try to do MAX3421E(as host) again.
It can read file-descriptor for low-speed-device.
But it cannot read any for full-speed-device.
It occur error(HRSL=h8D hrJERR) at issuing setup token.
Log indicate messages USB-camera and USB-mouse.
These don't use 'interrupt'procedure.
USB-mouse works fine.
---- USB camera ----
Prop0 Cog6 ok
usb
ST: 0000_0001
18 Waiting for device connect
HRSL:83 Full-Speed Device Detected
HIRQ 58 C9
HIEN:30 HIRQ:48 a a a a a a a a a a waitframe1 48
Issuing USB bus reset
end69 a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a waitframe1 69 <--HIRQ
69 waitframe finished
First 8 bytes of Device Descriptor
HRSL8D 69 >>>>> Error >>>>>
No response J-status
Prop0 Cog6 ok
---- USB mouse ----
Prop0 Cog6 ok
usb
ST: 0000_0001
8 Waiting for device connect
HRSL:43 Low-Speed Device Detected
HIRQ 4A CB
HIEN:30 HIRQ:48 a a a a a a a a a a waitframe1 48
Issuing USB bus reset
end69 a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a waitframe1 69 <--HIRQ
69 waitframe finished
First 8 bytes of Device Descriptor
HRSL80 HRSL80 HRSL90 69 Issuing USB bus reset
end69 a a a a a a a a a a waitframe1 69
Setting address to 0x07
HRSL90 HRSL90 69 a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a waitframe1 69
Device Descriptor ( HRSL90 HRSL80 HRSL90 HRSL80 HRSL90 69 0 NAKS )
Descriptor Size: 12
Descriptor Type: 1
USB version: 1.0
Device class: 0
Device subclass: 0
Device Protocol: 0
EP0 MaxPacketsize: 8
Vendor ID: 56E
Product ID: 3
Device release: 491
HRSL90 HRSL80 HRSL90 (Language ID String Descriptor is 4 3 9 4 )
Manufacture str index: 1 HRSL90 HRSL80 HRSL90 HRSL90 ELECOM
Product str index: 2 HRSL90 HRSL80 HRSL90 HRSL80 HRSL90 HRSL80 HRSL90 ELECOM USB Mouse
Serial number str index: 0
Number of Configuration: 1
Prop0 Cog6 ok
Both HIRQ indicate FRAMEIRQ and CONDETIRQ.
Next;
Commented out ["c" interupt" 0 cogx] in usb_desc_p1_0.1.
After displayed"Issuing USB bus reset", execution stopped.
For a while, error occured bacause timeout of "lock".
And then,HIRQ indicate SUSDNIRQ.
Thats really cool. I have been meaning to do the LED matrix as light sensor using the reverse bias thing, that would eliminate the phototransistor. Can you revers bias the LED's one by one via charlieplex, and have each detect the light from its neighbors? This would be a bit more complex, but it anybody can do, it would be you.
Comments
Thank you kuroneko-san.
n*(n-1) LEDs are controlled by n-wires.
http://youtu.be/KxE_FsZXEmU
Sal completed enough investigation of the P1V on BeMicro Cyclone V to come to some decisions on how to move forward.
The PF6 build automation worked fine on the FPGA, as expected; all we have to do is document it, as before.
Here's whats different: The FPGA changes things. Originally, SpinFORTH was an attempt to take advantage of forth and SPIN at the same time. It turns out, there isn't enough room and we have to choose one or the other. But we used SPIN in the build process, as the SPIN tools exist and are very stable. So we used FORTH to generate inittial SPIN files when rebuilding the kernel; rather than directly use FORTH to generate a new FORTH kernel.
Now, we can change the design of the prop chip itself. The video drivers, the counters, ROM tables and a couple other things went unused in the PropFORTH environment. We generally only use the Prop to bit bang and preprocess/prefilter datastreams, really fast. We use android devices for user interface, and external processing where it is needed. So Sal has removed the video drivers, unused counters, ROM tables, SPIN, and other things; and increased the clock speed (160Mhz), added more cores (16) RAM 128k, i/o (how ever many are on the board) and is making a PropFORTH only CPU on FPGA. The FPGA chip is still compatible with the physical chip. That is, PropFORTH 6 will also run on the physical chip, just slower due to the lower clock and smaller memory. PropFORTH 6 on the FPGA will include a dummy call to SPIN, which just loads FORTH on the physical chip. But, PropFORTH will now generate the new forth kernel directly, as normally done in forth systems. We shouldn't need SPIN or SPIN tools at all (unless some new person is starting out with a physical chip).
So the new direction is a FORTH-only CPU architecture on FPGA. This is kind of (what I imagined to be) the original idea Chuck Moore had, before he did the GA144. The difference is PropFORTH is for bit banging, low level stuff; not large systems. If we want a database or user interface, we would not do it in FORTH, we would use any existing solution, like LINUX or Android, depending on the need.
Sal obtained some smaller FPGA's, and some larger FPGA's. The idea is to demonstrate that the FORTH CPU architecture is scalable, and we can add what ever peripherals we need using FPGA logic. We can even get an ARM core on the same FPGA, and have our (non-deterministic) LINUX node on the same chip, with no impact to our deterministic execution in the FORTH application.
PropFORTH 6 is shaping up to be interesting.
Every additional minute spent in planning saves between a day and a week of fixing stuff due to insufficient planning.
The Propforth5.5 material on google http://code.google.com/p/propforth/ will be left intact. Its kind of a mess, and we don't have bandwidth or energy to clean it up at this point. But it is complete, so we'll leave this be until such time as we have a reason to do otherwise.
This week, Sal will endeavor to release PropForth 6 and the build automation for Prop 1 physical chip and P1V FPGA.
PropForth 6 will be on a hosted DOKU-WIKI https://www.dokuwiki.org/dokuwiki
The doku wiki pages are already drafted, we just have go over them and ensure the instructions are complete before they are made public.
PropForth 6 will no longer use SPIN. When generating a new kernel, Propforth 6 will produce a binary image, just as most forths tend to do. The primary kernel will contain only the functions required for the kernel itself. Any additional Prop 1 features (video gnerator, counters, timers, ROM tables, etc) can be added as extensions, but will not included in the primary kernel to save space, since they are seldom used (by us) in propforth applications.
We will use the new tools (propeller loader) in prop GCC to load our binary image the first time. After a virgin prop is loaded with propforth, we should never have to load it again. (Unless we do something fun and completely trash the image, which can happen but is generally rare.
So releasing propforth 6 is the next milestone. Afterwards, we will move towards a stand-alone build system using DIR505/Raspberry Pi plus prop board. This will be our model for future projects, where the prop handles the realtime/deterministic execution portion, and the linux node handles the crunching/workstation services.
We breifly discussed Inertial Measurement Unit and Kalman filter. Turns out that while we could do Kalman using fixed point math on the prop, it would be a bunch of work; and would be expensive in terms of computing time, even using the faster clock and larger memory of the P1V FPGA. Another option would be to do the Kalman in float on the RPi (read the sensor and do some pre-processing on the prop, and stream the data to the RPi for the actual Kalman's float and matrix operations). The fastest option might be to do the whole thing on the FPGA, and do optionized float in hardware on the FPGA. This last part is WAY out of my league at the moment, but Sal will look at it as a PF6 FPGA demo when we get to that point, if I can get my head around it between now and then.
Thats pretty cool! How much memory does this consume, how much do you have left? It looks quite compact based on counting the L, in the assembler loading word.
I am now converting some propforth v5.5 programs to v6.0.
I bought ThermalPrinter(ID597 or COM10438).
https://learn.adafruit.com/mini-thermal-receipt-printer
https://www.sparkfun.com/products/10438
HalfDuplexSerial code(assembler) modified Sal's original code.
Anybody use this?
I have questions.
I tried to print reverse-mode,updown-mode,emphasized-mode,deleteline-mode by charactercommant[ESC_ !].
But font don't change.
Not also bold font by [ESC E].
Also cannot receive printer-status.
ThermalPrinter don't transmit signal(checked by oscilloscope), although I transmit command[ESC v].
Are there advises?
http://youtu.be/Cxp9gquJxxc
When power to printer is 5V, Tx/Rx-pin(printer side) are 3.3V.
Maybe 3.3V(Tx/Rx) at 9V(power).
So level-shift don't need.
I have 2 manual.
These are a little bit different.
My printer's firmware is ver2.68.
Some command on manuals don't operate.
Not yet operate reverse printing mode.
I checked code(hdserialRx/hdserialTx). These operate finely.
Cannot get printer status[ESC v].
It should send [ESC v]. but printer don't reply.
I have no idea.
FontB are printing under testprintmode.
But I don't know how to print these fonts.
ESC ! n
About n;
bit0 1:small size character
bit1
bit2
bit3 1:emphasized mode
bit4 1:double Hight mode
bit5 1:double Width mode
bit6
bit7 1:Underline
My printer's firmware is ver2.68.
Other version might be different.
It can read printer status. But it seems to be not able to read values for Volt and Temperature.
How to display photo image on here?
This is simple game.
Drived 8x8DotMatrix by CharliePlexing_8x8Matrix.(Refering #520 in this thread)
[video]
[jpg]cimg4819.jpg[/jpg][photo]CIMG4819.jpg[/photo][photo]CIMG4819[/photo][photo]cimg4819.jpg[/photo]
[photo]cimg4819[/photo]
{img}CIMG4819.jpg{/img}{IMG}CIMG4819.jpg{/IMG}{IMG}CIMG4819{/IMG}{IMG}cimg4819.jpg{/IMG}
I try to do MAX3421E(as host) again.
It can read file-descriptor for low-speed-device.
But it cannot read any for full-speed-device.
It occur error(HRSL=h8D hrJERR) at issuing setup token.
Log indicate messages USB-camera and USB-mouse.
These don't use 'interrupt'procedure.
USB-mouse works fine.
Both HIRQ indicate FRAMEIRQ and CONDETIRQ.
Next;
Commented out ["c" interupt" 0 cogx] in usb_desc_p1_0.1.
After displayed"Issuing USB bus reset", execution stopped.
For a while, error occured bacause timeout of "lock".
And then,HIRQ indicate SUSDNIRQ.
I refered https://github.com/felis/USB_Host_Shield.
Someone operate MAX3421E as host?
Spin code also is ok although I don't have written it for a long time.
usb_desc_p1_0.1/usb_desc_p1_0.2 is shorted because of test.
This are commented ["c" interupt" 0 cogx]
H/W is same as SimpleGame(#526).
Only measuring 10seconds by pushing bottun.
You measure 10seconds by yourself.
If exceeding 15seconds, matrix display "---".
If time is not between 9seconds and 11seconds, matrix display "-".
Time is "9.000sec" to "11.000sec".
Sometimes start-up-sound disappear.
I have no idea yet.
[video]
https://www.youtube.com/watch?v=95LGS90BIB0
https://www.youtube.com/watch?v=fi1RGJZvBlk
[video]
[video]
Contained switch and photoTransistor into ballpen.
[video]
[video]
This use 1024bytes as buffer.
But "fl" can't get 1024bytes.
Executed by manual before loading LCD(128x64)_0.1
[video]
http://www.amazon.co.uk/Camera-Platform-Mount-Tower-Servos/dp/B00BUCSCE8
[video]
Display use St7565S(128x64)_0.2
1(on display) is pwm for rotate-SG90.
2(on display) is pwm for up-down-SG90.
Sorry, unit[ms] on LCD is mistake.
unit is [us].
This doesn't move smoothly because angle(sum for angle-velocity) is not good and servo response is bad.
Maybe accceleration sensor and floating calculation and brushless-motor are needed.
[video]
I updated 2_wire_LCD_0.3.
Diode type in 2_wire_LCD's curcuit is silicon.