[Featured][Alpha] CLAP - TI Link - http://clap.timendus.com

kalan_vod · Post by **kalan_vod** » Tue 16 May, 2006 4:34 pm

Well that explains it better, and I did read the read me!!

So have you updated it since last time?

Timendus · Post by **Timendus** » Tue 16 May, 2006 11:57 pm

Heheh

I'm glad you think it's helpful.

I haven't updated the library yet online, too much remains unclear about how the network layer has to interact with the interrupt and the user program, and besides that I need to find a good and fast way to test and debug the more complex networking code. The problem is that I'm writing something that I can't test with anything other than itself. I can't just output every value to the screen, because the puts routines give too much delay, which screws up the transmissions, and the only thing capable of talking to the library is the library itself

So it's kinda like driving a car in the middle of the night with your lights off at 150 km/h: you have no idea what you're doing because you can't see a thing, but if you take a wrong turn you've got a serious problem... Slightly demotivating...

kalan_vod · Post by **kalan_vod** » Mon 24 Jul, 2006 1:59 am

Well I am still interested in this, and I hope you can find time to work on it more. Maybe talk with some of the experts? oh wait, you are an expert with the link port XD

KermMartian · Post by **KermMartian** » Mon 24 Jul, 2006 2:23 am

Well, CALCnet2.2 has finally been written (not to be competitive, but you did give me a challenge). What it will support once I debug it (the code is completely written, but I too am running into debug difficulty):

>> theoretically infinite devices on a network
>> seamless addition of noncalc devices
>> no need for a central hub or server
>> no need to negotiate addresses or perform periodic network integrity checks
>> recommended maximum 256 bytes-per-frame, protocol maximum 65536 bytes per frame
>> full duplex communication with several collision and data integrity checks including parity and checksum
>> Designed as an interrupt, so fits perfectly within safeRAM and communicates with programs via two dynamic buffers (one read, one write)
>> total lines: 416; total bytes: 588

However, my main problem is just a limitation of PTI (and it looks like VTI and TiLem have the same issue). we'll see how they do head-to-head in terms of speed, functionallity, and reliability once we both get our stuff fully working.

CompWiz · Post by **CompWiz** » Tue 25 Jul, 2006 9:34 pm

so, it seems you have some competition Timendus. So, can you outdo kerm's features or release it first? :twisted:

Timendus · Post by **Timendus** » Tue 25 Jul, 2006 10:00 pm

Oh, I'm not that easily scared. Let's see a demo or a video first

But let's compare Kerm's claims to the _current_ state of the CLAP:

>> theoretically infinite devices on a network
Why would you want to?

>> seamless addition of noncalc devices
Same here

>> no need for a central hub or server
If by central hub you mean one processor handling routing, then same here

>> no need to negotiate addresses or perform periodic network integrity checks
Addresses are given out, not negotiated, no checks are in place yet

>> recommended maximum 256 bytes-per-frame, protocol maximum 65536 bytes per frame
No frames here, transmit till you drop

>> full duplex communication with several collision and data integrity checks including parity and checksum
None yet implemented, but so far I have yet to come across a situation where I'd need them

>> Designed as an interrupt, so fits perfectly within safeRAM and communicates with programs via two dynamic buffers (one read, one write)
Interrupt yup, but no buffers, only real time communication because buffers make coding for it even more difficult

>> total lines: 416; total bytes: 588
Don't know, too lazy to check, it's somewhere in this topic I believe

KermMartian · Post by **KermMartian** » Tue 25 Jul, 2006 10:55 pm

>> theoretically infinite devices on a network
>Why would you want to?
Don't have any reason to limit it - it's natively unlimited.

>> seamless addition of noncalc devices
>Same here
Excellent.

>> no need for a central hub or server
>If by central hub you mean one processor handling routing, then same here
Yes, that's exactly what I meant; also excellent.

