On Mon, Aug 19, 2002 at 11:31:59PM -0400, Jason Harper wrote: Hmmm, 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? I'll answer all of the responses so far here: > BAJ wrote: > > * I'd personally be happy if there were at least a connector for an > actual > > LCD display. I realize now that it can be virtualized, but it would > still > > be nice to be able to connect a physical one to the board somehow. > > My logic monitor idea can't possibly virtualize a LCD: most people's LCD > code asserts the E signal for only a few cycles, the monitor would almost > certainly miss it. If we're willing to compromise by limiting the port that the virtual LCD can be attached then a small bit of hardware, a latch or a flipflop, can be used to extend the cycle a bit by latching the data. I think it's worth investigating. > > I guess it wasn't very clear in the original documents, but my design does > effectively include a connector for a LCD: you simply plug it into the > breadboard in a designated space. I'm sure it was clear, but obscured in my mind by the other issues on the table and the time. > There will be 14 consecutive pins on the > breadboard connection that correspond to the standard LCD pinout: probably > PortB for the data pins, some PortA pins for the control signals, the > potentiometer wiper for contrast, and power pins in the appropriate place. Might I suggest conservation by using a 4 bit interface? That'll limit the port exposure to a single 8 bit port for both control and data. Same pinout of course, but the extra 4 data bits simply goes unused. > All that is required is that the LCD be the type with a single-row > connector, not the dual-row which seems somewhat more common. I figure that adapter cables can be used to rectify whatever differences that exists between the different pinouts. We probably should just pic one standard and go with it.... ---------------------------------------------------- Olin chimes in... >>>4 - The bootloader uses the hardware UART. New firmware (except for the >>>bootloader and the reset vector) can be uploaded into a 16F877 in about 37 >>>seconds using 115.2Kbaud. >> >>That's one thing that cannot be done easily with a single processor design. >>In fact I realize that's a deal killer because if the FT232 USB to serial >>design is used, that rate can be pumped all the way up to 2 Mbits/Sec. > >This should not imply, however, that a 16F877 can then be programmed in 2 >seconds. No. Not at all. It just that it'll turn the bottleneck to the programming time and not the interface speed as you alude to below... >The limiting factor is the time it takes the 877 to write to its >own program memory. One time I worked out how long it would take to >transfer all the bytes at the full 115.2Kbaud rate, and I sorta remember the >answer was around 5 seconds. In any case I remember the conclusion was that >the upload time was dominated by the flash memory write time. But a bitbanged interface would probably have issues at that speed. Therefore the hardware UART is a critical component on the infrastructure side of things. ------------------------------------------------------- And Alan.... > >Well thanks. I had got to a point where I figured a picture was worth a >considerable number of back and forth words cluttering up the MIT bandwidth >:) > >snip ......... > >>In short virtualizing I/O. This I can see as an extremely >>useful feature. It of course gives the crossplatform support >>junkie in me the willies, but as long as the specification >snip ......... > >While I like the idea of having the monitor report back to the computer >screen, it does seem to me to take a lot of chip space on the PCB. > >How to interface to the target processor? Use the I/O pins of the infrastructure PIC (iPIC). >How to how to interface to the second processor? I'm still trying to figure that one out. I had always envisioned a two chip system which would be an analogue to your iPIC and primary socket. Since the iPIC would have complete control over the primary socket PIC it would be possible to tie I/O pins directly and configure which would be active during a development session. But I'm not sure how to proceed with 2 secondary processors because neither will have control over the other... > >The easiest way I see to do this is to have a very long shift register made >of 74HCxxx (whatever the parallel in/serial out part number is, don't have >it immediately to hand) and read them using the SPI hardware in the >programming PIC. (hereinafter called the Interface PIC) which then sends the >data back to the host PC. The shift register is made long enough to read all >pins on both target PIC's, and separated on the screen into the two PIC's >for display. Perhaps a set of commands can be implemented in the Interface >PIC - host PC to select primary/secondary/both targets for display, and the >Interface PIC sends only the appropriate ones to the host. Maybe. The problem is that you lose the bidirectional capability that the iPIC's I/O pins give you directly, therefore losing flexibility. > >snip ...... > >>* Despite all of its faults, the prototyping area has to be a breadboard or >> something that's reusable. I read '...consists of all spare PCB area >filled >> with dual in line pads or "measle dot" pads on 0.1" centers'. This would >mean >> soldering to use it right? > >This is going to happen on any prototyping area, unless someone can source a >version of that breadboard that Olin photographed, which can be mounted on a >PCB. It may be that it gets supplied as a separate item in the box, which >the hobby user can screw on, and connect to with patch wires from pins by >the processor I/O pins, and the developer who has bought the unit for >convenience throws the breadboard bit away. That's one avenue. The other is the flip side of that: the main prototyping unit always comes with a breadboard, and then there's a separate final product PCB that's completely solder masked. The RatShack does that with their breadboard. Makes a lot of sense to me. > > >>* Jason's virtual peripheral/logic monitor (VPLM) concept negates the need >for >> a lot of physical hardware onboard. It also eliminates the worry about >> running physical wires to components. I'm not quite sure how well we can >> virtualize analog hardware though. But the upshot is that only a limited >> amount of physical I/O is required. > >See my comments above about the monitor functions. However there is another >couple of bits to consider. On my block diagram I show some push buttons as >input devices. These could be virtualised, again using the SPI function to >feed out to shift registers, but this would mean that the experimenter never >experiences switch bounce, so a couple of real switches will be needed, I think Jason had the right idea, few physical devices and the potential for lots of virtual ones. So a physical button or two would be fine, then have the ability to have 6,8,10 or more virtual ones. >perhaps also a rotary encoder. A virtual reset switch could be ideal, but a >separate push button on the board edge for each target would probably suit >those developers who buy the unit for convenience better. That's all fine. > >>* The primary socket in Alan's diagram needs to come filled with a 16F877A >so >> that the box is ready to go from first turn on. > >Agreed. It may even be worth having the processor programmed already with a >program that makes one port act as a 8 bit counter so the purchaser can get >used to using the logic monitor functions before trying to do their own >programming. Wouldn't hurt. > I am thinking that this should already be in the processor, so >the first thing they do is try the monitor rather than load the program off >CD into the processor to try the monitor. It may also assist factory test :) >It would verify that the chip will program, and is not faulty before leaving >the factory :) That's true too. > >>* We need high voltage for HVP somewhere. > >Agreed, and I think it should be in my power supply block, rather than >generated by the Interface PIC in the manner used by the ICD. Should be able >to be switched off by the Interface PIC though. Correct. > >>* I'd personally be happy if there were at least a connector for an actual >> LCD display. I realize now that it can be virtualized, but it would still >> be nice to be able to connect a physical one to the board somehow. > >I did ponder this, and figured that although there is a defacto standard of >the HD44780, and a sort of defacto standard pinout for the connector they >use, there is enough variation in the pin arrangements that this could be >difficult. The only solution here that I see, if provision is made for an >LCD, is to supply a "deluxe version kit" which has an LCD in the box, and/or >an add-on kit which provides an LCD for which the board is designed. >Unfortunately the add-on kit would need to be relatively high priced, else >10,000 people who never bought the PBK would buy the add-on kit to get a >cheap LCD :) May not be a bad thing to get quantities up for bulk buying >though :)) Else I would certainly consider providing a suitable connector >for it. Well you've seen my couple of thoughts on this above. If the LCD can be virtualized 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. > >>Excellent job gentlemen! So what's next? > >Some thought into what could be done for analogue experiments. > >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. >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. >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. > >No-one has passed any comment on what I have suggested as the physical form >of the PCB. No comment because I'm sure that it matters much. What's on the board is what's important to me. > >Beyond that it is time to start coming up with proper circuits and software >I believe. I am prepared to do circuits in Orcad, but it will take time, as >I need to fit it into spare time. Anything you bring to the table will be appreciated. BAJ -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.