ybox2 working!

darco

I finally got the finished PCB for the ybox2 in the mail yesterday. I populated it last night, but I ended up running out of parts. A quick run to Fry's combined with some early-morning soldering, and behold...



It works! Woo-hoo! Now comes the hard part: the Propeller TCP/IP stack. [noparse]:)[/noparse]



I actually plan on writing an IPv6 stack first, and then building an IPv4 stack on top of it. I'll be using the ENC28J60/SP driver from PropTCP as a starting point.

There are a few minor changes I need to make to the layout. After that, I plan on making a batch of around 20 boards. I'd be happy to send some PCBs to people to play with for around $10 each, including shipping. Send me a private message if you are interested.


(My blog post of this announcement)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
—
darco
www.deepdarc.com/

Dgswaner

Congratulations! I've been eagerly watching your project. I don't know enough about this to help getting this up and running, and admittedly I don't want to dive into this deep enough to help.... at least right now, my plate is just too full for more. But Let me know when I can buy one! Dang this is cool! are you planning on marketing these?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A complex design is the sign of an inferior designer." - Jamie Hyneman, Myth Buster

DGSwaner

Spork Frog

Sweet! I've seen your v1 before, looks amazing. Can't wait to see it when you get all the code work done.

darco

Spork Frog: I just wanted to clarify that the original ybox was created by Uncommon Projects, not by me. I'm just taking the idea and trying to fix the things I didn't like about it. A more detailed explanation is on this blog post.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
—
darco
www.deepdarc.com/

Harrison.

I've actually completed a real ipv4 sockets layer for my tcp stack project. It enables connecting to a server and listening for incoming connections. The code is still in beta since I am still regression testing (I made so many changes for optimization that I now have to retest everything).

It currently supports:
- Linux Kernel 2.4/2.6 Clients (telnet)
- Windows 2003/XP Clients (telnet / raw tcp sockets)
- Linux / Windows HTTP Servers (IIS 6, Apache 1.3 / 2, HFS)
- Gateway (router) support (tested on Netgear/Linksys/Linux routers)
- Multiple socket/buffer support with cross cog support
- TCP window sizing based on buffer size (allows the stack to receive large amounts of data without having to use a large buffer)

Does NOT support:
- IPv6 (none of my routers support it...)
- DHCP/DNS/ICMP (I have no need for it right now and I don't want to waste code space)
- ARP caching (saves space that way)
- Using FIN close states. Currently uses RST to kill / close connections. This needs to be fixed eventually.

It all fits in 1931 longs (including program and var space). I spent a huge amount of time optimizing by trial and error and using tons of constant()'s.

Latest Beta (this one includes a tv weather viewer for demo purposes):
harrisonpham.com/embedded/PropTCP/beta/eth_top_tv_weatherbox%20-%20Archive%20%20%5bDate%202007.12.05%20%20Time%2015.58%5d.zip

EDIT: Fixed 'not supported' list.

Harrison

Post Edited (Harrison.) : 12/5/2007 10:44:26 PM GMT

darco

Harrison: I gave your program a try on my board, and it worked great! All I had to change was the pins assignments for the enc28j60 and the IP address.

In case anyone was wondering, my pin assignments for the ybox2 are:

P00 - ENC28J60 RESET
P01 - ENC28J60 CS
P02 - ENC28J60 SCK
P03 - ENC28J60 SI
P04 - ENC28J60 SO
P05 - ENC28J60 WOL
P06 - ENC28J60 INT
P07 - ENC28J60 25MHz Clock

P08 - Speaker
P09 - LED Red
P10 - LED Blue
P11 - LED Green
P12 - TV DAC
P13 - TV DAC
P14 - TV DAC
P15 - 38KHz IR Input

P16 - Button
...

All of the other pins, except those for the serial EEPROM and the prop-plug, are free. They can be easily used for tinkering via the EX1, EX2, and EX3 headers.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
—
darco
www.deepdarc.com/

Drone

Darco, This is sweet. Some questions & comments:

1. I need a QWERTY keyboard attached to make a simple text messaging appliance. Do you think the IR receiver would work with an IR keyboard, if so does an object exist for this or do you think a a wired keyboard object can be modified?

2. I will also need an object for hanlding a dynamic DNS service like DynDNS or perhaps OpenDNS's free(?) DNS-O-Matic announced several days ago (www.dnsomatic.com). Your thoughts?.

3. Any thoughts on supporting IP/UDP?

4. I visited the cool project page you've put up - but can't find a schematic for YBox2.

5. After trying Harrison's TCP stack in your YBox2, how many simultaneous sessions can it handle?

Regards,

David

darco

1) As long as the keyboard is using the same carrier frequency as the IR sensor, I don't see why this wouldn't be possible.