>> recommended maximum 256 bytes-per-frame, protocol maximum 65536 bytes per frame
>No frames here, transmit till you drop
Not worried about one device hijacking the network?

>> full duplex communication with several collision and data integrity checks including parity and checksum
>None yet implemented, but so far I have yet to come across a situation where I'd need them
Real devices run into electromagnetic noise a lot more than PTI.

>> Designed as an interrupt, so fits perfectly within safeRAM and communicates with programs via two dynamic buffers (one read, one write)
>Interrupt yup, but no buffers, only real time communication because buffers make coding for it even more difficult
Fair enough. I found buffers made nonblocking communication possible across the board.

>> total lines: 416; total bytes: 588
>Don't know, too lazy to check, it's somewhere in this topic I believe
I'll see what I can find.

Oh, and CompWiz, I had published stuff long ago (although so has Timendus). I was just too lazy to code it, and to my chagrin, he managed to beat me to the punch.

Timendus · Post by **Timendus** » Tue 25 Jul, 2006 11:49 pm

>>> theoretically infinite devices on a network
>>Why would you want to?
>Don't have any reason to limit it - it's natively unlimited.
I have a maximum of 254 calculators, and I see no way anyone is ever going to need more than that. So instead of adding more overhead I prefer to keep things simple and realistic instead of being too theoretically correct.

>>> recommended maximum 256 bytes-per-frame, protocol maximum 65536 bytes per frame
>>No frames here, transmit till you drop
>Not worried about one device hijacking the network?
Nope, because it's not like the big bad Internet; hackers will still have to physically connect their calcs to yours. And if a program error blocks the network then it's a badly written program and the author should be ashamed of himself. I don't want to take responsibility for that.

>>> full duplex communication with several collision and data integrity checks including parity and checksum
>>None yet implemented, but so far I have yet to come across a situation where I'd need them
>Real devices run into electromagnetic noise a lot more than PTI.

I'm not talking about PTI. I dare say I have experimented more with actual hardware than you have.

>>> Designed as an interrupt, so fits perfectly within safeRAM and communicates with programs via two dynamic buffers (one read, one write)
>>Interrupt yup, but no buffers, only real time communication because buffers make coding for it even more difficult
>Fair enough. I found buffers made nonblocking communication possible across the board.
You're right. But there are timing issues to consider. When I give order to send something I want it to send that data NOW and not when it thinks its time to do so. So when my program reaches the next instruction I'll know that my data has been sent (and received on the other end), while your program only knows that it "should be sent some time soon". That may be nice on a PC where you have all kinds of events happening all the time, but on a singlethreaded machine I don't like that kind of uncertainty.

KermMartian · Post by **KermMartian** » Wed 26 Jul, 2006 12:25 am

>>>> theoretically infinite devices on a network
>>>Why would you want to?
>>Don't have any reason to limit it - it's natively unlimited.
>I have a maximum of 254 calculators, and I see no way anyone is ever going to need more than that. So instead of adding more overhead I prefer to keep things simple and realistic instead of being too theoretically correct.
But that's my point - there's nearly no extra overhead for the infinite possibilities. I assume 254 because FF or 00 is used for all-net addressing?

>>>> recommended maximum 256 bytes-per-frame, protocol maximum 65536 bytes per frame
>>>No frames here, transmit till you drop
>>Not worried about one device hijacking the network?
>Nope, because it's not like the big bad Internet; hackers will still have to physically connect their calcs to yours. And if a program error blocks the network then it's a badly written program and the author should be ashamed of himself. I don't want to take responsibility for that.
I'm trying to anticipate as many problems as possible: bad programming, random disconnection, lots of noise, calculator crashes sending random stuff to the linkport, etc.

>>>> full duplex communication with several collision and data integrity checks including parity and checksum
>>>None yet implemented, but so far I have yet to come across a situation where I'd need them
>>Real devices run into electromagnetic noise a lot more than PTI.

