I tried to operate GP2Y0E03(i2c device).
Value is proportional to actual distance.
Distance value
50mm 87 [87*(150/257)=50.77]
100mm 170 [170*(150/257)=99.22]
150mm 257 [257*(150/257)=150]
I expected directly getting value of distance.
I tried to operate GP2Y0E03(i2c device).
Anyone has used this device?
I didn't run across this one yet, but it looks pretty cool! Did you get it new or surplus in someplace like Akihabara? I have had surplus parts that were surplus because they test marginal to begin with. (BMP085 for one)
It looks like it does triangulation, so it would be very sensitive to the angle of the target. It would be most accurate aimed directly at the closest point of a flat wall, but any other point could give very different measurements. Also, it might not be completely linear due to aberration in the lens, etc.
I noticed that even the SF02 laser can give a wide range of readings when the target is "noisey" that is some points are closer and some points are farther, I.E. an angled surface or a round surface. If this is the effect in play you might get the best consistent measurements when the target is orthogonal to the sensor.
There is below in page16 on gp2y0e.pdf.
register0x5E Distance[11:4]
register0x5F Distance[3:0]
Distance value=(Distance[11:4]X16 + Distance[3:0])/16/2^n
n:shiftbit(register0x35)
When distance is 5cm, register0x5E=h15 register0x5F=h0C
I merely used 150/257 for calculation.
About current;
VIO's current is thorogh Tr(2SA1015:max150mA).
On manual, average supply curent is 36mA.
But I try to be able to flow more current to VIO.
Sorry, it's only calculation mistake.
I upload code lator.
Hi.
I drawed ImageSensor's element[220pcs] by using Processing2.2.1.
(Instead of ImageSensor_2_3.pde, ImageSensor_2_3.zip attached)
Processing code is poor because this is my first code.
1. Executing word"draw_ImageSensor" in GP2Y0E03_0.2.2.f.
2. Executing "ImageSensor_2_3.pde" for Processong.
3. After opening window, click mouse on its window.
4. Drawed graph
Graph's vertical is reflected light intensity, horizontal is element number.
When getting this graph, distance is 50mm.
There is bug in "serial" on PropForth5.5.
"1 5 serialsetflag" shoud not add hA when hD send.
But hA is sended.
So hD replaced to hC in word"draw_ImageSensor".
I/F curcuit diagram in GP2Y0E03_0.2.2 was wrong.
I will upload correct curcuit lator.
we get fewer requests for window recently since the end of XP.
On linux, (ubuntu, mint) we test with minicom and picocom as these are built - in or easy to install. Linux is usually very reliable, and free. It seems folks are moving to linux.
1.Executed Word"draw_ImageSensor" in GP2Y0E03_0.2.4.f
2.Executed ImageSensor2_4_2.pde in ImageSensor_2_4_2.zip
3.Mouseclick on window of ImageSensor2_4_2
4.Drawed like ImageSensor.JPG
When distance between sensor and wall changes, position of wavepeak and distance and intensity change
5.When hitting any key under active window for ImageSensor2_4_2, word"draw_ImageSensor" stop.
Communication between forth and processing
1.ImageSensor2_4_2 send d65 to Forth
2.When word"draw_ImageSensor" received d65, it send sensordata(660pcs) and distance(2pcs) to processing
3. Processing draw graph and distance-data and intensity-data
4. Repeat 1-3
5.When clicking mouse on window of ImageSensor2_4_2 , processing send d66 to forth
6.When word"draw_ImageSensor" receive d66, it break begin-loop
But sometimes it seems to remain data[d66] in receive-buffer.
I have no idea.
The plan for propforth development using the DIR 505 wireless router as linux node is being re-adjusted due to events.
Previously, we had planned move the build and test automation to the DIR 505 to add wifi and linux for minimal cost. We got as far as start the effort to establish a set of instructions such that every user could reproduce the same build environment (test rig hardware). Turns out everybody has a slightly different PC, with slightly different software (ubuntu LTS vs windows, etc), and any given rig need not have the same result. This causes an issue if we ever have to re-burn firmware in the DIR 505 (if something goes wrong which can happen), the steps can be fiddley. We got as far as setting up a virtual machine using virtual box. It looks prety good, really we just have to clean things up a bit.
The adjustments are due to the P1V prop in FPGA activity. Sal is interested in tweaking the prop. It turns out that the propforth build automation might also be useful as a regression test for general use, if a modified P1V version can build and run proforth, it is likely still compatible with the physical prop chip. Of cource, propfortth does not use EVERY prop instructiion, but additional ttest scripts can be added to include any set of instructuions and tests. Sal plans to re-factor the buld and test automationso that it:
1) runs on the most general hardware
2) has the least commands to kick of a test run
3) is easier to add new test scripts (for any set of user functions or tests for additional prop opcodes, etc).
The P1V FPGA regression test suite is getting inserted in the front of the plan. The DIR505 and eventually PF6 are still going to happen, but they will also be compatible witht he FPGA testing.
Eventually the plan may include a larger prop with more cores and more RAM, but that hardware is more expenseive and can wait till after we see results from current efforts.
Sal and I have our BEscope development kits (Altera Cyclone V + oscilliscope module for $62).
The current milestone is to set up the P1V so we can switch between the physical prop and the virtual prop, and run the same propforth build automation.
And the goal of this is to automatically test if the P1V is identical to the physical prop.
Our target is to have a "one click execution" of the build and test automation, so anybody can use this test environment without having to do anything with propforth. Just launch the suite of scripts, and check the results log, and bob's your uncle.
For the above to work, we have to have exact setup instructions, so anyone can have the exact setup that we have.
As before, we are setting up an ubuntu 14.04.1 virtual machine and loading the FPGA development and propforth build automation environments. One rig is a Window 8 box and the other is a Linux box; theoretically the smae virtual machine should run identically on both.
As of this morning, we are at 'download software from Altera'. Its a bit slow, but we are in no hurry since we have no deadline at this point. After the downloads complete we'll continue next week.
Neither of us have used FPGA this century, so we don't expect to progress quickly.
If anybody is following along and wishes to keep pace during development, PM me and I'll share details.
We have most of our documentation to set up the BEMicro, we've loaded the P1V image to FPGA, and load the propforth Devkernel.spin. Sal has the simulated prop running at 160Mhz. He removed some unused (by us) functions such as the video generator and ROM tables; and logic element usage is about 49%. Sal guestimates that we can have two props with 64k RAM each. So we are looking at 16 cores and 128k RAM. The thought is to further optimize logic element usage, and implement any required peripherals in FPGA. Ideally, we will boot on powerup to the Propforth devkernel. If we need a fast peripheral, (SD, USB, fast serial with protocol, ADC, etc) since we can implement theses in FPGA, we no longer need to consume dictionary space for the custom kernels.
We'll know more next week, but we're hoping for 16 cores, 160Mhz, 128k RAM, Propforth 5.5 devkerenl.spin running on powerup, and publishable instructions for BEmicro next week or so.
Next step will be the build and test automation (to demonstrate that the simulated prop runs identically to the physical prop).
When all this is complete we will return to the Propforth 6 release. The PF6 kernel (the multitasking pool) has been running stable for about a year. Sal should be be ready to release it when the test environment is released.
Sal made an FPGA P1V for propforth. We drafted the build and load steps, it also works on my machine.
It has 8 cogs, runs at 160Mhz, and has 128k of RAM. So far the image load to RAM only, there is no EPROM at the moment, so saveforth doesn't do anything just yet.
The FPGA_prop removes the video generators, the ROM, and SPIN, and boots directly to propforth. WE have lots of extra room, and its really fast.
The standard serial driver appears to be very fast, and Sal has not been able to cause it to choke when compiling to the dictionary. So we shold be able to use standard serial and not have to worry about changing buffers, the fl word, or any of that stuff.
It looks like propforth 6 will be designed to run on physical prop 1 chips, and on the tweakable FPGA image. The FPGA prop will be just another tailored kernel.
The plan we drafted for FPGA will include the ability to all peripherals in FPGA. ADC, DAC, more cogs (up to 16 I think) more RAM (128 to start) etc.
Any code that loads and runs in 32k will run on either. Any code that needs more that 32k will fail at that point on the phyiscal prop. But it should work similar to the EEPROM on the Prop 1, in that we can WRITE to whate every address we want, but we can only read from addresses that exist.
So if our drivers fit in 32k we can run them on either. We can have 7 or 8 dedicated tasks in PF5.5 on the P1, or many on the FPGA. In PF6, we can have as many tasks as fit into 32k on the P1, and as many as fit into memory on the FPGA.
One thing about the FPGA prop, the prop chip design will be tweaked internally to run proforth faster. In addition to the faster clock speed, the way it gets and executes assembler for propforth will be much faster. The same code will run on the physical prop, just at normal speed.
Of course, this will take some time to document and test, on top of the development time. This is being added to the design for the PF6 build and test automation. The best guestimate is that this will take a while, and there will b changes along the way. But no calednar date can given at this time.
FPGA P1V for propforth is great.
This is not on DE0-nano?
The BEMicro board (Cyclon V) is only $50 and includes an oscilliscope module. The oscilliscope does not seem to work right out of the box, but its still cheaper than any other option I know of.
Be aware that the IDE for the FPGA is a sort of buggy and a bit more complex than it needs to be. If one is not already accustomed to FPGA,it might be best to wait until the instructions are complete. This should be a couple weeks or months. I would not have been able to start with FPGA on my own. But Sal's instructions will include every step, from setting out the PC to testing the tweaked image, and simple enough so that I can do it on my own.
Both should be same result. But both are not same.
Assemblerword"_8x8matrix_Charlie" has bug. I cannot find out what is wrong.
Any idea?
No time to build a circuit to test, sorry. BUT my thought is:
The forth word works, and the circuit works.
The assembler code should be the same as the forth word, but it behaves different than expected.
The first difference is speed. The assembler word should be much faster than the forth word.
The delay looks like 1 ms. I think the delay should be bigger, maybe 20ms?
The slower forth words execution might be supplying the extra time to leave the LED lit.
Of course, this is just a guess. Can you check the LED pulse with oscilliscope?
I modified curcuit.
Removed P8-line.
Drived 8x8DotMatrix by 8-wires.
Code also become to simple because 8-wires.
So moving characters on 8x8Matrix can operate on Forth-word.
Charlieplexing_8x8Matrix_0.1_1 need assembler-word to move characters on 8x8Matrix.
Don't know the specifics of the forth assembler but given that __1msec and __nn are labels, do you really need the #? I'd expect mov $C_treg1, __nn and mov $C_reg4, __1msec.
Comments
Displayed fonts of ROM-chip to Adafruit matrix16x64.
Refer #468 in this thread about ROM-chip.
It looks a little dark on YouTube, but actually very bright.
[video=youtube_share;VA-Y0YsTb40]
Value is proportional to actual distance.
Distance value
50mm 87 [87*(150/257)=50.77]
100mm 170 [170*(150/257)=99.22]
150mm 257 [257*(150/257)=150]
I expected directly getting value of distance.
Anyone has used this device?
Prop0 Cog6 ok PowerUp Prop0 Cog6 ok i2c_detect 0 1 2 3 4 5 6 7 8 9 A B C D E F 00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: 40 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- GP2Y0E03 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- eeprom on QS board 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- i2c_device:2 Prop0 Cog6 ok disp_rg Hold bit 01 Maximum Emitting Pulse Width 07 Spot Symmetry Thresgold 0E Signal Intensity Threshold 9E Maximum Spot Size Threshold 7F Minimum Spot Size Threshold 39 Shift Bit 02 Median Filter 30 SRAM Access 00 Distance[11:4] 5C Distance[3:0] 08 AE[15:8] 01 AE[7:0] 27 AG[7:0] 11 Cover Compensation[5:0] 00 Cover Compensation[10:6] 00 Cover Compensation Enable Bit 03 Read out ImageSensor data 00 Signal Accumlation Number 03 Enable Bit(Signal Intensity) 00 Enable Bit(Miniumum spot size) 00 Enable Bit(Maximum spot size) 01 Enable Bit(Spot symmetry) 00 E-Fuse Target Address 80 E-Fuse Bit Number 00 E-Fuse Program Enable Bit 00 E-Fuse Program Data 00 Active/StandBy State Control 00 Clock Select 7F Software Reset 07 Bank Select 00 Right Edge Coordinate(C) 80 Left Edge Coordinate(A) 46 Peak Coordinate(B) 64 Prop0 Cog6 ok PowerDn Prop0 Cog6 ok i2c_detect 0 1 2 3 4 5 6 7 8 9 A B C D E F 00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- eeprom on QS board 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- i2c_device:1 Prop0 Cog6 okI didn't run across this one yet, but it looks pretty cool! Did you get it new or surplus in someplace like Akihabara? I have had surplus parts that were surplus because they test marginal to begin with. (BMP085 for one)
It looks like it does triangulation, so it would be very sensitive to the angle of the target. It would be most accurate aimed directly at the closest point of a flat wall, but any other point could give very different measurements. Also, it might not be completely linear due to aberration in the lens, etc.
I noticed that even the SF02 laser can give a wide range of readings when the target is "noisey" that is some points are closer and some points are farther, I.E. an angled surface or a round surface. If this is the effect in play you might get the best consistent measurements when the target is orthogonal to the sensor.
I brought GY2Y0E03 on netshop(this has real shop in Akihabara).
It also can buy at Digi-key.
http://www.digikey.com/product-detail/en/GP2Y0E03/425-2856-ND/4103766
I need to finish some project before I buy new parts.
I don't understand the 150/257. Did I miss this in the datasheet? I thought the reading should be the distance in mm.
Of course you checked the voltage and the current? and the reflectivity of the target? I don't have many ideas.
register0x5E Distance[11:4]
register0x5F Distance[3:0]
Distance value=(Distance[11:4]X16 + Distance[3:0])/16/2^n
n:shiftbit(register0x35)
When distance is 5cm, register0x5E=h15 register0x5F=h0C
I merely used 150/257 for calculation.
About current;
VIO's current is thorogh Tr(2SA1015:max150mA).
On manual, average supply curent is 36mA.
But I try to be able to flow more current to VIO.
Sorry, it's only calculation mistake.
I upload code lator.
I drawed ImageSensor's element[220pcs] by using Processing2.2.1.
(Instead of ImageSensor_2_3.pde, ImageSensor_2_3.zip attached)
Processing code is poor because this is my first code.
1. Executing word"draw_ImageSensor" in GP2Y0E03_0.2.2.f.
2. Executing "ImageSensor_2_3.pde" for Processong.
3. After opening window, click mouse on its window.
4. Drawed graph
Graph's vertical is reflected light intensity, horizontal is element number.
When getting this graph, distance is 50mm.
There is bug in "serial" on PropForth5.5.
"1 5 serialsetflag" shoud not add hA when hD send.
But hA is sended.
So hD replaced to hC in word"draw_ImageSensor".
I/F curcuit diagram in GP2Y0E03_0.2.2 was wrong.
I will upload correct curcuit lator.
Solved about serial bug.
Rededfined Word"serial".
Commented out only 2lines. Of course, serial on cog7 cannot define.
I hope bug-fix is next version.
BTW I bought "WireStrippingGauge".
It's veery useful.
If you have trouble about wiring on breadboard, this tool is helpful.
https://www.youtube.com/watch?v=tt5jpGTncLs
greeting peter
On windows, we usually test with teraterm, it is free and works well.
http://en.sourceforge.jp/projects/ttssh2/releases/
we get fewer requests for window recently since the end of XP.
On linux, (ubuntu, mint) we test with minicom and picocom as these are built - in or easy to install. Linux is usually very reliable, and free. It seems folks are moving to linux.
Updated forth-code & processing code.
1.Executed Word"draw_ImageSensor" in GP2Y0E03_0.2.4.f
2.Executed ImageSensor2_4_2.pde in ImageSensor_2_4_2.zip
3.Mouseclick on window of ImageSensor2_4_2
4.Drawed like ImageSensor.JPG
When distance between sensor and wall changes, position of wavepeak and distance and intensity change
5.When hitting any key under active window for ImageSensor2_4_2, word"draw_ImageSensor" stop.
Communication between forth and processing
1.ImageSensor2_4_2 send d65 to Forth
2.When word"draw_ImageSensor" received d65, it send sensordata(660pcs) and distance(2pcs) to processing
3. Processing draw graph and distance-data and intensity-data
4. Repeat 1-3
5.When clicking mouse on window of ImageSensor2_4_2 , processing send d66 to forth
6.When word"draw_ImageSensor" receive d66, it break begin-loop
But sometimes it seems to remain data[d66] in receive-buffer.
I have no idea.
The plan for propforth development using the DIR 505 wireless router as linux node is being re-adjusted due to events.
Previously, we had planned move the build and test automation to the DIR 505 to add wifi and linux for minimal cost. We got as far as start the effort to establish a set of instructions such that every user could reproduce the same build environment (test rig hardware). Turns out everybody has a slightly different PC, with slightly different software (ubuntu LTS vs windows, etc), and any given rig need not have the same result. This causes an issue if we ever have to re-burn firmware in the DIR 505 (if something goes wrong which can happen), the steps can be fiddley. We got as far as setting up a virtual machine using virtual box. It looks prety good, really we just have to clean things up a bit.
The adjustments are due to the P1V prop in FPGA activity. Sal is interested in tweaking the prop. It turns out that the propforth build automation might also be useful as a regression test for general use, if a modified P1V version can build and run proforth, it is likely still compatible with the physical prop chip. Of cource, propfortth does not use EVERY prop instructiion, but additional ttest scripts can be added to include any set of instructuions and tests. Sal plans to re-factor the buld and test automationso that it:
1) runs on the most general hardware
2) has the least commands to kick of a test run
3) is easier to add new test scripts (for any set of user functions or tests for additional prop opcodes, etc).
The P1V FPGA regression test suite is getting inserted in the front of the plan. The DIR505 and eventually PF6 are still going to happen, but they will also be compatible witht he FPGA testing.
We are starting with the BEMicro CV mentioned in this thread
http://forums.parallax.com/showthread.php/156989-BeScopeBundle-Tip-for-those-who-want-to-buy-an-FPGA-development-board?p=1287516&viewfull=1#post1287516
Eventually the plan may include a larger prop with more cores and more RAM, but that hardware is more expenseive and can wait till after we see results from current efforts.
Sal and I have our BEscope development kits (Altera Cyclone V + oscilliscope module for $62).
The current milestone is to set up the P1V so we can switch between the physical prop and the virtual prop, and run the same propforth build automation.
And the goal of this is to automatically test if the P1V is identical to the physical prop.
Our target is to have a "one click execution" of the build and test automation, so anybody can use this test environment without having to do anything with propforth. Just launch the suite of scripts, and check the results log, and bob's your uncle.
For the above to work, we have to have exact setup instructions, so anyone can have the exact setup that we have.
As before, we are setting up an ubuntu 14.04.1 virtual machine and loading the FPGA development and propforth build automation environments. One rig is a Window 8 box and the other is a Linux box; theoretically the smae virtual machine should run identically on both.
As of this morning, we are at 'download software from Altera'. Its a bit slow, but we are in no hurry since we have no deadline at this point. After the downloads complete we'll continue next week.
Neither of us have used FPGA this century, so we don't expect to progress quickly.
If anybody is following along and wishes to keep pace during development, PM me and I'll share details.
Used WS2812B(15pcs).
http://youtu.be/CcURj5M0DfQ
http://youtu.be/cENI-qbD2Sw
http://youtu.be/OuzG2KvJCUc
We have most of our documentation to set up the BEMicro, we've loaded the P1V image to FPGA, and load the propforth Devkernel.spin. Sal has the simulated prop running at 160Mhz. He removed some unused (by us) functions such as the video generator and ROM tables; and logic element usage is about 49%. Sal guestimates that we can have two props with 64k RAM each. So we are looking at 16 cores and 128k RAM. The thought is to further optimize logic element usage, and implement any required peripherals in FPGA. Ideally, we will boot on powerup to the Propforth devkernel. If we need a fast peripheral, (SD, USB, fast serial with protocol, ADC, etc) since we can implement theses in FPGA, we no longer need to consume dictionary space for the custom kernels.
We'll know more next week, but we're hoping for 16 cores, 160Mhz, 128k RAM, Propforth 5.5 devkerenl.spin running on powerup, and publishable instructions for BEmicro next week or so.
Next step will be the build and test automation (to demonstrate that the simulated prop runs identically to the physical prop).
When all this is complete we will return to the Propforth 6 release. The PF6 kernel (the multitasking pool) has been running stable for about a year. Sal should be be ready to release it when the test environment is released.
Displayed 7SEG-LEDS(8pcs) by 9 wires.
There is not demo because just experiment.
Just only word"check_7SEG".
This looks loike it doesn't follow the pattern:
digit4 outa=h20 d6 -- COMIt looks like it should be this:
digit4 outa=h20 d5 -- COMIs this a typo or do I understand incorrectly?In any case, this is cool, I been meaning to try this. Thanks for the experiment!
Sal made an FPGA P1V for propforth. We drafted the build and load steps, it also works on my machine.
It has 8 cogs, runs at 160Mhz, and has 128k of RAM. So far the image load to RAM only, there is no EPROM at the moment, so saveforth doesn't do anything just yet.
The FPGA_prop removes the video generators, the ROM, and SPIN, and boots directly to propforth. WE have lots of extra room, and its really fast.
The standard serial driver appears to be very fast, and Sal has not been able to cause it to choke when compiling to the dictionary. So we shold be able to use standard serial and not have to worry about changing buffers, the fl word, or any of that stuff.
It looks like propforth 6 will be designed to run on physical prop 1 chips, and on the tweakable FPGA image. The FPGA prop will be just another tailored kernel.
The plan we drafted for FPGA will include the ability to all peripherals in FPGA. ADC, DAC, more cogs (up to 16 I think) more RAM (128 to start) etc.
Any code that loads and runs in 32k will run on either. Any code that needs more that 32k will fail at that point on the phyiscal prop. But it should work similar to the EEPROM on the Prop 1, in that we can WRITE to whate every address we want, but we can only read from addresses that exist.
So if our drivers fit in 32k we can run them on either. We can have 7 or 8 dedicated tasks in PF5.5 on the P1, or many on the FPGA. In PF6, we can have as many tasks as fit into 32k on the P1, and as many as fit into memory on the FPGA.
One thing about the FPGA prop, the prop chip design will be tweaked internally to run proforth faster. In addition to the faster clock speed, the way it gets and executes assembler for propforth will be much faster. The same code will run on the physical prop, just at normal speed.
Of course, this will take some time to document and test, on top of the development time. This is being added to the design for the PF6 build and test automation. The best guestimate is that this will take a while, and there will b changes along the way. But no calednar date can given at this time.
You are correct.
digit4 outa=h20 d5 -- COM d6 -- a d7 -- b d0 -- c d1 -- d d2 -- e d3 -- f d4 -- g d8 -- dpFPGA P1V for propforth is great.
This is not on DE0-nano?
The BEMicro board (Cyclon V) is only $50 and includes an oscilliscope module. The oscilliscope does not seem to work right out of the box, but its still cheaper than any other option I know of.
Be aware that the IDE for the FPGA is a sort of buggy and a bit more complex than it needs to be. If one is not already accustomed to FPGA,it might be best to wait until the instructions are complete. This should be a couple weeks or months. I would not have been able to start with FPGA on my own. But Sal's instructions will include every step, from setting out the PC to testing the tweaked image, and simple enough so that I can do it on my own.
I did experiment for Charlieplexing about 8x8-Matrix-LED.
Forthword "matrix_test" operate well. Result is cimg4240.
But assemblerword "_8x8matrix_Charlie" don't operate.
This operation is same as Forthword "matrix_test". Result is cimg4241.
When data inside matrix are change, display don' change.
Both should be same result.
But both are not same.
Assemblerword"_8x8matrix_Charlie" has bug.
I cannot find out what is wrong.
Any idea?
No time to build a circuit to test, sorry. BUT my thought is:
The forth word works, and the circuit works.
The assembler code should be the same as the forth word, but it behaves different than expected.
The first difference is speed. The assembler word should be much faster than the forth word.
The delay looks like 1 ms. I think the delay should be bigger, maybe 20ms?
The slower forth words execution might be supplying the extra time to leave the LED lit.
Of course, this is just a guess. Can you check the LED pulse with oscilliscope?
Removed P8-line.
Drived 8x8DotMatrix by 8-wires.
Code also become to simple because 8-wires.
So moving characters on 8x8Matrix can operate on Forth-word.
Charlieplexing_8x8Matrix_0.1_1 need assembler-word to move characters on 8x8Matrix.
http://youtu.be/m1u-rLr_p6E
Word"test"
http://youtu.be/1nFGOhgb_dQ
I try to write 8x8DotMatrix(charlieplexing).
But not oprate.
I observed signal on P0 bu osciloscope.
It seems to work delay(1msec).
I tested only delay-code.
lockdict create delaytest forthentry $C_a_lxasm w, h121 h113 1- tuck - h9 lshift or here W@ alignl h10 lshift or l, z2WyP[W l, z2Wyxj1 l, z2WyxW1 l, z1SyZnR l, z2WyxW0 l, z1SyZnR l, z3[yP[L l, z1SV01X l, z2WyPvV l, z20iPyk l, z3ryPr0 l, z1SV000 l, zJY0 l, zFb l, freedict build_BootOpt :rasm mov $C_treg1 , # __nn mov dira , # 1 __1 mov outa , # 1 jmpret __delayret , # __delay mov outa , # 0 jmpret __delayret , # __delay djnz $C_treg1 , # __1 jexit __delay mov $C_treg4 , # __1msec add $C_treg4 , cnt waitcnt $C_treg4 , # 0 __delayret ret __1msec d80000 __nn d1000 ;asm delaytestThis should output pulse(Hi:1msec,Lo:1msec) during 2seconds.But no pulse.
Execution finish as soon as entering key.
This code is wrong?
I noticed your location changed to Markdorf. Interesting their Coat of Arms looks like the Hub of the Prop.
http://en.wikipedia.org/wiki/Markdorf