Skip to main content
Topic: BP Demo board v5 firmware development (Read 9574 times) previous topic - next topic

BP Demo board v5 firmware development

Hi, I'm continuing Sjaaks work on the demo board v5 firmware, I made this topic so you could add suggestions, and help me out a little :)
Sjaak, could you tell me what's that status last time you looked at it, any bugs you remember, etc...What need to be done for completion..etc..

if you could write a short (hopefully) description of the code..it would help me a lot, thanks
Also, any suggestions on what should be addressed first etc are welcome...
best regards FIlip.

Re: BP Demo board v5 firmware development

Reply #1
We looked at it together. Filip is testing thought the modes now and writing documentation.
Got a question? Please ask in the forum for the fastest answers.

Re: BP Demo board v5 firmware development

Reply #2
Notes on the board:
*VPU pin missing, makes it hard for BP v3 to give power to the pull ups, since the power v3.3 pin of the io header is busy, thus simple jumpering wont work.
*cap on the PGD/DACOUT pin is interfering with programming, so it must be removed, or a solder jumper added to stop it interfering..
*also the Buffer is giving me problems, but that should work fine...
best regards FIlip.

Re: BP Demo board v5 firmware development

Reply #3
[quote author="arakis"]Hi, I'm continuing Sjaaks work on the demo board v5 firmware, I made this topic so you could add suggestions, and help me out a little :)
Sjaak, could you tell me what's that status last time you looked at it, any bugs you remember, etc...What need to be done for completion..etc..

if you could write a short (hopefully) description of the code..it would help me a lot, thanks
Also, any suggestions on what should be addressed first etc are welcome...[/quote]

I think i posted somehwhere the current status of the firmware for this somewhere... the i2c part is most complete regarding addressing  the peripherals, For the UART part you need to enable the interrupts.

AFAIK the businteractions are working (i2c, spi, uart) it only needs to work  out with the peripherals (DAC, ADC, MEM). the hard part is to find a compatibel device to emulate.. All the source is there and broken up into seperate source files.

One thing that is nice to add is some kind or exploration like we did on the easter egg of the buspirate. some kind of adventurre of exploring an i2c or spi bus, this will help the understanding of the different busses (i.e. using pullups on i2c) Would be nice to add an i2c adventure and a spi adventure. Perhaps a blog thing that the first that will achieve the goal willl get a free pcb code (or some other free goodie).

Re: BP Demo board v5 firmware development

Reply #4
We can give a better prize for first solver but we must remember to remove it from svn :)

Btw good food today Sjaak, what fun!
Got a question? Please ask in the forum for the fastest answers.

Re: BP Demo board v5 firmware development

Reply #5
[quote author="ian"]We can give a better prize for first solver but we must remember to remove it from svn :)

Btw good food today Sjaak, what fun![/quote]

Anytime! Have fun at kwakoe ;)

Re: BP Demo board v5 firmware development

Reply #6
Ok fixed a few minor bugs...
*5b board jumpers now work as expected..
*I2C ADC now reads analog chanels 3 8 9 trough 0 1 2 commands,,,

so writing ti the write adress 0 and reading the read adress will get you the BP Demo boards analog in chanl0, writing 1 will get ju channl 1 writing 2 will get you chanel 2....any other number will be ignored...this is a fix as oposed to writing the actual ANx number.which was 3 8 and 9...

Now I'm working on the MEM function, but I'll need a little explanation on how this is intended to function..
plz, post commands for writting 10 characters to the mem, and another for reading them...
best regards FIlip.

Re: BP Demo board v5 firmware development

Reply #7
Since SPI and UART remain to be implemented I need instruction on how to implement PWM/ADC/DAC on each of those....

for example how to read write with SPI to EEPROM, how to SET duty cycle freq for PWM, same for DAC, and ADC....

Also for PWM ove I2c. we have one write one read adress so how to set duty cycle and freqency.
best regards FIlip.

Re: BP Demo board v5 firmware development

Reply #8
Sounds great, thanks Filip.

For MEM (EEPROM) we want something like like the 24AA and 25AA EEPROMs. You can take liberties though:

http://dangerousprototypes.com/docs/3EE ... I2C_EEPROM

There are demos for both there.

Let's focus on the EEPROM mode SPI adn I2C for now. The SPI commands are explained in the tutorial too. You don't have to follow it exactly, just a basic demo. THe simpler the better.

Can we use both addresses to write data? We don't need to give the PWM a read function at all.
Got a question? Please ask in the forum for the fastest answers.

Re: BP Demo board v5 firmware development

Reply #9
guess we could...
for UART the same controll could be implemented as with SPI...since they are both preaty much character by character with no adressing...
best regards FIlip.

Re: BP Demo board v5 firmware development

Reply #10
The best thing is to emulate the chips exactly so we can borrow the datasheet and the demos on the blog.

Regarding the memory I wouls emulate the 24x02 (i2c) and 25x02 (SPI), We could emulate the /WP with AUX or so

24aa02: http://www.microchip.com/wwwproducts/De ... e=en010774
25aa020: http://www.microchip.com/wwwproducts/De ... e=en025534

for adc i found these candidates:
http://www.microchip.com/wwwproducts/De ... e=en533561
http://www.microchip.com/wwwproducts/De ... e=en025692

