|
Post by David Murray on Apr 5, 2006 16:36:54 GMT -5
I've been thinking a lot about these picaxe devices every since I saw them here. I'm pretty sure I will wind up using some, these things look great. Trouble is, I really still want to use the DTV as the main user-interface for my project (the shuttlecraft) and maybe even more than one. However, I need to be able to have the DTV communicate with these things.
Let me give you an idea of what I've got in mind. I'd like to have one or two DTV units inside the shuttlecraft with regular LCDs. I already have several composite LCDs from car headrests and Sony PS-one. I'll use those and a PS/2 keybaord for the main user-interface.
Then I'd like to have several Picaxe units around the shuttlecraft doing different jobs. Think of it like a nervous system with the DT V being the brain. The smaller picaxe units could be responsible for reading temperature from various places (Hull, 6 inches underground, indoor, and outdoor) And perhaps some other weather monitoring equipment like humidity, wind speed, etc. I'd like to be able to measure the voltage levels at different places in the electrical system. And I'd like to read the state of every switch in the craft. I'll always make sure each toggle switch has an extra set of poles just for this purpose. So the computer would know even if the lights were on, etc. I'd like to have several hitachi character LCDs (I already have several big, backlit ones.. why not use them?) displaying a variety of information. Most of the information could come directly from the Picaxe controllers. But I want the DTV to have the same information available to it.
So in the end I want information being displayed on the character LCDs independent of the DTV. But the DTV should be able to have a constant datastream comming to it with all of this information so it can be displayed on the screen.
Don't forget my moving lights on the warp engines. I can run those directly from the DTV, I already create an interrupt-driven routine to control those LEDs on a shift register, and it works well. And because it runs on the interrupt routine it doesn't affect the rest of the software. I can vary the speed and pattern by POKEing values to certain memory locations.
so.. now that everybody sees most of my vision for this. I'm looking for some suggestions on the best way to read the data from the picaxe. The DTV doesn't support the i2c protocol. It would probably be difficult to impliment since none of the user-port lines available can generate an interrupt. So I'd need some really simply communication method just using regular I/O lines. But the big thing is, I don't want to drain the CPU time or have to do any complicated multitasking to be able to receive data from the picaxe to the DTV.
Looking for suggestions here.
|
|
|
Post by Jeff Ledger on Apr 5, 2006 20:25:04 GMT -5
I won't get mine to tomorrow night, so this isn't the voice experience talking... *yet* However, the serial lines used to communicate new code to the PICAXE work both directions. How about sending data back to the DTV by serial?
I like the idea of using the PICAXE to do the smaller jobs all around then transmit the data back to the DTV. This is the way I would do it too. You could create a type of protocol that would identify which PIC you were talking to.
The weaknesses of the PICAXE are strengths in the DTV. The PICAXE tune command is lame, (a lot like the old apple sound) and the idea of having to use an LCD doesn't seem as attractive as full-color formatted data from the DTV.
BTW, a little off topic, I assume you are going to program simulations into this shuttle-craft. Are you going to use any hydraulics to shake the craft or at least the inside floor to add to the effect?
Jeff
|
|
|
Post by David Murray on Apr 5, 2006 21:17:02 GMT -5
Well, I had considered using the built-in 2400 baud serial lines. However, that would be difficult to impliment. As my discussion over on comp.sys.cbm has revealed, the part of the user-port that handles RS232 is not present on the DTV. (that rules out using terminal programs on the DTV without modification) I am not sure it would be feasible to create a software based 2400-baud asynchronous setup on the DTV. It would eat up a lot of CPU time and make the software programming more difficult.
However, I realized earlier today that some of the picaxe chips have interrupt capability. That being the case, I could have it be the slave and the DTV could send out a clock signal when it was ready to recieve or send a bit of data.
|
|
|
Post by pyrofer on Apr 6, 2006 7:39:07 GMT -5
Yes, this would be the best way. Have 2 data lines from the userport, a Clock and data. Give each PIC an address, and the simply clock out commands, clock in data. (maybe a third reset line). You could do something like a command to read data from the pic and send it as 2 byte values, the address and the command 'read' and then clock in 2 byte values back (16 binary inputs, 2 8bit analogue inputs) etc. Giving each PIC its own address even with just a byte (255 pics!) would allow huge expansion. Obviously the more data you clock in/out the less time the DTV has for showing cool stuff on screen. You could also go for something like this, www.dontronics.com/micro-vga.htmland use a real PIC 18f2620 (LOADS of ram) There are free C compilers for the PIC too. I can also recommend this, www.dontronics.com/micro-lcd.htmlfor direct display from the PIC Both of these displays are perfect for displaying information from a PIC or DTV in addition to the Composite output Hope ive given you lots of ideas.
|
|
|
Post by gmoon on Apr 6, 2006 8:00:21 GMT -5
Everyone has a favorite microcontroller You can generate VGA and composite video with the AVR, too. www.serasidis.gr/circuits/AVR_VGA/avr_vga.htmwww.eyetap.org/ece385/lab5.htmUsers of both the PIC and the AVR have made standalone video games with the micros only and no additional video parts. Regarding the comm protocol, why not ask Daniel, since he's already done it? (JS port <-> PC interface) And all joystick buttons on the DTV are bidirectional, so you have more than 8 inputs for your tasks, certainly. The DTV may not be i2c ready, but since the I/O pins are tri-state you can still tie them together in a bus from multiple satellite controllers. I don't know much about the PICAXE, but you might be limited to the protocols already defined on the chip--not sure if you can escape the Basic lang.
|
|
|
Post by David Murray on Apr 6, 2006 11:17:24 GMT -5
Gmoon, I won't use the joystick ports. Keep in mind a few things. One thing is that the hummer units (all I have access to) only have 3 joystick lines available. But the main thing is that I plan on having a PS/2 keyboard attached and need to be able to use it. The only way to use the joystick ports for input/output is by disabling the keyscan routines. I have 9 other I/O lines available (user 0-7 and the cassette sense is also avaiable on the DTV board) and I'm sure I can make those do what I need.
I like the LCD displays. I also like the VGA adapter. Neither of them will work very well for my application. I'm trying to be as cheap as possible. So there won't be any VGA compatible screens. The LCDs I'm going to use are cheap Hitachi character LCDs. I already have those and can get more of them dirt cheap. You can buy those screens online brand new, but most people never think to pull them out of used, broken equipment. Anytime I see a printer, fax machine, fancy office telephone, etc.. being thrown away, I take the LCD out.
|
|
|
Post by gmoon on Apr 6, 2006 12:28:58 GMT -5
The FAQ home.earthlink.net/~dgdtv/Serial: PA2 is Test pin 10 (from the Schem) Just clear the interrupts and read the js port lines from machine code. It's the most reliable way, anyhow. I think I was always accidently pressing the js buttons when I first added the keyboard. I'm only commenting on the fact that you have an embarrassment of wealth here. I love LCD displays This is driven by a ede702 (just a proprietary PIC), I would make my own driver now that I have some micros to play with. I totally agree that the strengths of the DTV are as an interface.
|
|
|
Post by David Murray on Apr 6, 2006 16:38:27 GMT -5
Well, not exactly. If you clear interrupts then your keyboard won't work until interrupts are turned back on. ANd if you have other things connected to the joy ports that are actually holding certain lines high/low, then it will interfere with your keyboard and you will type the wrong letters. Just try holding down your joystick in a certain position and type with it.
I did figure out a way to use the joyports as inputs and outputs with the help of some circuitry. For example, you could combine two lines using an AND gate and make sure they are two lines that would not normally be set high at the same time by the keyscan routine. Then anytime your software needed to output a signal, it could set both lines high. inputs could be done in a similar fashion allowing you to disable the scan routine, set a certain combination high to trigger a gate to allow an input to come through temporarily. THat was something I was considering in order to use my original DTV (NTSC, version 1) as controller for the LEDs since it had no user port. But before I implimented the idea, I found out about the hummer and it's user port.. and of course the flashram makes it much more desirable for this type of thing.
|
|
|
Post by gmoon on Apr 6, 2006 18:16:25 GMT -5
Ahh, sorry--I assumed you understood that you would restore the interrupts immediately after polling the joysticks. The routine would take much less time than the keyboard poll. You won't loose any keystrokes. Well, no more than you would loose normally. ALL interrupt-driven routines have limitations. If course, if you use the joystick ports for bidi communications, you might loose some keys, but the c64 handled a slow async serial port and still polled it's keyboard every 1/60 of a sec. What you describe is a form of handshakeing, which you'd have to implement so no input arrives during the keypoll. But you could just pull a line lo or high to signal to the sender that it's OK to send. Outside of that routine, no data would arrive. Anyway--I'm not saying you should use the jsport, only that you could. If you don't need it, and it's a hassle, then don't use it
|
|
|
Post by kaos116 on Apr 6, 2006 23:53:48 GMT -5
I am not sure this is possible with the DTV unit, but I had to add some receive lines to a single board computer that didn't have any IO's left. What I ended up doing was using the PS/2 keyboard port. If you can do a little multiplexing. You can get the data in through this port and use it as you want. Let me try to explain it this way. If you can put one call routine in your code at a time when the keyboard is idle. You can get data in from another source by piggybacking the PS/2 lines. The CPU can route this other data to a spot in the program that it is needed. If you are only wanting simple data ie. temperature, time, humidity. These are simple data bytes and can be pushed in very quickly at 9600 baud.
Just my 2 cents.
Good luck,
Todd
|
|
|
Post by gmoon on Apr 7, 2006 8:02:21 GMT -5
That's a cool idea.
If (my) memory serves the c64 had a small keybd buffer (10 - 16 bytes, something like that), so you'd just have to keep up with that.
|
|
|
Post by David Murray on Apr 7, 2006 9:31:36 GMT -5
You know, there are lots of PC parts that interface with the PS/2 keyboard port. One thing that comes to mind are credit-card swipe readers and barcode readers. They usually just send the alphanumeric information just as if it has been typed in by the keyboard. I wonder if those would work on the DTV. I know the keyboard routines are kind of slow. I can type faster than the C64 can read.
|
|