RetroBSD

2.11BSD operating system for microcontrollers
It is currently Tue Sep 25, 2018 4:34 pm

All times are UTC




Post new topic Reply to topic  [ 182 posts ]  Go to page 1, 2, 3, 4, 5 ... 10  Next
Author Message
 Post subject: pic32prog
PostPosted: Tue Sep 16, 2014 1:35 pm 

Joined: Tue Sep 16, 2014 12:51 pm
Posts: 47
Location: christchurch, new zealand
hi,
does anyone know how to get in touch with serge (username: vak), the author of pic32prog? i'm wanting to extend it to handle a very primitive class of programming hardware that consists primarily of just a single signal wire from host to programmer, and was hoping he could provide a little advice on reworking adapter-mpsse.c to achieve this end.

cheers,
rob :-)


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Wed Sep 17, 2014 7:02 am 
Committer
User avatar

Joined: Wed Oct 10, 2012 11:01 pm
Posts: 1079
Location: Sunnyvale, CA
Hi Robert,
I got your e-mail about your idea of extremely simple ICSP adapter for pic32mx. Sorry I did not respond yet, as I'm still not sure about it. These days, you know, when PICkit2 clones are available for $14 (free shipping), it makes little reason to invent another slow solution. The idea is viable, but does it worth the effort?
Best wishes,
--Serge


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Wed Sep 17, 2014 12:18 pm 
Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1091
Hi Serge and all,

A one wire bus is a very good idea, but....

Some one wire buses: 10base2 ethernet (cheaper net). My favorite: knowledge net. I also did one for our products. Very simple. Small code. etc.

I think more to the point is what hooks do we need to make adding "whatever" bus to our system easy and straightforward? Both in the boot loader and the kernel.

Now that I have a RAM loadable kernel driver more or less working, maybe this is one way to begin?

Wiz


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Wed Sep 17, 2014 1:02 pm 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
wiz wrote:
Hi Serge and all,

A one wire bus is a very good idea, but....

Some one wire buses: 10base2 ethernet (cheaper net). My favorite: knowledge net. I also did one for our products. Very simple. Small code. etc.

I think more to the point is what hooks do we need to make adding "whatever" bus to our system easy and straightforward? Both in the boot loader and the kernel.

Now that I have a RAM loadable kernel driver more or less working, maybe this is one way to begin?

Wiz

And once again Wiz goes off on a complete tangent. I fail to see what any of that has to do with programming a PIC32 chip through a custom programmer using the pic32prog program...? Nothing at all to do with RetroBSD, it's kernel, or its bootloader, that's for sure.

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Wed Sep 17, 2014 3:22 pm 

Joined: Tue Sep 16, 2014 12:51 pm
Posts: 47
Location: christchurch, new zealand
vak wrote:
The idea is viable, but does it worth the effort?
--Serge


my idea is to be able to make the programming hardware cost as little as absolutely possible, preferably cheaper than the cost of the PIC32 itself. speed of programming is not important for reasons outlined below...

my interest arose through the release of micromite basic (MMbasic) for the 32MX150 (and now 32MX170). mmbasic communicates through a serial console and has a built-in full screen basic code editor - source code is saved in flash and can be set to autorun. it provides a very neat learning environment contained on just one chip, but has the disadvantage that to update firmware folks need to buy a programmer that costs at least 4x the price of the chip itself. as with many such projects, the author (Geoff Graham) releases updates fairly frequently.

i started a thread on the defacto micromite forum, setting out a challenge to produce the "simplest 32MX150 ICSP" possible. this has proven to be one of the most popular threads ever, running to over 500 individual posts and nearly 30,000 views. as a result, a wealth of information has been uncovered and shared. when i started the thread i did not realise pic32prog existed.

two frontrunners have emerged recently, but both have kept their source code tightly closed. for one, the programming hardware is a $3 FT232R pcb and a single resistor, the other uses a second micromite as the hardware interface between PC and target. both are very much less than reliable.

because of a firmware release with a malformed .HEX file, both the frontrunner solutions failed - i found this an odd coincidence. after a bit of forensics investigation i discovered that both of the developers had independently taken pic32prog, stripped out copyright and licensing information, and unnecessary code, then just written 'wrappers' for it. this somewhat upset me, to say the least, and led me to revisit a hardware solution i had proposed earlier on.

