[s:]I called it "firmwareA2" so that the directory is more easily recognizable for what it contains, firmware for the Web Platform. The "A2" refers to it now being the second alternative firmware choice for the Web Platform.[/s:] As directed by Ian, the /trunk/web-platform/firmwareA2 directory has been moved and renamed to the /trunk/web-platform/FreeRTOS/port-eric directory as of r550.
I have set up the directory structure under [s:]/firmwareA2[/s:] /port-eric as specified in the Wiki. To this end, the /trunk directory will always contain the most recent but potentially unstable version of the code. The /tags directory will contain directories for released versions; code here should never be changed. The /branches directory will contain directories for maintenance of that numbered branch. Bug fixes should be made in /branches/X.X and this code should always be kept stable.
Based on this format, I have committed my code to /trunk and created a /tags/0.0.0 and a /branches/0.0 directory. Right at this moment (r543) all three of /trunk, /tags/0.0.0, and /branches/0.0 contain the exact same code except for the version string they report. Project files are in the root folder, all source code is in the /src directory and the output files are in the /bin directory. The CustomColors.txt file is for use by the MPLAB editor to add user defined color syntax highlighting. This is under Edit, Properties, Text tab, User Defined Color File.
At this point I would say the code is at a pre-alpha release stage but it does run. The DHCP client will acquire an IP address and a web server will be started. The web server will read files from the /www directory on the microSD card. Currently long file names are not supported so all files must follow the 8.3 naming convention. Therefore, create an /www/index.htm file for the default page. (I also added a /www/favicon.ico from the DP site to mine:) The USB serial port is set for 115200 baud 8,N,1 and will provide status messages. At this point the console will echo characters you type back to you but that is all it does.
I would not have released it at this point yet except that Ian asked to see how it was progressing. I doubt a lot of people will be interested in it but it is now available. I will continue to work in the /trunk directory and I expect things in there to change drastically. If you want to fix any bugs or would like to make some minor updates please do it it the /branches/0.0 directory and please keep the code stable. Anyone is more than welcome to follow along and test the code in /trunk. It is however still growing and evolving at this point and I may move/combine/eliminate any code in there in a seemingly random fashion.
A .hex file is available in the /bin directory that can be programmed in to a v1.0 or v1.1 Web Platform. At this point there is no bootloader. The .hex file must be programmed with a PIC programmer. Since Ian recently stated that all Dangerous Prototypes projects are first and foremost to fill a personal need for him and then as an added bonus to make the work available to the hacker community, I do not feel too bad in saying that this firmwareA2 project is the same for me. I am glad to give back to the community, am open to suggestions and welcome your feedback but I realize this may only be useful to me.
Well, not really the black market, more like the gray market. I came across someone selling Web Platforms on eBay from Hong Kong. I didn't realize there was that much of a market for these things that someone could make money selling them on eBay.
I am trying to get a new router setup for when I move to a more permanent home here in a couple weeks. At some point I messed up a config file or two and locked myself out of all the lan subnets/VLANS. I had to pop open the case to get at the serial console. This is brought out to a row of unpopulated .100" holes and operates at 3.3v levels. I of course had my Bus Pirate laying on my desk/workbench. In a matter of seconds I had the console up in a terminal window using the transparent pass through macro. A couple quick vi edits and the Ethernet connections were back up.
This of course isn't anything terribly special. I have several USB to serial converters in my parts bin that I could have used for this. But the versatility of the Bus Pirate means it is always getting used and so always right at hand for the next job.
One of the things that slightly annoyed me about the Bus Pirate was that normal line editing commands other than backspace were not implemented in the terminal. I make a fair number of typing mistakes, probably more than the average person, and so wanted a little more advanced editing capability.
I made several changes to the ProcMenu.c code to add:
[left arrow] ^B Moves the cursor left one character
[right arrow]^FMoves the cursor right one character
^AMoves the cursor to the beginning of the line
^EMoves the cursor to the end of the line
[backspace]^HErases the character to the left of the cursor and moves the cursor left one character
[delete]^DErases the character under (or to the right of) the cursor and moves the cursor left one character
I also added the ability to insert text into the middle of a line because otherwise left and right arrows aren't that useful. If you are not at the end of the line and you type a printable character it will insert the character at the current cursor position and shift the rest of the line to the right. Likewise, if you are not at the end of the line and you use backspace or delete the appropriate character will be erased and the rest of the line will shift to the left.
I had to cheat and use a couple goto's to get it all to fit with the bootloader -- it is that tight. I made these changes for my own use but if we can get them to fit it would be nice to include them (or a subset) in the next release. I have a few other changes I want to implement using the up and down arrows to cycle through the command history. I don't need/want the bootloader on my Bus Pirate so I am not concerned if the command history changes are too big but I will try to get them to fit and also try to clean up the code to see if I can make some extra room (and get rid of the goto's).
Please give this a try and let me know if you find any bugs or if it broke anything else. Also let me know if it does not give the expected behavior. I tried to copy the way I think most terminal and command line editing works but I may be off on something.
I was using it in UART transparent pass through mode with another project I am working on. It had been working just fine for a day or two and then it just stopped working. I had used it successfully with in five minutes or less before it died. At first I thought it was a problem with my project and that my last code change broke the serial interface.
After looking through my code for a while I decided to check the Bus Pirate. I unplugged the Bus Pirate and plugged it back in to get out of the UART transparent pass through and back to its command prompt. When I plugged it back in I discovered that it in fact had stopped working. After disconnecting and reconnecting it a few times along with closing and opening my terminal program I tried it on another computer but got no response there either.
The power light will come on and the USB activity light will blink when it is plugged in. The computer is recognizing the USB serial port so the FTDI chip is working. I jumpered PGC and PGD and then plugged it in and the mode light came on. So I downloaded a new v5.7 firmware using the BPv3-Firmware-v5.7.hex file. This seemed to go fine with the following response from ds30 Loader.
[hr:][/hr:][tt:]Initiating download... Searching for bl . Found PIC24FJ64GA002 fw ver. 1.0.2 Waiting for bootloader to be ready...ok Writing flash...ok Download finished Tx 65.2kB / Rx 382 bytes / 12.4s[/tt:][hr:][/hr:]
I unplugged the Bus Pirate, removed the jumper and plugged it back in but still get no response.
I'm not sure what else to try. I could try programming it directly but, the boot loader seems to be working correctly and it just installed a fresh copy of the firmware so, I don't see where programming it directly would do any better.
What should I check next? I don't think it should make a difference but this is a SparkFun version.
The only other useful information I could think of was a memory dump of the PIC so I have attached that as well.
I appreciate any help anyone can provide. Thanks in advance.
From the photos it looks like they are reselling the DangerousPrototypes product and did not recreate their own version as they did with the Bus Pirate. Out of curiosity, does anyone know if DangerousPrototypes is getting and commission on these? Is SparkFun fabbing these themselves or buying from Seeed?
I just got my Bus Pirate a couple days ago from SparkFun. I have since read that there was some minor controversy over SparkFun creating their own hardware version. I just wanted to add that I would have probably never heard of the Bus Pirate or found DangerousPrototypes if it wasn't for SparkFun selling their version. Now that I'm here I'll probably end up getting a Logic Sniffer too.
The first thing I tried to do with my Bus Pirate was get a surplus LED display working. I had picked up the alphanumeric display some time ago but never got around to playing with it. This seemed like a reasonable first challenge. The Bus Pirate and I would have to do some "real" work instead of just reenacting a canned EEPROM demo. But it I thought it would be a simple enough exercise to be accomplished in an evening. The display uses a serial to parallel shift register and then the digits are multiplexed. It must be sent a "packet" of five bytes continuously to keep all the segments refreshed.
Using the SPI mode I could easily send the five bytes needed to get one digit at a time to light correctly. I was able to verify the display hardware and my understanding of the digit and segment to bit mapping. Next I wanted to try to see if I could get multiple digits working. I read through the whole Bus Pirate documentation Wiki and it appeared that the BASIC script engine would let me do what I needed. I was planning to create a loop that would send the seven five-byte packets repeatedly with time delays between each packet.
I first discovered that the SEND command will only accept a one byte argument and it must be in decimal format. This is not very convenient but it is workable. I was not yet sure how I was going to do the looping or the delays so I just typed out all the send commands on lines 100-104,200-204,...,700-704. I am not at my development computer now but I think the LIST command said it was 202 bytes.
On to my problem. I typed RUN just to see if a "0" would rapidly flash across all the digits in succession. And it did, more or less. The display flickered with what looked like a zero on each digit but it did not stop with the 7th digit light. The 5th digit was the one still light. When I LIST'ed the program I found that the lines were not in order! Each subgroup was in the correct order, i.e. X00,X01,...,X04, but the groups themselves were not in order. It went some thing like 100-104,300-304,...,700-704,...,500-504. This somewhat explained why the fifth digit was the one that remained light.
Now the bigger question is why are the lines out of order. When I typed the lines in I typed them all in order, 100-104,200-204,...,700-704, all at one time so I know they are not being listed in the order I typed them. Does anyone have any idea what is going on?
I searched the forums and could not find any threads about the BASIC script engine at all, let alone any problems. It appears maybe not that many people use this feature but I think could be very useful -- if it works. From what I have read it seems a lot of people are using some scripting language on a computer for more complex tasks instead on the internal BASIC interpreter. In my case, I do not regularly use any scripting language. It would take me longer to install, configure, troubleshoot, learn, etc. a new scripting language to do some simple development work than to just switch over to MPLAB and write a test program in C natively for the PIC/dsPIC I normally use. The built-in BASIC script engine however would be a very quick way to test things a little to complex or burdensome to do by hand with the normal Bus Pirate interface. I vote to keep it.
The Bus Pirate is still plugged in with the BASIC program in memory. When I get back to that computer I can provide actual listings or any other data that may be useful. Thanks for making this project available and for any help you can provide.