2) I believe that dyndns uses an HTTP push to update, which would be pretty easy. You'll likely want DNS and DHCP support as well.

3) Looks like harrison has done some work for supporting UDP

4) The schematic is a mess at the moment. I want to clean it up a bit before posting it.

5) The code just goes to his website, grabs some pre-formatted austin,tx weather, and displays it. It loops every thirty seconds. It doesn't do anything else, so there isn't any concept of a session to test.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
—
darco
www.deepdarc.com/

Paul Baker

I would think using a wireless keyboard which has a PS/2 termination on the PC side would be the simplest method of going wireless, you use the technonloogy built into the keyboard and it just appears as a standard keyboard to the Propeller.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Harrison.

3. Any thoughts on supporting IP/UDP?

UDP isn't hard at all. It is a single packet non stateful protocol (WAY easier than tcp). My http server demo includes a UDP echo server if you want to take a look at that.

5. After trying Harrison's TCP stack in your YBox2, how many simultaneous sessions can it handle?

The new sockets layer currently handles 2 simultaneous socket connections by default. You can handle more by changing a constant and copying and pasting 5 lines of code to reserve buffer/socket state space.

Harrison

Drone

Paul, Yes an IR keyboard with a dongle would work "out of the box", but then I have to add the PS/2 socket to the ybox and it looks like there may not be enough board space for an elegant solution. It would be much better IMHO to have the keyboard connect via the native IR on the ybox2. Hmmm.... Now where did I put that old IR keyboard?

I have yet to study how the likes of DynDNS works. I've used Server-Side Includes to return IP addresses from a remote Apache Web server then scraped the address off what comes back with a Perl script (obviously not using a Propeller though). A list of other addresses for other "peered" text messaging boxes could be returned as well, building a static routing table if you will. So if the server queried is at a fixed IP address using this technique, perhaps DNS would not be needed. I'm not so sure DNS support would be required provided the likes of DynDNS either, especially if DynDNS servers are at a fixed IP. A real glitch pops up here when you consider security though. If you're going to be transmitting connection tables with quasi-fixed IPs, it would be better to use a secure protocol like https or ssh. Computationally this may overwhelm the Propeller(?)

I agree UDP is way simpler to implement than TCP. That's why I asked; I would assume that like other stacks, UDP was built first then TCP added. So Harrison, is UDP already in your stack or does it need to be implemented? I haven't looked at the source yet and don't have the hardware to try it. I'll have a look at the HTTP server too.

Harrison, you previously stated "Multiple socket/buffer support with cross cog support". Are connections spawned in different cogs? Can the stack get to 4 or 5 simultaneous low-rate (people typing on a keyboard) TCP sessions? In the worst case, this would be a mesh connected network of 4 or 5 boxes with everyone typing simultaneously and data coming in simultaneously. The incoming data would appear with a sender ID followed by all user characters up to the first newline in first-come-first-displayed basis, envision Propeller mini-IRC amongst a closed group.

Given the potential protocols involved including the potentially computationally difficult secure connection issue and multiple session support, I was starting to lean toward an embedded Linux solution for the primary platform with the Propeller glued on primarily as a video display card of sorts. But success of ybox2 has me revisiting this.