my own hardware solution fulfils the 'cheapest possible' requirement - the idea that a kid with $20 pocket money can buy all the bits to create his/her own working micromite basic computer. i've established that pic32prog achieves 99% of what is required on the software side, just needing another adaptor file, a modification of adapter-mpsse.c, to expose a single point of interface to PGC and PGD.

with PGC and PGD brought out, the two signals can very simply be encoded into pulses generated by a serial port running at 1Mbps. these can then be decoded using the following circuit:
Attachment:
File comment: LM555 as an ICSP interface
pic32MX programmer using LM555.gif
pic32MX programmer using LM555.gif [ 10.61 KiB | Viewed 19233 times ]

PGD can be read by counting out/in characters sent to the LM555, and sampling PGD only when the counts match.


so, you see that my desire is for pic32prog to be used in a somewhat unintended fashion, to infrequently update firmware on a basic (retro-computing one might say) system that needs to cost an absolute minimum. a pickit3 or similar blows out the budget of the target audience (kids, beginners) but an LM555 with a bit of clever software fills the bill.

i've installed minGW, downloaded the pic32prog sources, and fixed up the make file so i can now recompile pic32prog. but my C programming dates back nearly 30 years and was on a mainframe, so i really do need just a little help (well, perhaps a lot) in modifying a second copy of adapter-mpsse.c to support the hardware i have in mind. at the same time i'd like to add support for the FT232R solution too.

and i want to keep this all open-source!

cheers,
rob :-)


Last edited by robert.rozee on Wed Sep 17, 2014 4:15 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Wed Sep 17, 2014 4:00 pm 
Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1091
Hi Matt,

I suppose once the chip is cold programmed, it could reprogram itself??

It CAN do this, right?

Seems like a VERY good idea to me :).

New code for the boot loader or main flash supplied from the network or its own SD card.

Lots of fun!

Wiz


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Thu Sep 18, 2014 12:33 pm 
Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1091
Hi Robert,

I am a BIG fan of simple programmers :).

555s are cheap. Nice design :). That said, I almost always talk myself into a cheap PIC instead. The only real annoyance is programming them. I suppose if you really hate yourself you could do a USB one :) for the windows addicts.

Speaking of which I did a cheap PIC16 programmer with only a few transistors, etc. Worked great. Ran on the parallel port and then the serial port for debug (both plugged in at the same time.) A simple script assembled the PIC16 code, downloaded it and started the serial debugger.

In most cases PICs are MUCH cheaper than 555 or analog designs. But needing programming, much more opaque to newcomers!

In this case it is tempting to dedicate one PIC32 "unit" to the programming task and have it talk to the 2nd "unit" that needs programming. Having multiple identical units makes it simpler for the user?

Sounds like a nice project you are working on. Good Luck!

Lots of fun!

Wiz


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Thu Sep 18, 2014 3:19 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
You can build a pic out of 555s:
http://hackaday.com/2011/08/05/building ... 555-chips/

Moreover, you can replace each 555 with:
http://www.evilmadscientist.com/2013/555-kit/
:lol:

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Thu Sep 18, 2014 6:14 pm 
Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1091
Hi Pito,

Nice :).

Maybe it could be built with tunnel diodes.... Remember those?

Or maybe even neurons?

Wiz


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Fri Sep 19, 2014 4:28 am 

Joined: Tue Sep 16, 2014 12:51 pm
Posts: 47
Location: christchurch, new zealand
wiz wrote:
Hi Robert,

I am a BIG fan of simple programmers :).
[...]
Speaking of which I did a cheap PIC16 programmer with only a few transistors, etc. Worked great. Ran on the parallel port and then the serial port for debug (both plugged in at the same time.) A simple script assembled the PIC16 code, downloaded it and started the serial debugger.

In most cases PICs are MUCH cheaper than 555 or analog designs. But needing programming, much more opaque to newcomers!
Wiz


over the years there have been many designs for programming the lower-end PICs through serial and parallel ports. such programmers are very simple (a few transistors), but unfortunately can't handle PIC32's and the likes. nor do they work with modern serial ports too well.

the problem is twofold:

1) today, any serial or parallel port is invariable external and connected to the PC via a usb bridge. this limits what one can do with the I/O lines, and introduces a whole load of latency and synchronization issues.

2) talking to a PIC32 requires being able to manipulate in a complex way three lines: MCLR, PGC and PGD. it is normally not possible to get 3 usable output lines from a standard usb to serial bridge.

