Teensy 3.1 code updates

[lbattraw]

Hi, I've looked over the Teensy support and would like to contribute to expanding it, particularly to support all 3 serial ports and different settings. I've done some work already toward this but ran into problems with the struct passed to initialize the UART, since I'm not clear on what's being passed from other functions and what's necessary. --Been a while since I did any serious C development. Does anyone, such as the author of of the first Teensy implementation have any pointers on further development? I'm not sure how much of the existing Teensy code is usable or needs to be rewritten to properly support all the features of MP, so any hints would be appreciated.

Best regards,
Larry Battraw

[dhylands]

Hey Larry,

I did the initial Teensy stuff, and would love to see contributions from others.

The best way to proceed is to create a fork of the micropython repo, create a branch, and push your changes to the branch.

Then you can send me a URL to your repo and the branch name, and I can check it out locally and see what the issue is. Then we can discuss stuff in github, referring to actual code.

I've been meaning to get back to the Teensy port and get some more peripheral support. The micropython/teensy tree builds. I haven't tried it recently, but will do.

My own personal goal is to get enough support that I can get my little bot running again.

[lbattraw]

Thanks for the reply, Dave. I've finally gotten around to forking the project and merging in my changes. Things are kind of a mess in uart.c since I was playing around trying to figure out why it locked up every time I tried to initialize the UART via uart_init. Looks like the struct that's being passed is invalid for some reason, and it fails to ever return after executing the memset function on line 77. Probably something pretty simple, I'm just not clear on what should be stored there.

Here's my repo: https://github.com/lbattraw/micropython

-Larry

[lbattraw]

[I can't edit my previous post since it hasn't been approved by the moderator]
Dave, I made a mistake in my last post, the hang is actually in the memset of &self->uart at line 228 in the pyb_uart_init_helper function. I'm not clear on why writing to that should cause it to hang, hence my confusion about what the struct contains. Even trying to print the value of self->uart will cause a hang. I'm testing this by running "pyb.UART.init(1,115200)".

-Larry

[dhylands]

Hi Larry,

I think that this is a problem:
https://github.com/lbattraw/micropython ... #L284-L285

Code: Select all

    if (MP_OBJ_IS_STR(args[0])) {
        const char *port = mp_obj_str_get_str(args[0]);
        o->uart_id = mp_obj_get_int(args[0]);
    }

Since args[0] is a string, calling mp_obj_get_int on it will fail and cause an exception to be thrown.
https://github.com/lbattraw/micropython ... #L211-L232

I haven't tried compiling and running your code yet, but that looks like something to fix.

[lbattraw]

Hi Dave,

Thanks for the tip, I've done quite a bit of work and finally gotten something working in a very rough state. Currently UART.init and UART.write work, although init only sets the baud rate currently. To specify which port to write to you add a keyword argument of uart_id, like so (It defaults to 0):

Code: Select all

pyb.UART.init(115200,uart_id=2)
pyb.UART.write("test str", uart_id=2)

It spits out a bunch of debugging messages currently, but then I'm only just getting started. BTW the Teensy labels UARTs as going from 1-3, but I went ahead and numbered things starting at 0.

The hardest part of doing this minor enhancement was figuring out what of the existing, non-compiling code could be adapted and what was necessary to rewrite/remove completely, since there was (And is) quite a bit of code sitting in inactive blocks that I assume came from the stmhal UART code. It looks like things have changed quite a bit since the Teensy port was done, so referencing stmhal code vs. Teensy was a bit tricky. Now I've wrapped my head around how data is passed around and various conventions it should be considerably easier to add the read functionality and fill out the init portions and other pieces.

-Larry

[dhylands]

Actually, the "dead" code was from before a restructuring was done in MicroPython.

At the time, stmhal hadn't finalized the APIs for peripherals and stuff, and I just went ahead and created something, which is what I used for:
http://blog.davehylands.com/2014/01/mic ... sy-31.html

So when the peripheral APIs were finalized, I brought up enough of the port to build, but left around the older files as a reference.

The best way to know whats used and what isn't is to consult the Makefile. We could also move the unused files into a subdirectory, or rename them until they get ported.

When you look at the code, there are really portions to each peripheral file. There is what I call the API portion, which has the MicroPython interface, and then there is the implementation.

For some of the generic things, like GPIO, I was able to abstract things enough that we could share the stmhal files. Whether we go that route, or copy/paste the stmhal peripheral file and modify it or do some factoring really needs to be decided on a case by case basis.

My gut tells me that the UART code is more complicated that the GPIO code, so doing the copy/paste is probably a good place to start.

STM seems to make things 1 based and FreeScale seems to make things 0 based. My guide has been that we should follow in the steps of the datasheet. So if the datasheet references UART0-5 then we should make the python interface reference UART IDs 0-5

I'll take a look at your code.

[dhylands]

@lbattraw - Did you push your changes?

I'm not sure if I'm looking at the latest or not (since the code doesn't seem to match your description).

[lbattraw]

@dhylands - re: recent code changes

Yep, I have pushed several times recently, which might be part of the problem Things are changing rapidly as I keep finding new things I'm doing wrong, and there's always something new to fix...

I've been looking at your HAL code for Teensy as I realized I didn't have a way to output strings via the USB VCP, and am wondering some more about where to split up such code and the existing Teensy Arduino libraries (Which I wanted to reference instead of duplicating sections). Ideally I'd like to build on all that existing, tested code to avoid reinventing things (Or copying things that might later be changed in the original code base), with just some glue code to make it work with MicroPython. It might also make it a little less difficult for future ports since if they can use the Arduino API they may be able reuse glue code as well. That's the idea anyway. Any thoughts on this, creating/copying code vs. using Arduino interfaces?

-Larry

[lbattraw]

Actually, the "dead" code was from before a restructuring was done in MicroPython.

At the time, stmhal hadn't finalized the APIs for peripherals and stuff, and I just went ahead and created something, which is what I used for:
http://blog.davehylands.com/2014/01/mic ... sy-31.html

So when the peripheral APIs were finalized, I brought up enough of the port to build, but left around the older files as a reference.

The best way to know whats used and what isn't is to consult the Makefile. We could also move the unused files into a subdirectory, or rename them until they get ported.

Dave, I hope you didn't consider my comments about "dead code" as criticism, I was just trying to refer to the parts of it that were "ifdef'd 0" out of compilation. The first thing I tried to do was set the ifdef to true in a function and try and compile it with my changes, which didn't work so well due to all the changes in the MicroPython core code. I eventually had to start coding things over since there were too many differences in the way things are structured between then and now (Not that I've done that much yet).
As you mentioned, APIs and conventions have changed and so the code you originally used as a template from the stmhal port has also changed, which was confusing when I went to look for things. --Definitely not a problem with your work, things have changed rapidly as you noted.

BTW this is the first time I've seen the page you mentioned, nice work on the breadboard!

-Larry