This section allows you to view all Messages made by this member. Note that you can only see Messages made in areas you currently have access to.
Messages - bonybrown
I was certain that crystals were non-polarised components, and that is true; it's the pinout of the 4 pins on the package the crystal is in that makes the orientation important. (the two pins at one end of the package don't connect to the crystal internally)
Thanks for the link to the datasheet. Hope you're able to get it working. Currently, the RTCC half-second interrupt is used for the uIP periodic processing, so if the RTCC isn't running, the periodic processing won't either.
... the uIP stack fails to initialise (ie it hangs immediately after "timer init" and a blank line) if I use the reset button or after a firmware upload. The heartbeat LED is on solid. The only way to get it to work is to remove the power and then it's fine.
Hmm, that doesn't happen here, but after "timer init" is printed, SDInit is called...so it's something in there causing it to hang.
I have spotted a bug in there where it sets the SPI Primary and Secondary pre-scalers (or rather, where it's NOT setting them) that's causing the transfers to and from the card to be clocked at 64kHz, instead of the >100 and < 400 kHz that the spec says should be used for the card initialisation. Once the initalisation is done, the spec says we can step up to 25MHz (but I think the PIC will only go to 10MHz). I've got that change locally, and it improves the SD card performance hugely (as you'd expect). I'll commit that as soon as I can.
Failing that, I'll have to modify the initialisation routine to "give up" after a set number of attempts, and report the error. That should help track it down. I guess we'll need that anyway for people using this without an SD card inserted.
Thanks for giving it a go.
That code didn't work at first, but that was due to the SPI interface. I see lots of code that doesn't bother to read SPIBUF after a write, but on the dsPIC, doing that will lock up the SPI due to the receive overflow bit being set - so maybe that's a dsPIC specfic thing?
Once that was sorted out, I didn't seem to have any problems. Maybe I'll hit problems when I start looking at writes?
I've added the 'cat' and 'ls' commands to the telnet server (I guess that's 'type' and 'dir' to the windows' folk)
There's also a 'sddump' command that will dump sectors from the sd card in the same way that memdump dumps memory, for troubleshooting.
Writing files is as yet untested (and there's no telnet commands that do any writing yet, anyhow), but the dosfs library does support it.
Would be good to know if it works with other people's SD cards.
So the telnet server has now been updated.
I've tested it with linux, windows and mac clients ( all the OS standard "telnet" commands) and it works fine, all in character at a time mode, ie, lowest common denominator.
I've added a new command as well : [tt:]memdump [address] [count][/tt:] which will dump the memory from [address] to the telnet client. Here's a sample session:
[tt:]tony@barellan:~$ telnet 10.0.0.251
Connected to 10.0.0.251.
Escape character is '^]'.
Web platform telnet. Enter help for commands.
RTCC Date/Time: 2010-05-16 23:16:12
>memdump 0x1400 64
1400 ce de 42 9d 6f 64 f8 f5 ..B.od..
1408 d0 a6 6b f7 a3 e1 4a ad ..k...J.
1410 44 3c 4c d4 9f 07 9c 0b D
1420 4e fe e7 7a 56 65 7a 83 N..zVez.
1428 0b 75 a7 39 a6 0e f4 f9 .u.9....
1430 f0 c5 d3 27 74 a9 b1 7f ...'t...
1438 30 5a 90 03 1c 47 0a 6d 0Z...G.m
>quitConnection closed by foreign host.
For those interesting in implementing commands for telnet, the signature of the function you would need to implement is now:
[tt:]void telnet_command( file_handle_t handle, char** argv, unsigned int argc )[/tt:]
That is, almost exactly like a standard 'c' main(), except the return type is void, and the file handle for the tcp connection is passed in for your command to read and write from. The parameters to the command are already parsed and presented in the char* array argv, with argc items. argv is the command name. argv is the first param.
If I can get the echo state stored out, it will work sufficiently, except for the backspace key at the moment.
Hopefully I can do some telnet option negotiation soon, and that should help improve the interoperability.
An improved telnet task was committed to svn about 10 hrs ago. It now echos ( annoyingly if your client is in character, local echo mode) and added a new command "paramcheck" as a demo of how to read parameters for commands from the line it "executes".
Todos: option negotiation for echo and line/char mode; support for backspace character in char mode; then adding some useful? commands. I have these in mind: settting the date/time; configuring ip address, mask and gateway and storing those to the flash memory chip...and of course reading them and setting up uIP on startup. Might be good to be able to set the mac address too.
Well see I'm a linux user so the linefeeds are sufficient. I hadn't thought of that. It should be a simple matter to do a bulk replacement of n with rn (or nr...I'm not sure which way round they should go )
And that probably also explains the second one - my telnet uses line mode and seems to do local echo automatically. It doesn't send the data to the device until you hit "enter", so I didn't echo back what was sent. The messages you see in the console aren't errors; just debugging stuff ( I don't have a picKit or anything like that - it's all just printf statements for debugging )
And thinking about how the parser works now, it's probably not going to work in 'one character at a time' mode. To be honest, I'm not really happy with that part of the code, so I'll have to revisit it. If you can set your telnet to line mode, it should work (if that's any consolation?)
But good feedback, thanks!
Just dropped another update to the uIP stack project to svn/trunk/web-platform/firmware/uIPStack.
Some notable changes are:
- The code runs 3 "tasks" that it multitasks between. One for the IP stack, one for the serial port (debugging help) and another for a handler for telnet (port 23). The point of the multitasker is to make it simpler to code stuff without worrying about blocking other things that need to happen (particularly, the network stack, or other tasks)
- The telnet server task is pretty easily extendable ( just add the name of the command, and a pointer to the function that implements it to telnettask.c)
- To find out what commands it supports, enter "help"
- It should be reasonably easy to write a web server task now, but without the ability to read files, you can't serve much (maybe dump all the memory to a html response??)
The IP address is fixed in code as 10.0.0.251. You'll need to change as desired.
Lots of debug stuff still being printed to the serial port at 115200 (8/1/none)
You read from EEPROM_SSPBUF into temp, but temp is not used anywhere in the function.
The compiler *may* have optimised the assignment out of your code - as a result the buffer isn't read, and the SPIROV may be set, locking up the SPI module. There must be something like this going on because if the module is configured correctly, there should be nothing stopping it from sending a byte ( as in, it doesn't care if anything is actually listening in master mode - or even if the correct pins are assigned to the module )
Try making temp "volatile":
volatile short temp;
...that should stop the compiler optimising it out (if that's the problem at all)
Seems R4A and R5A are "duplicates" of R4 and R5 - the resistors in series with the LINK and ACT leds on the front of the card.
And, on the schematic, R4A and R5A are on different nets to R4 and R5.
I was thinking about cutting the tracks going from the PIC to R4 and R5, and re-wiring to R4A and R5A, and connecting the (R4,R5) ACT and LINK leds back to unused PIC outputs (if there are any left that can source sufficient current)
I now have it working using the packet ready interrupt from the enc28j60 to replace the polling, and using DMA to transfer the data buffers for send and receive.
There are certainly some pitfalls to be aware of when using the SPI with DMA ! For example, the documentation doesn't say so directly, but you cannot do TX only mode on the SPI - because if *something* doesn't read SPIxBUF before the next byte is clocked in, the Rx overflow bit is set,and the whole SPI interface stops; so you need to assign a second DMA channel to the SPI to repeatedly read SPIxBUF to a dummy one word variable. I'll write up some more details when I get some time to do so.
Also, the enc28j60 interrupt is connected to one of the few non-remappable dsPIC pins - so I couldn't map it to an external interrupt peripheral. It is on a Change Notification (CN) pin though, so I used the CN interrupt. The only downside there is that you get two interrupts - one for each interrupt pin transition. Not a big deal, though.
Performance wise - no real difference I can see from the ping times; theoretically, the biggest improvement will be in "responsiveness" of other tasks on the dsPIC, especially when sending or recieving larger packets. Each SPI transfer is 8 bits; one bit is 4 Tcy's; 32 Tcy per byte; for a 1000 byte packet = 32000 Tcy that the dsPIC doesn't have to stall polling the SPI status bits. 1000 byte packets are conceivable, as the allocated packet buffer is 1500.
I need to do some direct comparisons I guess - after I work out how to measure that!
Next, I'd like to be able to IDLE the enc28j60 and dsPIC, let the interrupts take care of the wake up, and see how that affects current consumption. If only there were more hours in a day!
Ian - I will take up that offer of SVN access, if you're still extending it?
This (attached) is based on the code in the uIP_Pic33_port_k project in the google code svn. There's lots of commented out blocks, code comments that are not longer correct, debug code and it's a bit all over the place, but at least demonstrates the code works.
The project attached here will setup the IP address of the web platform as 10.0.0.251 and listen on port 23 (telnet ) for a max of 10 simultaneous connections.
You should be able to ping it, and telnet to it. It will echo back messages sent to it.
You should also know that it will output a lot of debugging stuff on the usb serial port ( at 115200 ). The code always enables the UART, so the usual warnings about backpowering the usb chip apply (ie, make sure you have the usb cable connected )
I'm getting ping times of around 0.680 mS. The SPI bus is operating at SPRE 1:1 and PPRE 4:1, which seems to be as fast as the datasheet suggests is possible @ 40MHz Fcy (so that's 10MHz SPI, although the ENC28J60 says it will work up to 20MHz. I haven't tried that... seem to recall some other thread having problems going that high? )
Next steps I'd like to try are to replace the polling loop with an interrupt from the ENC28J60 when packets arrive, and to try using DMA to get the packets into and out of the ENC28J60.