Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

What hardware features would you like? #137

Open
ddavidebor opened this issue Apr 6, 2020 · 18 comments
Open

What hardware features would you like? #137

ddavidebor opened this issue Apr 6, 2020 · 18 comments

Comments

@ddavidebor
Copy link

Hello beautiful people.

I work for a big ECAD software house, writing articles.
I would like to make a couple of articles improving the bus pirate V4 hardware.

Which features / improvements / bugfixes would you like ? only hardware-wise

David
@mofosyne
Copy link

mofosyne commented Apr 8, 2020 •
edited
Loading

Okay I'll bite (In order of cost/absurdness):

  • USB type-c connector at least? (Allows for hooking up to your smartphone too!)

  • Convenience function of linking the VPU (Voltage input for on-board pull-up resistors) to either the 3.3v or 5v output?

  • NFC tag for easy config or status display (e.g. instant uart logging) (Especially if paired with a community run buspirate config script exchange app)?

  • Variable voltage output from 0 to 5v ?

  • Enough cpu power to host an embedded webpage instead of just a serial console by pretending to be a usb network gadget with a local mdns url (e.g. buspirate.local )? (Thought this may be a bit of a wishful thinking).

  • (Is this even practical or sensible?) a small ICE40 frontend so you can fully configure the io pin anyway you want?

@ddavidebor
Copy link
Author

ddavidebor commented Apr 8, 2020 •
edited
Loading

  • USB type-c connector at least? (Allows for hooking up to your smartphone too!)

Definitely!

  • Convenience function of linking the VPU (Voltage input for on-board pull-up resistors) to either the 3.3v or 5v output?

could you elaborate a little bit on how this feature would be used?

  • NFC tag for easy config or status display (e.g. instant uart logging) (Especially if paired with a community run buspirate config script exchange app)?

I am actually writing about NFC at this very moment, and I like it, but I am not a fan of multiple ways of accessing a device.

  • Variable voltage output from 0 to 5v ?

Definitely a small controlled power supply would be a good feature, and not hard to do.

  • Enough cpu power to host an embedded webpage instead of just a serial console by pretending to be a usb network gadget with a local mdns url (e.g. buspirate.local )? (Thought this may be a bit of a wishful thinking).

Honestly, I'd like that. I don't like using serial over USB in this decade, but is not feasible on the current MCU.

  • (Is this even practical or sensible?) a small ICE40 frontend so you can fully configure the io pin anyway you want?

I was thinking about moving from the header to included probes with better connector, and using a digital matrix switch to implement that, but they are quite pricey. ICE40 are actually cheaper, so not that crazy of an idea.

@mofosyne
Copy link

mofosyne commented Apr 8, 2020

The VPU to VCC is basically about saving a single wire for the instance of quickly hooking up to an i2c module.

Right now doing so take a bit more time scrounging for either a breadboard or soldering a wire if the module only has one VCC input.

@ddavidebor
Copy link
Author

allright got it

@tomtastic
Copy link

Everything I'd like to see is being incorporated into Glasgow : https://github.com/GlasgowEmbedded/glasgow

@ddavidebor
Copy link
Author

ddavidebor commented Jun 2, 2020 via email

@tomtastic
Copy link

Which useful protocols are missing in your opinion?

  • 1-Wire - Planned
  • I2C - Yes
  • SPI - Yes
  • JTAG - Yes
  • Asynchronous serial - Yes
  • MIDI - Possible
  • PC keyboard - Possible
  • HD44780 LCD - Possible

As far as not liking the fact it uses the ubiquitous Python3 language to program the FPGA, I'd say anyone that has tried to compile a BusPirate firmware with MPLAB and XC-16 would probably prefer the Glasgow.

@ddavidebor
Copy link
Author

1-wire mostly.

PICs are horrible to program, this has never been news.

But Glasgow requires a working compiler to be used. This means that you can't throw it into the toolbox, forget about it for a year and expect it to work. There is going to be updating and maintenance to do on the computer. So the design fails to meet the criteria for it to be a tool.

This is without considering the fact that programming requires quite a few working binaries. chance of stuff breaking increases much faster than linear with the number of binaries. Those binaries are going to be a huge shitshow to run on Windows.

And whoever had the idea to program it with their own python-based hardware design language, it has doomed it to the same life as every project where someone decided to both implement a functional goal AND recreate the wheel. That is, they never go as fast as one would have tough, lag behind the competition, then people get bored of wasting their time with no results and everything gets abandoned.

