[quote author="ian"]As far as I know, MPLAB 8 is still the only official compiler. MPLABX is not recommended for use in production. This could have changed, but arhi had some strong words about the situation a few weeks ago I think.
I also think there are several level of optimization in the compilers under 8. We don't use them because they break the firmware, but only the highest level is disabled after the initial 60 days.[/quote]
Why does the optimization break firmware? Is it a problem in how the firmware is coded, or is the compiler itself so badly broken? I haven't noticed any problems running the firmware compiled with MPLAB X and [tt:]-Os[/tt:], so if it's specific to the MPLAB 8 compiler then that would seem yet another reason to switch…
[quote author="beeduino"]I used this info to recompile the firmware but whatever value for Program Memory End I set - the hex file was the same - no diffs. What other options could be in affect?[/quote]
Well, the only thing I can think of is that this change did not take effect, e.g., you only tried to “Export hex” and did not “Clean and build”, or maybe the setting did not get saved for some reason. (Did you click “Apply”?)
Unfortunately the MPLAB user interface is so bad that I cannot even guess what other settings I might have touched that could possibly affect this. If the above suggestions don't work, I would perhaps try re-importing the MPLAB 8 project and redoing the configuration without ever compiling with the incorrect settings.
[quote author="beeduino"] MPLABX 1.0 under debian, optimization is set to -O1, Bus Pirate svn code.[/quote]
I'm using the same configuration, except I use [tt:]-Os[/tt:] optimization.
[quote author="ian"]I'm sorry, I don't use MPLABX yet, I can't help with the export.[/quote]
I think maybe you should; it's quite a sad state of affairs that the MPLAB X project in SVN won't even compile (one has to import the MPLAB 8 project), and the deprecated MPLAB 8 is not only one of the worst IDEs I have ever come across, but also Windows only and does not include a free optimizing compiler.
[quote author="beeduino"] I was trying to recompile the firmware yesterday with all available settings - 0xa7fa, 0xa6ff, 0xa7ff. In all the cases the hex file was the same - no diff.[/quote]
Did you do “Clean and build” after changing the setting? It has no effect if you just “Export hex”. I had the exact same problem with the same error message, but solved by following the steps I gave in the MPLAB X thread.
[quote author="beeduino"] Also I compiled firmware but when making exporting for bootloader in MPLABX the setting of 0xa7fa was prefixed with "!!!". And it looked like a warning.[/quote]
Change the 0xa7fa to 0xa6ff to get rid of the warning.
(I struggled with this same issue earlier. I am now using MPLAB X to compile the firmware with no issues.)
Note: there was a problem in the previous patch when using BASIC scripting to do frequencies over 32KHz: the last line of [tt:]updatePWM[/tt:] in [tt:]AUXpin.c[/tt:],
or the value will overflow. I've updated the patch posted above, but the two downloaders of the previous version should change this line.
On another note, BASIC scripting command [tt:]freq[/tt:] seem actually quite silly now that it takes KHz only. I did not add a Hz equivalent, though, since again there is the problem of [tt:]int[/tt:] having insufficient range to represent the full PWM range in Hz, and there's no [tt:]long[/tt:] equivalent of [tt:]getint[/tt:] (which would be trivial to make but would increase code size again).
I'm also not sure how you would prefer to deal with the KHz vs Hz in BASIC? As BASIC hasn't been available on <v4 by default(?), I don't think it would be particularly problematic to break compatibility with existing BASIC scripts and just use Hz, and also on the v4 the size issue of creating a [tt:]long[/tt:] version should not be, well, an issue. (But, for what it's worth, I only have v3.5 myself and the BASIC scripting still fits, even with this patch.)
[quote author="ian"]Thank you for the patch. Do you think we could combine it into a single command by adding a 'f' submenu that prompts for Hz range or KHz range?[/quote]
How would that "f" command work, do you mean that it would have three questions (Hz/KHz, frequency, duty cycle)? If yes, then it would be better, in my opinion, to just always ask the frequency in Hz; it's easier to just type "000" after the KHz than read and answer another prompt. Or if you mean that it should toggle the behaviour of the "g" command between Hz and KHz, then that has the problem of introducing a hidden state into the system + if there is an additional menu for this functionality why not just the simpler (and smaller code) of the current "g"/"G"…
Personally I think there are only two reasons to have the KHz version at all:
1) Compatibility with existing scripts that may rely on "g" to take KHz arguments. 2) There is no [tt:]long[/tt:] equivalent of [tt:]getint[/tt:] so "G" cannot take command-line frequencies over 32,767Hz (but can in the interactive menu due to [tt:]getlong[/tt:]).
[quote author="ian"] Adding this much code in the BPv3 firmware could be problematic because we are running out of room, but this should go in v4 for sure. [/quote]
Yes, the original patch adds 1161 bytes of code to BPv3 when compiled in MPLAB 8 (no optimizations). I tried to tweak it for smaller code size and got it down to 867 bytes (and also changed [tt:]updatePWM[/tt:] to use the same PWM setup routine instead of duplicating all the code). With MPLAB X none of this is particularly relevant, since with [tt:]-Os[/tt:] (size optimization) enabled the build is over 14K smaller. (I would argue for transitioning to MPLAB X [tt:]-Os[/tt:] builds regardless of this patch, but that is another topic. =)
In any case, the new patch (smaller compiled code) is attached (and also uploaded to the URL in the first post). (This patch is to be applied instead of, not on top of, the original patch I posted above. Use [tt:]svn revert AUXpin.* procMenu.*[/tt:] to undo the first patch if already applied.)
The inability of to set hardware PWM lower than 1KHz is due to the Bus Pirate firmware, not the chip itself. It is possible to set hardware PWM down to 2 Hz by using the binary mode commands to directly manipulate the registers. I made a little firmware patch for the Bus Pirate to enable this in the interactive ASCII mode as well, see this thread.
2WIRE>g 1KHz-4,000KHz PWM Frequency in KHz (50)>10 Duty cycle in % (50)> PWM active 2WIRE>g PWM disabled 2WIRE>G PWM 2-4000000Hz Frequency in Hz (500)>10 Duty cycle in % (50)> PWM active 2WIRE>G PWM disabled
Frequencies confirmed by measuring the AUX output.
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:].
[quote author="atmega88"]What distribution you are using ? I use Debian Squeeze and it is installed from net-install cd and i disabled apt for installing recommended and suggested packages so i maybe missing some package. But i did look and i think that i have everything for usb to work propriety...[/quote]
I have Ubuntu 10.04, current Debian stable (probably squeeze but I forget the nickname), and also Mac OS X with avrdude installed from macports. Works on all with the command line shown above. Are you sure you have all six wires connected properly to your AVR chip? They are BP MOSI -> AVR MOSI, BP MISO -> AVR MISO, BP CLK -> AVR SCK, BP CS -> AVR RESET (not SS!), BP GND -> AVR GND, BP 3.3/5V -> AVR VCC (unless you are using another power supply).
I'm writing my own Ruby library for controlling the Bus Pirate in binary mode. I actually have nearly the complete binary mode (all protocols) implemented, but I want to fine-tune and test it a bit before I release it (open source). The broken part was just a few routines I copypasted from somewhere to get started (I started with 1-wire since I had the DS18B20 thermometers handy), now I've rewritten the broken part and switched to using Ruby's [tt:]serialport[/tt:] gem.
