New Micros Tini21xx Microcontrollers

Has anyone used any of these Tini21xx microcontrollers? They are supposed to be able to run uCLinux. I am considering getting the Tini2138 Development kit. They have this adapter for plugging it into a standard breadboard (or circuit board). I can write code for it and program it under Linux. This is one small microcontroller, and I am wondering if it’s too small. It does seem to have all the features I want in a main microcontroller, and it is an ARM MCU with plenty of memory. There are others in the series also that have various memory configurations. A person could stash one of this pretty much anywhere…

8-Dale

I haven’t used it myself, but this looks good. Just to let you know, while the CPU can run uClinux (as it says on the uClinux site), there is nowhere near enough flash/RAM on the package you linked to, to do so. You need basically 2MB flash/ 4MB RAM to run any variant of a modern Linux kernel, and really twice that to do anything much besides run the kernel. Adding such high speed devices is not trivial (I believe there was a thread where I suggested this to Pete a few months back before he had finalized his PIC board design). That said, it is an excellent looking micro for general “bare-metal” use and if you learn ARM assembly and programing such could allow you to hack any type of ARM device as a large number of USB peripherals essentially have one of these in there plus a few other chips to do whatever is required. I also like the price, and may end up getting one.

The Tini2138, which is what I would get if I go this way, has 512 Mb Flash.

Yes, I find this to be an interesting and attractive unit, as well as fairly inexpensive for what it provides. I don’t think I would actually try to run Linux on it even if I could, but then, it might be fun to try just to see if it would… :wink:

For Linux, I would probably get something more along the lines of this Cirrus board which looks nice. The price on this is not bad either.

I still think I want to get a Tini2138 system too though just because it’s so darn small and cute and has the raw power to run a lot of stuff.

8-Dale

Um… The Tini2138 has 512 KByte of flash and 32 KByte of RAM. Just click on the link you provide. This is a lot compared to say a PIC 18F4550 with 32 KB of program flash and 2K of RAM, or a dsPIC which maxes out at around 144 KB of flash and 8K of RAM, but is nowhere enough to run Linux.

The Cirrus is also a good find. I’m surprised I didn’t see it sooner, since I visit SparkFun a lot too. I really like the specs, especially the USB ports, and the price is good for what it offers. Really the only thing lacking is WiFi, which could be added easily enough through USB. A 2.5" hard drive would also remove any storage issues. The only thing I don’t like is the size, the board really should have been made slightly smaller.

Whoops, you’re right! I don’t know how I missed that. Hmmmm, I wonder how they figure this would run uCLinux then.

I agree on the size. I am still searching out Linux capable SBCs. :slight_smile: I am surprised Sparkfun has not got more controllers like this Cirrus board. The price point I would like to be at is right in the ball park. The USB is a definite plus too.

8-Dale

When uClinux says it will run, I’m not sure if there is a single chip variant of the ARM7TDMI-S with enough flash/ RAM, as there are a range of sizes on the site, the Tini2131 for example has only 32K/8K. This is the chip I like the best at $30 and a full ARM7 command set. The Tini2106 I thought had external flash/ RAM on the board since it has 128K/64K, but those chips are a motor controller and RS-232 chip respectively. It is very possible another manufacturer makes a bigger ARM7TDMI-S with enough, since all the board are just breakouts for the single chip computer on them.

It is also very possible, just like the 68K series of chips, the ARM7TDMI-S is a standard enough design that other manufacturers made variants without internal flash/ RAM for designs like the Cirrus board where larger amounts of external storage is desired. I have an (1979 vintage) DIP 64 68000L which has no on-board flash or RAM for example. The related MC68HC812A4 is on the New Micro site Link has 4MB flash/ 1MB RAM on a single chip. With a tad more RAM that chip could run Linux just fine. My old 68K could too if I gave it enough flash and ROM, though it would run like a snail (4 Mhz), have horrible power consumption (12V), and be a nightmare on the breadboard, but in theory is possible. A Mac classic is essentially a 68000P (64 DIP too) and Z80 based chip (for video), Apple ROM, and a bunch of 7400 series buffers. I have an old Mac Classic motherboard in the electronics teaching lab here and have done a breadboard computer using a Z80 though not running anything complex like embedded Linux.

I doubt it would be easy (require some massive recoding or possibly a hardware ROM abstraction layer) to get Linux running using SEEPROM or I2C RAM with that chip, but this is also another possible way the chip could be supported. I have I2C SEEPROMs (8 pin DIPs) that goto 1 MB, and a MMC’s SPI interface could be used on the flash end. There are I2C RAM drivers (not sure how large they go, I’ve only seem around 64K), but even with a number of these, this could be a viable method too.

