Nothing solid on this yet, maybe an update to the PIC programming commands, maybe an extra version command or something for flashrom.
Couple bugs in servo mode:
*Does not prompt if no value is provided
*Allowed in HiZ
*Needs documentation :)
I can help with the servo mode code (& other stuff) if it is needed. I don't think it is too bad to have servo mode in HiZ (IMO) but if you think it might cause problems I don't think it is too hard to change that.
The idea behind HiZ is there is no output/interaction on the pins. basicly in HiZ it is safe to attach the buspirate to anything (almost ;))
Looks like we are going to split the firmware up into multiple chunks. See also the poll about this: http://dangerousprototypes.com/forum/in ... opic=794.0 (http://dangerousprototypes.com/forum/index.php?topic=794.0)
I'm gonna add some #defines to base.h to make two versions of the firmware, that will limit us less in the development ;) Also make the libraries definable. Downside is the textes are currently stored as one big blob into the firmware. I leave this for now, till a good idea pops up.
My vision is to keep at least in each firmware:
- The terminal system (D'uh!)
- scripting
- usermacro
- raw2wire
- raw3wire
- binmode
- sump
- easteregg
- openocd
Firmware 1:
- spi
- i2c
- 1wire
Firmware 2:
- lcd (readd the i2c board?)
- keyboard
- jtag?
[quote author="ian"]
Couple bugs in servo mode:
*Does not prompt if no value is provided
*Allowed in HiZ
*Needs documentation :)
[/quote]
See http://dangerousprototypes.com/forum/index.php?topic=780.0 (http://http://dangerousprototypes.com/forum/index.php?topic=780.0)
I guess it should have been posted here.
Randy
No problem! I was already integrating it into the current source...
Should be ready soon. :)
I just commited rev 467 to the svn:
- improved servo code (provided by Randy)
- updated the text for servo code, added servo command to the help
- split the firmware into essential and demo to temporary address the space issues
- updated the 'i' command (between [] are the modules compiled in)
The essentials firmware:
HiZ> i
Bus Pirate v3a
Firmware v5.6RC (r467) [HiZ 1-WIRE UART I2C SPI 2WIRE 3WIRE] Bootloader v4.1
DEVID:0x0447 REVID:0x3043 (B5)
http://dangerousprototypes.com
HiZ>
The demonstration firmware:
HiZ> i
Bus Pirate v3a
Firmware v5.6RC (r467) [HiZ 2WIRE 3WIRE KEYB LCD] Bootloader v4.1
DEVID:0x0447 REVID:0x3043 (B5)
http://dangerousprototypes.com
HiZ>
the new helpscreen:
General Protocol interaction
---------------------------------------------------------------------------
? This help (0) List current macros
=X/|X Converts X/reverse X (x) Macro x
~ Selftest [ Start
# Reset ] Stop
$ Jump to bootloader { Start with read
&/% Delay 1 us/ms } Stop
a/A/@ AUXPIN (low/HI/READ) "abc" Send string
b Set baudrate 123
c/C AUX assignment (aux/CS) 0x123
d/D Measure ADC (once/CONT.) 0b110 Send value
f Measure frequency r Read
g/S Generate PWM/Servo / CLK hi
h Commandhistory CLK lo
i Versioninfo/statusinfo ^ CLK tick
l/L Bitorder (msb/LSB) - DAT hi
m Change mode _ DAT lo
o Set output type . DAT read
p/P Pullup resistors (off/ON) ! Bit read
s Script engine : Repeat e.g. r:10
v Show volts/states . Bits to read/write e.g. 0x55.2
w/W PSU (off/ON) <x>/<x= >/<0> Usermacro x/assign x/list all
2WIRE>
And here some statistics:
essential firmware: 61269 bytes (96%)
demonstration firmware: 51066 bytes (80%)
And added the command to the wiki
[quote author="Sjaak"]
The idea behind HiZ is there is no output/interaction on the pins. basicly in HiZ it is safe to attach the buspirate to anything (almost ;))
[/quote]
Although being in HiZ mode does prevent you from generating a PWM, returning to HiZ does not remove the AUX pin from the timer and allow the pin to return to an input.
If you add this:
BP_AUX_RPOUT = 0; //remove output from AUX pin
to bpInit() in base.c it will disconnect the AUX pin and return it to HiZ.
Randy
Thanks guys, and good catch on the reset when changing modes. I wonder if that effected the PWM too.
Hello, Ian and other Hero members,
I've firmware 5.5 installed.
I do not understand the voltage monitor. In my opinion pin 10, black, is always GND. Also there are other pins wich cannot get another function.
So, can you guys explain.
Henk.
There are two manufacturers of the buspirate and they both make probe cables. Unfortunately they use both the same colourscheme, but backwards. The official outlet is seeed (we sell all our hardware there) and thus we support their cables.
The discussion is here: http://dangerousprototypes.com/forum/in ... opic=502.0 (http://dangerousprototypes.com/forum/index.php?topic=502.0) and in the newterm topic http://dangerousprototypes.com/forum/in ... en#msg4653 (http://dangerousprototypes.com/forum/index.php?topic=291.msg4653;topicseen#msg4653)
All the pins (except the powersupplies and gnd) can have other functions. The function of the pin changes with the protocol choosen.
Ps. Kaaskop? :D
[quote author="Sjaak"]
Looks like we are going to split the firmware up into multiple chunks. See also the poll about this: http://dangerousprototypes.com/forum/in ... opic=794.0 (http://dangerousprototypes.com/forum/index.php?topic=794.0)
I'm gonna add some #defines to base.h to make two versions of the firmware, that will limit us less in the development ;) Also make the libraries definable. Downside is the textes are currently stored as one big blob into the firmware. I leave this for now, till a good idea pops up.
My vision is to keep at least in each firmware:
- The terminal system (D'uh!)
- scripting
- usermacro
- raw2wire
- raw3wire
- binmode
- sump
- easteregg
- openocd
Firmware 1:
- spi
- i2c
- 1wire
Firmware 2:
- lcd (readd the i2c board?)
- keyboard
- jtag?
[/quote]
Im not sure how much it would save but i would consider making the easter egg option in a compile your owm version.
I figure that if you are compiling your own version then you probably know about the easter egg anyway so wont need it.
I assume it might save some space that could be used by something else.
Thanks to Sjaak for the explanation.
Ps: Yes, Breda
[quote author="ian"]
Thanks guys, and good catch on the reset when changing modes. I wonder if that effected the PWM too.
[/quote]
Yes, it did.
[quote author="Scorpia"]
[quote author="Sjaak"]
Looks like we are going to split the firmware up into multiple chunks. See also the poll about this: http://dangerousprototypes.com/forum/in ... opic=794.0 (http://dangerousprototypes.com/forum/index.php?topic=794.0)
I'm gonna add some #defines to base.h to make two versions of the firmware, that will limit us less in the development ;) Also make the libraries definable. Downside is the textes are currently stored as one big blob into the firmware. I leave this for now, till a good idea pops up.
My vision is to keep at least in each firmware:
- The terminal system (D'uh!)
- scripting
- usermacro
- raw2wire
- raw3wire
- binmode
- sump
- easteregg
- openocd
Firmware 1:
- spi
- i2c
- 1wire
Firmware 2:
- lcd (readd the i2c board?)
- keyboard
- jtag?
[/quote]
Im not sure how much it would save but i would consider making the easter egg option in a compile your owm version.
I figure that if you are compiling your own version then you probably know about the easter egg anyway so wont need it.
I assume it might save some space that could be used by something else.
[/quote]
I certainly know about the easteregg, since I added and debugged it ;) It sure save a couple of bytes, but it is cool to have it in (and it needs to be compiled in for max fun). We tried to make it educational besides the fun. So head up north and take a look yourself :X
[quote author="henkvbeek"]
Thanks to Sjaak for the explanation.
Ps: Yes, Breda
[/quote]
No problem. I think it should be added to the wiki to avoid further confusion.
Ps. Rotterdam here ;P
I think it should be added to the wiki to avoid further confusion.
There's some pin references on the blog, I think there's more in the SVN too. I can move these to the WIKI and start a section on cables.
I got one simple idea. When we got servo signal generator. Why we would not upgrade it to full PPM generator, so you can feed RC transmitter for wireless servo control. what do you think?
If it's still possible ... ;)
I'd like to release v5.6 with the servo updates, menu updates, and any other minor updates.
Can we give the split firmware a different major version, or maybe an alternative branch name? I really want a maintenance release to install in the production units, but I don't mind the split release either for more functionality.
Right now what needs to be added? I don't want to support the I2C LCD board, I don't think anyone uses it at all. The JTAG terminal could go in a library all it's own (restjes) for the moment, until we actually need to split out another library (PC Keyboard...) to make space for main features.
For example, right now we still fit, though the egg is gone. Maybe the egg should be a whole separate firmware too... Vimark and I couldn't figure out how to fit Z machine in the PIC :)
Let me hold on for a bit longer, I'm not ready to let go :)
I made an essential build and a demonstration build possible through defines. There are two defines in base.h #BP_FW1 (essentials) and #BP_FW2 (demonstration).
The compiled in 'modules' are printed in the infoscreen. See my original post: http://dangerousprototypes.com/forum/in ... 63#msg7763 (http://dangerousprototypes.com/forum/index.php?topic=810.msg7763#msg7763) Perhaps a suffix 'Essential' or 'Demonstration' (or more suitable names).
You btw didn't unlink the easteregg code only the reference to it in the userhandling (svn-wise).
Sorry, I forget to check in the project files because they always change no matter what so I have them set to ignore.
I'd like to propose one possible change and one variant.
1) The change is to allow finer tuning of the Generate command. At present, it appears to allow steps of 1KHz, starting at zero and increasing to 4 MHz.
Although useful as it is, I would find it much more usable if I could get finer-grained control.
For example, I needed a 32.768 KHz signal the other day while I away from my shop. My choices from the Bus Pirate were either 32.0 or 33.0 KHz. Neither was close enough to work.
I don't know if its reasonable to allow setting of output frequency down to 1 Hz resolution but 10Hz or 100Hz resolution would sure be nice.
Thoughts?
My other question is regarding the wire colors shown when you display Volts. The cable from Seeed has two mini-grabbers on the brown and orange wire, with ez-hooks on the remaining 8 conductors.
If you insert the connector one way, the colors match what is shown in the Volts display, with Gnd on Brown and a voltage on Orange.
If you reverse the connector, the mini-grabbers wind up on MOSI & MISO which often is really useful.
I guess that what I am saying is that I'd like to be able to toggle the Volts display between the two different wire color schemes. Maybe "v" & "V" ?
Thoughts again?
Many thanks!
dwayne
[quote author="DwayneR"]1) ... allow finer tuning of the Generate command. At present, it appears to allow steps of 1KHz, starting at zero and increasing to 4 MHz.
Although useful as it is, I would find it much more usable if I could get finer-grained control.
For example, I needed a 32.768 KHz signal the other day while I away from my shop. My choices from the Bus Pirate were either 32.0 or 33.0 KHz. Neither was close enough to work.
I don't know if its reasonable to allow setting of output frequency down to 1 Hz resolution but 10Hz or 100Hz resolution would sure be nice.
Thoughts?[/quote]The hardware is fundamentally limited by the clock frequency going into the timer, and the number of bits in the counter. Specifying the desired frequency in Hz will not always be accurate.
It might be better if the Bus Pirate protocol had a command to query/set the basic peripheral clock rate, pre-divide options, counter settings, etc. Then, the client app could present options to the user in terms of period length or frequency. It might even be possible to have a popup with the precise frequencies and/or periods that are available with any given settings, and these options would change as different clock sources are selected, different pre-divide values are chosen, different timer modes are picked, etc.
I don't own or use the Bus Pirate, but I am very familiar with the PIC Timers. Since the Bus Pirate firmware is getting crowded, it seems like it would be best to make the protocol as thin as possible, and put the heavy calculations in the client software that runs on the host. Of course, I realize that this is difficult when there are multiple operating systems to support and when most people use a thin serial terminal for a client, but it does seem like fancy firmware will always take more space than simple firmware with a fancy client. I suppose there is also the concern for legacy compatibility, but I'm just throwing in a suggestion to think outside the box...
[quote author="rsdio"]
The hardware is fundamentally limited by the clock frequency going into the timer, and the number of bits in the counter. Specifying the desired frequency in Hz will not always be accurate.
It might be better if the Bus Pirate protocol had a command to query/set the basic peripheral clock rate, pre-divide options, counter settings, etc. Then, the client app could present options to the user in terms of period length or frequency. It might even be possible to have a popup with the precise frequencies and/or periods that are available with any given settings, and these options would change as different clock sources are selected, different pre-divide values are chosen, different timer modes are picked, etc.a suggestion to think outside the box...
[/quote]
Let me propose something along the lines of what you just said: Can the BP monitor and display its own generator's frequency? If so, it might be as simple as allowing the user to tweak the counter bits up and down and home in on the desired frequency.
So far, I use the BP with a dumb terminal program (Procomm Plus). Its installed on all of my machines (Win98se, XP, Win7). Have to say that I haven't actually used it on my Win7 box yet, though - but give me time .
Anyway, I'm hoping for something that does NOT require the use of a dedicated client.
Thanks!
dwayne
[quote author="DwayneR"]Let me propose something along the lines of what you just said: Can the BP monitor and display its own generator's frequency? If so, it might be as simple as allowing the user to tweak the counter bits up and down and home in on the desired frequency.[/quote]That's an excellent suggestion, I'd say. I'm not familiar with the BP protocol, but if it allows setting the actual Timer registers and the counter bytes, then what you request is possible.
The only unknown for the PIC firmware is the external crystal frequency, but I think that can be determined by reading the oscillator settings. The PIC18, at least, requires that any external crystal be divided down internally to 4 MHz, after which a PLL boosts it to higher frequencies. I guess that means the 4 MHz starting point is a known value, so the peripheral clock speed can be determined by reading the various oscillator registers, regardless of which crystal is installed. The only thing I'm not sure about is whether the Configuration settings can be read by firmware - but I know the programmers can read it out so it must be possible.
As I recall, the PIC doesn't have enough timers to do a tick count and do PWM at the same time. I'll check it out though.
[quote author="rsdio"]
[quote author="DwayneR"]Let me propose something along the lines of what you just said: Can the BP monitor and display its own generator's frequency? If so, it might be as simple as allowing the user to tweak the counter bits up and down and home in on the desired frequency.[/quote]That's an excellent suggestion, I'd say. I'm not familiar with the BP protocol, but if it allows setting the actual Timer registers and the counter bytes, then what you request is possible.
The only unknown for the PIC firmware is the external crystal frequency, but I think that can be determined by reading the oscillator settings. The PIC18, at least, requires that any external crystal be divided down internally to 4 MHz, after which a PLL boosts it to higher frequencies. I guess that means the 4 MHz starting point is a known value, so the peripheral clock speed can be determined by reading the various oscillator registers, regardless of which crystal is installed. The only thing I'm not sure about is whether the Configuration settings can be read by firmware - but I know the programmers can read it out so it must be possible.
[/quote]
The buspirate runs on it internal oscillator (32MHz), which rules out precise frequency generation over the whole range. The pic can read all of it memory together with fuses and deviceID. You can see it with the 'i' command (deviceID): http://dangerousprototypes.com/docs/Bus ... nformation (http://dangerousprototypes.com/docs/Bus_Pirate_menu_options_guide#I_Hardware.2C_firmware.2C_microcontroller_version_information)
For precise control of the pwm generator : http://dangerousprototypes.com/docs/Bitbang (http://dangerousprototypes.com/docs/Bitbang) :
00010010 - Setup pulse-width modulation (requires 5 byte setup)
Configure and enable pulse-width modulation output in the AUX pin. Requires a 5 byte configuration sequence. Responds 0x01 after a complete sequence is received. The PWM remains active after leaving binary bitbang mode!
Equations to calculate the PWM frequency and period are in the PIC24F output compare manual. Bit 0 and 1 of the first configuration byte set the prescaler value. The Next two bytes set the duty cycle register, high 8bits first. The final two bytes set the period register, high 8bits first.
Binmode can be done with the hercules utility: http://www.hw-group.com/products/hercules/index_en.html (http://www.hw-group.com/products/hercules/index_en.html)
Thanks Sjaak, I forgot about that.
Here's the link to the OC manual:
http://ww1.microchip.com/downloads/en/D ... 39706a.pdf (http://ww1.microchip.com/downloads/en/DeviceDoc/39706a.pdf)
There are probably online calculators too, or you can follow the method I used in the Bus Pirate source:
http://code.google.com/p/the-bus-pirate ... UXpin.c#95 (http://code.google.com/p/the-bus-pirate/source/browse/trunk/source/AUXpin.c#95)
@Sjaak - I just noticed the updatePWM command, I believe you added. Is there a reason I can't combine the bpPWM and updatePWM functions, or recycle the body into a shared helper function?
/me slaps Ian with a trout!
:P
I added it for the scripting engine. Basicly it is the same as the bpPWM() without userinput, instead it uses two global variables (because the way the scripting engine interfaces with the bp). It can be reused, no problem.
Ok, I might try to work on that today, but I have lots of new PCBs to play with :) I'd like to make a 5.6 bugfix for tomorrow.
If I recall from my (m)iRC days, I thought the slapping trout needed to be wet :)
I made some modifications for a 'main' compile that keep the modular compiles possible (except the LCD cleanup in buspiratecore which should be duplicated in the define in HD44780.c. I also added clear PWM between modes.
Here is the change log, if there are no other updates this will go out tomorrow.
- fixed swapped SPI sniffer macros
- stop PWM/servo between modes
- fixed servo prompt and error
- prevent servo in hiz
- updated the text for servo code
- added servo command to the help
Nice addition of the BP_MAIN define.
[s:]I need to change a bit in the help system (;) but nothing more to add I guess. They can wait till 5.7 ;)[/s:]
Added to the svn together with the new nightly builds
Thanks Sjaak. I'm taking this thread down and starting v5.7. Firmware will be up in a few minutes.
I already built the nighties (contraction of eighties an ninties??) ;)
Thanks!