A development board for Lua programming

[doub]

For some time now I've been thinking about creating a general purpose development board in the same category as the Arduino, ie. without a high level operating system, but that I could program with the Lua programming language, because I'm a big fan of that language. A project called eLua aims at running Lua on various kinds of microcontrollers, but I'm looking for something slightly different.

The main constraint to run Lua on microcontrollers is memory size. The Lua interpreter is fast enough to be able to run on most processors, but even if it's one of the most compact scripting language interpreters around, it still require a few hundreds kilobytes of ROM, and at least as much RAM, and potentially much more to run large programs. And even if many microcontrollers now have many hundreds of kilobytes of Flash, RAM is usually much more scarce. And this is not a problem for C/C++ programming, so most general purpose dev boards don't provide external RAM.

So this project is about packing a relatively fast microcontroller, but not complex enough to require a high level OS (like Linux for SoC-class chips), with a big RAM chip. I picked a STM32F427, because I have some experience with the STM32 family, the core is a Cortex-M4F (floating point will help running Lua), and it is one of the few Cortex-M microcontrollers with an SDRAM controller. SDRAM is desirable over SRAM because it's much more dense and there are 256Mbits (32Mbytes) chips available for a few dollars.

Apart from that I attached the MCU to an Micro-SD card slot, two USB OTG ports, a 5V DC input, and all the other available pins (the SDRAM uses quite a lot of the 144 MCU pins) are exposed as user-available I/Os.

I've completed an initial schematic and a tentative routing (10cm x 6cm, 2 layers) in EAGLE, and I'd be happy to have comments before I order the first PCB batch, especially on the schematic. Here are the current files:

• luaboard.sch
• luaboard.brd

[jeanmarc78]

Hello doub,

Have you considered using a commercial cheap router such as the tp-link tl-wr703.
You can find them for around 20$ on ebay (with the AC adaptor and shipping included).
Multiple hardware upgrades have already been described.

You can install an openwrt (openwrt.org) linux package and lua is already installed and used to customize the internal web server to allow remote access.

Main features : 400MHz CPU, 4M Flash, 32M RAM, 1 RJ45 100 Mbps, Wifi, 1 USB otg, very small, low power required

Best regards,
JM

[doub]

Have you considered using a commercial cheap router such as the tp-link tl-wr703.
You can find them for around 20$ on ebay (with the AC adaptor and shipping included).
Multiple hardware upgrades have already been described.

Yes, I've considered using a System-on-Chip with a full fledged Linux. The problem is that I consider the quality of the software stack of such systems to be relatively low, and particularly hard to upgrade and improve because of the sheer size of that software (Linux alone has millions of lines of code, and add to that a full userspace) and the poor documentation of these SoCs (many vendors just provide botched drivers for an old version of Linux and call that support).

So for this project I'd like to keep the software stack as small as possible, with just a libc, Lua, and all the rest will be user-defined. I plan to provide some libraries to ease accessing the MCU peripherals from Lua, but I don't want to force any programming paradigm on the users, so they can experiment with new kinds of multi-tasking or software architecture.

[doub]

I updated my board to match the Sick of Beige 100x62 template, since it was so close in dimensions. I'm still interested in some feedback for the schematic and routing, so to motivate you here are some pictures of the board at approximately real size (on a 96dpi monitor, click for higher resolution):





A couple of 3D renders:





Also links to an image of the schematic, the schematic and the board files for EAGLE.

[bernieke]

First python (http://www.kickstarter.com/projects/214 ... ontrollers), now Lua.

What a great world this is :)

[mip]

Not having Eagle (KiCad only), I cannot have a look at the schematics.

One point that caught my eye from looking at the boards is the traces to the SDRAM: The trace lengths should match.

