Network notes: These examples assume the Web Platform is wired with CAT5 cable to your home Broadband/DSL Router's Ethernet port, and you are working from a computer either on the same wireless or wired network. Direct connection (laptop to Web Platform) will not work so easily as there is no device to give out DHCP addresses.
The build system does not "re-make" if the existing output files are there.
I am quite a bit better at Makefiles since I modified the platform scripts for ds-pic. If there's something I can fix easily I will do so any push it to github. Good luck!
Yeah - to make it clear I gave up with FreeRTOS (kernel-enforced time switching) and concentrated on Contiki support (co-operative scheduling). Contiki has a file-system interface, although I've not used it.
No idea, I don't know the PIC24 architecture well enough to comment. The PIC32 port took me about a week to get going, albeit the Ethernet driver was already running by others, so I only had to do the Contiki wrapper.
I would start simple, get the A2D side working on the web platform board and output it to the serial port. As a minimum you will need a protective diode and a resister network to get the battery voltage down to the 3.3V A2D range. Some people also use a mosfet to disconect the load from the battery when not charging. When you have the data sampling OK, I would look at the ethernet side and broadcast the readings as a binary UDP broadcast, and try to pick those up over the network. You can knock up a python GUI for any PC using my example very easily. Only then would I go to the trouble of trying to integrate that 50lbs of gorrilla SNMP implementation, as that's probably an order of magnitude more difficult than the rest of it.
I'd really like to hook some buttons on the web page to the LED's to make the demo better, plus post sensor readings to Patchube or something. I have a way to read/rewrite pages to the flash eeprom, it's basic (and small) one day I'll get that cleaned up and uploaded to Github. Then we might have a possible WP default firmware on our hands :-)
My own use for the port is a 7-day multi-zone heating controller: DS18S20 temp probes, a relay, solenoid controllers (w/ SN754410). I was trying to put together another board for a LCD/joystick control but never got it finished.
The configuration bits aren't set properly when I build with the contiki "make" system for some reason I've never tracked down... so those hex files need some help if you flash them to a naked board.
To work around I set config bits explicitly with the Microchip pickit3 programmer, or else use the USB serial -programmer firmware DP uses as that does not seem to overwrite working config bits with bad ones. anyway glad it works for you :-)
Here's some example code (based on Ian's) used by the webplatform to assign UART0 to be 'wired' to a particular set of pins. In this case it's to pins RP14/RP15 which the PCB has routed to the FTDI chip for USB serial port debugging.
//UART1 SETUP //UART can be placed on any RPx pin //configure for RP14/RP15 to use the FTDI usb->serial converter //assign pin 14 to the UART1 RX input register //RX PR14 (input) RPINR18bits.U1RXR = 14; //assign UART1 TX function to the pin 15 output register //TX RP15 (output) RPOR7bits.RP15R = 3; // U1TX_O
//peripheral setup U1BRG = 85; //86@80mhz, 85@79.xxx=115200 U1MODE = 0; //clear mode register U1MODEbits.BRGH = 1; //use high percison baud generator U1STA = 0; //clear status register U1MODEbits.UARTEN = 1; //enable the UART RX IFS0bits.U1RXIF = 0; //clear the receive flag U1STAbits.UTXEN = 1; //enable UART TX
}
I have another example I can dig out where I route UART1 to pins on the extension port "GPIO" header as an application serial port. You need to look up in the DP schematic which pins from IO1 header you want, and the corresponding RPx number. http://dangerousprototypes.com/docs/Web ... I/O_Header
You should be able to wire four devices to have there own 2 pins each (8 pins). eg. RP19,20 for device #1, RP 21,6 for device 2 etc. There's only 7 RP ports on Header IO1, so you'll need to steal another from somewhere else. My advice here is to re-purpose one of the lines going to the SPI EEprom chip since they are also taken to a pin header (I've done this to get I2C on this board). Your software needs to modify the values in registers RPINR18 and RPOR7 to select which module of the four you want to speak to each time.
Bear in mind the pins are only 3.3V outputs, that could be lower than TTL serial UART converters take on the input - check the datasheet as you might need a transister driver to pull it up. If your devices are full RS232 serial ports, they will be outputting/expecting -12V/8V or whatever it was that seemed a good idea in the 70's. Grab a few breadboard compatible MAX234's dual drivers from Maxim on eval, and recommend a resisters divider for the output 5V -> 3.3V shifter to avoid sinking too much through the input buffer protection diode and you should be set.
Do all devices talk to you at the same time, do they round-robin? Do you initiate the comms or the other devices? I'm wondering if it's possible to use the one free hardware UART module and use the peripheral mapping feature to switch the UART between different pins in the GPIO header. Might be possible to use interrupt on change to re-config the UART in time to get the second byte of each serial communication if that is enough. Obviously much easier if you are the initiator as you can rewire Rx before Tx.
If you need truly asynchronous reception on 6 lines, and can get away with RX-only with a low baud rate it should be possible to use interrupt on change features to bit-bash the RX ports on GPIO lines. Use a free running reference timer and sample-on change then some analysis to infer the bits sent. More tricky if they are all using there own oscillator sources due to drift (ie. might not be able to share a common timer unless you have a very quick timer to oversample).
Logging messages out to external flash and the web gui are more tricky :-)