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.
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.
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.
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 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...
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.
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.
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)
@"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(?)
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.
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.
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
@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.
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
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...
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
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.
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:
To load the program to flash and then execute it:
rossh
IIRC, you really put your "high-speed-net" through the wringer(?)
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:
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