Shop OBEX P1 Docs P2 Docs Learn Events
Full Duplex Eight Port Serial Driver In C? - Page 2 — Parallax Forums

Full Duplex Eight Port Serial Driver In C?

2»

Comments

  • I'm just curious why a multi drop approach with RS485 is not an option. From my own experience, it seems like multiple serial COMs over any kind of distance without adequate shielding or a differential communication approach is just asking for a headache. Especially if there are any solenoids, motors, etc. that are prone to generating plenty of electrical noise.

  • True, trying to send single-ended signals over an appreciable distance, especially using higher baud rates, is asking for trouble.

    If I was wanting to push serial signals over such distances, I would have to convert them to RS-422 or RS-485.

    But fortunately I only need to run them to an add-on board that plugs into the Prop2 Eval unit. We're only talking a few inches at most with a max baud rate of 115.2Kbps. These signals then interface with a WiFi radio and a GPS receiver mounted on the accessory board. So no worries there.

    I'm glad that both of the currently maintained C compilers (FlexProp and Catalina) now support up to 8 serial ports (which is based upon the driver written by @Cluso99).

    Incorporating the 8 port driver under FlexProp is done with a struct __using() while Catalina offers it natively like its two and four port drivers. So in Catalina I can now use functions like s8_rx(), s8_rxcheck(), s8_tx(), s8_txcheck() etc.

    Of course one could also use the C functions written by @iseries wherein the ports are treated as part of a file system.

    With these various options now offered, the C programmer has the choice as to which approach is a better fit.

  • RossHRossH Posts: 5,336

    @Wingineer19 said:

    EDIT1: OK, reviewing the Catalina Prop2 Manual, it certainly appears that I don't need to use any Loader option unless I want to upload to an SD Card, which I don't. I want to program the on-board flash. I've checked the Flash Switch settings on the Board and it appears to be OK. I'm able to upload a program from FlexProp to the Board and execute it, but not having the same luck using Catalina. The investigation continues...

    Hello @Wingineer19

    Post a binary and I'll try to upload here. It's a long time since I've used the payload flash loader. I'll take a look at it.

    rossh

  • Wingineer19Wingineer19 Posts: 279
    edited 2021-09-05 02:18

    @RossH,,

    OK, after many attempts of moving the FLASH switch to OFF for programming, then over to ON and rebooting for observation using HyperTerminal, the program was successfully uploaded. I'm using a Prop2 Rev B Evaluation Board, which really shouldn't matter in the scheme of things.

    Looking over the Rev B manual for the Boot Mode Selection, and with FLASH=OFF, P59U=OFF, and P59D=OFF, there exists a 60 second window when the micro will look for serial port activity (without an SD Card installed -- which it isn't). This is the setting I used to upload the program.

    With FLASH=ON, P59U=OFF, and P59D=OFF, there exists a 100 ms window for serial port detection, followed by bootup from the SPI flash. This is the setting I used to run the program and observe via HyperTerminal.

    Is there a way to modify the Loader such that it won't be necessary to flip FLASH=OFF to upload, then over to FLASH=ON to run? If FLASH=ON, P59U=OFF, and P59D=OFF, would the 100 ms window be sufficient for the Loader to access the serial port and commence uploading to SPI flash?

    I left FLASH=ON, P59U=OFF, and P59D=OFF when testing with FlexProp, and it was able to upload to SPI flash in this mode, then run the program after I hit reset. It would be really nice if the Catalina Loader could do the same.

    I will email you a copy of the .bin file for your testing.

  • RossHRossH Posts: 5,336

    @Wingineer19 said:

    Is there a way to modify the Loader such that it won't be necessary to flip FLASH=OFF to upload, then over to FLASH=ON to run? If FLASH=ON, P59U=OFF, and P59D=OFF, would the 100 ms window be sufficient for the Loader to access the serial port and commence uploading to SPI flash?

    I left FLASH=ON, P59U=OFF, and P59D=OFF when testing with FlexProp, and it was able to upload to SPI flash in this mode, then run the program after I hit reset. It would be really nice if the Catalina Loader could do the same.

    I will email you a copy of the .bin file for your testing.

    Thanks. It may be to do with the program size. I have been testing it using small programs, and it generally works ok. However, loading flash on the P2 has always been a bit problematic. I use P2ES_flashloader.spin2, which I believe is the same code that others use with no problems, so I've never been sure why it is unreliable for me. Every time I test it it works flawlessly for many loads in a row, then fails randomly for a while, then works flawlessly again for no apparent reason. This makes it very difficult to track down what's going wrong, but I think it probably is to do with the timing.

    I will have another go at making it more reliable, but in the meantime load your binary to flash using other means. Do you need to use flash at all for your testing?

    rossh

  • @RossH said:
    I will have another go at making it more reliable, but in the meantime load your binary to flash using other means. Do you need to use flash at all for your testing?

    rossh

    For incremental code additions I normally just upload to HubRam and perform interactive testing. Then I periodically upload it to flash for testing. Of course for field testing everything will have to be in flash memory.

    That's the nice thing about the Prop1 and Prop2 with both FlexProp and Catalina. I can upload code to the HubRam for testing and save the wear and tear on the EEPROM/flash memory. Then upload to EEPROM (Prop1) or the SPI flash (Prop2) when the time is right.

    I can't do that with my ESP32 module since the Arduino IDE uploads the code directly to flash memory. If there's a way to upload it only to SRAM instead I haven't found it yet...

  • RossHRossH Posts: 5,336

    Hello @Wingineer19

    Got your binary. It behaves the same as my own programs - it will load to flash and run correctly a dozen or more times, then it will fail to load a couple of times in a row, then it goes back to loading just fine again for another dozen or so times.

    It's very frustrating! :(

    Still, as long as it is not holding you up , I will work on it as I get time.

    rossh

  • @RossH said:

    Still, as long as it is not holding you up , I will work on it as I get time.

    rossh

    No problem at all. I will continue coding and uploading to HubRam to perform the incremental testing. When the time comes to upload it to flash I will mess with it until it finally works.

  • RossHRossH Posts: 5,336
    edited 2021-09-05 07:37

    Hello @Wingineer19

    The good news is I know what's going on now, and payload is quite reliable. The bad news is that you will still have to flick a switch to program the flash, because payload cannot currently use the 100ms serial window on the P2. This is because of the way it tries to detect if it is talking to a P1 or a P2. I will have to rewrite the Propeller detection code to use the 100ms window on the P2, or perhaps add an option to allow you to force payload to assume it is talking to a P2.

    Here is how to program the flash reliably on the P2_EVAL board with the current version of payload, and then use payload in interactive mode without having to execute two different commands:

    First, ensure the switches on the P2_EVAL PCB are in the following state:

    • FLASH on
    • P59v off

    To load the program to flash and then execute it:

    • turn P59^ on (if it is off)
    • execute the command flash_payload miniplate.bin -i -b115200
    • wait for all the LEDs to go out (this indicates programming the flash has completed)
    • turn P59^ off
    • reset the P2

    rossh

  • @"Beau Schwabe" said:
    I'm just curious why a multi drop approach with RS485 is not an option. From my own experience, it seems like multiple serial COMs over any kind of distance without adequate shielding or a differential communication approach is just asking for a headache. Especially if there are any solenoids, motors, etc. that are prone to generating plenty of electrical noise.

    IIRC, you really put your "high-speed-net" through the wringer(?)

  • RossHRossH Posts: 5,336
    edited 2021-09-06 04:05

    Hello @Wingineer19

    I have updated the main Catalina thread (https://forums.parallax.com/discussion/172036/catalina) with a new version of payload that allows you to program the FLASH RAM and execute your program without having to mess with the P2_EVAL board microswitches. You can now just set your microswitches to:

    • FLASH on
    • P59^ off
    • P59v off

    and then use a command like:

    flash_payload miniplate.bin -o2 -i -b115200

    The addition of the -o2 overrides the Propeller autodetection and this allows payload to use the 100ms serial window.

    rossh

Sign In or Register to comment.