It looks a tad wrong XD very wrong in fact
qazz42 wrote:
It looks a tad wrong XD very wrong in fact
It's a link cable. >_< Grow up, please.
So my first order of business, I think, is to use an Arduino or two to make a visual LED line debugger that will flash colors based on the CALCnet line state (cf. my Arduino to TI-84+ video for an example of that in action). That will save me from having to blindly guess the state of the lines, or use a limited emulator like PTI in that screenshot.
cough * looks nothing like a link cable* cough
Oh, fine, my teenage mind aside, I think some LED light would be great
Oh, fine, my teenage mind aside, I think some LED light would be great
qazz42 wrote:
cough * looks nothing like a link cable* cough
Oh, fine, my teenage mind aside, I think some LED light would be great
In an ideal world, I would be using an oscilloscope to debug it, but I unfortunately don't have one at my apartment. I wonder if there's a such thing as a simple Arduino-based oscilloscope build...
Oh, fine, my teenage mind aside, I think some LED light would be great
And indeed:
http://www.practicalarduino.com/projects/scope-logic-analyzer
http://accrochages.drone.ws/en/node/90
*bump* Just to keep everyone up-to-date on this, I don't see to have actually documented the protocol used in the current 834-lines calcnet2.asm file, so I brought it with me this morning on my netbook to start reverse-engineering on my commute to and from work. I'll try to complete it by this evening or tomorrow, and commence testing of the current system with a logic analyzer monitoring the network lines whenever I finish that.
Yay, Cemetech6 mobile is just barely useable enough that I can post from my phone now! Sure, I would appreciate testers, but I realized that I need to add one more feature. Currently, there are only point to point messages, but for many things I will probably need one to many messages so that a calculator can ask about all the other calculators on the network. I am debating about the proper way to implement that.
So, how is CALCnet going to interact with DCS? Will you have it so that it is a separate app or will it be in-built to DCS?
For now, it will be separate. If I can get it to be sufficiently small and stable, I may reintegrate it with DCS.
Some thoughts while riding the rails today:
Code:
Some thoughts while riding the rails today:
Code:
To sent a packet:
----------------------
Wait for low clock line
Hold clock low for 1/60th sec (100,000 cycles - waste? I think so, but maybe not)
IIRC, pull down data after 100,000 sec and commence transmission
[5 byte sender] [5 byte recipient] [2 byte length] [length bytes]
I think this is correct, anyway.
Would be an important idea: checksum would be a big help here, even an 8-bit CRC (see Tari's thing).
To Receive:
==============
Check if clock is low. If so, see if it stays for (at least 6000?) cycles. If so, someone's sending.
Grab the first 5 (10?) bytes and see if it's for us.
To Add:
========
Seems to me that there needs to be some way to explore the network, for example to probe out what other devices are on the network. THe application level can then be responsible for doing something with that, like trying to list the contents of each network device.
> Details: If a device sends a broadcast request to the network, it would be important that devices outside the network (like other calcnets connected via gCn) did not respond. How to prevent this? Just denying network population requests from propagating past a gCn bridge would probably work, but might bring its own limitations.
> Problem: With a normal packet sent, a device might expect to receive one or zero responses one time. With a network population probe, the sender would not know how many responses it should return.
> Another problem: How to detect when a device LEAVES a network? what if it's just disconnected or turned off or crashes? A "disconneting" packet is insufficient. Perhaps some kind of application- or protocol-level ping packet to verify recipient existence?
Possible idea for solving current problems: does the recipient address comparison break byte sequence timing?? Check this.
graphmastur wrote:
Is there a diagram of how these calcs are supposed to be connected?
For the trivial cases of two to four calculators, a simple star hub (connect all the calculators in parallel with no intervening hardware) is sufficient. I'll be posting some photos of my Arduino at the center of such a network this evening once I get my testbed set up. For a larger number of calculators, some kind of high-speed intermediary hardware will be necessary to assist with line pulldowns, but I haven't gotten to dealing with that case yet, nor ascertaining at what number of calculators that becomes necessary. I also haven't designed the gCn hardware, if any, yet. At this point, I'll either try to use libticables and the SilverLink to individually play with the two lines, or I'll write an Arduino intermediary. qazz42 wrote:
so, wait, how many calc will be needed to set up calcnet?
Just two, but obviously I'll be testing and demonstrating much larger networks.
ah, this will be great, now I have an excuse to get a third calc XD
BTW, how would one set CALCnet up? or is that being worked on?
BTW, how would one set CALCnet up? or is that being worked on?
So I set up a basic testbed using an arduino, a unit-to-unit link cable cut in half and soldered onto headers, and a breadboard. The Arduino is tapped into the middle of the calc-to-calc cable, and I tested the two calculators as perfectly capable of sending and receiving variables in this testbed using the TI-OS options therefore. I'm working on writing a small oscilloscope-type logic analyzer in Processing, modifying an existing program called ArduinoScope, which is extremely poorly documented. I'll post screenies of that once I get it working. As you can see, this current only supports two calculators, but adding more is as simple as cutting up another or more link cables and soldering on the headers.
Nice!
If OTZ80 ever comes alive, I think CalcNet3 could be used to set up a classroom network, and hook up the OTZ80s to it for educational use.
Any thoughts on that?
If OTZ80 ever comes alive, I think CalcNet3 could be used to set up a classroom network, and hook up the OTZ80s to it for educational use.
Any thoughts on that?
Thanks. CALCnet3 could absolutely be used to set up a classroom network, even with TI-84+ calculators and limited extra hardware. Needless to say, I don't see a lot of teachers adopting it. I have designed CALCnet3 to be more or less OS-independent, though; the interrupt just needs about 270 bytes each for the send and receive buffers somewhere in memory, and it's happy.
And now, the SOFTWARE side of my network analyzer (netalyzer?) setup! I got the analyzer/logger working; here's a log of it sending DoorsCS7 from the TI-84+SE to the TI-83+. The top plot is the red wire in the unit-to-unit cord, and the bottom plot is the white wire. I have it set to a slow scrolling speed, so you can't see the details of the individual packets. Isn't it nice to see how much empty "air", or "wire" if you will, that the TI-OS linking protocols leave between each send and transmit packet? Huzzah for efficiently-written bcalls, not. I'll be loading up the previously-written CALCnet2 driver tomorrow, and we'll see how it performs.
And now, the SOFTWARE side of my network analyzer (netalyzer?) setup! I got the analyzer/logger working; here's a log of it sending DoorsCS7 from the TI-84+SE to the TI-83+. The top plot is the red wire in the unit-to-unit cord, and the bottom plot is the white wire. I have it set to a slow scrolling speed, so you can't see the details of the individual packets. Isn't it nice to see how much empty "air", or "wire" if you will, that the TI-OS linking protocols leave between each send and transmit packet? Huzzah for efficiently-written bcalls, not. I'll be loading up the previously-written CALCnet2 driver tomorrow, and we'll see how it performs.
http://brandonw.net/calcstuff/network.jpg
awww, I expected it to look a bit like this ^
I am going to need to learn to solder....
awww, I expected it to look a bit like this ^
I am going to need to learn to solder....
qazz42 wrote:
http://brandonw.net/calcstuff/network.jpg
awww, I expected it to look a bit like this ^
I am going to need to learn to solder....
As I said, I'm not going to be connecting lots of calculators together yet, but I eventually will. There's no point trying to unravel and debug network activity between eight calculators before I get two talking to each other reliably. awww, I expected it to look a bit like this ^
I am going to need to learn to solder....
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
» Go to Registration page
» Go to Registration page
» Goto page Previous 1, 2, 3, 4 Next
» View previous topic :: View next topic
» View previous topic :: View next topic
Page 2 of 4
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Advertisement