Shop OBEX P1 Docs P2 Docs Learn Events
Propforth v5.5 is available for download - Page 17 — Parallax Forums

Propforth v5.5 is available for download



  • caskazcaskaz Posts: 957
    edited 2014-07-01 23:22
    I connected Adafruit matrix16x32 2pcs.
    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.
  • caskazcaskaz Posts: 957
    edited 2014-07-07 05:22
    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.

    Anyone has used this device?

    Prop0 Cog6 ok
    Prop0 Cog6 ok
         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: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    Prop0 Cog6 ok
    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
    Prop0 Cog6 ok
         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: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    Prop0 Cog6 ok
  • prof_brainoprof_braino Posts: 4,313
    edited 2014-07-07 11:54
    caskaz wrote: »
    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.
  • caskazcaskaz Posts: 957
    edited 2014-07-07 16:45
    Hi prof_braino.

    I brought GY2Y0E03 on netshop(this has real shop in Akihabara).
    It also can buy at Digi-key.
  • prof_brainoprof_braino Posts: 4,313
    edited 2014-07-07 19:59
    I saw that at digikey, and almost bought it. Pretty nice for $8.
    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.
  • caskazcaskaz Posts: 957
    edited 2014-07-07 22:14
    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

    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.
  • caskazcaskaz Posts: 957
    edited 2014-07-28 07:58
    I drawed ImageSensor's element[220pcs] by using Processing2.2.1.
    (Instead of ImageSensor_2_3.pde, 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.
    306 x 327 - 12K
    640 x 480 - 144K
  • caskazcaskaz Posts: 957
    edited 2014-08-01 00:59

    Solved about serial bug.

    Rededfined Word"serial".
    Commented out only 2lines.
    : serial
    \ 0 io hC4 L!  <-- comment out
    \ 0 io hC8 L!  <-- comment out
    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.
  • funkheldfunkheld Posts: 32
    edited 2014-08-01 04:11
    hello, where there is a good terminal to the propforth well represent?

    greeting peter
  • prof_brainoprof_braino Posts: 4,313
    edited 2014-08-02 21:35
    funkheld wrote: »
    hello, where there is a good terminal to the propforth well represent?

    greeting peter

    On windows, we usually test with teraterm, it is free and works well.

    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.
  • caskazcaskaz Posts: 957
    edited 2014-08-03 00:34
    Updated forth-code & processing code.

    1.Executed Word"draw_ImageSensor" in GP2Y0E03_0.2.4.f
    2.Executed ImageSensor2_4_2.pde in
    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.
  • caskazcaskaz Posts: 957
    edited 2014-08-03 04:35
    Fixed bug about remaining data[d66] in receive-buffer.
  • prof_brainoprof_braino Posts: 4,313
    edited 2014-08-31 11:15
    Today's call

    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

    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.
  • prof_brainoprof_braino Posts: 4,313
    edited 2014-09-21 09:01
    Today's call

    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.
  • caskazcaskaz Posts: 957
    edited 2014-09-30 17:24
    Hi, I made 7segmentLED.
    Used WS2812B(15pcs).
  • caskazcaskaz Posts: 957
    edited 2014-10-03 22:55
  • prof_brainoprof_braino Posts: 4,313
    edited 2014-10-19 10:08
    today's call:

    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.
  • caskazcaskaz Posts: 957
    edited 2014-10-25 05:12
    I did experiment of Charlieplexing.
    Displayed 7SEG-LEDS(8pcs) by 9 wires.
    There is not demo because just experiment.
    Just only word"check_7SEG".
  • prof_brainoprof_braino Posts: 4,313
    edited 2014-10-26 09:52
    caskaz wrote: »
    I did experiment of Charlieplexing.
    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  -- COM

    It looks like it should be this:
    digit4  outa=h20
           d5  -- COM
    Is this a typo or do I understand incorrectly?

    In any case, this is cool, I been meaning to try this. Thanks for the experiment!
  • prof_brainoprof_braino Posts: 4,313
    edited 2014-10-26 10:22
    Todays Call.

    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.
  • caskazcaskaz Posts: 957
    edited 2014-10-26 15:55
    Hi prof_braino.
    You are correct.
                  digit4  outa=h20
           d5  -- COM
           d6  -- a
           d7  -- b
           d0  -- c
           d1  -- d
           d2  -- e
           d3  -- f
           d4  -- g
           d8  -- dp

    FPGA P1V for propforth is great.
    This is not on DE0-nano?
  • prof_brainoprof_braino Posts: 4,313
    edited 2014-10-27 09:17
    caskaz wrote: »
    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.
  • caskazcaskaz Posts: 957
    edited 2014-10-28 04:51
    I did experiment for Charlieplexing about 8x8-Matrix-LED.
    Forthword "matrix_test" operate well.
    Prop0 Cog6 ok
    Result is cimg4240.

    But assemblerword "_8x8matrix_Charlie" don't operate.
    This operation is same as Forthword "matrix_test".
    Prop0 Cog6 ok
    h08040201 matrix L!
    Prop0 Cog6 ok
    h80402010 matrix 4+ L!
    Prop0 Cog6 ok
    matrix _8x8matrix_Charlie
    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?
    640 x 480 - 189K
    640 x 480 - 185K
    1024 x 768 - 59K
  • prof_brainoprof_braino Posts: 4,313
    edited 2014-10-28 18:51
    caskaz wrote: »
    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?
  • caskazcaskaz Posts: 957
    edited 2014-10-29 08:01
    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.
  • caskazcaskaz Posts: 957
    edited 2014-10-30 06:40
    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,
    build_BootOpt :rasm
              mov       $C_treg1 , # __nn
              mov       dira , # 1
              mov       outa , # 1
              jmpret  __delayret , # __delay
              mov       outa , # 0
              jmpret  __delayret , # __delay
              djnz      $C_treg1 , # __1
              mov       $C_treg4 , # __1msec
    		add       $C_treg4 , cnt
              waitcnt   $C_treg4 , # 0                               
    ;asm delaytest
    This should output pulse(Hi:1msec,Lo:1msec) during 2seconds.
    But no pulse.
    Execution finish as soon as entering key.

    This code is wrong?
  • kuronekokuroneko Posts: 3,623
    edited 2014-10-30 07:06
    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.
  • PublisonPublison Posts: 12,366
    edited 2014-10-30 07:14
    OT but.... @kuroneko

    I noticed your location changed to Markdorf. Interesting their Coat of Arms looks like the Hub of the Prop. :)

    74 x 80 - 23K
  • kuronekokuroneko Posts: 3,623
    edited 2014-10-30 07:17
    Never checked the details, only been here for a week :)
Sign In or Register to comment.