Software serial?

[pythoncoder]

@dhylands I don't doubt your solution is superior. But I still can't see a bug in mine apart from the fact that start_time is unused. Alas I don't follow your explanation. The only places where I add the bit time is in the calculation of end_time and the result is anded with 0x7fffffff. So it can never produce a result of 0x80000010: end_time will be 0x10.

Say system_get_time() = 0x7ffffff0 and bit_time = 0x20
end_time = 0x80000010 & 0x7ffffff0 = 0x10
if (0x7FFFFFFF & system_get_time()) is still > end_time it will loop until (system_get_time() & 0x7FFFFFFF) is a small number.
Then it will wait until (0x7FFFFFFF & system_get_time()) exceeds end_time before sampling the bit.

On each pass end_time is recalculated by the same means so it can never exceed (system_get_time() & 0x7FFFFFFF).

Perhaps you could clarify for the elderly and hard-of-thinking

[pythoncoder]

@dhylands On a more general point do you think there is any mileage in this being offered to the maintainers? There is evident demand for a solution. The code needs cleaning up to meet the coding standards and it could be enhanced to provide features such as flow control but the effort would only be justified if it were likely to be accepted.

The algorithm has a fundamental issue in that the entire character is processed in the interrupt context. This precludes full duplex operation. It also means at low bit rates the CPU will be hogged for long periods. This will also occur for the duration of continuous streams of incoming characters.

Solving this would involve substantial effort. My guess is that a hardware timer would be required for rx and tx, with each bit being handled by a timer interrupt although I haven't looked at this in detail. If the esp has only two hardware timers this has evident adverse consequences. Or is there another way? Does the esp support DMA?

Despite this, the existing solution is surely useful in many applications where half duplex and short bursts at fast baudrates are the norm; its limitations could be declared in the docs. What's your view?

[dhylands]

I haven't played with the ESP yet, so I'm not really familiar with its HW capabilities, so I can't offer much input.

[cversek]

Hello again,
After pulling in the latest commits from the upstream git repository, my modified firmware (with SoftUART functionality) seems to cause the `.irom0.text` section to overflow when linking:

Code: Select all

LINK build/firmware.elf
xtensa-lx106-elf-ld: build/firmware.elf section `.irom0.text' will not fit in region `irom0_0_seg'
xtensa-lx106-elf-ld: region `irom0_0_seg' overflowed by 976 bytes
make: *** [build/firmware.elf] Error 1

Here is the MEMORY section of `esp8266.ld`:

Code: Select all

MEMORY
{
    dport0_0_seg : org = 0x3ff00000, len = 0x10
    dram0_0_seg :  org = 0x3ffe8000, len = 0x14000
    iram1_0_seg :  org = 0x40100000, len = 0x8000
    irom0_0_seg :  org = 0x40209000, len = 0x87000
}

I tried to boost the size of this section ` irom0_0_seg : org = 0x40209000, len = 0x88000` and was able to compile and load the firmware. However, when entering the REPL I get this error message:

Code: Select all

The FAT filesystem starting at sector 144 with size 875 sectors appears to
be corrupted. If you had important data there, you may want to make a flash
snapshot to try to recover it. Otherwise, perform factory reprogramming
of MicroPython firmware (completely erase flash, followed by firmware
programming).

I suppose now I'm bumping up against the file system. Where and how can this be configured? Thanks.


EDIT:
So I think I found a possible solution. It turns out that `0x40209000 + 0x88000 = 0x40291000` is the new end of the firmware and the user flash space must come after that address. And according to `modesp.c` line 639:

Code: Select all

STATIC mp_obj_t esp_flash_user_start(void) {
    if (IS_OTA_FIRMWARE()) {
        return MP_OBJ_NEW_SMALL_INT(0x3c000 + 0x90000);
    } else {
        return MP_OBJ_NEW_SMALL_INT(0x90000);
    }
}

It seems that these addresses are all relative to 0x40200000; so, I just changed 0x90000 to 0x91000, compiled and reloaded the firmware, and now the REPL seems to work! Is this safe or am I tampering with something that will bite me down the road?

[pythoncoder]

I suggest you look at https://github.com/micropython/micropython/issues/2735 where this was discussed.

[cversek]

@pythoncoder
Thanks for the reference. My takeaway from that discussion is that instead of hard-coding that address, it would be better to add some reserved sectors via modules/flashbdev.py#L6:

Code: Select all

class FlashBdev:
    SEC_SIZE = 4096
    RESERVED_SECS = 16 #needed for user native code extensions 
                       #NOTE: will destroy existing filesystems
                       #NOTE: might not work with 1-Mbit flash size devices and OTA firmware 
    START_SEC = esp.flash_user_start() // SEC_SIZE + RESERVED_SECS
    NUM_BLK = 0x6b - RESERVED_SECS

The rationale for choosing 16 (64k) reserved sectors was from a suggestion that future releases might bump the firmware space up by 64kbytes but there might be trouble fitting in the OTA firmware on 1-Mbit flash devices.

FWIW, I'm primarily using a recent Feather HUZZAH board which has a 32-Mbit flash. I have started to make new changes to my fork of the adafruit/circuitpython fork.

[happyday]

I am excited to try your code. Thank you. Forgive my challenge, but I have not built a MicroPython bin and hope you will help me through a challenge I am having. Adafruit's directions include downloading esp-open-sdk into the Ubuntu VM. I do not know how to modify a Vagrant install in order to replace esp-open-sdk with what I assume I should be using to get to software serial:
$ git clone https://github.com/p-v-o-s/micropython.git

Could you please help me with this step? Do I use Adafruit's code to install and access an Ubuntu VM via Vagrant commands? If I do this, I don't have the code you have evolved in micropython.git.

Thank you.

[ohin]

@cversek: I successfuly built the micropython firmware from your fork, flashed it, and was able to create instance of SoftUART. However I was not getting any output out of read() function. It was timeouting with no response. I used the pins (12,14) from your example.

To confirm the line is ok, I checked from Arduino, and I was able to read the data. Is there anything I could to check to figure out, where the problem lies?

[cversek]

@happyday

$ git clone https://github.com/p-v-o-s/micropython.git
Could you please help me with this step? Do I use Adafruit's code to install and access an Ubuntu VM via Vagrant commands?

Yes, you can follow Adafruit's video for setting up the esp8266 build environment within a vagrant VM, that's what I did. Instead of using the home directory, you can checkout my fork in a different directory. E.g.

Code: Select all

$ mkdir PVOS
$ cd PVOS
$ git clone https://github.com/p-v-o-s/micropython.git

Then you work from that directory and follow all the same steps (making sure you refer to the new location) and it should work.

[cversek]

Is there anything I could to check to figure out, where the problem lies?

@ohin
Not knowing what kind of device you are trying to communicate with and what your other settings are, I'm not sure I can give you much help. Make sure you set the same baudrate on both devices and that you pair RX (pin 14 in the example) on the Feather HUZZAH board (assuming that is what you are using) with the TX of the remote device.