Difference between revisions of "Current events"
| Line 1: | Line 1: | ||
== The Second Spectranet == | |||
A key part arrived last week - a reel of solder wick (amongst a bag of other stuff from Farnell). This is a vital part of home surface mount assembly. | |||
I got busy completing the second Spectranet. Again, I did this fairly cautiously - a bit at a time - first, just having a board with the CPLD and 3.3v power circuits, configuring the CPLD, then putting the memory on, and testing the memory, and then the W5100 and its associated parts. This time, I used hot air and solder paste for all the ICs including the static RAM and the buffer for the W5100 (both of which I manually soldered last time), which was far faster, tidier, and easier. I've also got more confidence that visual inspection is enough to tell that the board can be plugged into a Spectrum. I still tested every pin on the memory after assembly for shorts and opens after doing a close inspection with the magnifying glass. I think I can spot any short and most opens now. | |||
My plan is to build the third board by putting the CPLD, memory and associated discrete components on all at once - I think the solder paste will stop the little 0603 parts from blowing away (and when it melts, the surface tension will keep things in place), test this, then do the W5100 end of the board. If that all goes well, and visual inspection is sufficient to see any possible problems, then the fourth board will be done all at once. | |||
The real time sinks at the moment with building the boards is: | |||
* testing for continuity/shorts manually | |||
* picking and placing the passives | |||
As I've already said, I think the first can be eliminated by visual inspection then software testing on an actual Spectrum. The second can be sped up with a sort of 'production line' approach - lining up the tapes of discrete components in order and doing one set at a time. | |||
On the software side, I know there are some code improvements that need to be made to the C library, and I also need to test the C library using caller function call conventions (all functions are callee convention by default, this is where the function itself cleans up the stack, rather than the code that calls it, which saves quite a bit of space). | |||
I also decided the 'major' example program for the Spectranet will be a basic IRC client. I decided on an IRC client because it's something people can use straight away, the protocol isn't complex, and it shows the multiplexing of user input and receiving data from the network. I'm only going to write the very barebones of it (for now), just enough to get on a server and chat, probably nothing like DCC for the moment. This has also let me explore a bit more of the Z88DK, for instance, using the Z88DK's IM2 support for handling the keyboard (which I did today). It's also some code that others can extend if they wish and turn into a fully featured client. Also, the IRC input and screen handling routines can be re-used for other similar types of program, such as a MUD client, or even something like AIM. | |||
But the aim of all of this is to have hopefully half a dozen development boards available for others to get their hands on by the end of the month, in a state that's immediately useful. | |||
[[User:Winston|Winston]] 23:02, 8 June 2008 (BST) | |||
== Configuration == | == Configuration == | ||
Revision as of 23:02, 8 June 2008
The Second Spectranet
A key part arrived last week - a reel of solder wick (amongst a bag of other stuff from Farnell). This is a vital part of home surface mount assembly.
I got busy completing the second Spectranet. Again, I did this fairly cautiously - a bit at a time - first, just having a board with the CPLD and 3.3v power circuits, configuring the CPLD, then putting the memory on, and testing the memory, and then the W5100 and its associated parts. This time, I used hot air and solder paste for all the ICs including the static RAM and the buffer for the W5100 (both of which I manually soldered last time), which was far faster, tidier, and easier. I've also got more confidence that visual inspection is enough to tell that the board can be plugged into a Spectrum. I still tested every pin on the memory after assembly for shorts and opens after doing a close inspection with the magnifying glass. I think I can spot any short and most opens now.
My plan is to build the third board by putting the CPLD, memory and associated discrete components on all at once - I think the solder paste will stop the little 0603 parts from blowing away (and when it melts, the surface tension will keep things in place), test this, then do the W5100 end of the board. If that all goes well, and visual inspection is sufficient to see any possible problems, then the fourth board will be done all at once.
The real time sinks at the moment with building the boards is:
- testing for continuity/shorts manually
- picking and placing the passives
As I've already said, I think the first can be eliminated by visual inspection then software testing on an actual Spectrum. The second can be sped up with a sort of 'production line' approach - lining up the tapes of discrete components in order and doing one set at a time.
On the software side, I know there are some code improvements that need to be made to the C library, and I also need to test the C library using caller function call conventions (all functions are callee convention by default, this is where the function itself cleans up the stack, rather than the code that calls it, which saves quite a bit of space).
I also decided the 'major' example program for the Spectranet will be a basic IRC client. I decided on an IRC client because it's something people can use straight away, the protocol isn't complex, and it shows the multiplexing of user input and receiving data from the network. I'm only going to write the very barebones of it (for now), just enough to get on a server and chat, probably nothing like DCC for the moment. This has also let me explore a bit more of the Z88DK, for instance, using the Z88DK's IM2 support for handling the keyboard (which I did today). It's also some code that others can extend if they wish and turn into a fully featured client. Also, the IRC input and screen handling routines can be re-used for other similar types of program, such as a MUD client, or even something like AIM.
But the aim of all of this is to have hopefully half a dozen development boards available for others to get their hands on by the end of the month, in a state that's immediately useful.
Winston 23:02, 8 June 2008 (BST)
Configuration
While it's all fine and dandy to have a working C library, you've also got to be able to configure the Spectranet to get on the network in the first place!
For all my testing, my ethernet uploader program (on the Spectrum) has been just dumping in some static configuration settings into the hardware. Now the hardware can be configured properly. Part of this was writing a user interface (a simple menu based one) to allow the user to enter the usual settings - whether or not to use DHCP, and if not using DHCP, the IP address, netmask, gateway, DNS servers etc. Configuration is stored in the last 256 bytes of the 128k flash chip (page 0x1F). The configuration program therefore can't run from ROM, because trying to execute code from the ROM you're writing to doesn't work, because the CPU fetching instructions will cause the unlock sequence for the flash chip to no longer be the unlock sequence. Therefore, the configuration program must run from RAM. To do development testing, I've just been loading it at address 32768, but once fully integrated it'll be temporarily stored in the Spectranet's fixed workspace page at 0x3000.
Incidentally, all code that accesses main ROM functions, including standard Spectranet ROM code that's not in the main ROM (0x0000-0x0FFF) does so via the indirect call table. This has several useful properties: code doesn't have to be reassembled if the main ROM gets changed (thus changing call addresses), and most of the code will work unchanged with entirely different ethernet hardware, since it never directly accesses hardware, and all it knows about is a set of public function calls. The configuration utility is no different in that respect. The DHCP client also uses the call table. The only higher level code that doesn't is the resolver code for gethosbyname(), but that's because it's part of the main ROM.
When it comes to coding, one thing I find really tedious is writing user interface code (and the most tedious UI coding of all is writing PHP/CGI/ASP scripts for web sites, especially if someone mentions AJAX, but that's a rant for another day). So the configuration UI is simple and functional. At its core is a table based menu generator, which is a table of pointers for menu strings and function call addresses to handle the menu selection. A similar approach is used to display the current configuration settings - a table of pointers to strings, and a table of pointers to the memory that contains the actual configuration option. Doing it this way is more flexible (and I can re-use the menu generator for things like the NMI menu) and a great deal less tedious than writing a bunch of repeating asm code to display various options.
Flash memory is sort of like EPROM, except to re-write it you don't need to shine UV light at at - instead, you give it an erase command. Writing to flash, the only operation you can do is change a bit set at 1 to 0, and not the other way around. The erase operation essentially sets the sector back to all bits set to 1. The flash chip, incidentally, doesn't care if a byte has been written to before - if, for example, you write the value 10101010 to a byte, you can write it again - to 01010101, without needing to erase. The type of flash I'm using is organized into 16k erase sectors, so you don't have to rewrite the whole chip. Even so, 16k must be rewritten. What the configuration program does is copies the last 16k of flash (in which the last 256 bytes contains the configuration area) to the Spectranet's RAM. The configuration program then modifies this copied data in RAM, and when you choose 'Save and exit', it erases the last 16k sector in flash, and copies back the 16k that was copied in earler, thus preserving anything in that last 16k that someone might have put there. It uses Spectranet RAM to do all of these operations, since this won't affect any programs a user might have in the Spectrum's main memory. I want to follow the principle of 'least surprise', and this clearly includes not stomping all over a program that the user might be working on in main RAM! (And in any case, I included static memory on the Spectranet so that the ROM as well as networked programs have some extra workspace).
As far as general progress is concerned, I would have preferred to be a bit further on than I am now, but I'm getting really close to having something suitable for others to do some development with. I have some more solder wick now, so I'll also be making a few boards for development use this month. I also want to write at least one "real" program that does something in the real world for two reasons: provide a useful working code example, and to provide real world testing. I will probably do something reasonably straightforward like a simple IRC client, or perhaps a minimal HTTP server.
Winston 14:56, 1 June 2008 (BST)