flexBASIC com problem??

Comments

• JRoark Posts: 1,215

  2021-09-10 21:48 edited 2021-09-10 21:50

  This is a guess (I’m away from my dev sys), but check to see if there are any tab chars in the spin source file.

  I have been having no end of “fun” chasing this in my own code. Change any tabs in spin code to spaces and it works flawlessly. This seems to be a change in the last couple of Flex versions.
• ersmith Posts: 5,910

  2021-09-10 23:02

  Or use --tabs=8 (set the Edit > Editor Options > Tab stops setting in FlexProp to "8"). Some of the header files have tabs in them instead of spaces and that messes things up if you use a setting different from 8. It'll be fixed in the next version.
• Rsadeika Posts: 3,824

  2021-09-12 12:47

  I sort of got the FullDuplexSerial.spin to work. I had to manually clean up std_text_routines.spinh, but some things are not working as expected. I am not a Spin programmer, so I probably messed something up.

  I have an ActivityBoard hooked up to a Raspberry Pi via GPIO and ttyUSB0, and using flexBASIC. I tried using SendRecvDevice() so I could use things like Print # and input #, to no avail. The program compiles correctly but I am not seeing anything on the RPi putty serial terminal side. I make sure I have the correct baud setup, among other things.

  So, am I to conclude that the SendRecvDevice() is not functional for the P1?

  Ray
• ersmith Posts: 5,910

  2021-09-12 13:34

  SendRecvDevice works fine on P1, e.g. the following is one of the standard test programs that I run before every release:

  function toupper(c as ubyte) as ubyte
    if c >= asc("a") and c <= asc("z") then
      c = c - asc("a") + asc("A")
    endif
    return c
  end function
  
  sub putx(c as ubyte)
    c = toupper(c)
    print \c;
  end sub
  
  sub closex
    print "closed handle"
  end sub
  
  print "demo program"
  open SendRecvDevice(@putx, nil, @closex) as #2
  print "hello, world!"
  print #2, "hello, world on handle #2"
  close #2
  

  I suggest you test the connection with your RPi with the simplest possible program (maybe something in Spin) and verify that works, then build up from there.
• Rsadeika Posts: 3,824

  2021-09-12 13:59

  Interesting, I verified the connection using a SimpleIDE program that I have. That program has no problem making the connection to the RPi.

  I can get the FullDuplexSerial.spin, in flexBASIC, to coneect to the RPi, but when I apply the SendRecvDevice() to the FullDuplexSerial.spin setup, it no longer responds to the RPi. I am using the example set up that is in the FlexBASIC Language Reference, for this.

  Ray
• ersmith Posts: 5,910

  2021-09-12 14:55

  @Rsadeika said:
  Interesting, I verified the connection using a SimpleIDE program that I have. That program has no problem making the connection to the RPi.

  I can get the FullDuplexSerial.spin, in flexBASIC, to coneect to the RPi, but when I apply the SendRecvDevice() to the FullDuplexSerial.spin setup, it no longer responds to the RPi. I am using the example set up that is in the FlexBASIC Language Reference, for this.

  What pins are you trying to use for FullDuplexSerial? If they're the standard pins (31 and 30) perhaps there's a conflict with the built in print -- you'll have two COGs trying to use the same pins.
• Rsadeika Posts: 3,824

  2021-09-12 15:26

  I am using FlexProp on the RPi, ttyUSB0 to connect to the ActivityBoard. I am using pins 3 and 4 on the ActivityBoard with FullDuplexSerial.

  I am not sure if there is a conflict between FlexBASIC/FullDuplexSerial and FlexProp/ttyUSB0. FullDuplexSerial uses pins 3 and 4, while FlexProp uses pins 31 and 30. Since I have a very small program, it has plenty of COGs available I would think.

  I have found the same problem occurring when I use SimpleSerial, if that info helps any.

  Ray
• ersmith Posts: 5,910

  2021-09-13 19:43

  If they're using different pins then there shouldn't be a conflict there. It must be something else. Are you able to post your code? That would let us try to figure out what may be happening.
• Rsadeika Posts: 3,824

  2021-09-14 13:47

  This is getting to be a real problem. Not sure if this is a hardware problem or a software problem. I will start with verifying that the hardware is not the problem first. Not sure if I have replacement boards.

  Ray
• Genetix Posts: 1,742

  2021-09-14 19:14

  Rsadeika,

  Why not start with SIMPLE programs that test each part of your hardware.

  Also double and triple check your wiring.

  Might be a stupid question but are your batteries weak?
• Rsadeika Posts: 3,824

  2021-09-14 19:59

  Not having very much luck today.

  I found an RPi board that did not have flexprop installed, so I went ahead and did a new installation, it installed ver 5.9.2. First thing I noticed, the flexprop folder only had flexprop and not flexprop.tcl. When I do a Compile for P1 or Compile & Run on P1, I get "Error: Attempt to provide package msgcat 1.7.0 failed". So no compilation is being done. How do you fix that.

  I also checked one of my RPi units that I did a recent update, I believe ver 5.9.2 beta, the flexprop folder contains both flexprop and flexprop.tcl. are these the same files?

  Ray
• ersmith Posts: 5,910

  2021-09-14 21:17

  Try again, Ray. I think you got a copy of flexprop while it was in transition.

  The program is called "flexprop" now, not "flexprop.tcl" -- all platforms actually build a complete binary now, just like Windows always has. You probably can run just src/flexprop.tcl if you want to.