Skip to main content ↑ ↓

Topics

This section allows you to view all Topics made by this member. Note that you can only see Topics made in areas you currently have access to.

Topics - Arkku

1
Bus Pirate Development / Patch to add hardware PWM support down to 2Hz
Hi, while writing a binary mode library for the Bus Pirate I noticed that it's possible to set the hardware PWM down to 2 Hz, but the interactive ASCII interface (command [tt:]g[/tt:]) only provides options down to 1 KHz. I made a small patch to the firmware, which adds a new command [tt:]G[/tt:] that asks for the PWM frequency in Hz. Using an external frequency counter I found this working down to 2 Hz on my BPv3.5, although I'm not sure if it's a limitation of my frequency counter or of the chip that 1 Hz doesn't work (so 1 Hz value is allowed).

Some observations:

1) I needed to enable [tt:]getlong[/tt:] for BPv3, previously it was only used with BPv4.

2) Confusingly [tt:]getlong[/tt:] is actually the equivalent of [tt:]getnumber[/tt:] and not [tt:]getint[/tt:] as one might think, and there is no [tt:]long[/tt:] version of [tt:]getint[/tt:]. As such it is not possible to specify a command-line argument to "G" with a frequency higher than [tt:]INT_MAX[/tt:]. I don't see this as a major problem, though, since one can use the "g" version in KHz with higher frequencies (that wouldn't have 1 Hz precision anyhow).

3) I also changed the [tt:]g[/tt:] command (PWM in KHz) to use my modified method for calculating the register values. This saves code space so the size impact of adding this command is fairly minimal (essentially just [tt:]getlong[/tt:]). However, this means that any bugs in my patch will also affect the old "g" command. I did test this with various options, though, and my calculation method is simpler with fewer magic numbers.

(There is still an internally used [tt:]updatePWM[/tt:] that I didn't touch. Personally I think the cleanest solution would be to have that use the same PWM calculation methods as well instead of duplicating everything for the interactive and non-interactive versions as seems to be done throughout the codebase.)

4) I don't know where the thresholds used for prescaler selection come from, but I kept the existing values (4 KHz, 31 KHz, and 245 KHz).

The patch is against the latest SVN sources, and can be applied in the firmware sources directory ([tt:]trunk/Firmware[/tt:]) with [tt:]patch -p0 <my_patch.diff[/tt:].


Oh, the patch itself:
http://arkku.com/misc/buspirate_hz_pwm_patch.diff
2
Bus Pirate Support / 1-wire ROM search broken in binary mode? (Edit: No.)
Hi,

I wrote a small library for myself to access the binary mode of Bus Pirate (v3.5, FW 6.1 r1676), and noticed that there seems to be a problem with the 1-wire ROM search function when there are multiple devices on the 1-wire bus. In ASCII mode everything works fine:

Code: [Select]
1-WIRE>(240)
SEARCH (0xF0)
Macro     1WIRE address
 1.0x28 0x28 0x65 0x91 0x02 0x00 0x00 0xEB
   *DS18B20 Prog Res Dig Therm
 2.0x28 0xA4 0xCE 0x91 0x02 0x00 0x00 0x3F
   *DS18B20 Prog Res Dig Therm
 3.0x28 0x2B 0x6B 0x91 0x02 0x00 0x00 0x10
   *DS18B20 Prog Res Dig Therm


However, in binary mode the search only works correctly when there is exactly one device on the bus:

Code: [Select]
1 alone) 0x28286591020000eb
2 alone) 0x28a4ce910200003f
3 alone) 0x282b6b9102000010

But when I have two or three devices on the same bus (exactly the same way as in ASCII mode), I get:

Code: [Select]
1+2) 0x28286591020000eb
     0x28acef91020000ff
1+3) 0x28286591020000eb
     0x282b6f91020000fb
2+3) 28a4ce910200003f
     28afef910200003f
1+2+3) 0x28286591020000eb
       0x28acef91020000ff
       0x28afef91020000ff

The results are consistently the same for each combination when I try multiple reads, but always incorrect for all but one device. Note that the error is not consistent across different combinations, e.g., device 3 has a different id in 1+3, 2+3, and 1+2+3 combinations.

I am fairly certain I am not reading the binary data incorrectly since I get the correct number of bytes and the beginning of each id always seems to match so reading does not seem to be out of sync there. Is there a bug in the firmware, and why would the Bus Pirate use a different ROM search method for ASCII vs binary mode?


Edit: Oh, by-the-way, the 1-wire binary mode works perfectly for actually accessing all three devices on the same bus once the correct ids are known. The problem is just with the binary mode search ROM command that returns incorrect ids.

( ! ) Fatal error: Uncaught exception 'Elk_Exception' with message 'Please try again. If you come back to this error screen, report the error to an administrator.' in /var/www/dangerousprototypes/forum/sources/database/Db-mysql.class.php on line 696
( ! ) Elk_Exception: Please try again. If you come back to this error screen, report the error to an administrator. in /var/www/dangerousprototypes/forum/sources/database/Db-mysql.class.php on line 696
Call Stack
#TimeMemoryFunctionLocation
10.01282291096session_write_close ( )...(null):0
20.01312422688ElkArte\sources\subs\SessionHandler\DatabaseHandler->write( )...(null):0
30.01312423464Database_MySQL->query( ).../DatabaseHandler.php:119
40.05742562200Database_MySQL->error( ).../Db-mysql.class.php:273