I have just came up with few ideas:
FreeRTOS http://www.freertos.org/ (http://www.freertos.org/) - as the PIC is running @80Mhz, you probably cannot use all the power just by simple application (most of the time you are sleeping/waiting for interrupt), unless you are doing bit-banging. What RTOS gives you, is some memory managenment (malloc, free), simple task creation (threads), and most important sync primitives (semaphores, mutexes, queues, etc)
All you need to do is edit one file for constants and add few lines of code, compile and it's up. :)
The beauty of this is when you issue sleep, normally the cpu sleeps or nops, and wastes cycles. But in RTOS, it switches to other task (like LED update, low priority thing ... ) and switches back when time's up. You controll the priorities of tasks and how much (stack) memory each task has.
http://www.freertos.org/tutorial/index.html (http://www.freertos.org/tutorial/index.html)
uIP or lwIP stack are used in Demos for the FreeRTOS, they can be used as examples and finally replace the microchip tcp/ip stack on the webplatform.
OpenOCD adapter (?) - ethernet does not suffer the latency problem as the USB does (1 packet each 1ms), Sending UDP packets on local network is mostly reliable - this could boost the implementation of buspirates OpenOCD adapter a lot !
These are just some ideas. Please let me know what you think :)
Those all great ideas. I have a uIP port in the works, and a GPL SD card library (DOSFS). I should get them into the SVN if anyone else wants to take a look.
The RTOS is a great idea, hadn't though of it. OpenOCD seems straight forward port, and a good first test of a non-Microchip TCPIP stack.
i would help :) but i don't have web platform yet. I'm waiting for the Chinese holiday to be over
I've just started playing with ny web platform. I like the idea of running FreeRTOS on it. Has anyone tried this yet?
I do not have a Web Platform but I have used FreeRTOS on PIC24's and dsPIC's. It really makes somethings so much easier. You can add two more-or-less unrelated functions without worrying about the interactions and timing issues. Ques and semaphores make IPC very easy. I have had one thread (called a task in FreeRTOS) running a graphical LCD that takes care of the LCD hardware and basically copies a frame buffer in RAM to the display. I have another thread running a serial port console. For a while I even had another thread running a character LCD at the same time while I was switching from the chacarter LCD to the graphical LCD. You can set priorities on the tasks, have them block on ques/semaphores/mutexes, have them sleep for a given amount of time or until woken from another thread or even from an interrupt. ISR's that do not depend on the RTOS API can even run at a higher priority than the kernel (really just a basic schedular) without any problems.
It really is a great tool. I'd love to see Dangerous Prototypes start to use it on PIC24/dsPIC's for future projects.
I think I am going to go ahead and get one of the new v1.1 Web Platforms while they are available. I probably won't have time to do much with it right away though. But when I do get to it I'll probably try to get it going with FreeRTOS if someone else has not already got it working by then.
I also love the idea of moving from USB to Ethernet as the standard interface for future Dangerous Prototypes. Replace the serial terminal with telnet then use NFS or FTP to get data on or off the unit. Even better would be to have an X-client running that could have a GUI open up on any computer. These would be truly platform independent solutions using standard network protocols that are available on any system and do not require custom code on the computer.
How cool would it be, for example, to have a future version of the Open Logic Sniffer with the client GUI software embedded in the unit running over X -- just plug it into your network, telnet/rsh to it and have it open a window on you desktop! Maybe we need a slightly scaled back Web Platform that can become the standard network interface for multiple Dangerous prototype projects. Define a standard header and then it could be the connectivity solution for all future projects. You would only need to purchase one of them and you could use it with any project or get one for each project you want to use at the same time.
-Eric
Great ideas. I like the idea of working with freertos.
Replace the serial terminal with telnet
Some related work has been done with the free uIP TCPIP stack port for the web platform. Most of the registers, SD card, etc, are accessible via a telnet interface.
For the Web platform, an ethernet-based design makes the most sense. However, for other projects I'm not so sure. It seems like USB allows very low-power operation, and all USB ports supply power. On the other hand, I'm not so sure that ethernet is a low-power design - does anyone know? Also, POE has more than one standard, and certainly not all ethernet ports provide POE. I don't think that requiring a separate power supply for every DP project is an improvement on the existing situation.
Look for another posting in the Prototype pub on this topic, which is actually not restricted to the Web platform.
OK. If I get some time, I'm going to try to run FreeRTOS on the Web Platform.
There is already a dsPIC port, so I hope it will be relatively straightforward.
[quote author="rsdio"]
For the Web platform, an ethernet-based design makes the most sense. However, for other projects I'm not so sure. It seems like USB allows very low-power operation, and all USB ports supply power. On the other hand, I'm not so sure that ethernet is a low-power design - does anyone know? Also, POE has more than one standard, and certainly not all ethernet ports provide POE. I don't think that requiring a separate power supply for every DP project is an improvement on the existing situation.
[/quote]
Good point about supplying power over USB vice having a separate power supply. POE is not ubiquitous yet and even then it is not trivial to use with out a dedicated chip.
If we did define a standard header for connectivity solutions then the networked version could be one and another could be a USB based version. Keep things modular and interchangeable.
-Eric