It seems like it should be possible to create a small form factor microcontroller board that can run Linux. I am thinking somewhere in the size range of an Atom Bot Board, perhaps a bit larger to handle the extra hardware required for an ARM9 or similar MCU and extra RAM/Flash. I bet Pete could come up with something in the ballpark. :slight_smile: It has to have Open Source tools that can run on Linux/*BAD though. :smiley:

8-Dale

Lol. You found one for me a long time ago, the ts-7400 embeddedarm.com/epc/ts7400-spec-h.htm. It fits what you want, though the $125 console board to set up the thing is a bit of a drag.

The Wifi box option for $250 is also a bit painful, though you can get 128MB of RAM that way, and it looks like the WiFi card they use might be better than simply using an external USB.

Yes, I know. This TS-7400 could be real nice for robotics if it were not for the added cost of the other board you need to develop for it. However, when I look at the development system prices for other similarly featured boards, it doesn’t look all that bad.

It would cost a grand total of $355.00 to get a TS-7400 board with 64 Meg RAM and RTC plus the full development kit. That’s not really bad. The TS-7400 uses the same Cirrus MCU the Sparkfun board uses and looks to be much smaller.

8-Dale

I am reconsidering the Gumstix now. They have come out with a new WiFistix CF board that I would put with the Connex 400xm BT motherboard and the Waysmall Stuart. The total cost of this setup without a case is $288.00, which really is not that bad for a modular system like this and the features it provides such as full Wifi B/G and Bluetooth wireless connectivity.

Starting out with just the Connex 400xm BT motherboard and Waysmall Stuart would only be $189.00. The only problem I see with Gumstix is the lack of expandability, since you can only attach two boards to a Connex motherboard (one Connex expansion and one Waysmall expansion) because it has just two headers (one 92 pin and one 60 pin). However, the configuration I listed does seem to have everything I would want in a Linux based microcontroller, including speed (400 Mhz vs the usual 200 MHz or less of similar microcontrollers).

For right now though, I am going to get another Atom Bot Board and Atom PRO, since I can use these right away on WALTER. and my BRAT. Then I will go into my PIC learning phase and get this programmer from Sparkfun. From there it will be on to some Linux based board, such as the Gumstix or Cirrus board from Sparkfun.

I know that isn’t much flash, but I am not sure I will require a lot (even though more would definitely be better). I still don’t know why Gumstix didn’t put at least one USB Host port on the Gumstix motherboards - it makes no sense.

I am running Debian Etch on both my systems now (dual booting) and am sure I would not have tried it if it had not been for you. :slight_smile: So far I am liking it but am wishing there were a searchable database of packages. I did a test build for an ARM toolchain and am about ready to do the real build.

http://www.sparkfun.com/commerce/images/MCP-USB-0.jpg

From the look of it, it may have just one serial EEPROM, but it is PicStart+ and MPLAB compatible. I don’t know if that would imply any compatibility with Linux software or not. I will have to wait until I get the programmer in a month or so and see what else it might work with. Right now, I just want something that works with MPLAB. :slight_smile:

As much as I would like to see Open Sourced PIC development tools, including good IDE and compilers, I have resigned myself to using Windows for PIC development.

I have not built PikLab under Debian yet, but have gpsim and such installed. Please keep me in the loop on your progress with PikLab and your programmer. I look at buying a different programmer if it can be made to work with Linux based software. I’ve forgotten which PicKit2 programmer you have. This should work with MPLAB too, right?

8-Dale

I glad you enjoy Debian. :slight_smile: Please let me know how the cross-compile goes. I wish I could cross-compile MIPS stuff for my router and such but was unable to get that to work. I actually acquired a working SGI O2 (my Indys were too slow and didn’t have full hardware support) and was just going to install the MIPS version of Debian so I could compile natively.

As far as searching, there are two ways to search packages. First is apt-cache search which is the easiest way to find packages if you only half remember the name. For example, (using something I did), I forgot the bare X11 setup is via x-window-system. I tried apt-get install x-windows-system and it failed, so I apt-cache searched x-window and it pulled up the right name.

However, you probably want to goto debian.org/distrib/packages, you can search for files in packages just make sure to use the right search box, the top for package names, the bottom for files and other, and to select Testing (Etch) since they have this for all releases.

As far as my progress in Piklab, I downloaded the rpm and used alien to make it into a .deb. Then I installed that. The gputils package has all the PIC assembly stuff. With that installed, I can write and compile PIC assembly all I want. I did have to make a couple of symbolic links since Red Hat based distributions use different names for two libraries:

/usr/lib/libpcreposix.so.0 -> libpcreposix.so.3
/usr/lib/libpcre.so.0 -> libpcre.so.3

I had to do this before when using rpms, so the install went very quickly.

I then had to compile the PK2 code from source to support my programmer. I had to downgrade the firmware to version 1.0 in windows first, but it works in both Windows and Linux just fine now. Support for version 2.0 in Linux is in development. The downside is besides the experimental PikC compiler (haven’t tried SDCC), I don’t have a working Linux C compiler. Since I actually have a tutorial with the chair of the Computer Science department here in assembly programming this semester (MIPS and PIC, and one of the reasons I’m not on the forum as much as I used to be), I don’t care so much right now. Since PikC is under rapid development, in the future, I think it will be a viable alternative (assuming an Open Source license). SDCC has a Debian package, and I should try it when I have some time.

As far as a programmer, you can see an image in our other thread here: lynxmotion.net/viewtopic.php?t=1771, but it is a PicKit2 clone. Microchip released the hardware plan and firmware (it uses a pic) for the PikKit2, so many people have made clones. Any PicKit2 compatible (unless they say they added stuff or something so it can’t use Microchip firmwares) should be able to work. The one from microchip is actually rather expensive, but I got mine for $45 along with the ziff sockets in the image.

A word of caution, getting the PikKit2 (even a real one) to work under Windows is not plug and play with this version of MTLAB (even though it says it should work on Microchips website), my guess is in a newer release these bugs will be ironed out. You can search for the details, but I couldn’t program from within MTLAB, I had to use the programming utility with the binary, the same as on Linux with PikLab.

:slight_smile: So far, I think Debian is my favorite packaged version of Linux. I tired of RPM managed distributions rather quickly.

I just downloaded and built PikLab from sources. :slight_smile: I had to find and install the dev files for libusb, and then it compiled without errors. I have not tested it yet though. I already have gputils, gpsim, and sdcc installed from deb packages. :slight_smile: This is a complete new type of software development for me but I am getting more and more excited about it as time goes on. :smiley::smiley:

Don’t you have all the GCC development stuff installed for your native system? That’s one of the first things I get installed if it isn’t already installed when I build a new Linux setup. :slight_smile:

It looks like you just have to get your programmer working with PikLab now.

I believe SDCC is also being actively developed, which is good as it will give us more options. I really want to be able to write my PIC code in C/C++.

Ah, OK. Two of the requirements I have for a programmer is it has to be fully compatible with MPLAB and be able to programm all the PICs I want to use. These include the 18F4620/80/85, 18F2620/80/85, 18F2550/4550, dSPC4011/12/13, and a few others. I don’t want to have to buy more than one programmer to program the chips I want to work with. I am planning to get my PIC programmer for my birthday (May).

This is enough to make me avoid the PicKit2 type of programmer. While I am capable of dealing with things at the hardware level, I am at a point where I want to be able to concentrate on my applications as much as possible. My hardware tinkering consists mostly of putting modules together with stock components now. I just enjoy the software aspects more than the hardware aspects these days. :smiley:

I still want to get a Tini2138 to fiddle with at some point also. I can put one just about anywhere on a robot and it would make a great little master controller.

8-Dale

I meant for PICs.

Yea, I don’t know why the PkiKit2 doesn’t work with PikLab. It says it should on the PikLab website. I know my kernel sees it with full ID and such and I have libusb installed. Really odd.

As far as programmers go, yes the PicKit2 doesn’t support dsPICs as of now. It does have the ability to do so in the future (there are greyed out dsPIC options all over in the Windows software), so unless you really want to work with the dsPIC now, I think its an okay buy. The fact the firmware has so many revisions (at least 8 now) and still has future expansion features not implemented basically says Microschip didn’t want to spend a lot of time testing this and rushed it out the door since nearly all the functionality is in software/ firmware. Also, they wanted a programmer that could grow to support new devices which might not exist when the programmer was made. In a year or so I won’t be surprised if it supports the full line of PICs and can do debugging (it is supposed to, but only supports a handfull of PICs as of now) and stache-like stuff.

I also agree the Tinis are a great group of ARM micros. I almost wish I could extend my tutorial to ARM assembly programming too, but that would be way, way to much. The MIPS stuff on higher level (> R3000) cores is killing me as is. Also the fact I have PICs, mainly 18F4620s and 18F4550s, and a working PIC programmer, makes me wary of purchasing new equipment until I have a more complete mastery of what I already have.

That’s odd, for sure. My build of PikLab seems to be working. It does have an item under Programmers for PicStart+, which is good for my choice of programmer. However, not many PICs are supported with a PicStart+ and any of the current toolchain choices. Even fewer 18F devices are supported right now, which I am sure will eventually change.

The dSPICs are on my list of the chips I want to work with, since Pete’s board uses them also and I still want to build at least one of those.

This is fine if you want to wait a year or more for something to support what you want to do. I am not in that group though. When I get my PIC programmer, I am going to want to start working with the PICs right now. :slight_smile:

I agree totally! That’s why I want to master the Atom PRO before I move on to actually using the PICs I have here (many, of various 18F25xx, 18F26xx, 18F45xx, 18F46xx, and a few others plus analog stuff. I have gotten many orders from Microchip, including quite a few analog components. :smiley: After I have created a few PIC projects, I can feel comfortable moving on to ARM and AVR stuff.

I am still watching the Arduino also - the current board is almost setup perfectly for robotics. It just needs a set of 3 pin headers to replace the current single pin headers with power and ground plus power selection like the Atom Bot Board has. There are a few folks wanting to expand Arduino to the Atmega32, which is where I would feel comfortable jumping into Arduino.

8-Dale