I am about 2/3 completed on writing the Ethernet drivers for a Realtek RTL8019AS controller. This allows for a 10MB ethernet connection to a local network and/or the Internet. I have successfully implemented the ARP (hardware address resolution), ICMP (Ping response), UDP, and TCP/IP telnet server on a basic level. I was able to telnet into my SBC computer from the Internet. I am also working on an HTTP server implementation. I still want to add FTP server code to round out the package.

So far, I've used about 4k of memory. To get where I want it to be, will require about 6-8k, including buffer memory.

My question is, if you wanted to add ethernet to your system, would you prefer to let the 6502 do the work, or would it be desireable to let a dedicated controller handle the low level stuff and just let the 6502 pass control commands and the high level data.

The advantages include less memory needed and less processor time spent handling all the low-level protocols.

The disavantages include interfacing the controller and creating the control command structure, and the complexity of having multiple processors in your sytem.

Not to mention some just don't want non-6502 processors in their system (I was considering an AVR in this case).

What do ya think?

Daryl

This is a tough call. What does your specific application call for?

Dedicated processors are great when you're looking at a well-defined interface of some kind. However, as soon as you operate outside the scope of that interface, you start running into protocol-related problems.

For the Kestrel, I was going to let the CPU manage the Ethernet interface.

There is a lot of steps to receiving, verifying checksums, decoding packet types, capturing actual data payloads, configuring responses, forming outgoing packets, etc. If you are only running a single application, then using the 6502/65816 to do all of the manipulation won't be a problem as you'll be waiting for the data payload either way.

However, if you are trying run multiple tasks, and only one is working with the ethernet, then you'll be slowing down the other tasks and/or slowing down the data throughput by using the 6502.

Me personally, I hope to have a system that can focus on the task/tasks at hand and not get burried in the low-level manipulation of I/O devices.

For example: Creating the "SBC web server". Now, on top of processing ethernet I/O, you'll have to access a good-sized file system. If we have the 6502/65816 do all of the low level ethernet I/O and the low level storage system I/O, will there be any time left to process some external stimuli that might be used in our web pages? Home automation/security monitoring/status reporting/etc applications where you want to use the Internet to access your system without needing an entire PC running 24/7.

Anyhow... I am currently working on the ethernet I/O and FAT16/32 support for compact flash storage. By using an AVR to handle the low level I/O, I can allow the 6502/65816 to spend more time processing the data collected by the various I/O sources.

The AVR's provide such resources as UART/SPI/I2C/ADC/PWM/general purpose I/O that make them ideal for data collection. The 6502 is better suited to perform the manipulation of the data and control the flow.

Thats my thinking....

Daryl

10 megabit ethernet = about a megabyte/second transfer speed.

6502 at 1 Mhz = about 100 kilobytes/second transfer speed.

Better to let the controller do it.

Toshi

The 6502 SBC I'm working on at the moment will have a co-processor to manage its ethernet. I didn't thing my 1Mhz processor was up to it so I'm using 18F pic at 40Mhz.

I'm trying out the Microship SPI based ethernet adapter chip ENC28J60 (on an EDTP breakout board).

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Remember that IP was invented at a time when processing power was *SO* expensive that even logical ANDing netmasks was considered too much overhead (hence why localhost is assigned an entire class-A for itself).

IP isn't hard to manage if you factor your code correctly. BSD sockets is not an example of what I'd call "well factored." See the uIP stack for an example, non-sockets-derived TCP/IP stack that also supports UDP, and does so quite efficiently.



If you implement a sockets-like API that exists in the core OS and runs as a "kernel thread," yes. But that's a lot of conditions!!! If you run TCP/IP management code as an application-layer package, it can be task switched along with everything else, thus guaranteeing rapidity of real-time response to external stimuli. The tradeoff is that instead of 20ms ping times, you might now get 40ms. Big deal.



It sounds to me like you've already made up your mind then, and I have to question why you bothered asking in the first place.



Several things.

1) Ethernet has the capacity to swamp the processor, no matter what -- EVEN IF you use an external, dedicated controller. So, no matter what is going to happen, your CPU is going to be too sluggish to keep up with a 10Mbps solid transfer rate. Packets WILL get dropped. Guaranteed.

2) You can cache frequently accessed files in a RAM disk, thus significantly dropping your filesystem I/O costs. Look to how Forth manages its screens for an example -- it very closely mimics how 32-bit processors with paging MMUs works, only it does it in software. I would like to note that besides relying on native OS file caching capabilities, many web servers will actually do their own caching of content as well. Modern web servers are more I/O bound than you think!