Thanks for the discussion...

David

Max Wooden

I built a ybox at Maker Faire back in May and while I absolutely love it, there were some improvements that were needed. Look like you hit the nail on the head! I will be interested in getting a board from you when it's ready.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Max Wooden
Reedley, California

Post Edited (Max Wooden) : 12/7/2007 9:06:20 AM GMT

Harrison.

Drone,
I currently don't support UDP due to the fact that most of my stuff goes over the internet. The issue with UDP is that your application layer will need more smarts to ensure people don't break your application by injecting random stuff.

From what it seems like, you already have a centralized server of sorts (I believe the YBox/YBox2 relies on a central server also). I would recommend using this server to handle all data, kind of like a IRC server of sorts. You could skip implementing your own protocols by using http + webservices. This way, you don't need to open ports on firewalls and the Propeller won't be overwhelmed by huge amounts of data. Think of it as a server side, web based chatting application.

"Multiple socket/buffer support with cross cog support" means that you can call the public functions from multiple SPIN cogs. The code will always use 2 cogs (one for packet processing, and one for low level assembly SPI). Incoming/outgoing packets are all processed in a single thread for simplicity (I couldn't figure out a good way to share enc28j60 communication between cogs). This is all transparent to the user code through the use of socket handles.

I'm hoping that Darco will be able to write a more optimized tcp implementation than I did. Mine is a bit slow due to the single threaded socket send/receive (a flood of incoming packets will slow down the outgoing packets). I'll do some benchmarks this weekend to see what kind of transfer rates I can get with mine.

Darco,
I forgot to say that I would also be extremely interested in obtaining a board from you when it's ready for prime time. I've been meaning to design my own miniature board, but I am lazy and can't really afford expensive single board manufacturing on my college budget.

Harrison

Post Edited (Harrison.) : 12/7/2007 8:53:38 AM GMT

Drone

Harrison, Yes - I initially thought about using my remote server to run the whole shebang but I would really prefer no single point of failure. You've outlined the advantages of the server based approach nicely. But now it's obvious I'm going to have to deal with this dynamic DNS issue, and that's going to force me to interact with a remote server of some type anyway. So it might as well be my own.

Right now the idea is just an appliance to communicate with some family members back in the US (I'm in Jakarta). What I envision ideally is a little set-top box that blinks a light and (optionally) beeps a buzzer when a message is waiting or someone is "calling". The user watching TV can just pick up the remote and switch the A/V input to the box to reply. I can't get my Father to take up text messaging (much carry a hand-phone consistently in the first place) and email isn't really as interactive as I'd like.

I was looking for my old IR keyboard when I ran across a Linksys WRT54GL wireless router I modified to run Linux. I also added a couple of real serial ports and broke out some GPIO pins on this little $50 Linksys box. All I need to do now is make a serial to TV interface out of the Propeller and figure out how to drive a keyboard with the WRT54GL. It already has WiFi to connect from the set-top to/from the main router/firewall/WiFi A/P in the house. Look Ma no Ethernet cable on the floor! Hmmm... Dealing with the tool-chain and creating or modifying the keyboard and/or infrared (LiRC) drivers for the Linksys box may be a bit of a steep slope to climb.

Regards,

David

Post Edited (Drone) : 12/7/2007 10:55:45 AM GMT

darco

I've made the following changes to the board:

* The pull-up resistor for the EEPROM was moved under the prop
* The EX1 header was expanded to include pins 31,30,29,28.
* Added a jumper in series with VDD and the regulator output. I figured it would be useful for calculating the current, or in case you wanted to add resettable fuse. If nothing else it could just have a wire soldered across.
* Moved the resistors for the video DAC away from the edge of the socket. (It turned out that I had to remove part of my socket to get it to fit properly with the old location of the resistors.)

I also want to add some headers for VSS and VDD near each of the EX headers. If anyone has other ideas for things to change, let me know. If all goes well, I'll be making the order next week.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
—
darco
www.deepdarc.com/

darco

Here is the updated schematic.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
—
darco
www.deepdarc.com/

Dgswaner

Draco, I'm putting my YBox2 together, I have a few questions?

Do you have a value for C9 and C10?
On your Schematic dated 12/12 C8 and C3 show a value of 10uF is this correct? I'm hoping it's .1uF, 10uF will be hard to fit in these locations.
I can't find C15 on the Schematic but there is a C15 labeled on the board.
L1, I saw that you just had a wire jumper do you have a value for the inductor... I tend to fry things and like the idea of a "slow burning fuse"

I ordered your exact parts list from your Blog and the only parts that It missing are C1 C2 SP1 and LED1. I'll try and find the part numbers and post them to make a complete list.

I'm very excited about this board! unfortunately I have to wait for my Propeller chip to get here.... and I can't order it until the 1st. ;(

Thanks

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A complex design is the sign of an inferior designer." - Jamie Hyneman, Myth Buster

DGSwaner

Post Edited (Dgswaner) : 1/24/2008 3:30:12 PM GMT

darco

Hey, sorry for the late reply. As you mentioned, I have been very busy and I haven't been monitoring the forums.

C9 and C10 are not critical, but around 0.1uF is what I'm thinking is reasonable. What's more important is the voltage rating (needs to be "high") of such caps. Unfortunately, I'm no EE, so I'm not sure what's the best values. I put them on the board for completeness sake, but I've left them empty on the boards I've populated.

I used the wrong silkscreen pattern for C8. It's a tight fit, but I've managed to squeeze a 10uF cap into there without any problems. It doesn't need to be very high voltage—a 10uF, 5v cap would suffice, as it is the cap for the on-chip 2.5v voltage regulator. Take a look at this picture to see how the caps fits on my board.

C3 on the schematic I'm looking at is 0.1uF.

C15 is next to the speaker, SP1. It is 0.1uF.

C1 and C2 are pretty flexible. I'm using 22uF caps on the second one I built because that's what I had on hand.

The inductor was described in the datasheet as "a ferrite bead", so I would assume that it is for noise suppression more than anything else. Not having a ferrite bead on hand, I used a wire instead, and it seems to work fine. Your guess is as good as mind.

By the way, I've since updated the ybox2 tin drill guide based on some experience using it. You should use it instead and ignore the earlier one.

www.deepdarc.com/ybox2

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
—
darco
www.deepdarc.com/
[url=mailto:xmpp:darco@deepdarc.com]xmpp:darco@deepdarc.com[/url]

Post Edited (darco) : 1/24/2008 6:25:06 PM GMT

Dgswaner

Thanks for the info this will allow me to complete my board tonight, except for the Propeller chip. I think I may go donate plasma so I can get one sooner!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A complex design is the sign of an inferior designer." - Jamie Hyneman, Myth Buster

DGSwaner

darco

Just a quick note for everyone who is interested... I've attached to this message my "ybox2 bundle". It contains eagle files, gerber files, schematics, drill guides, and some source code to get you started. Everything is released under the GPL, in the spirit of the original ybox.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
—
darco
www.deepdarc.com/
[url=mailto:xmpp:darco@deepdarc.com]xmpp:darco@deepdarc.com[/url]

Ym2413a

That's very cool. [noparse]:)[/noparse]
I like the fact that the chips are all DIP.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Share the knowledge: propeller.wikispaces.com
Lets make some music: www.andrewarsenault.com/hss

lee oswald

lee oswald says:

I'm new to ybox2 started in late 2010 with three ibox and one usb adapter 3v.
Your code saved my project and also saw that ybox2 works!
but measuring the size of the packets I saw that I'm getting a maximum size of 150 bytes.
I took the liberty of running your WeatherUpdate and got 181 bytes.
this is some restriction of widgets or assembler code?.
where I could increase this value? tried in several places without sucess.
would be great help to me an indication,
even though it was brief.

need at least 300 without fragmenting the packets.
appreciate any help in advance.