For Propeller + Biloid interest group

[Brilldea]

lnielsen -

Thank you for the mention of the uOLED-IOC! The IOC is a great companion for the uOLED-PROP-96 by expanding the I/O capability. How many pins is the software dedicating to the AX-12? If you used the uOLED-IOC you have options of connecting the I/O to the GPIO chip or directly to the Prop. Of course, the Prop would have a faster I/O access, but an ASM routine for talking to the GPIO is in the works (whenever I get more time) and that would allow for fast access to the GPIO.

A while ago I thought about desinging some hardware for using the AX-12 and the uOLED product together. Maybe I will have to stir up that idea if there is enough interest. Would a breakout board, sort of like the uOLED-IOC, be desired by the community? The board would have the connectors to hook up the AX-12 and a place to plug in the uOLED-PROP-96. Maybe a button or two or how about a capacitive slider like your IPOD? Your thoughts?

[i-Bot]

The uOLED-96-PROP is certainly challenged on I/O with only really 4 pins available. I only use 1 pin for the AX12 interface, since it is half duplex. However it is possible to have multiple serial buses on the same uOLED.

My carrier board has a 5Volt regulator to drop the 9.6V AX12 supply. It also has an NMOS FET as the voltage translator to/from 3.3V for the serial data.

The AX code is in assembler and would not run off an expander port at 1M bps

If you are looking to a carrier board, it should be small, and have the voltage regulator and the logic translator.

I2C does seem the way to go for other expansion. This would allow available I2C devices like accelerometers, compass, sonar to be used.

For my code, I have been concentrating more on the CM-uOLED code, which is the controller. I diverged from the work at Crustcrawler, though gained some good ideas there. The Crustcrawler code would not work on the uOLED due to the 64MHz clock. I made new code which does work OK at 64M. I also integrated the serial protocol and the checksum into the assembler part. The object just exposes spin methods for the bus commands. I am now looking to read MTN motion files from the SD card and interpet them into bus commands using a COG dedicated to a motion engine.

I have not made much more progress on the AX-uOLED code, which is the peripheral. This has a different interface since it exposes methods to manage an area of Hub RAM similar to the memory map of the AX devices. A seperate COG runs the assembler program which continually monitors the serial bus looking for our ID or the broadcast ID, perfoms commands, and reads/write to the hub RAM. I completed the memory interface, though I had to add I2C and EEPROM assembler routines to use the program EEPROM to save the lower memory segment. The new TX and RX routines in the CM version could also be used in the AX. I am not sure when I will return to this version. I still see no simple way to send data from BCP, except byte by byte, hence my focus on the CM. I already made routines to display 16bit bitmaps on the uOLED from SD card which I use on the RoboNova, but again see no easy way to send filenames from BCP.

[lnielsen]

i-Bot: You are right, the serial bus will always have to run on a dedicated Propeller pin and not through the IOC. I don't know how fast the IOC is, can it only read switches and stuff or can I do audio through it?

Brilldea: I see a couple of ways to go. I like I_Bot's idea of a super AX-S1, it should be register compatible with the S1 but be able to play WAV files and animated GIFs. It would be great to add an accelerometer like this one.

As a controller, I think it would be nice to support both TTL and RS-485 busses preferably as a single bus combined via open-collector so you could add a RX servo if you need more power in a joint. You could have a few buttons around the screen as a soft screen and bluetooth to talk to a gamepad controller

So many great ideas, so little time...

[Brilldea]

Yes, so many ideas and so little time.

With the IOC, you can use it in two ways. One way is called basic mode. This mode has 16 GPIO and 2 dedicated prop pins plus the 2 prop pins used for programming (not to forget the I2C bus as well). Another mode is called extended and requires slight soldering modifications to the IOC and uOLED-PROP-96, but it will open up the ability to have 16 GPIO, 4 dedicated prop pins plus the 2 prop pins used for programming and the two pins used on the I2C bus. So, the IOC really expands the I/O for the Prop.

You guys have certainly been thinking about and realize what you want and need in a carrier board. I need to do more research and studying before I jump into designing a ssytem, but it is very doable to make a carrier with a regulator, AX-12 interface (or two) and a some other buttons and switches with a little I/O left over for experimentation.

As far as audio goes, what are you looking for? If you just want pops and clicks, then, yes, I think the GPIO should be able to handle it with an ASM driver (current driver is in SPIN). I don't have much experience in coding or hardware design for audio, so I better research that or I might eat my words.

Hmmm....I better pick up an AX-12 servo or two soon.

[tom_chang79]

Any more updates to this effort? I've recently been very interested in the propeller microcontrollers ever since I read the article on the propeller-based BOE bot in the Spring issue of Robot Mag...

I would love to see some examples of software as well as the hardware - mechanical and electrical implementations with the Bioloid system...

Did you guys piggy-back this awesome processor with the CM-5 unit, or did you guys replace the CM-5 unit with this venerable microcontroller?