Communicating through a GBA's link port

[Spencer E.]

Originally Posted by EHaskins

You can program GBAs. You need a special cartage that accepts an SD/SD micro card, but it is possible.

As for the physical connection I don't know it what you're trying to do is even possible.

If all you want is a terminal/configuration you may want to look into getting a used PDA(with a serial port), and writing a simple terminal app.

If I can get a serial connection from the GBA to the RC could I not do potentially the exact same thing as hooking a laptop up to the RC? The GBA's link port acts almost exactly like a serial port, just arranged differently. I'd rather have to carry a GBA in my pocket out to the field rather than a laptop . Plus, how could would people think it would be if you programmed your autonomous through a Game Boy .

Oh and Astronouth, looking at the IFI programming port pinout it seems as though they do use CTS and RTS in their communication. Do these two pins have to go CTS-CTS and RTS-RTS or does it have to be CTS-RTS and RTS-CTS just like it has to be Tx-Rx and Rx-Tx?

[EHaskins]

Originally Posted by Spencer E.

If I can get a serial connection from the GBA to the RC could I not do potentially the exact same thing as hooking a laptop up to the RC? The GBA's link port acts almost exactly like a serial port, just arranged differently. I'd rather have to carry a GBA in my pocket out to the field rather than a laptop . Plus, how could would people think it would be if you programmed your autonomous through a Game Boy .

Oh and Astronouth, looking at the IFI programming port pinout it seems as though they do use CTS and RTS in their communication. Do these two pins have to go CTS-CTS and RTS-RTS or does it have to be CTS-RTS and RTS-CTS just like it has to be Tx-Rx and Rx-Tx?

I am NOT familiar with GBA programming, but I would think it is possible, if the serial port of a GBA is what you say.

You would not be able to compile code on the GBA, but if you wrote some type of script that would be saved in EEPROM on the RC then it is possible you could use the GBA as a terminal to modify the script.

If you wanted to do something like that I would recommend creating the script and the PC editor, and then porting an editor to GBA.

[Spencer E.]

Originally Posted by EHaskins

I am NOT familiar with GBA programming, but I would think it is possible, if the serial port of a GBA is what you say.

You would not be able to compile code on the GBA, but if you wrote some type of script that would be saved in EEPROM on the RC then it is possible you could use the GBA as a terminal to modify the script.

If you wanted to do something like that I would recommend creating the script and the PC editor, and then porting an editor to GBA.

What my plan was to do is make a pre-compiled list of commands for the GBA that could be compiled into a list of ID numbers that the user could select and make a list of editable (speed, time, distance) commands, which would then store the commands in the RC through EEPROM. Once stored, when autonomous mode started, the RC would read the EEPROM and run the corresponding function related to the ID number that was stored by the GBA.

[Astronouth7303]

Originally Posted by Spencer E.

What my plan was to do is make a pre-compiled list of commands for the GBA that could be compiled into a list of ID numbers that the user could select and make a list of editable (speed, time, distance) commands, which would then store the commands in the RC through EEPROM. Once stored, when autonomous mode started, the RC would read the EEPROM and run the corresponding function related to the ID number that was stored by the GBA.

Sounds a lot like Kevin's terminal menus used in his camera code.

I've been thinking about writing a script that generates those menus and the EEPROM code to deal with it, and the idea that the menu could be driven in different ways (serial terminal, GBA, ...) makes it that much more interesting.

Also, standard serial cables are wired straight (pin 1 goes to pin 1). All labels in RS-232 specs are relative to the DTE (the computer, or in your case the GBA). Which means that the line that the GBA transmits on is connected to the pin labeled Tx.

It seems that "UART" mode would be what you want. If you look at http://www.work.de/nocash/gbatek.htm#siouartmode, you'll notice that there's a CTS mode flag. I recommend setting it to 0 (Send blindly) and wiring GBA SD (GBA pin 4) to the RTS pin. Then you may wire the CTS pin to GBA SC (GBA pin 5). (Pinouts from http://www.hardwarebook.info/Game_Boy_Link.)

One thing that has not been described in the documents is how the GBA's "UART" mode relates to RS-232 settings. Specifically baud, parity, data bits, and stop bits. 8 data and 1 stop bit has become something of a de facto standard. Which leaves parity and baud. I can't remember what the RC uses for these, and I can't find what the GBA's settings are. I guess this is an exercise left to the reader!

[Tom Bottiglieri]

Funny you bring this up. I thought I was an original thinker..

I had an idea similar to this a while back. I wanted to make an open source inertial navigation system for FRC with focus on ease of use and availability of parts. INS's are tough, as you need to have pretty custom hardware including the correct sensory and the horse power to process your signals. So, I figured I could "borrow" and hack up hardware thats available in the market place. Also, I wanted this system to be able to handle other robot functions, such as autonomous control, so it needed to have a screen.

I stumbled upon this., which gave me means to get pretty accurate 3 axis acceleration and yaw rate readings on the nintendo DS. I looked into the DS linux and homebrew projects, along with how to grab hold of an RS-232 serial connection through the SPI port it uses to read games. Running Linux would be my first choice on this, as I could write all of the software with little overhead and its just plain cool.

So, the DS enables you to have an INS with touchscreen for a pretty good price. Unfortunately I haven't had time/money/motivation to follow up on this. Oh well, maybe next year.

[jgannon]

In case anybody is interested, the most recent versions of the Botball controller have been using the GBA for I/O and processing.

https://botballstore.org/catalog/pro...roducts_id=118

[Adam Y.]

Originally Posted by jgannon

In case anybody is interested, the most recent versions of the Botball controller have been using the GBA for I/O and processing.

https://botballstore.org/catalog/pro...roducts_id=118

Im pretty sure the above is just a fancier version of the xport controller.

[Spencer E.]

Originally Posted by Astronouth7303

One thing that has not been described in the documents is how the GBA's "UART" mode relates to RS-232 settings. Specifically baud, parity, data bits, and stop bits. 8 data and 1 stop bit has become something of a de facto standard. Which leaves parity and baud. I can't remember what the RC uses for these, and I can't find what the GBA's settings are. I guess this is an exercise left to the reader!

On the gbatek site you gave me there are bits you can set to fix the baud rate, parity and data rate, so setting those bits to match the settings of the RC should work. Setting them to the right bits would probably be easier through assembly, I find it easier to directly access the memory rather than using C. Using devkitPro though you can use assembly opcodes right inside your C code (as per they do with the initialization of the RC).

[Jake M]

Originally Posted by Spencer E.

What my plan was to do is make a pre-compiled list of commands for the GBA that could be compiled into a list of ID numbers that the user could select and make a list of editable (speed, time, distance) commands, which would then store the commands in the RC through EEPROM. Once stored, when autonomous mode started, the RC would read the EEPROM and run the corresponding function related to the ID number that was stored by the GBA.

Heck, if it's legal to have one on the robot during competition, you could have a whole set of pre-programmed cartridges, containing autonomous routines, and then maybe a separate one for running calibration routines. Personally, I love the idea, and as a fairly experienced GBA programmer (hacker) it's all entirely possible. Heck, I might just try this myself. I can't even remember the last time I palyed my old GBA. And it's not like you'd have to destroy the whole thing to use it. That's gotta be the coolest part.