I passed a long time this weekend checking datasheets and PIC24 series. 96KB is really a very good thing especially for the scripting engine, or for buffering captured data if USB is too slow to transfer data to PC. I'm checking also to use this chip on (modified) WebPlatform!!!
as for upgrade path, I think that we should also ask ourselves if we need to stick with Microchip parts. STM32 parts offers PPS, more peripherals, more protocols implemented in hardware (IRDA, ISO... ), more options on pins (PullUp, PullDown, Res completely disabled, Open Drain, ...) ... and ALL THE SERIE is compatible (all hardware and peripherals are at same adr), so you can upgrade without changing any line of code.
Should we think to switch to another serie of MCU ?
Hi, Microchip introduced a new USB chip, the PIC24FJ256GB206 that we may consider for a new Bus Pirate, it's a 64 pin chip with 256 KB of Flash and (more importantly) 96 KB of RAM It has also a nice ammount of peripherals (3xSPI, 3xI2C, CCP .... and USB ) http://www.microchip.com/wwwproducts/De ... e=en547864
Hello Ian, Please, don't misunderstand me, I'm not defending the FTxxx chips !I know it's a real bottleneck and they bring with them their part of problems and induce some desing pollution!
I only meant that I see it better to have all logic on an independent chip, and all transport in a second chip. This second chip can be another USB (low cost) PIC, another USB/UART tranceiver, or a chip capable of high speed Bulk transport like the Cypress solutions ... This will introduce an overcost of few $$$ and keep desing clean.
Now for V4, you can (should) of course try direct implementation on same chip using actual proto of course (and I can help on devs, actually I'm reworking the Scripting Engine of V3).
[quote author="rsdio"] [quote author="octal"]... polling the USB bus is mandatory[/quote]That is only true with the older Microchip USB Stack. The new versions support both polling and interrupt-based USB firmware options. The hardware has always supported USB interrupts for those brave enough to write their own USB stack, but now Microchip makes it much easier.
[/quote]
Hi rdsio, I checked Microchip last USB stack and they effectively added two defines : "USB_INTERRUPT" and "USB_POLLING"
As I said in previous posts, in case USB_POLLING is enabled, you need to call a function named USBDeviceTasks() to poll connection and remain connected to host (PC) side. When USB_INTERRUPT is enabled, they simply use a generic interrupt handler to call this function
//These are your actual interrupt handling routines. #pragma interrupt YourHighPriorityISRCode void YourHighPriorityISRCode() { //Check which interrupt flag caused the interrupt. //Service the interrupt //Clear the interrupt flag //Etc. #if defined(USB_INTERRUPT) USBDeviceTasks(); #endif }//This return will be a "retfie fast", since this is in a #pragma interrupt section
Nothing has changed since first versions of the USB stack!!! In some rare cases, when users had problems with some hosts (intempestive disconnection), (most) developpers where using a timer (High priority) interrupt to call this routine as needed.
This does not change the original problem, using an USB enabled PIC introduce two majors problems (desing architectural points): 1- Interrupt handling to keep USB connection alive means that all firmware functions need to be written with that in mind (no blocking functions) 2- Hardware signals generators or managers (hardSPI/ HardI2C, ...) will not suffer from that, but software protocols may become non deterministic relatively to the timing routines!!!
I think if a $2~$4 chip avoids all that and makes the firmware completely independent of the communication channel with PC it's really worth it!!!
[quote author="rsdio"] That is only true with the older Microchip USB Stack. The new versions support both polling and interrupt-based USB firmware options. The hardware has always supported USB interrupts for those brave enough to write their own USB stack, but now Microchip makes it much easier. [/quote]
I didn't knew that. The only way we used to do it with 18Fx550 was to poll the bus in a timer interrupt. thx
[quote author="rsdio"]My impression is that the FTDI chip is too slow, and too simplistic compared to a PIC with USB firmware. There's not really any point to making a new Bus Pirate platform unless it can break the serial bottleneck. [/quote]
I'm talking about the [glow=red,2,300]2[/glow]232, not the 232 chip. Do you think CDC on PIC will do better? not that sure. HID reports are also limited, and HID support with LibUSB seems to be a bit problematic under OS/X (check Saleae problems with the dev of the cross-platform version of their Software that handles Logic analyzer).
Hi Sjaak, Even on PIC18 most of work was done in interrupts. I was only talking about the fact that polling the USB bus is mandatory, and this one WAS DONE on PIC18 mostly using a timer interrupt!
As for the select PIC24 chip for BP4, I didn't checked the (errata) datasheet yet, I just saw quickly the description, and it seems to be a nice and quite capable chip (3xSPI, 3xI2C, ...) ... and I still think that adding a $2 (or even $5 for the quick FTDI2232) chip to handle all USB stuff (and avoid the VID/PID licensing pb) is worth it if we want to keep the design of the BP fimrware very clean and very simple. Think about the future of this tool!!! any maintenance work will involve a lot of competence from future developpers who may join the dev team later.
[quote author="ian"] Could you elaborate on why an interrupt is not a solution? [/quote]
Cause if you use Software protocols implementation for example like I2C (to be able to strech signals or avoid hardware bugs), you'll need to take into account the usb polling (in the interrupt) ... Software timing will become really a night mare to handle in ALL protocols. (why FPGA developpers always use an external chip for USB instead of implementing it in the FPGA?) Understand me, I dont say it's not feasible (as most usb programmers works this way) but the profit from using an USB chip is really not that important! Development effort will become more important for very little profit ... and all you'll win in price, you'll lose it paying for VID/PID licenses (considering the production volume you're doing).
[quote author="ian"]
The Bus Pirate with a UART connection does not provide enough speed for a lot of the apps that support it. [/quote] On PC104 boards you can got UARTs at up to 2MB .... enought for logging slow I2C data When you use a BusPirate to spy an I2C bus that have very low traffic (only few bytes each 10 min) you dont need too much band width.
[quote author="ian"] We're going to make a batch of prototype hardware for anyone that wants to mess with it, but that's as far as we're committed now. [/quote] I personally used USB only with PIC18 series (and with STM32). If you think you will be going this direction in BP4, I can help. But right now, I used only Microchip USB stack. I never looked for a free usb stack for Microchip mcu. If you have already took decisions about anything related to that, let me know, I'll be glad to help on that.
I think that integrated USB is a very bad choice! think about timing and usb state machine. You need to poll usb in less than 10ms each time. Some developpers use an interrupt to do that, but this is not a solution. BusPirate should evolve in a way that it can provide better signals timing possibilities. Having to support USB is a problem. All firmware should be written arround USB state machine, this means more constraints for less profit. I think that we could even split the desing of BusPirate in two separate modules, 1- one module that will be BusPirate signals and protocols handling, 2- and one module for data transfert from/to PC.
This second module can be: - either USB based (FTxxxx), - or Ethernet based which is (for me) a better choice because any PC on the lan can control BP, and any PC can control any number of BP on the Lan (we ca also do distant logging on internet), - or either simply an UART (without tranceiver) based ... this will make it possible to pilote BusPirate using handheld devices or some small industrial PC-104 boards like the mini2440 ARM based board http://www.friendlyarm.net/sites/produc ... 2440_2.jpg http://www.friendlyarm.net/sites/produc ... 440-35.jpg
why not switch to dsPIC33 ? they have more RAM and better peripherals (especially PWM for motor control). For the price, I think that now that Bus Pirate has made its proofs, so I think that users will accept to pay 3 or 4 more $$ to have a dsPIC instead of a PIC24.
Hi Ian, any news about porting DOSFS to webPlatform ?
I tried to use Microchip lib to access the SD on my webplatform, but without success (got a linker error that I cannot figure out how to solve).
My aim is **not** to make a webserver!!! I'm using WebPlatform as a TCP Client (using DHCP). I used mainly the Tweet example you provide and modified it to call my own server to upload data. Everything work OK. Now I want to be able to log data to MicroSD, and when TCP connection is available, I want to upload all data to server using HTTP-GET and URL data passing technique (this choice is imposed by the context I'm working in, so dont ask me why not use FTP or direct TCP ... or TFTP ...). The main pb I'm facing is when I include the Microchip lib, and activate needed directives to use the lib (with SPI stuff .... I disabled EEprom access), the linker is complaining about FSOpen routine I dont really understand what's happening. Microchip lib seems to be made mainly to serve as a Webserver pages repository, and I dont need it for that. Is there any advance with DOSFS port?
[quote author="ian"] In my experience, browser doesn't matter, but I haven't tested every combination. [/quote]
I confirm that. I used personally SAFARI on my MacBoocPro laptop, I used FireFox and IE on Win7 desktop, and I used my HTC Desire webbrowser (on my Android PDA), and all gives the same results !!! all should work. Mayb be he can change the MicroSD he is using.
Hello, on the examples provided for webplatform I saw that everytime the UART is configured and that the example provide an implementation for UART1TX(), UART1RX(), ...
I would like to ask a question (maybe stupid one): Why not simply use the peripheral lib functions provided by Microchip for UART like OpenUART1(...), putsUART1(...) ...
is there anything against using these functions ? (are these blocking functions ?)
I'm asking this as these functions are complete (fnc to print/read strings, char, ...) and I need such advanced dumping possibilities for debug (via the FT232 chip already on the webplatform board).