Check the JTAG pins (PA13,14,15,P_B_3 (not P_D_3), PB4, don't split those signals to different io headers). Or better: provide footprints for a standard JTAG connector.

USB ports should have transient voltage suppressor (TVS) diodes.

The IO headers should have VCC, GND on the same positions. Maybe GND, VCC, GND starting on pin 1 so that a GND pin could be sacrificed as an index pin when connecting flat ribbon cable connectors (or use double row connectors, which are more common).

Provisions should be made for a 32khz xtal.

Check the space between board edge and io connectors. At least the connector on the long side should be able to be soldered with a 90° pin array to be able to plug it directly into an experimenter's board.

There's plenty of room left, maybe add some "prototyping area" next to the pin rows.

[ddavenport]

Like mip, I could not look at the schematic and I do not have Eagle (and it failed to install on my machine). Maybe you could post a PDF or SNG of the schematic?

I would also like to add my support for a good JTAG signal breakout. I am not concerned about the actual connector pattern, but a standard one would be best. We use a clip-on JTAG connector at work as it is a small patter and requires no parts to be populated.

In addition to the 32kHz crystal as recommended by mip, I would suggest adding a connector for the Vbat input to keep the RTC running.

Also, if you would like some help in getting Lua running, I would be happy to spend some of my spare time with such an endeavor.

[doub]

Not having Eagle (KiCad only), I cannot have a look at the schematics.

The board fits on the free version of EAGLE, which is available for Windows, Mac and Linux. But if you can't install it, there's a link to the schematic in PNG format at the bottom of my previous post.

One point that caught my eye from looking at the boards is the traces to the SDRAM: The trace lengths should match.

Unfortunately, the STM32F4 has external memory signals on all four sides of the LQFP144, which is 20mm wide (twice the distance between it and the SDRAM). Maybe half of the signals are on the side I placed next to the SDRAM, but the others are scattered around. I don't see how I could fit 20mm of spare length for these 20 or so signals to match the ones further away, especially on a 2 layers board.

That being said it's the first time I work with SDRAM. It is single data rate, 166MHz clock (from the chip spec, I guess I can run it slower). Do you think signal length matching will matter that much?

Check the JTAG pins (PA13,14,15,P_B_3 (not P_D_3), PB4, don't split those signals to different io headers). Or better: provide footprints for a standard JTAG connector.

I did check them, they are all available, but on different headers (some on the bottom, some on the left). I exposed all I/O pins of the MCU in almost the same order as the package to simplify routing. I'll see if I can move all the JTAG ones on the same side.

A standard JTAG connector might be more complicated to put. Keep in mind that the board might be smaller than it looks. The external headers pitch is 2mm, not the usual 2.54mm.

And for a little background, I didn't put too much effort into exposing JTAG because the MCU contains a USB bootloader hardcoded in system memory, so reflashing the chip should be easy to do just using the USB port. Basically I expect that very few of the intended users might have a need for JTAG besides me.

USB ports should have transient voltage suppressor (TVS) diodes.

My STM32 projects using USB have so far been alright without these, but I must admit that I was much more space constrained. Moving to the SoB format freed 2mm on that side of the board, so I can probably add these.

That being said I designed the USB ports to be optional, so that the 3 pins (D+, D- and ID) of each port can be used as GPIO. I'm a bit concerned that puting TVS diodes on these lines may reduce their usefulness as GPIOs. In particular the same pins I believe are used for the CAN transceivers, and I don't know if these diodes would be a good thing or a bad thing for CAN.

But I never used TVS diodes, so I'll document myself before deciding.

The IO headers should have VCC, GND on the same positions. Maybe GND, VCC, GND starting on pin 1 so that a GND pin could be sacrificed as an index pin when connecting flat ribbon cable connectors (or use double row connectors, which are more common).

The two side headers have completely different signals, just what happened to be there on the MCU package. It's not like a generic side port with the same functionality. What would be the added value of having the power pins on the same position in that case?

Provisions should be made for a 32khz xtal.

I'll see if I can put the footprints for a crystal, even if I don't populate it. I exposed the VBAT pin, so I guess some might want to use this in very low power scenarios and use a RTC when in sleep mode.

Check the space between board edge and io connectors. At least the connector on the long side should be able to be soldered with a 90° pin array to be able to plug it directly into an experimenter's board.

I'll check that, but with a 2mm pitch header, it won't fit on a regular 2.54mm breadboard. I'll see if they make 2mm breadboards, or maybe see if I can make an adapter board.

There's plenty of room left, maybe add some "prototyping area" next to the pin rows.

[/quote]

There is not that much space left. Keep in mind that the headers pitch is only 2mm, and having only 2 PCB layers to play with I don't have lots of flexibility for routing. Also my assembly skills are limited, so if the board gets too dense I won't be able to assemble the prototypes.

Anyway, thank you very much for the feedback. Please have a look at the schematic and tell me if you see something broken. I'm especially not sure about the DFU button handling.

[miro]

Nice board! I would place an external rtc (ie. DS3231, 16pin 300mil SO package) with a cr1225 battery holder there..
Btw, an usb high-speed modes requires a phy chip, afaik.

[doub]

Btw, an usb high-speed modes requires a phy chip, afaik.

Yes, but the high speed controller in the MCU has a full-speed capable internal PHY. It's labelled HS to distinguish it and to relate to the STM32F4 manual.

An external UTMI high speed PHY consumes a significant amount on pins on the micro-controller, so I've let that for daughter boards. I'll consider it in future revisions if there's a demand, but right now for me GPIO pins are more important than high speed USB, especially given that when programmed in Lua, reaching that high a data throughput might be hard (you'd probably need to complement Lua with C code for such tasks).

[jiri]

i have used TVS "DVIULC6-4SC6" for USB. It is used as near as possible from connector.

I'm not expert in EMC, but why do you make pcb on 2 layers. 4 layers would be better for EMC. There is SDRAM and high speed wires without ground under wires.

Jiri

[gtz]

Nice board, but it looks like if the traces to the SD-RAM are all of different length.
I've not tried to do such a layout my salve, but have read about more than one project, where they had to do multiple layouts, because the unbalanced lines to RAM causes phantom bugs.

You might run into similar problems.

I hope you don''t, but just a word of warning.

Happy hacking,
gtz.

[gtz]

*deleted*, you already link to the eLua Project in the first section.

My bad,
gtz.

[gtz]

And a final post.

I like your board, but would like one with ethernet. The chip you've selected already contains an ethernet MAC, so all you need to add it a PHY, but I realize, you're low on space.

Just an idea,
gtz.

[nickjohnson]

I love the board, especially the routing. Did you use a topological router, or do that by hand?