I've been using newterm for so long I forgot everyone else wasn't. rhyde commented that he wanted to move back to newterm but was stuck at v4 because of the PIC programmer command. These are fairly minor changes, and there's really no reason to keep working on the v4 branch if we just have to port everything over. I'd like to prepare a v5 release, but I have a list of outstanding bugs to clear.
These are the things I'd like to clear for a v5:
[s:]*Add PIC programmer command to newterm[/s:]
[s:]*Smartcard ATR problem[/s:]
[s:]*Frequency counter low frequency problem[/s:]
[s:]*Test with PCF8563[/s:]
I need to go over a bunch of boards today, but I'll probably work on these items tomorrow. The PIC programmer is almost to a good beta state, so people will need to upgrade anyways.
I added a v4.3 code freeze to the SVN. I'd like to move the newterm folder to the main code directory in trunk. Sjaak - can you do this because you have the latest code and I don't want to cause you a headache by messing with the SVN.
I'd like to release a bootloader v4.3/4.4 update too, I've been using it forever and love the new features, but it might be a bit much for right now. Maybe I'll make a test installer and post it in the forum instead of on the blog.
Sometimes in the forum I say I add something to my list. I attached a (camera phone) image of the todo list :)
Edit: Sjaak already added the new command to rawwire
v5.1 to do
*I2C clock stretching (maybe 5.1, maybe hardware?)
*Increment rawwire to v2 (wait on this for an updated SPEC)
*Updated I2C sniffer
*Detect hardware version
I have also a to do list *) for the v5:
- [s:]openOCD support[/s:]It compiles :D
- [s:]convert JTAG library[/s:]
- [s:]convert AT-keyboard library[/s:]
- [s:]remove old (commented out) code[/s:] Ian already did a great job on this
Also make some room for the above. [s:]I was thinking making the scripting engine optional with a #define[/s:]. Useless i2c subs commented out (will be needed in new hw (4+) revision)
*) subject to change ;)
todo for 5.1:
- [s:]implement robots evaluator in the scripting engine[/s:] Udif fixed it already
- adjustable baudrate (bp terminal itself and the UART library)
Edit: jtag library is removed upon request ;)
Edit2: code cleanup (How could I forget!)
Ah man, I really wish we could get rid of the JTAG library. Maybe we could at least get rid of the state machine and add something to do the last clock tick to leave a state with TMS high. Macros? That code is nasty, and it takes a bunch of space. Very few people use it.
I'm going to do the ATR for the smartcard first, I think it's easiest. It's a problem of not dropping the clock or data after the stop condition.
In v4 firmware the I2C stop was updated to be more compliant, but as a result the clock line isn't returned low and the smartcard read is corrupted.
To work around this, I updated this demo to manually place the clock low () after the stop bit (}). This command can be included in previous versions too with no ill effects because the clock is already low. The new command for reading out the sim card is:
{0x30 0 0xff} r:255 r:10The demo has been updated too:
http://dangerousprototypes.com/2009/08/ ... rd-update/ (http://dangerousprototypes.com/2009/08/31/bus-pirate-sle4442-smart-card-update/)
There was no reasonable firmware fix for this aside from a custom stop condition for smartcards.
Now I'm doing the frequency counter.
I removed rawwire increment because I think we should wait until an existing command changes - it's still in flux. New commands not supported in an old firmware return 0 so the 'no such command' is already acknowledged. 7 has the programmer reading HEX and programming now, but the 'hold clock high on last bit for a long time' needs to be updated. I think that's the last bug, then we should look at a better protocol based on your binary PIC mode.
Looks like we'll need to use an autorange on the frequency counter. Timer1 only inputs on the SOSC pins, and does not have a PPS assignable input. PPS input table attached.
On a zero count I'll add an 'auto range' text and try again with 0 prescaler.
You've got a day off or what? you're so fast ;)
Shall I take a look tonight at pc-at library? I think the pic binmode can wait a bit (the OLS can be rescued atm and that is the main concern?)
A whole day of Bus Pirate hacking fun :) Work on whatever you like, I'll be around to work on these 3 related projects all week (OLS upgrade, BP upgrade, PIC programmer). I think there will probably be an interim v4.3 release today to get all the recent updates (OpenOCD, rawwire update, etc) into a final v4 firmware. I'd like to release an initial rescue package tomorrow, and I don't want to rush v5 that much.
We'll probably need to remove the config words from the info screen. The 4 lines need to be the same for a number of apps that parse the output for version number.
Another thing to consider is that v3b has a certain pin grounded. By using the internal pin pull-up resistors we can tell if it's v3a or v3b too :)
Do I hear a bugreport about the '+'? Whooooot! It sounds like a great day! ;)
I think the configwords should be on the info screen never the less.
BTW I already added the new pic revision that is out.
There are actually multiple things going on with teh frequency measurement and generator. Here's my change log so far:
*PWM input was less than the displayed range, changed so freq can = 1 to 4000 and duty can be 0-99 (was 4 and 2).
*added autorange,
*noticed that at low frequencies the error is very high (1khz only tripped the 256prescaler 3 times, showing 768hz speed), so autorange now applies to all counts less than 256 (1% error). These frequencies should still be in spec for the pin and timer (seems to work in tests), and the results for low frequencies are MUCH more accurate (see screenshots).
*The PWM currently displays the PR2 and prescaler for accuracy calculation, but I doubt it means anything to anyone so I removed it.
*The Khz/mhz display does noT show decimals, so 4999 shows 4999Hz (4KHz). Rather than add a decimal point, I just added + to the display so it shows 4+KHz. The real point of the division is so you don;t have to count places to get the frequency, so this still helps without floating points.
Also:
*cleaned out a lot of old code as I was poking around.
*I promised a few app authors to keep the first four info lines the same so they could count on it. I added the config words back, but they now appear on line 5 when you are in a mode (moved to start of extended info function).
*updated some text (not yet included in the compile, will do it all at once): I2C start/stop shows correct signal shape now, PWM is no longer beta.
Attached my latest compile, and committed changes to SVN.
I'll look at clock stretching, but it may slip to v5.1 depending on how many other things have to be changed.
Didn't someone submit an updated I2C sniffer too?
I'm going to wait on the I2C clock stretching. It's going to take a larger overhaul, probably a new custom I2C library. Maybe we can discretely enable hardware I2C for people who want it?
Here's a wikipedia example with clock stretching:
http://en.wikipedia.org/wiki/I%C2%B2C#E ... r_protocol (http://en.wikipedia.org/wiki/I%C2%B2C#Example_of_bit-banging_the_I2C_Master_protocol)
Tested the PCF 8563, didn't find any problems with v4.1 or v5.0:
http://dangerousprototypes.com/forum/in ... 74#msg5674 (http://dangerousprototypes.com/forum/index.php?topic=548.msg5674#msg5674)
be aware the userinput function is a bit different then the old one!
Yes, it's much nicer ;) I added comments to that part, and several other parts of the new code as I figured out how it works.
I'm putting the final touches on a v4x to v4.3 bootloader upgrade now.
I just said it because you said:
*PWM input was less than the displayed range, changed so freq can = 1 to 4000 and duty can be 0-99 (was 4 and 2).
But by looking at the source code I know what you meant :D I took the original values and I guessed they were hw limitations.
I'm sorry for the lack of comments ;)
btw the sniffer: http://dangerousprototypes.com/forum/in ... 06#msg5406 (http://dangerousprototypes.com/forum/index.php?topic=602.msg5406#msg5406)
You did a lot of work, thanks! I'm gonna port the pcatkeyb function now and hopefully move the newterm to the trunk. fingers crossed!
Hi,
I have done some test with PWM on latest Firmware v5.0 (Firmware v5.0-pre3 (r358) Bootloader v4.2) with my Bus Pirate v3b and my Open Bench Logic Sniffer.
It seems there's a problem for PWM Duty Cycle at 1% output signal is always set to low state !! (it works for Duty Cycle99%)
See the other test it seems some PWM Duty Cycle are not very accurate depending on test.
See the zipped report in attachement.
The autoranging frequency command is nice. However it needs a better way of printing. I find the (1+KHz) a bit confusing, can we skip it? It's better not to do the division and display MHz/KHz so people know the magnitude or add a proper printfloat (move to the 5.1 wishlist :) )
I just added it to the strings anyway and I updated the svn with the textes and the keyboard library added.
BTW: also smashed a cosmetic bug in convert commando and changed the version string to 'Firmware v5.0-RC1 (r369)'
[quote author="TitanMKD"]
Hi,
I have done some test with PWM on latest Firmware v5.0 (Firmware v5.0-pre3 (r358) Bootloader v4.2) with my Bus Pirate v3b and my Open Bench Logic Sniffer.
It seems there's a problem for PWM Duty Cycle at 1% output signal is always set to low state !! (it works for Duty Cycle99%)
See the other test it seems some PWM Duty Cycle are not very accurate depending on test.
See the zipped report in attachement.
[/quote]
I believe the pwm isn;t very useful (read accurate) in it lower and higher duty cycle settings. It also depends on the frequency used (just by looking at the source frequencies of 244 or 30 KHz will give the highest precission). We are getting this one out (the v5) and afterward we will look deeper into it.
This is why the original code has the minimal dutycycle of 2% (I guess)
Thanks for the detailed report TitanMKD. PIC PWM modules have limited resolution depending on the speed. Some settings will only have a few bits of resolution. 4MHz (?) for example only has one bit, 50%, anything else resolves to 0% or 100%. The PWM could estimate and issue a warning when the selected duty cycle gives 0 or 100%.
@Sjaak - feel free to change it. I just wanted to fix the underlying problem, I'm not at all attached to the display. We can make it just show (MHz) (KHz) as a hint of the scale, or we could bite the bullet and do the proper thing and make it show decimals to one place or so ;) Or all of these, each in it's own time. I'm going to test the latest programmer now, after that I might add the decimal display to freq measurement.
updated the svn with rev 370:
- added OpenOCD
- disabled pic library by default
- disabled I2C subs in basic system
and attached it.
Hi ian+Sjaak,
I have developed the I2C sniffer further, it now uses compression and still captures 400kHz fine I'm happy to share the code, if your interested, I don't know what direction you want the scanner to go in, as the original displays results realtime and that was a nice feature and the code I have developed returns results after a capture, perhaps a new macro could be added for high speed capture ?
Darren
[quote author="Sjaak"]The autoranging frequency command is nice. However it needs a better way of printing. I find the (1+KHz) a bit confusing, can we skip it? It's better not to do the division and display MHz/KHz so people know the magnitude or add a proper printfloat (move to the 5.1 wishlist :) )[/quote]Why not just have the firmware report the period of the signal, the precise value from the hardware, and leave it to the front end to convert this to frequency? That way, you won't need floating point or even decimal or comma printing in the firmware.
[quote author="Darren"]
Hi ian+Sjaak,
I have developed the I2C sniffer further, it now uses compression and still captures 400kHz fine I'm happy to share the code, if your interested, I don't know what direction you want the scanner to go in, as the original displays results realtime and that was a nice feature and the code I have developed returns results after a capture, perhaps a new macro could be added for high speed capture ?
Darren
[/quote]
I don't know how usefull the old sniffer was, but i think it was limited to low speeds. I would say replace the current.
If you would share the code we are happy to integrate it into (I think) 5.1. Could you explicit state you donate the code and place it under Create Commons 0 license?
[quote author="rsdio"]
Why not just have the firmware report the period of the signal, the precise value from the hardware, and leave it to the front end to convert this to frequency? That way, you won't need floating point or even decimal or comma printing in the firmware.
[/quote]
I think just printing the precise number (the frequency) is good. It only needs a friendly display (the printfloat), so 1900 would display as 1.900KHz.
[quote author="Sjaak"]
[quote author="rsdio"]
Why not just have the firmware report the period of the signal, the precise value from the hardware, and leave it to the front end to convert this to frequency? That way, you won't need floating point or even decimal or comma printing in the firmware.
[/quote]
I think just printing the precise number (the frequency) is good. It only needs a friendly display (the printfloat), so 1900 would display as 1.900KHz.
[/quote]Sorry, I was making a few assumptions. First of all, I assume that the firmware is directly measuring the period, not the frequency. Converting the actual period into an equivalent frequency requires more firmware, and Ian seemed concerned about the additional code needed to figure out where to show the decimal point, or to deal with floating point. I also get the impression that the Bus Pirate firmware is already too large, but I might be getting confused with another Dangerous Prototypes platform.
In other words, make the firmware do less, and it will be both more accurate and take less code. Since the period is more accurate than the conversion to frequency, it seems better to have the firmware report the period and let the computer front end handle the calculations to the precision desired by the user. Of course, some users will be working with a simple terminal as a front end, so they'd have to pull out a calculator. But I'm thinking along the lines of a more elaborate front end than that.
Bottom line: If you can get it to display 1.900 kHz, then I think that's much better than 1+ kHz.
The v5 firmware adds a ton of new functionality, but it is pushing the limit of what the PIC will hold.
The frequency measurement actually takes a 1 second tick count, it doesn't measure the period and calculate. Edge triggered period measurement would be a handy feature to implement though, for stuff like baud rate estimates and clock signal estimates.
The v4 firmware displayed the raw tick count, and a non-decimal KHZ or MHZ figure so you don;t have to count places to see that it's 4MHZ. It looked like this:
HiZ>f
Frequency on AUX pin: 1987654Hz (1MHz)
HiZ>
That's a lot closer to 2MHz and it's confusing. I changed it to:
HiZ>f
Frequency on AUX pin: 1987654Hz (1+MHz)
HiZ>
The best would be a proper decimal, but the current decimal output function is specifically for ADC readings.
HiZ>f
Frequency on AUX pin: 1987654Hz (1.9MHz)
HiZ>
[quote author="rsdio"]
[quote author="Sjaak"]
[quote author="rsdio"]
Why not just have the firmware report the period of the signal, the precise value from the hardware, and leave it to the front end to convert this to frequency? That way, you won't need floating point or even decimal or comma printing in the firmware.
[/quote]
I think just printing the precise number (the frequency) is good. It only needs a friendly display (the printfloat), so 1900 would display as 1.900KHz.
[/quote]Sorry, I was making a few assumptions. First of all, I assume that the firmware is directly measuring the period, not the frequency. Converting the actual period into an equivalent frequency requires more firmware, and Ian seemed concerned about the additional code needed to figure out where to show the decimal point, or to deal with floating point. I also get the impression that the Bus Pirate firmware is already too large, but I might be getting confused with another Dangerous Prototypes platform.
In other words, make the firmware do less, and it will be both more accurate and take less code. Since the period is more accurate than the conversion to frequency, it seems better to have the firmware report the period and let the computer front end handle the calculations to the precision desired by the user. Of course, some users will be working with a simple terminal as a front end, so they'd have to pull out a calculator. But I'm thinking along the lines of a more elaborate front end than that.
Bottom line: If you can get it to display 1.900 kHz, then I think that's much better than 1+ kHz.
[/quote]
Basicly the function counts pulses during one second, the result is frequency (with a slight error cause by prescalers and not using a crystal). By dividing it the error becomes less and more readable.
The firmware is indeed getting fairly big now (all options won't fit atm). We are working on that too.
like ian says :D
BTW: i think the output should be formatted to the user and the user don't needs to convert anything.
[quote author="ian"]
The best would be a proper decimal, but the current decimal output function is specifically for ADC readings.
HiZ>f
Frequency on AUX pin: 1987654Hz (1.9MHz)
HiZ>
[/quote]
In pseudocode (wrote it between eating two slices of bread ;)) :
if(l>1000000)
{ temp=l/1000;
print(temp);
print(',');
l-=(temp*1000); //or modulo
}
if(l>1000)
{ temp=l/1000;
print(temp); // leading zero's
print(',');
l-=(temp*1000); //or modulo
}
print(l); //leading zero's!
the print function, except the first one needs to display max 3 leading zero's.
I updated to the latest SVN and moved all the newterm files to the main source folder. There's also a snapshot of v5newterm off the main directory. I also switched the commit logs to go to a google group because there's lots of activity and everyone should be able to get the notices:
http://groups.google.com/group/dangerou ... evelopment (http://groups.google.com/group/dangerous-prototypes-development)
I'm taking a look at it now. I'd like to maybe make a new bpWfloat function for the bpWvolts and the frequency measurement to use, not sure how feasible this is.
[quote author="ian"]
I updated to the latest SVN and moved all the newterm files to the main source folder. There's also a snapshot of v5newterm off the main directory. I also switched the commit logs to go to a google group because there's lots of activity and everyone should be able to get the notices:
http://groups.google.com/group/dangerou ... evelopment (http://groups.google.com/group/dangerous-prototypes-development)
[/quote]
Thanks for moving. Was postponing that one :D
The frequency isn't a float btw ;) Displaying more digits in voltmeter mode is useless (not precise enough).
[quote author="Sjaak"]Basicly the function counts pulses during one second, the result is frequency (with a slight error cause by prescalers and not using a crystal). By dividing it the error becomes less and more readable.[/quote]Thanks for the description! I didn't think about a "frequency counter" but was rather thinking of ways to use a Timer to measure period. Since your original value is frequency after all, my comments are moot.
But, as Ian says, it would be cool to measure the period between edges of the signal. It would be great to use the Capture feature of the PWM/Timer circuits on the PIC to directly measure the period. You lose the long-term averaging of the frequency counter method, and could suffer from jitter for high frequencies compared to the PIC clock, but it would be a nice feature to have as an option.
I'm sorry, I didn't get the frequency output implemented today. It took me longer than expected to finish the Flash Destroyer wrap up.
No problem! It was a nice post about the internals of the eeprom. I would have guessed the bits cannot be set to '1' (erased) instead it couldn't be cleared.
Updated the svn with version 378:
- added friendly function to print large decimals
- some text fixups
Bus Pirate v3
Firmware v5.0-RC4 (r378) Bootloader v4.1
DEVID:0x0447 REVID:0x3043 (B5)
http://dangerousprototypes.com
HiZ>
HiZ> f
Frequency on AUX pin: 12,345,678 Hz
HiZ>
Find it attached to this post.
This doesn't belong here, but I added two new commands to the v5 rawwire mode They're just placeholders for a better function, but they currently send 4bit/16 and read 4bit/16 with 1 byte overhead (6/14 not implemented yet).
it's not as nice as your pic mode with no-bytes overhead. It's a huge improvement over the current situation because the programmer can send command+data at once and it might eliminate one of the big bugs we currently have Right now we can only write one page at at time, then have to leave ICSP mode and return again to program the next page. This is really slow, but it works for now. I think it's because currently the BP received the command, sends it, acks it, sends data byte 1, acks it, sends data byte 2,acks it. IF oyu look at the logic analyzer you can see a huge delay between the three parts of each command, I think this is giving us a bug. Either way getting a whole command and sending it at once will speed things up a lot.
Sjaak, here is the I2C sniffer code, I'm happy for you to use it in whatever shape or form you like :)
Thanks Darren!
We'll put it in v5.1
We are rounding the v5.0 up to make it final. We checked rev 382 into the svn.
- binairy rawmode is updated for the picprogrammer application (actually rev 381)
- fixed a small display bug when sending string in the I2C mode
Also the nightly builts were checked in, so you are ready to go north!
Hello everyone
just playing with one SPI device on my bench and i have found out that there is one thing which i miss.
When I write data to device, in SPI mode, you should receive another byte, so I would appreciate that this byte is displayed, ideally after command.
For example:
WRITE: 0x40 RECIEVED: 0x01
This is very usefull, when device operates in "window" mode...
I believe it is there already. Is it printed on the wrong row (i.e. extra line feed)? I believe it says READ: instead of received.
I'll look tonight into this (i'm at work atm)
This is example from console...
SPI> [0x40 0xa1 0xc0 0xa6 0xa2 0x2f 0xf8 0x00 0x27 0x81 0x10 0xac 0x00 0xaf]
CS ENABLED
WRITE: 0x40
WRITE: 0xA1
WRITE: 0xC0
WRITE: 0xA6
WRITE: 0xA2
WRITE: 0x2F
WRITE: 0xF8
WRITE: 0x00
WRITE: 0x27
WRITE: 0x81
WRITE: 0x10
WRITE: 0xAC
WRITE: 0x00
WRITE: 0xAF
CS DISABLED
And my proposal is
SPI> [0x40 0xa1 0xc0 0xa6 0xa2 0x2f 0xf8 0x00 0x27 0x81 0x10 0xac 0x00 0xaf]
CS ENABLED
WRITE: 0x40 READ: 0x01
WRITE: 0xA1 READ: 0x02
....
....
I couldn't resist to take a quick look at the source. You need to open the bus with '{' instead of '[' to do a read/write instead of an write.
Your example will be this:
{0x40 0xa1 0xc0 0xa6 0xa2 0x2f 0xf8 0x00 0x27 0x81 0x10 0xac 0x00 0xaf}
I also realize there is an other error when using this with non-inverted CS chips. But this a later concern!
Jop, worked for me :))
thx...i missed this note in manual and have been using [] brackets all the time...