In Circuit Programmer

To do in circuit programming, the universal board needs to be modified slightly. Please discuss this here. This is the process I'm suggesting (same as the powercomms one)

1. create the circuit diagram based on current design, and post it here for review. preferably in kicad, although just for discussion, a napkin drawing would probably work too.
2. create a breadboard / tester board. does it still function as a universal board? does in circuit programming work?
3. if so, do an order of test boards, distribute to developers to test. do they work?
4. if so, send it to production as v1.3 of the universal board.

Why does it need modifying? I have reprogrammed PICs with flash over a serial link before without any extra hardware. The PIC did it all internally. I just sent packets with 64 data bytes and the PIC wrote them to flash and then sent an ack back.

The flash was twice as big as the program so I wrote it to the second half and then told the PIC to reset. The first sector of the PIC contains a small bootstrap that never changes and redirects the vectors to the second sector. The bootstrap looks for a valid complete program in the second half of the flash. If there is one it erases the first half, copies the program to it and then erases the second half. If not it just executes the program in the first half.

The beauty of this method is that the process can be interrupted at any point and still recover. It does however waste half the memory but I find the smallest devices have far more memory that I need for simple control functions. Also the boot sector which never changes has no protocol dependent code in it so you can update you serial protocol if you need to.

---

[www.hydraraptor.blogspot.com]

In the other thread, we came to the consensus that it makes sense to have both high-voltage ICSP for initial programming or if you screw things up to break the serial bootloader. Adding an ICSP header for high voltage programming is a trivial modification so it'll probably be finished before a serial bootloader could be developed. I think once a serial bootloader is in place it'll be used for almost everything and the high-voltage programming will be used for emergencies only. There's another thread for discussing the serial bootloader.

For what it's worth, I've modified the schematic for high voltage ICSP in Kicad and I'm working on making the board suitable for manufacturing at home... it'll take several more hours at the rate I'm going. If the routing gods are good to me, I may be have a prototype working this weekend.

Edited 1 time(s). Last edit at 06/08/2007 05:55PM by emf.

Nop, I think that you will find that the universal control card firmware really hammers the memory limits of the 16F628. Upgrading to the 16F648 effectively doubles the memory, but if your estimate that the method you propose requires half again as much memory you're still going to be cutting it close. Might want to upgrade to the 18F chips. They have far more memory for very little more and, as well, have a much more bulletproof interrupt stack which has diagnostics that can tell you when you overflow. You know a 16F has overflowed when you start getting bizarre behaviour out of it.

Wasting half the memory in a PIC does seem rather... well, wasteful :-)

Some of the reasons we're still using an ancient CVS version of SDCC relate to code bloat in newer compiler versions leading to running out of memory in a 16F628. If the serial programming design being contemplated *doubles* PIC memory requirements, it's likely to be a hard sell for v1.0.

We have something that works as far as PIC, boards and firmware, now. Switching platforms at this point seems to me likely to divert scarce human resources away from the remaining things that really *need* doing for v1.0. Therefore, unless there is very good justification, IMO we should stick with the 16F628A for that release.

In other words, the UCB design is probably "slushy" right now -- mostly frozen. Small changes that make replication (and future mutation) easier (like ICSP, IMO) may make it for 1.0, or at worst a follow-on 1.2 or 1.3 release; larger changes (like switching to a different PIC family!) ... well, I would suggest we wait on those.

If 1.0 is actually going to happen somewhat on schedule, then (IMO) the team will need to try and stay focused.

Jonathan

There's a good argument for shifting from the 16F628A to the 16F648. The two are pin and code compatible. The 648 costs marginally more and you get double the memory. Right now, if I've heard Simon correctly, we've pretty much filled up the memory on the 628A. The 648 would give us some room to modify and upgrade the firmware without having to go in for a lot of drama figuring out how to compress code every time you needed to add something.

There are no real downsides to upgrading to the 648 for v1.

If it's a drop-in replacement (so no board changes at all) and it lets us use a released version of SDCC for firmware development, that could be worth doing. It was your comment:

> Might want to upgrade to the 18F chips.

that had me a bit concerned there :-) That's not going to be a drop-in replacement, for sure!

Has anyone tried building Reprap firmware for a 16F648 and sticking the resulting PIC in a UCB? Did it run? If no one has done this, once I have a working UCB, I might be tempted to try it myself -- as an experiment, not as a recommendation for v1.0!

Codebase cleanup (including allowing use of current versions of all software tools) is definitely going to be valuable in the longer term (it makes evolution so much easier!). Whether that is enough of a priority to be worth major effort pre-v1.0 is something I've not made up my mind about yet.

Back to the topic of this thread: if serial PIC programming *requires* migration to 16F648 to work at all, I'm not sure it is worth it in the near term. Hopefully there is a way to avoid that, and still do serial PIC programming. Just my personal opinion.

Jonathan

I expect that there is an 18F equivalent for the 16F628A/16F648. A long time ago I shifted away from the 16F628A to the 16F877A so that I could get more I/O ports. This was in the days before the Universal Board design emerged. I was able to go from the 16F877A pin compatable to the 18F4610. I expect that something of the sort can be done for the 628A, too. Simon said some time ago that SDCC can handle 18F chips. I expect that somebody, however, will have to do a lot of work building up a reliable 18F SDCC compiler if the drama that's gone along with new versions on the 16F SDCC compiler is any guide. Mind, I'm quoting heresay with this. I stay away from SDCC.

Probably a shift to 18F should be kept back till something like Darwin 1.1 or 1.2. It's not a big jump, but it will take some work. For cost conscious people, there is not a big price jump between 16F and 18F, if any. Even the monster 4610 chip I'm using costs only about $5 and it has 64K of flash memory.

Edited 2 time(s). Last edit at 06/09/2007 01:22AM by Forrest Higgs.

I think we had this discussion before you joined Jon, yeah, 16f648 is a drop in replacement and it works just the same.

Nope, I'll have to take that back. A cursory look at the Microchip catalog doesn't turn up anything in the 18F range that is pin compatible with the 16F628A and others of its ilk. Problem seems to be that you don't get 18F chips without A/D channels and the 16F628A doesn't have any. Mind, there are a lot of 18F chips in the same price range as the 628A, but then tend to have more pins and be a lot more powerful. That means that if you did an upgrade you'd have to redesign the Universal Board. That's too much to undertake for version 1 or even version 1.x of Darwin, I would suspect.

> Even the monster 4610 chip I'm using costs only about $5 and it has 64K of flash memory.

Are you buying them in bulk? Mouser quantity one price is US$10.61. [www.mouser.com] Mouser seems to be the current RepRap project reference supplier.

Jonathan

Mouser can be a little weird on their PIC chip pricing at times. I bought half a dozen directly from Microchip. I think the price including shipping from Thailand worked out to something like $5.61/unit. If you are going to stock PIC chips like the 16F628A or the 16F648 in your store, you might want to check Microchip's prices.

Just checked. Looks like the price out of Thailand has gone up about $1.50/unit in the 4 months since I did my last purchase.

[www.microchipdirect.com]

They're asking about $6.50 for them now before shipping.

I've found that for PIC chips Microchip gives you approximately the unit price for one that Mouser will give you for 25.