[quote author="rsdio"] [quote author="Scorpia"]Hmm, i didnt see airmail to australia. just dhl which was about $20+. i will check again, if they do airmail to australia then i will surely give them a go. probably for a mcp2200 uart board.[/quote]I recall hearing about Aussie-based cheap PCB fab long before I met DP. I refrained from using them because of the shipping to Seattle. But you might find them perfect since they're "local" (yeah, I know it's a big country - I've flown across Australia!)
If you don't already know about these guys and can't find them, I can ask my friend who linked me up originally. [/quote]
It looks to me like it could be a cheaper alternative the the standard fdti chip everyone uses. Also being pin compatable wth the 18f44K50 (?) PIC it would be possible to have some nice options on boards that required different firmware.
I am currently looking at getting some usb-ttl boards made up that could be both a replacement for the fdti serial boards as well as a development platform for the 18f chip.
anyone have any comments on this chip or any other information as i havnt got to use one yet so i am guessing a bit.
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
With the eeprom in mind, Would any of the eeproms your talking about be quick enough to be used as a storage location for the Logic analyiser ? If it was quick enough to store reading them I could see more and more reasons to go the larger chip.
but my prefernce would be for the larger footprint, even if it only came with a smallish eeprom by default. at least it could be changed in the future.
Or as a seperate idea, is there any room to run both? have the current 5 pin chips by default with a footprint for the 8 pin on the board for module expansion/storage etc if the user requires it.
Why do we need to switch between USB ports when to the FDTI one is just a serial port as far as the PIC is concerned?
I never said anything about connecting both to the PC at once. As for increased cost well i think its worth it. One thing that this would allow for example would be developing the USB OTG part of the pic while still using the current terminal interface of the usb-serial chip.
but as i said, its just a personal preference. Im am in no way the designer. Just voiceing an opinion.
[quote author="Sjaak"] the speed of i2c would be fine, since it will be only used when needed.
Though I prefer a 128Kbyte or bigger to work with (256Kbyte is ideally). This will be far more easy to implement and better for backwards compatibility (i2c also )
[quote author="Scorpia"] Interesting,
I personally would be in favor of keeping the USB chip and adding a second interface for testing purposes.
It would allow the use of the current firmware and allow further hacking/advancements. The cost savings to me would be hardly worth removing the chip. [/quote]
We thought about this, but having a native usb sollution would trigger to us to make a usb stack and will be much faster in terms of speed (baudrate). [/quote]
Keeping the usb chip and added the native USB gives the best of both worlds. you can keep the current software and then upgrade to the native usb connection as required. so to me having both is a big advantage
I really hope that since yu are using the GB version of the chip that the USB pins ont he pic get routed to a USB plug of some sort, i really think its a great idea going forward. giving direct USB access via the PIC.
Also i am not suggesting any software be written to support USB, but just the ability to add it lateras the hardware is ready is all i would be asking for at this stage.