you are correct that PIC's are much cheaper than an LM555 and associated components, but have one great failing as a programming device: the chicken and the egg problem - for a PIC to be used to program other PIC's, it first needs to be programmed with something! i wish to arrive at a solution that requires no initial programming.


usb to serial bridges based on the CP2102 and similar are dirt cheap and easily obtained on ebay from china for just a few dollars, but have too few pins that can be controlled. this was a major sticking point, but after much mulling over the issue and discussions, led to the idea of using an LM555 to using serial port TxD characters as pulses: char(0) produces a long negative pulse, char(255) produces a short negative pulse. this can be decoded easily with an LM555 to give one back PGC and PGD data. it is a bit like reading morse code.


it opens up using PIC's to those on a severely limited budget or with next to no resources. it is something simple enough for a beginner or kid to build themselves, giving them a tool that they built themselves and that is useful.

one can say, "why not just buy a PICKIT3?", but for many a PICKIT3 is outside of their budget. i want to bring those people back into the fold. i just need a little help to achieve this - even if just programming advice.


rob :-)


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Fri Sep 19, 2014 12:25 pm 
Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1091
Hi Robert,

I agree.

A friend recently loaned me a box. Pretty hot computer. SATA drive removed.

Eventually I booted Linux from CD and 'installed' the OS on an SD card. Works well.

Which brings me to more or less the same point as you. The box ONLY has USB ports and one ethernet port!!

What a disaster!! How do you interface real hardware to it. Particularly since USB is a proprietary nightmare both as to licensing and hardware!

I like your solution. Buy USB -> serial and build 555 support board.

I would suggest another prong or two to the solution.

PIC32 'supports' USB (does it really?). Figure out how to use that so that your board can program other similar boards. This would be a 2nd solution.

i.e.- Make it a USB ->serial->555 work alike. Not too hard??

Better yet make the PIC32 talk ethernet. Though I haven't yet done it, it seems to me that the PIC32 'should' be able to generate 10baseT in software (the at tiny can!). If I can figure out a cute way to receive 10baseT I neatly avoid all the proprietary stuff and have a 2nd hardware solution.

Note to myself: I really ought to cut out some time to try to get this working...

p.s.- Or just use the PIC32 box to develop software that runs on the PIC32. We really ARE there at this point :) ! This is what I am currently doing. The "BIG" development box is NOT NEEDED except as a serial terminal. And as a box to facilitate moving stuff from one PIC32 to another. Works great here.

Lots of fun.

Wiz


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Sat Sep 20, 2014 5:31 am 
Committer
User avatar

Joined: Wed Oct 10, 2012 11:01 pm
Posts: 1079
Location: Sunnyvale, CA
Well, an ultra cheap pic32 programmer sounds like a worthy challenge by itself. But I should notice, pickit3 clones are not so expensive these days. Recently my friend ordered a bunch of them for $16 per unit: http://www.aliexpress.com/item/pickit3- ... 42544.html


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Tue Sep 23, 2014 12:30 pm 
Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1091
Hi Serge and all,

I wonder if there are any PIC32 boards for $16?

Seems like it ought to be possible?

Basic board with user added sockets, etc. maybe?

Gotta run RetroBSD!

Wiz


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Tue Sep 23, 2014 12:47 pm 

Joined: Tue Sep 16, 2014 12:51 pm
Posts: 47
Location: christchurch, new zealand
there is the PIC32MX170, which in a 28-pin DIP package has 64k of ram and 256k of flash. i've heard some suggestion that a '190 may be planned with double the rem and flash.

the 28-pin DIPs can be assembled onto a piece of veroboard with just a 10uF ceramic capacitor as the only external component needed.

rob :-)


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Wed Sep 24, 2014 3:56 pm 
Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1091
Hi Robert,

Good suggestion. We do need 128 k ram to run RetroBSD. And the more the better! A cheap PIC32 'mz processor might do it? I too prefer DIP plug-in. I guess I gotta look at Microchip product line again to see if there are any recent micros that fit.

Right now caching seems to work well using the SD card. Maybe some SD cards have their own cache RAM that we unknowingly use?

$16 is a pretty tough price target, but maybe the basic model lacks sockets and many parts and thus meets our goal?

Lots of fun.

Wiz


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Thu Oct 02, 2014 5:46 pm 

Joined: Tue Sep 16, 2014 12:51 pm
Posts: 47
Location: christchurch, new zealand
i've been making good progress - the PE downloaded in less than a minute, and complete programming and verify in about 20. plus there is room to see a considerable speedup with improved buffering. i am using an 'intelligent' programmer. at the moment a 32MX150 running a short micromite basic program that decodes single-letter commands, with plans to later on move to a arduino mini (costing a couple of dollars on ebay).