if there are more bits to emulate sign extend them. Also speed can be an issue but I2C supports clockstretching (although the bpv3 doesn't). There are several adc input (also internal ones) i don't know the best way to select them, perhaps a memory location in eeprom.

ADC here;
http://www.microchip.com/ParamChartSear ... &pageId=79

Re: BP Demo board v5 firmware development

Reply #11
I'm looking at multi-chanall I2C ADCs form microchip like the MCP3424 
we could emulate it,
http://www.microchip.com/wwwproducts/De ... e=en536354

here is how it's configured

When the Master sends an address byte with the R/W bit low (R/W = 0), the device expects one configuration byte following the address. Any byte sent after this second byte will be ignored. The user can change the operating mode of the device by writing the
configuration register bits.

config bit's from 7-0 RDY C1 C0 O/C S1 S0 G1 G0

RDY: Ready Bit
This bit is the data ready flag. In read mode, this bit indicates if the output register has been updated
with a latest conversion result. In One-Shot Conversion mode, writing this bit to “1” initiates a new
conversion.
Reading RDY bit with the read command:
1 = Output register has not been updated
0 = Output register has been updated with the latest conversion result

Writing RDY bit with the write command:
Continuous Conversion mode: No effect
One-Shot Conversion mode:
1 = Initiate a new conversion
0 = No effect


C1-C0: Channel Selection Bits
00 = Select Channel 1 (Default)
01 = Select Channel 2
10 = Select Channel 3
11 = Select Channel 4 //since we have only 3 chanles we could use the 4th to read the temperature, or FVR

O/C: Conversion Mode Bit
1 = Continuous Conversion Mode (Default). The device performs data conversions continuously
0 = One-Shot Conversion Mode. The device performs a single conversion and enters a low power
standby mode until it receives another write or read command


S1-S0: Sample Rate Selection Bit
00 = 240 SPS (12 bits) (Default)
01 = 60 SPS (14 bits)
10 = 15 SPS (16 bits)
11 = 3.75 SPS (18 bits)


G1-G0: PGA Gain Selection Bits (this could be simulated inside software (simply multiply the read values)
00 = x1 (Default)
01 = x2
10 = x4
11 = x8

for PWM emulation we could use some of those 3 channel PWM LED driver with I2C control (to emulate) on is on the AUX pin, the other two are on the two LEDs...
best regards FIlip.

Re: BP Demo board v5 firmware development

Reply #12
*intro: I'm really new to the Bus Pirate, my first actual project using it's firmware actually...

This project is officially named Murphy's curse.

I spent the whole day yesterday literately, up til 2 in the morning trying to get the i2c slave bulk reads to work...And I didn;t get it.. today when I woke up, I decided to clear the whole function and just look at what the heck is going on...and then I got it..
with a clear function after the interrupt flag the I2C registers 5 interrupts for command [0xa1 rrrr] as it should..but when I add something inside the function 3-4 lines worth, it goes haywire, and registers 3-5 interrupts sporadically, if I add even more, it only registers 3...etc.....This gave the idea that the problem might be that the master isn't respecting the CLK streching that the salve does...and sure enough I looked at the Bus Pirate v3 I had and it doesn't support clock stretching...

In other words I wasted a day and a half on something I should have known from the start, (see * at top). It looks like there is no way to implement bulk reads with the Bus Pirate v3...

So I dusted of my BP v4, dired it up and sure enough everything worked from the go....And I mean everything....
single read, single write, bulk, write, bulk read... Well the bulk read part was making little bugs like skipping a location etc...
so I spent the rest of the day tweeking it to work perfectly. And just at the end of work day, the thing dies, I mean nothing works...
I switch over to the BPv3 and check the function I know worked with it and they still do, but with BPv4 everything died...
Ok so I hook it up to the self test, and sure enough the CLK pin gives a FAIL on the HIZ 1 test...
I look at it with a multimeter, and it's shorted the CLK pin is shorted to gnd, and the BP can;t make it go HiZ....
(this took an hour to check, as my multimeter died, had to resolver a wire)

So I start cleaning the board.....and nothing, so I apply Flux and give it a quick hot air...and clean it, and still nothing....
the dam CLK line is still at GND, even though I theraly check it with a magnifying glass and there just is no GND connection anywhere.......At this point I'm thinking the BPv4 PIC died on that pin...so I  hot air remove it...clean the pads, etc...and re-solder it (this took 2h as my hot air died, had to open it up and fix some wiring) ..
I connect it to usb it starts up, but soon dies again, I connect it to MPLAB and check with a Programmer, and its givving the wrong deice ID 00000....so after some more cleaning, fluxing, re soldering, hotairing, cleaning, fluxing re-soldering etc.....it finally start to work, with the CLK pin fixed as welll....(did I mention my micro b cable died in the middle of this, and I had to run to the shops to get another one)......

I other words this board has had everything fail that could have failed, by definition it's Murphy's board....
best regards FIlip.

Re: BP Demo board v5 firmware development

Reply #13
scrach that, just looked at it again and the CLK is still connected to ground, ~170ohms resistance between GND and CLK pin....this is exacly how it acted before I took it apard, It worked for a while and now it's broken again...
I've had it....I moving on to whatever I can get to work witht he bpV3..and I'll return to this when/if I fix my BPv4 or replace it...
best regards FIlip.

Re: BP Demo board v5 firmware development

Reply #14
You can enable i2c hardware support on bp (code should br there) or move to a lower bitrate. Also run the bpdemo at a higher clock.