>I go away for a couple of days because I'm starting a >new gig and all the conversation stops. I presume that >no discussion means virtual agreement? Well I suspect some of it may be that I did a diagram and now it's all left to me :) The other factor possibly is that once the real work starts, everyone wanders off :) ... ... >>How to interface to the target processor? >Use the I/O pins of the infrastructure PIC (iPIC). Hmm, this is why I suggested a string of PISO shift registers, clocked in through the SPI data in port. Some more SIPO registers could be loaded through the SPI data out port for virtual controls. I don't think there will be enough pins on the iPIC to have enough monitoring otherwise. The monitoring ones would always be inputs, so should not be a problem, except maybe if connected to a port with an analogue signal on it. I guess the virtual push buttons could be individual pins on one port of the iPIC, with jumpers allowing them to be connected to any pin of either of the target processors. >Well you've seen my couple of thoughts on this above. >If the LCD can be virtualised properly, there's no need >for a physical one to come with the unit, just a socket. >Again we just pick one socket style and then it's up to >the user to get a matching connector for it. We could >sell those separately for example. Hmm, in view of the differences between HD44780 emulations, and the scant data on any of them, I wonder which we should emulate. :) I see a problem with someone designing code for an LCD, using the virtual LCD to get the code going, then going and purchasing a real unit and expecting the code to work. Where will they end up complaining about this wotsit development board that doesn't drive their LCD? My personal feeling is that to do a virtual LCD is a lot of work. To me it would require a processor on the board to emulate the LCD because the monitor will not pick up strobe signals fast enough to carry out the emulation well enough. If one is going to use another processor, then there may as well be a proper LCD. I could see use in a virtual 7 segment display though. This would not limit the functionality of a port, as the display is not strobed to a device external to a latch external to the processor. I would work on the basis of using a port bit per segment, maybe allow another couple of (specifiable) data lines to be used as digit selectors to get a multi-digit display, and doing the emulation totally in the host PC. It may be that this is how you envisage doing the LCD, without bothering with the hassle of the CS, RS and EN lines, but if that is the case, I think you will run into strife as I outlined above. >>Possible items >>A potentiometer on an A/D port >Through an opamp voltage follower so that the input is >independant of the current impeadance of the the pot. >Personally I'd key this as a input device rather than >an exercise in using the A/D. Well I saw it as an exercise in learning how to use the A/D, and then the user can go on and use it for an input device. :) I take your point about an op-amp though, for two reasons, first it will act as protection to the input port if external voltages are connected, and will buffer the source impedance down to a level which will mean it is not a factor in using the A/D. >Supply an LM35 wired to an A/D port for temperature experiments. >I'd leave this one out as temp is a bit specialized and there's >more than one useful way to do it. For example I now swear by >DS1620 digital themometer/ thermostat chips. Well again I saw this as a learning tool, to go from a sensor to a display, with all the hardware being pre-built on the board. The achievement in having a sensor that measures something "real" and displays the result will be a milestone for a beginner. It may be there are other sensors that would fit the economic model better, but I think they are all less linear than the LM35, or one of its close cousins. The DS.... series devices are all digital interface IIRC, and I was looking for a second analogue application to include on the board. >>Supply an LM3919 with LED bar graph wired to a PWM port for analogue output >>experiments - more rugged than a meter, and less expensive than a DVM chip >>and display. > >Only if it's virtual. I don't think there's any need for actual physical >hardware for this activity. Hmm, yes I can see where you are coming from, but I wonder if the monitor hardware will be able to monitor the PWM waveform, or would you expect to dedicate a CCP module on the iPIC to this purpose? Again I was looking for a cheap way to have a hardware monitor of an analogue waveform. I also get the feeling that if we try and have virtual instruments for everything, some of the "experimenters fun" will disappear. Being able to code a real "knightrider" display would (to my way of thinking) carry more kudos, than having it display virtually on the screen. :) Anyway, I am now doing a little work on a circuit diagram, and investigating the ins and outs of the FT-232 chips. It seems that in the last few days (literally) they have announced a new version. have not figured what the difference is, except it seems it is supposed to be better. :) -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.