Propeller IDE lacking ability to reset via RTS?

WBA Consulting

With the Propeller Tool, you could go into Preferences:Operations and change the "reset" function for the Propeller from the default "DTR" to the option of "DTR & RTS". This allowed the use of boards designed with the FTDI FT230X chip. I discovered tonight, that the Propeller IDE software does not have any options for changing the Propeller Reset function.

Does anyone know if this could be an option in future releases? I was going to use the FT230X in a Propeller design due to real estate (as I did with my PropBSC), but I don't like the idea of no functionality with Propeller IDE.

Tracy Allen

I believe you can can reprogram the ftdi chip itself, using FTPROG. Reassign that pin to DTR.

WBA Consulting

Thanks Tracy. Unfortunately, the FT230X is what FTDI calls a "Basic UART" not a "Full Handshake UART", so DTR is not available even as a CBUS pin configuration.

I just need to move to the FT231. The good news is that the current version of the FT231 is in a 4mm square QFN package as well (20 pin versus the FT230X's 16 pins), so my real estate concerns are ruled out. Cost between the two is negligible, so I think this is now a non-issue.

I just have to remember that whenever I use my PropBSC prototypes, I have to use the Propeller Tool to download code.

David Betz

I haven't seen Brett online for ages. Who is maintaining PropellerIDE these days?

rogloh

Hi, slightly old thread resurrection but today I was able to figure out a way to get PropellerIDE to use RTS for doing a Propeller reset with the FT230X serial device but you first have to obtain then modify the PropellerIDE source code and rebuild. I'm not going to explain all those steps but the code change itself was simple enough to at least put in a hack.

In your PropellerIDE/src/propellermanager/src/propellerdevice.cpp file you need to add a line to the constructor that corresponds to your device name and associate with the "rts" string if you want to get it to reset with RTS instead of DTR (which is the default). I use MacOS X and my FT230X based device name comes up starting with "cu.usbserial-DM00SVxxx" when it is plugged in. Depending on what your OS is your's will be named differently under Windows/Linux etc. Other code in this same file later uses this keymap to sub string match and if it does get a match it will use the named reset method associated with that port name.

It works on my FT230X system and doesn't mess up the other devices I use which still get DTR reset method applied. Happy days.

namespace PM
{

    PropellerDevice::PropellerDevice(QString devicename)
        : Interface()
    {
        _resource_error_count = 0;
        _minimum_timeout = 400;
        _reset_defaults["cu.usbserial-DM00SV"]   = "rts"; // modified RL 26-FEB-2018
        _reset_defaults["ttyAMA"]   = "gpio";
        _reset_defaults["ttyS"]     = "dtr";
        _reset_defaults["ttyUSB"]   = "dtr";

        _reset_gpio = 17;

        _enabled = true;

EDIT: By the way if you use Linux and your serial device names are all generic like /dev/ttyUSB0 /dev/ttyUSB1 and change each time you plug them in, this may help give them more persistent names (which may or may not work with the above, not sure): http://hintshop.ludvig.co.nz/show/persistent-names-usb-serial-devices/

yeti

rogloh wrote: »

EDIT: By the way if you use Linux and your serial device names are all generic like /dev/ttyUSB0 /dev/ttyUSB1 and change each time you plug them in, this may help give them more persistent names (which may or may not work with the above, not sure): http://hintshop.ludvig.co.nz/show/persistent-names-usb-serial-devices/

I used that for a while and gave away all CH34x based boards because they cannot be "individualised". Probably some of my FTDIs are fakes/clones that would drive Windows users mad but even they behave well with this on Linux so far and came with individual serial "numbers".

My CP2102 USB UARTs came all with the same settings but can be individualised too.
—▶ https://github.com/DiUS/cp210x-cfg

Maybe the recipes in the mentioned article do not fit perfectly any more on systemd infected OSes? I stumbled over different rules for SystemD infected and healthy penguins in the context of the FTDI chip used on Lattice's HX8K evaluation board.
—▶ https://github.com/cliffordwolf/icestorm/issues/105

So maybe the other chips need a different treatment too in SystemD days?

I haven't touched this topic for a longer time.

Maybe this is worth an own thread for collecting which chips have unique numbers in their description when freshly unboxed and which ones come in uniform and can be freed to be an individual using which tools.