Although FAT is pretty simple, you ARE aware that you are allowed to use other filesystems on the storage media, right? If you're going to spend the time to optimize the software and/or dedicated controller, you might as well optimize the choice of filesystem as well. Or create your own as the case may be.



Well, what kind of manipulation are you talking about here? Overall, I find the capabilities of the AVR core to be comparable to the 6502's raw capabilities. Yeah, there are some warts that I wish would disappear, but that's also true of the 6502 and 65816 too. And when you boil it down, the ATmega cores, at least, are on average twice as fast as a comparably clocked 6502 thanks to its 1-cycle-per-instruction execution rate.

Remember too that the application you're designing doesn't sound like it's the kind that you'd want to have slashdotted. That is, it sounds like only 2 maybe 3 people at most would ever be interested in the data it provides. Hence, 2 to 3 concurrent accesses ought to be trivial for the system to handle, with or without TCP/IP header management in software.

There's no reason to make a 6502 run that slowly (1MHz) in any new designs, but certainly have nothing against using a separate microcontroller as a peripheral I/O IC. If you can make a PIC do it and offer it for sale (preprogrammed) as such a peripheral IC, I have no doubt you'll have some takers.

Yes, I am leaning towards the AVR, but I value the opinions of others who may have already experimented with this. Someone may have a better solution. Case in point, the bit manipulation exercise from the Programming
section http://www.6502.org/forum/viewtopic.php?t=821

I learned a whole new approach to that because someone asked a question.



Yes, I have already written the LBA drivers for CF and IDE so I know the file system resides at the next higher level. I am leaning towards FAT so that the removeable media can be read from other systems such as PC's. Also, data can be collected from other sources and processed by the SBC. (Digital pictures or audio files)

Granted, using a simpler file system might be advantageous and drivers could be written to allow other systems to read it. This might be best asked in a new topic.

Thanks for your inputs...I am grateful for everyone's ideas and comments.

Daryl

No offence meant but I really agree with Daryl. See it as asking for a second opinion. And I also found out that one still can learn :)

_________________

That is very interesting to me, because I am working on a similar project, using an old ISA-card with an RTL8019AS. But I am still not got as far as you and just designing the hardware. Have you written your code in Assembler or in C ?

Joachim

I wrote it all in assembly lanuage. I am also using an old ISA board that I bought for $4 at a used electronics shop.

For now, its wired through one of my 65C22's. Eventually, I will try to hang it directly off of some I/O address space.

Daryl

I prefer assembly language, too.

You might found some interesting information about inserting the Realtec 8019 into microcontroller designs at:

http://www.cornelius-consult.de/index.p ... 4&lang=eng

I hope, you will let us know about your progress.

Joachim

Good luck with that, I did it in EhBASIC and it was a needy beast. I much prefer the 3Com 3C509 as, once you've got it going, it's far less demanding on the CPU.


Isn't it good when you get your first ping response? 8^)=


WINS is also a good protocol to add, then you can give each device a name and do things like PING <name> instead of PING <IPaddress>



I'd let the 6502 decide what to do with the packets and have the ethernet controller just buffer the packets in and out, which is more or less what the 3Com cards do for you.


The 6502 is quite capable of handling a fair ammount of traffic via ethernet, my Vic 20 can keep up with serving web pages to one machine while responding to pings from over 150 tasks on seven other machines (works out to about 15KB/second).


I think you're quite mad, but then I've done it twice already so who am I to judge?

Lee.

Yes, there is a far amount of setup to read/write the buffers



First ping was 544ms, but I had diags printing to my RS232 at the same time. Once I removed the diags, I was getting 16ms. Once I map it directly into my I/O space (not through the 65C22), it should come in below 10ms!



I'll look into it... although, I am just happy the IP's are being responded to!!



The RTL8019AS has 8k of buffer space built-in, so if I do use the AVR's, I'll want it to do a little more than just buffer packets.



My plan is to finish the code using the 6502 and mapping it into the address space. Then test its capabilities and speed. If it keeps up with the basic tasks, I may keep it like that. If it bogs down, then may give the AVR a try.



mad? Is that a new opcode....I must look that one up, maybe I can update my code, save space, and improve speed!!!


.... time for my meds...

MAD exists only on the 6507 and 6509 processors. The 6502 never had it, and the 6510 replaced it with the much less useful SAX instruction. However, it made a kind-of comeback in the 65802 and 65816 processors; WDM is actually the new name for the same basic functionality, though suitably enhanced to take advantage of the 16-bit capabilities of the processor.

Contrary to popular belief, the WDM name is not the initials of the CEO of Western Design Center. It is actually a typo for its true name, DWM, which stands for Do What I Mean. WDM is retained for backward compatibility with earlier assemblers.