>I'm not talking about PTI. I dare say I have experimented more with actual hardware than you have.
You probably have, but I'm including this for the same reason as above.

>>>> Designed as an interrupt, so fits perfectly within safeRAM and communicates with programs via two dynamic buffers (one read, one write)
>>>Interrupt yup, but no buffers, only real time communication because buffers make coding for it even more difficult
>>Fair enough. I found buffers made nonblocking communication possible across the board.
>You're right. But there are timing issues to consider. When I give order to send something I want it to send that data NOW and not when it thinks its time to do so. So when my program reaches the next instruction I'll know that my data has been sent (and received on the other end), while your program only knows that it "should be sent some time soon". That may be nice on a PC where you have all kinds of events happening all the time, but on a singlethreaded machine I don't like that kind of uncertainty.
As a matter of fact, I have a flag that gets reset by the interrupt when the frame goes through and is acknowledged by the receiver, so you know _exactly_ where it's at.

Timendus · Post by **Timendus** » Wed 26 Jul, 2006 12:52 am

kerm_martian wrote:But that's my point - there's nearly no extra overhead for the infinite possibilities. I assume 254 because FF or 00 is used for all-net addressing?

Yup. Nearly no overhead still is some overhead, plus more complex (to write, to maintain, to port) code, plus more bytes of code for something that you'll never ever need.

I'm trying to anticipate as many problems as possible: bad programming, random disconnection, lots of noise, calculator crashes sending random stuff to the linkport, etc.

Well that's very ambitious, but I prefer a small, fast, easy to code/maintain/port, graceful breakdown (quit with error message or just quit, or jump to program specific error handler if present, don't know yet) over hundreds of bytes of error checking and wasted clockcycles in calculating checksums and whatnot for -again- something that hardly ever happens. By the way; you can never anticipate bad programming. People will always find ways to crash even the most stable bit of software...

As a matter of fact, I have a flag that gets reset by the interrupt when the frame goes through and is acknowledged by the receiver, so you know _exactly_ where it's at.

I guessed you would. It's a nice way to handle things, I'll admit that, but I think we just have very different goals in mind for this. You're trying to recreate the Internet with all it's inpredictabilities, I'm just trying to make a nice and easy to use package for people to make multiplayer games and stuff with. My code is clear, layered, documented, meant to be read. My routines do their job and nothing more. Yours will -I expect- be something external (embedded in Doors CS right..?) that you communicate with through buffers and by calling routines, and you are afraid you'll limit people so you try to put everything in it that anyone could ever need. Where in my setup people can just expand on my routines themselves.

I'm afraid the CLAP will not be ready for the Summer of 2006 Release Spree in time by the way. I still have a lot of documents to write (protocol documentation, manuals and stuff) and some really tricky code to finish. I prefer to finish my other projects first, because I think (hope) they will be less time consuming.

KermMartian · Post by **KermMartian** » Wed 26 Jul, 2006 3:13 am

That second to last paragraph sounds like a very clear and accurate summary of the situation to me, Timendus. I think I'll just fade into the background again for a while in this thread until I have something concrete to show.

Timendus · Post by **Timendus** » Wed 26 Jul, 2006 9:49 am

Well, in that case, seeing that we have very different goals, I don't think we really are each other's competition. More of a developers choice of what suits their goals best. Sorry CompWiz

KermMartian · Post by **KermMartian** » Wed 26 Jul, 2006 12:43 pm

Definitely. Doesn't particularly sound like rabid competition to me.

CompWiz · Post by **CompWiz** » Wed 26 Jul, 2006 1:02 pm

Aww. Well, while I do like a nice competition, I did enjoy the discussion you had, while it lasted. :mrgreen:

KermMartian · Post by **KermMartian** » Wed 26 Jul, 2006 10:07 pm

I actually thought it was pretty helpful in highlighting the differences between our protocols, and it even gave me some ideas indirectly for fixing my bugs.