To my consideration, that's not a tool, that's a well designed demoboard.

@tomtastic
Copy link

I think the BusPirate development was pretty doomed too, have you counted the outstanding issues with the community firmware, almost nothing works reliably and is trial and error which firmware works with what :)
Anyway, I'm not here to bash the BusPirate, I've enjoyed using mine many times, but I'm afraid it (even the v4) is already an ancient platform now with very little active development.

@ddavidebor
Copy link
Author

ddavidebor commented Jun 3, 2020 via email

@chepo92
Copy link

chepo92 commented Jul 17, 2020 •
edited
Loading

I just submitted and issue #142 before reading this

IMHO, working on a new hw would be great, but also needs a working realiable and more universal firmware first,
In order to refloat this project, it definetly has to be ported to support and be run on modern chips, ideally should be uC agnostic, STM32/ESP32 or other state of the art and cheap 32bit boards, this would make it more universal to use, considering that nowadays many makers/hobbyst come from the Arduino world, and the more electronics-using non standard chip guys (me included) always find that needing a special programmer (STlink Jlink, or even a BusPirate board) and a license to compile that cost 2x-10x the price of the target chip, is just a bit expensive (I know the companies have to subsist, but that should be for Bussiness to Bussiness, not a weekend hobbist).

I mean, if one could compile and run BusPirate fw in an Arduino (wish it was fast enough), everyone would use it, you just need to wire 4-5 pins from your board. As example I use a lot the Arduino as ISP to program and upload bootloaders to different boards by ICSP, but it lacks the ability do debug.

Someone did a first attemp https://github.com/ildar/esp-pirate

The glassgow looks great, but is hardware dependant (also very sofisticated and advanced to use an FPGA), and maybe not everyone wants to debug at GHz.

@mofosyne
Copy link

I know the companies have to subsist, but that should be for Business to Business, not a weekend hobbyist.

I really hope there is a way to figure out a cooperative organisation structure that could provide sustainable way to grow and maintain open hardware. But that's a topic for another time perhaps.

@chepo92
Copy link

chepo92 commented Jul 19, 2020

I know the companies have to subsist, but that should be for Business to Business, not a weekend hobbyist.

I really hope there is a way to figure out a cooperative organisation structure that could provide sustainable way to grow and maintain open hardware. But that's a topic for another time perhaps.

There are many ways, just see many projects here in github that are normally sponsored or have a patreon with many supporters, maybe they are not the most profitable bussiness but at least some can sustain or partially afford it's own continuity, but it has to be constantly maintained, well organized and with a minimum critical mass of users, also a very motivated developer team.

If I find some time i would dedicate it to start porting BP firmware to other boards

@ddavidebor
Copy link
Author

@chepo92 please look into the hydrabus, I have researched this topic extensively and it's the best successor

@chepo92
Copy link

chepo92 commented Jul 22, 2020

Thanks for the tip @ddavidebor
I also found and bought this cheap board FT2232HL to test (my objective is something good and cheap, I know it sounds like a rat, but I think many makers prefer cheap toys to play, explore, learn and break)
As I read some articles in the net

hydrabus looks very promising, will look after it when I have more budget as a pro tool, besides, it doesn't currently ship to my country. Do you have one?

@ddavidebor
Copy link
Author

ddavidebor commented Jul 22, 2020 via email

@PSLLSP
Copy link

PSLLSP commented Aug 10, 2020 •
edited
Loading

What about AxiCat? I have no experience with that device but it seems it is similar device like BusPirate but build with AVR MCU... Price is similar to price of BusPirate.

https://www.elektor.com/axicat
https://www.axiris.eu/en/index.php/i-o-cards/axicat

Standard AxiCat is issued with an ATmega164A microcontroller (16kB FLASH/1kB SRAM/0.5kB EEPROM). :-(
Specification states that ATmega164A can be replaced with pin compatible devices ATmega324A/644A/1284 (more FLASH, SRAM and EEPROM, up to 128kB/16kB/4kB)
USB chip is FTDI FT245.

@techlobo
Copy link

techlobo commented Jul 8, 2022

No, I don't like their HW, I'm not buying it But i'm considering making a competing hardware board
…

Did you ever progress this alternative board?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@tomtastic @mofosyne @PSLLSP @ddavidebor @chepo92 @techlobo