[quote author="tayken"] Naaah, no need to stop loving PICs. [/quote]
It is not easy, I have a pretty big stock of pic's at home, but from time to time I get *very* frustrated by some decisions microchip make. (just look at pk3 - they said they will provide stand alone gui over a year ago, maybe already 2 years ..)
[quote author="tayken"] Actually there are some open source projects being developed because of this situation. Remember, "Necessity is the mother of invention" [/quote] toolchain is not open source (and the one they pushed recently ain't really out there yet) and still most projects are around "small" pic's.
[quote author="tayken"] Hopefully Microchip will learn to support open-source community or they are doomed. There are many many makers-hackers-diy people out there. [/quote]
yeah, they probably will, if bunch of ppl stop using it. problem is that there's no great alternative. I use msp430 a lot but they are all smd only and in those tiny packages I hate soldering but I use them more and more, atmel has good hardware but the community is "weird", I tend not to use devices where fanatics rule community... the "mine device is better then any other, I know that, no need to look at the other one" does not bring any confidence in decisions those open source projects made..
anyhow, we are waaaaaaaaaaaaaay of topic here, no intention to start a flame
Thanks for the explanation. I went trough the licence many times and it does not show this, but who cares what's written if they are trigger light.. better to avoid their code then as you are trying to do . The major reason I ask is that they don't keep backwards compatibility with their own code so for every version they put out you have to modify your code, and if you get one version, fix it and make your code work with it - it will not work as after few months the base you patched is no longer available ... I had no idea they have that state of mind, I will have to rethink use of PIC's in the future because of this, I'm not big fan of atmel but they do have this sorted out + fully working gcc compiler for both small 8bit mcu's all up to cortex cores ... TI is closed anyhow so only what comes with gcc is available and that's anyhow open source so with msp430 I also don't have a problem .. looks like my pic loving days are over
I noticed that many projects that are open source (different licences) leave out microchip libraries out of the code (bp uses usb lib but leaves it out, the similar issue can be seen in other project with fat/sd/usb and many other microchip libs). Looking at the headers in these sources from microchip I don't see why are the sources excluded from the projects? The only thing I see in the microchip licencing info is that those are not to be used on non microchip mcu-s, but since all this projects (BP for one) use microchip mcu (PIC24.. for e.g.) there should be no problem ?!
there are no protocol changes, client attm has no way of knowing what obls is capable of so it is up to the user to select valid combination. If you select sample size larger then what obls can store you will get repeated data from the board as buffer is read from the beginning. The latest version of "alternative java client" does not allow you to select impossible combinations (4 channels 24K for example) but again, it assumes you have the 2.12 bitstream, there's no way it can check if it is actually available. There was a thread on the forum about adding the "capability" extension to the protocol where obls board can return info on capabilities, but no work is done in that direction
great to know it is possible ... (I'm still learning vhdl), thanks for the data sheet snippet, will read the whole section again so I might figure out how it works
[quote author="Myrmidon"] Then i hooked them back up to the outputs and it worked fine. But for some reason it's not seeing the latch, data and clock info. [/quote]
connect them "all" together - your OLS has 16 buffered inputs, connect 8 to latched outputs on 595 and 3 to latch/data/clock ..
The most probable reason you do not see proper values on the latch/data/clock is that your scan frequency is too low. Note that clock/data is changing 8 times faster then your latched outputs .. so you need higher scan rate ..
[quote author="cronix"] I do most of my sampling on 100Khz. [/quote]
are you sure you are using right tool for the job? if you are sniffing some standard protocol (i2c, spi, serial) you might be better off with bus pirate
I'm pretty stunned what can this 2232H do (should be very simple to replace a whole bus pirate with 2232h for example - but the software would have to be on pc side)... as for the 5V tolerant the data sheet states (Document No.: FT_000061, FT2232H DUAL HIGH SPEED USB TO MULTIPURPOSE UART/FIFO IC, Datasheet Version 2.08):
Quote
+1.8V (chip core) and +3.3V I/O interfacing (+5V Tolerant).
Quote
The I/O pins are +3.3v cells, which are +5V tolerant (except the USB PHY pins).
and the 2232HQ mini module I purchased states the same thing (no buffer between pins and chip and 5V did not kill any pins ).
anyhow, going too far off topic .. looks like reshuffling the pins will solve the problem
I am attm making a simple CPLD + SRAM test (mostly because I learn how to work with CPLD/FPGA) and when I finish I will try to attach that to the OBLS .. My fpga knowledge is still very low but will post here results of the test (will probably do first test on weekend, day job takes too much time attm)
I am playing these days with FT2232H and I understand why Maryam from FTDI recommended it over the FT232... This baby can do bitbang (only one channel - 8 bits) at 60MHz sync (FT is providing 60MHz clock for read/write)!! .. runs 480Mbps and do usb to SPI/I2C/JTAG without breaking a sweat (all together with examples in c++ how to do it ) and can also do dual channel async bit bang (not sure attm what is the max speed, from what I read, 30MHz each should be possible)... and it is not too expensive (~5GBP) and is 5V tolerant ... It is definitely worth the look.
I'm using it both on linux 64bit and windoze 64bit (win7) and the problem is that I have to use 32bit jre on windoze (rx library does not work for me for 64bit one).
second thing, from what I see one can easily talk much faster with obls then 115200, adding 921600, 460800 and 230400 bps speeds in drop down and using them to connect to obls should be simple and easy and should speed things up a bit
..