Ethernet and uIP Stack

[OwenS]

BigDumbDinosaur wrote:

OwenS wrote:

Pretty much every modern browser requests one regardless - they're used for tab and bookmark icons.

I have those features disabled. Sometimes less is indeed more.

Thats fine and all until you have 32 tabs open and all that is left to identify them is the icons

[8BIT]

I have uploaded the drivers and apps for the ENC28J60 Ethernet board to my website.

Here is an Ebay link to the actual module that I purchased:

http://cgi.ebay.com/ws/eBayISAPI.dll?Vi ... 0544483669

Daryl

[BigDumbDinosaur]

OwenS wrote:

Thats fine and all until you have 32 tabs open and all that is left to identify them is the icons

I wouldn't have that much activity going on in any case. I seldom have more than three or four active pages going at any one time. My life doesn't revolve around the Internet.

[OwenS]

BigDumbDinosaur wrote:

OwenS wrote:

Thats fine and all until you have 32 tabs open and all that is left to identify them is the icons

I wouldn't have that much activity going on in any case. I seldom have more than three or four active pages going at any one time. My life doesn't revolve around the Internet.

Neither does mine - some are things I keep open all the time (Such as forums I frequent) and the others are primarily things that I've recently found interesting or relevant.

Its the kind of thing that happens when you set your browser to save your tabs on close

[kc5tja]

At home, I rarely have more than 4 tabs open at any given time. At work, that number increases to around 16. Still, I've seen people with as many as 90 tabs on their browser, packed so densely that they actually have multiple rows of tabs (at least with IE; I doubt Firefox would behave that way, at least without a plug-in). Again, this is for work-related stuff.

Still, I find so many websites have the same or similar-enough favicon that the feature is only truly useful for confining which tabs to search through to find the tab you're really looking for.

[8BIT]

I've created another application for the uIP stack.

This one contacts an SNTP (Simple Network Time Protocol) server and gets the current time. The time is returned as the number of seconds since Jan 1, 1900, so a little math is needed to convert it to a date/time format. Also, this 32bit value will roll-over in 2036 and start over at $00000000 (Current value is ~ $D2180352).

This is useful for a machine with the capability to generate the time of day (TOD) while powered up but needs to have the date initialized each time. A startup routine would call this app and set the TOD clock.

If anyone is using the uIP stack and would like more info, just PM me.

Daryl

[8BIT]

8BIT wrote:

I have uploaded the drivers and apps for the ENC28J60 Ethernet board to my website.

Here is an Ebay link to the actual module that I purchased:

http://cgi.ebay.com/ws/eBayISAPI.dll?Vi ... 0544483669

Daryl

This one is cheaper. It does not have the 5v level converter but the ENC28J60 is 5v tolerant and it has been working just fine on my SBC-3's SPI interface.

http://www.ebay.com/itm/120771613394

Daryl

[BigDumbDinosaur]

8BIT wrote:

The time is returned as the number of seconds since Jan 1, 1900, so a little math is needed to convert it to a date/time format. Also, this 32bit value will roll-over in 2036 and start over at $00000000 (Current value is ~ $D2180352).

I'm a bit surprised you didn't use the UNIX epoch as the time base, since algorithms are plentiful for that. However, 1900-2036 is good—it covers my lifetime, and then some.

I'm working on a variant of this which uses a 48 bit time_t and is capable of working from 1800 onward. With the 65C816, a larger time_t value is not cumbersome to manage. As my POC unit has real time clock hardware, the initial date and time can be gotten from it and used to set the time_t value. Once that is done, jiffy IRQs will drive the time_t clock, with a resolution of 0.01 seconds.

I have a basic form of that running right now in a 40 bit uptime counter (current value $001F478B0A, or approximately 23 days, 18 hours). The least significant byte increments with each jiffy IRQ, which is generated by the watchdog timer in the real time clock hardware. I have the watchdog set to interrupt at 10 millisecond intervals. The code progression to do this is very simple with the '816:

Code: Select all