two problems at the moment though:
1. getting in touch with Serge. emails and PM's have gone unanswered, and i really am at a point where i need some guidance from him.
2. with Serge's code i am having real trouble reliably resetting the target into a "known state", and some of the things done around resetting just don't make sense. not helped that the pic32mx150 devices that i'm working with seem to respond to many JTAG commands when MCLR is in a state that does not match the datasheet.

Serge - are you still out there?


rob :-)


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Thu Oct 02, 2014 7:43 pm 
Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1091
Hi Robert,

Programming VIA j-tag:

I started my pic32 journey using j-tag. I eventually built a j-tag debugger

that could dump and program. The principle problem that I discovered was that the pic32 seemed

to need a processor clock to communicate between the j-tag stuff and the processor core??!!

My j-tag debugger runs on an old Linux (knoppix 3.6) box via parallel port, but otherwise runs reliably.

It is VERY slow. I can read a write the WHOLE pic32 state which is comforting. I suspect that the actual

operation of the j-tag -- processor core may have some gotchas? Programmer beware. Or put

another way: Are we having fun yet? I do have a few comments that say something like. I am not sure why this is needed? But it seems to be needed to work.

I am NOT looking forward to trying to figure out the MZ !!!!

wiz


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Fri Oct 03, 2014 7:43 am 
Committer
User avatar

Joined: Wed Oct 10, 2012 11:01 pm
Posts: 1079
Location: Sunnyvale, CA
Hi Robert,
Sorry, I'm still out of topic... Tomorrow I will to your PM's about the bitbang intrinsics.
--Serge


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Fri Oct 03, 2014 12:19 pm 

Joined: Tue Sep 16, 2014 12:51 pm
Posts: 47
Location: christchurch, new zealand
Serge: that would be excellent :-) please read the below before replying to those PM's, as many of the problems i was having when writing them i have now resolved.

i can now program a pic32mx150 intermittently. when programming it works, downloading the PE takes around 30 seconds, programming 128k is another 13 minutes, while verifying takes 5 minutes. so less than 20 minutes all up, which seems quite acceptable.

BUT, one unique problem for me is that the .HEX image i am using, almost immediately after it starts running, disables the JTAG interface. this is by design according to the MMbasic author. so it is absolutely essential that the downloaded code not be allowed to run while pic32prog is talking to the target.

pic32prog seems to do odd things with MCLR (via bitbang_reset) that i don't fully understand, and i am not even totally sure if passing in sysrst = 1 should set MCLR high or low, or toggle the current state. i feel my intermittent problems may be related to the target accidentally starting to execute code from flash.

one other problem is that verify seems to always fail at address 0xFC00B80, but i am ignoring that one for the moment - the downloaded code (MMbasic interpreter) still seems to work ok and there are other issues i need to iron out first.


cheers,
rob :-)


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Sat Oct 04, 2014 8:00 am 
Committer
User avatar

Joined: Wed Oct 10, 2012 11:01 pm
Posts: 1079
Location: Sunnyvale, CA
Hi Robert,

I'm glad you've been able to sort out bitbang_send() and it's parameters. If it works for you, it's great. Even if slow, it could be useful for bootstrapping a fresh chip, say program a small bootloader first, and then use USB HID protocol or stk500v2 protocol for uploading an user application.

As for reset, pic32pog should not allow the programmed target code to run until the session is terminated by bitbang_close(). Signal MCLR is active low, so when sysrst=1 in bitbang_reset(), MCLR pin should go low.

Signal MCLR (named /SYSRST on most jtag adapters) is activated (set low, or sysrst=1) first in adapter_open_bitbang() function, and held active until the processor is switched to EJTAGBoot mode by serial_execution() function. Since then MCLR is deactivated (set high, or sysrst=0), but the user code cannot start, as the core remains in Debug mode right after reset, still under control of pic32prog software. EJTAGBoot is cleared in bitbang_close() function, then MCLR toggled low-high, and the user code starts.

I have no idea about the address 0xFC00B80. It seems out of range: no programmable flash memory is mapped here.

Best wishes,
--Serge


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 182 posts ]  Go to page 1, 2, 3, 4, 5 ... 10  Next

All times are UTC


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
cron




Powered by phpBB® Forum Software © phpBB Group

BSD Daemon used with permission