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

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

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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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

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.

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

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

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:

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.

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

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.


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.

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