;	———————————————
;	process RTC IRQ
;	———————————————
;
         longa                 ;16 bit .A & memory
;
;
;	decrement time delay counter...
;
         lda tdsecct           ;time delay seconds
         beq .iirq002          ;timed out, so ignore
;
         ldx tdirqct           ;msecs timer
         dex                   ;msecs=msecs-10
         bne .iirq001          ;not time to update seconds
;
         dec tdsecct           ;secs=secs-1
         ldx #hz               ;reset msecs to 1000
;
.iirq001 stx tdirqct           ;new IRQ timer value
;
;
;	process uptime counter...
;
.iirq002 ldx utirqct           ;msecs*10 counter
         inx
         cpx #hz               ;reach 1000 msecs?
         bcc .iirq004          ;no
;
         inc utsecct           ;bump uptime LSW
         bne .iirq003          ;done
;
         inc utsecct+s_word    ;bump uptime MSW
;
.iirq003 ldx #0                ;reset msecs*10 counter
;
.iirq004 stx utirqct           ;new msec counter value

In the above, s_word is the size in bytes of a 16 bit word (I don't bury magic numbers in code), hz is the jiffy interrupt rate per second (100), and longa is a macro that sets up the MPU for 16 bit accumulator operation. Note how being able to decrement or increment 16 bits at a time is real convenient—less code, less branching and fewer clock cycles. The time delay counter is callable from the BIOS jump table and can be set to as much as 18 hours.

[8BIT]

BigDumbDinosaur wrote:

8BIT wrote:

The time is returned as the number of seconds since Jan 1, 1900, so a little math is needed to convert it to a date/time format. Also, this 32bit value will roll-over in 2036 and start over at $00000000 (Current value is ~ $D2180352).

I'm a bit surprised you didn't use the UNIX epoch as the time base, since algorithms are plentiful for that. However, 1900-2036 is good—it covers my lifetime, and then some.

Unfortunately, I did not choose the time format. The SNTP protocol defines the packet contents. The protocol designers chose to use Jan 1, 1900 as the base. I have a crude conversion built using tables to speed the conversion process. However, the tradeoff is more memory required.

I am looking into how hard it is to account for the rollover so that it can survive past 2036. I still plan to be around, but not so sure I'll still be using the code then!

Daryl

[BigDumbDinosaur]

8BIT wrote:

BigDumbDinosaur wrote:

8BIT wrote:

The time is returned as the number of seconds since Jan 1, 1900, so a little math is needed to convert it to a date/time format. Also, this 32bit value will roll-over in 2036 and start over at $00000000 (Current value is ~ $D2180352).

I'm a bit surprised you didn't use the UNIX epoch as the time base, since algorithms are plentiful for that. However, 1900-2036 is good—it covers my lifetime, and then some.

Unfortunately, I did not choose the time format. The SNTP protocol defines the packet contents. The protocol designers chose to use Jan 1, 1900 as the base. I have a crude conversion built using tables to speed the conversion process. However, the tradeoff is more memory required.

I guess I wasn't fully comprehending and didn't mentally link the year range to the fact it was SNTP you were implementing. 1900 was chosen as the SNTP base to avoid having to deal with negative integers, as is the case with time_t values that represent pre-1970 dates.

Quote:

I am looking into how hard it is to account for the rollover so that it can survive past 2036. I still plan to be around, but not so sure I'll still be using the code then!

I believe there is an update to SNTP that accounts for the year 2036 problem. I haven't looked though, so I may be imagining things.

[8BIT]

Sorry if I was not clear on the source of my data.

What I read is that they are calling each 64-bit block an 'era'. We are currently in era 0 and after the 2036 rollover, we will be in era 1. Dates prior to 1900 are considered era -1.

There will be a few pico or nano seconds, 1^(-32) seconds, when the full 64-bit value is 0 which is defined as invalid.

A fix will involve defining the era or just assuming that any value with the most significant bit clear extends beyond 2036. That would get us to ~2104.

Daryl