Welcome! Log In Create A New Profile

Advanced

Project: Teacup Firmware

Posted by Triffid_Hunter 
Re: Project: Teacup Firmware
June 02, 2015 09:31AM
It should be no problem to use either one of the heater outputs or the controllable fan output on the Duet to power a solenoid, but you would need to add a flyback diode because the boards do not include them.



Large delta printer [miscsolutions.wordpress.com], Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: Project: Teacup Firmware
June 02, 2015 09:41AM
Thanks dc42, I will buy Duet & Duex boards.

Mike
Re: Project: Teacup Firmware
June 02, 2015 10:05AM
Quote
dc42
Quote
leadinglights
Nor would I expect you to. I had hoped though that you could give some starting points such as if there is or is not already code for I2C or SPI in Teacup.
It is not my intention to port to a PIC, only to use a PIC controller to do the actual tool change - that is well within my abilities. Deciding whether to use Teacup or something else is my present quest.

Mike

You might want to look at how RepRapFirmware on Duet electronics handles tool changes. Whenever a tool is released, a macro file for that tool is run. Whenever a tool is selected, another macro file is run; then the tool heaters are commanded to operating temperature; finally a 3rd macro file is run. The macro files contain ordinary gcodes, so you can do what you like in them. The standard firmware configuration supports up to 5 extruders and 6 heaters.

@dc42 - offtopic and sort of thread hijacking here. Could you please discuss RepRapFirmware programming in a separate thread or PM Mike about it?
Re: Project: Teacup Firmware
June 02, 2015 10:32AM
Quote
AndrewBCN
Quote
dc42
Quote
leadinglights
Nor would I expect you to. I had hoped though that you could give some starting points such as if there is or is not already code for I2C or SPI in Teacup.
It is not my intention to port to a PIC, only to use a PIC controller to do the actual tool change - that is well within my abilities. Deciding whether to use Teacup or something else is my present quest.

Mike

You might want to look at how RepRapFirmware on Duet electronics handles tool changes. Whenever a tool is released, a macro file for that tool is run. Whenever a tool is selected, another macro file is run; then the tool heaters are commanded to operating temperature; finally a 3rd macro file is run. The macro files contain ordinary gcodes, so you can do what you like in them. The standard firmware configuration supports up to 5 extruders and 6 heaters.

@dc42 - offtopic and sort of thread hijacking here. Could you please discuss RepRapFirmware programming in a separate thread or PM Mike about it?

@AndrewBCN - I don't think that dc42 did hijack the thread: I have been asking for any thoughts or assistance in how to control a whole bunch of extruders and a extruder swapper. dc42 pointed out that another set of electronics uses macros -which I do understand, and G codes - which I also understand. Perhaps I could have asked if Teacup does anything similar which I can build on.

Alternative I could spend the next few months trying to get to grips with each available open source firmwares at the expense of getting my hardware working.

Mike
Re: Project: Teacup Firmware
June 02, 2015 12:53PM
Quote
AndrewBCN
@dc42 - offtopic and sort of thread hijacking here.

Well known pattern. People try Teacup and if it doesn't work out of the box, most of these people prefer to wrestle weeks with other and more expensive stuff.

There's even a branch "multi-extruder", which implements the T word. But to see that one would have to take a look. Gen7 as well as SevenSwitches have such a flyback diode.


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Project: Teacup Firmware
June 02, 2015 12:57PM
Quote
leadinglights
I have been asking for any thoughts or assistance in how to control a whole bunch of extruders and a extruder swapper.

You didn't. This was your question:

Quote
leadinglights
Does Teacup have a way of sending out and receiving commands from a RAMPS board through SPI, I2C or serial interfaces?


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Project: Teacup Firmware
June 02, 2015 03:02PM
Quote
Traumflug
Quote
leadinglights
I have been asking for any thoughts or assistance in how to control a whole bunch of extruders and a extruder swapper.

You didn't. This was your question:

Quote
leadinglights
Does Teacup have a way of sending out and receiving commands from a RAMPS board through SPI, I2C or serial interfaces?

In the first quote I said "I have been asking...." which referred to questions I have asked on the RepRap forums - including the one quoted in my first post. In the second quote you have excerpted the first sentence from a paragraph which covered what it was being used for.

Although I will be ordering a a Duet/Duex combination this is as a fall back position, it still has one stepper motor too few for my requirements (5 extruders, 1 extruder swap motor and a lift solenoid plus 5 heaters)

Mike
Re: Project: Teacup Firmware
June 02, 2015 03:30PM
Quote
leadinglights
Although I will be ordering a a Duet/Duex combination this is as a fall back position, it still has one stepper motor too few for my requirements (5 extruders, 1 extruder swap motor and a lift solenoid plus 5 heaters)

Have you browsed [reprap.org] to see whether there are any other electronics that better match your requirements?



Large delta printer [miscsolutions.wordpress.com], Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: Project: Teacup Firmware
June 09, 2015 03:28PM
I noticed an interesting behavior and was wondering if it was something peculiar in my setup. When homing via G28, I notice that the extruder is turning ever so slowly. It's not a big deal - it's just a bit more filament ooze that I need to clean up at the start of the print. I just thought it odd enough to bring up here. Maybe I'm just the only one who noticed smiling smiley
Re: Project: Teacup Firmware
June 10, 2015 05:22AM
As a developer I'd

a) put this issue into the issue tracker and

b) start checking late in dda_create() to see wether these homing movements cause E steps (dda->steps[E]).


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Project: Teacup Firmware
June 10, 2015 11:32PM
Quote
Traumflug
a) put this issue into the issue tracker and

Done

Quote
Traumflug
b) start checking late in dda_create() to see wether these homing movements cause E steps (dda->steps[E]).

I'll start checking into the code to see if I can identify anything.

I'm not really worried about this. More curious than anything.
Re: Project: Teacup Firmware
June 15, 2015 05:43PM
Quote
leadinglights
Nor would I expect you to. I had hoped though that you could give some starting points such as if there is or is not already code for I2C or SPI in Teacup.
It is not my intention to port to a PIC, only to use a PIC controller to do the actual tool change - that is well within my abilities. Deciding whether to use Teacup or something else is my present quest.

Mike

Since no one directly answered your question:

Marlin: Uses I2C to communicate with various LCD panels. Uses SPI to communicate with SD card readers. you'd need to connect your device onto a BUS and then program a module for Marlin to communicate with your device on an assigned address on that bus. Wire is the Arduino layer for communicating on the I2C bus. [www.arduino.cc]

Teacup: Since it is not Arduino specific, you would have to implement an I2C or SPI stack. Atmel has many application notes and there are libraries for this.

The challenge however: since this is a Bus and you would usually daisy chain devices, then use a "chip select" pin or what ever, if there is already an LCD or an SD card reader on the bus, your device (i think) would have to connect to it on an I2C or SPI bus header, or use software SPI. There are many ways to solve your problem though. Seems marlin can't support more than 3 extruders and Repetier Firmware supports four.

Edited 1 time(s). Last edit at 06/15/2015 05:47PM by thetazzbot.
Re: Project: Teacup Firmware
June 15, 2015 06:05PM
Quote
thetazzbot
Teacup: Since it is not Arduino specific, you would have to implement an I2C or SPI stack.

The SPI part was done over the last few days, as part of SD card reading. It's in the sdcard3 branch.


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Project: Teacup Firmware
June 16, 2015 02:40AM
Quote
Traumflug
Quote
thetazzbot
Teacup: Since it is not Arduino specific, you would have to implement an I2C or SPI stack.

The SPI part was done over the last few days, as part of SD card reading. It's in the sdcard3 branch.

How about the ultralcd support?
Re: Project: Teacup Firmware
June 16, 2015 02:50AM
Quote
thetazzbot
How about the ultralcd support?

I see no reason why this should happen. Plenty of [censored] yelling wishlists, zero people actually writing such code. For me, there are more interesting things to hack, e.g. jerk-less look-ahead, which is something I'd have actual use for.


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Project: Teacup Firmware
June 16, 2015 10:59AM
Quote
Traumflug
Quote
thetazzbot
Teacup: Since it is not Arduino specific, you would have to implement an I2C or SPI stack.

The SPI part was done over the last few days, as part of SD card reading. It's in the sdcard3 branch.

@Traumflug. Thank you for the information. I now know that there is existing SPI code that I can build on I will be able to do the other end. thetazzbot has PMd me that he may also be able to give some input.
Since this is now a general item of potential interest I will start a new thread in the Developers sub forum where I can both solicit help and feed back anything that I come up with.

Mike
Re: Project: Teacup Firmware
June 16, 2015 11:00AM
I want to work with teacup, and the new config tool. I plan to try it on an Uno and a V3 Engraver board I have laying around. I ordered some Sevenswitch PCB's that I will try to make work for the hotend. No heatbed since I will use PLA only.
Re: Project: Teacup Firmware
June 19, 2015 01:10PM
Here's where I've gotten so far in the configtool.
board.CNC_Shield_V3_UNO.h is attached at the bottom.

I'm using
AIO2 (UNO) / Resume (CNC Shield) for the Hotend Seven Switch Connection,
and
AIO3 (UNO) / Coolant En (CNC Shield) for the thermistor







I had to manually set the CPU by editing the board file. It would be nice is all the CPU's were listed. Does the CPU part look right?


/***************************************************************************\
*                                                                           *
* 1. CPU                                                                    *
*                                                                           *
\***************************************************************************/

/** \def CPU_TYPE
  CPU types a user should be able to choose from in configtool. All
  commented out.
*/
//#define CPU_TYPE atmega328

/** \def CPU
  CPU actually present on the board.
*/
#define CPU                      atmega328

/** \def F_CPU_OPT
  CPU clock frequencies a user should be able to choose from in configtool.
  All commented out.
*/
//#define F_CPU_OPT 16000000UL

/** \def F_CPU
  Actual CPU clock rate. #ifndef required for Arduino compatibility.
*/
#ifndef F_CPU
#define F_CPU                    16000000UL
#endif

/** \def MOTHERBOARD
  This is the motherboard, as opposed to the extruder. See extruder/ directory
  for GEN3 extruder firmware.
*/
#define MOTHERBOARD


/***************************************************************************\
*                                                                           *
* 2. PINOUTS                                                                *
*                                                                           *
\***************************************************************************/

#define X_STEP_PIN               DIO2
#define X_DIR_PIN                DIO5
#define X_MIN_PIN                DIO9
//#define X_MAX_PIN                DIO21
#define X_ENABLE_PIN             DIO8
//#define X_INVERT_DIR
#define X_INVERT_MIN
#define X_INVERT_MAX
#define X_INVERT_ENABLE

#define Y_STEP_PIN               DIO3
#define Y_DIR_PIN                DIO6
#define Y_MIN_PIN                DIO10
//#define Y_MAX_PIN                DIO26
#define Y_ENABLE_PIN             DIO8
//#define Y_INVERT_DIR
#define Y_INVERT_MIN
#define Y_INVERT_MAX
#define Y_INVERT_ENABLE

#define Z_STEP_PIN               DIO4
#define Z_DIR_PIN                DIO7
#define Z_MIN_PIN                DIO11
//#define Z_MAX_PIN                DIO31
#define Z_ENABLE_PIN             DIO8
//#define Z_INVERT_DIR
#define Z_INVERT_MIN
#define Z_INVERT_MAX
#define Z_INVERT_ENABLE

#define E_STEP_PIN               DIO12
#define E_DIR_PIN                DIO13
#define E_ENABLE_PIN             DIO8
//#define E_INVERT_DIR
//#define E_INVERT_ENABLE

//#define PS_ON_PIN                DIO14
//#define PS_MOSFET_PIN            xxxx
//#define STEPPER_ENABLE_PIN       DIO25
//#define STEPPER_INVERT_ENABLE

/** \def DEBUG_LED_PIN

  Enable flashing of a LED during motor stepping.

  Disabled by default. Uncommenting this makes the binary a few bytes larger
  and adds a few cycles to the step timing interrrupt in timer.c. Also used
  for precision profiling (profiling works even without actually having such
  a LED in hardware), see
  [reprap.org]
*/
//#define DEBUG_LED_PIN            DIO21


/***************************************************************************\
*                                                                           *
* 3. TEMPERATURE SENSORS                                                    *
*                                                                           *
\***************************************************************************/

#ifndef DEFINE_TEMP_SENSOR
  #define DEFINE_TEMP_SENSOR(...)
#endif

/** \def TEMP_MAX6675 TEMP_THERMISTOR TEMP_AD595 TEMP_PT100 TEMP_INTERCOM
  Which temperature sensor types are you using? Leave all used ones
  uncommented, comment out all others to save binary size and enhance
  performance.
*/
//#define TEMP_MAX6675
#define TEMP_THERMISTOR
//#define TEMP_AD595
//#define TEMP_PT100
//#define TEMP_INTERCOM

/** \def TEMP_SENSOR_PIN
  Temperature sensor pins a user should be able to choose from in configtool.
  All commented out.
*/
//#define TEMP_SENSOR_PIN AIO3

/** \def DEFINE_TEMP_SENSOR
  Define your temperature sensors here. One line for each sensor, only
  limited by the number of available ATmega pins.

  Name must match the name of the corresponding heater. If a heater "extruder"
  exists, a temperature sensor of that name has to exist as well. Same for
  heater "bed". There can be one sensor without corresponding heater, name it
  "noheater".

  Types are same as TEMP_ list above - TT_MAX6675, TT_THERMISTOR, TT_AD595,
  TT_PT100, TT_INTERCOM. See list in temp.c.

  The "additional" field is used for TT_THERMISTOR only. It defines the
  name of the table(s) in thermistortable.h to use. This name is arbitrary,
  often used names include THERMISTOR_EXTRUDER and THERMISTOR_BED. Also,
  several sensors can share the same table, which saves binary size.

  For a GEN3 set temp_type to TT_INTERCOM and temp_pin to AIO0. The pin
  won't be used in this case.
*/
//DEFINE_TEMP_SENSORS_START
//                 name      type           pin    additional
DEFINE_TEMP_SENSOR(Hotend,   TT_THERMISTOR, AIO3,  THERMISTOR_HOTEND)

// Beta algorithm      r0      beta  r2    vadc
// Steinhart-Hart      rp      t0    r0      t1    r1      t2    r2
//TEMP_TABLE HOTEND   (100000, 4066, 4700, 5.0)
//DEFINE_TEMP_SENSORS_END


/***************************************************************************\
*                                                                           *
* 4. HEATERS                                                                *
*                                                                           *
\***************************************************************************/

#ifndef DEFINE_HEATER
  #define DEFINE_HEATER(...)
#endif

/** \def HEATER_PIN
  Heater pins a user should be able to choose from in configtool. All
  commented out.
*/

/** \def DEFINE_HEATER
  Define your heaters and devices here.

  To attach a heater to a temp sensor above, simply use exactly the same
  name - copy+paste is your friend. Some common names are 'extruder',
  'bed', 'fan', 'motor', ... names with special meaning can be found
  in gcode_process.c. Currently, these are:
    HEATER_extruder   (M104)
    HEATER_bed        (M140)
    HEATER_fan        (M106)

  Devices don't neccessarily have a temperature sensor, e.g. fans or
  milling spindles. Operate such devices by setting their power (M106),
  instead of setting their temperature (M104).

  Also note, the index of a heater (M106 P#) can differ from the index of
  its attached temperature sensor (M104 P#) in case sensor-less devices
  are defined or the order of the definitions differs. The first defined
  device has the index 0 (zero).

  Set 'pwm' to ...
    1  for using PWM on a PWM-able pin and on/off on other pins.
    0  for using on/off on a PWM-able pin, too.

  Using PWM usually gives smoother temperature control but can conflict
  with slow switches, like solid state relays. PWM frequency can be
  influenced globally with FAST_PWM, see below.
*/
//DEFINE_HEATERS_START
//            name      port   pwm
DEFINE_HEATER(Hotend,   AIO2,  1)

#define HEATER_HOTEND HEATER_Hotend
//DEFINE_HEATERS_END


/***************************************************************************\
*                                                                           *
* 5. COMMUNICATION OPTIONS                                                  *
*                                                                           *
\***************************************************************************/

/** \def BAUD
  Baud rate for the serial RS232 protocol connection to the host. Usually
  115200, other common values are 19200, 38400 or 57600. Ignored when USB_SERIAL
  is defined.
*/
#define BAUD                     115200

/** \def XONXOFF
  Xon/Xoff flow control.

  Redundant when using RepRap Host for sending G-code, but mandatory when
  sending G-code files with a plain terminal emulator, like GtkTerm (Linux),
  CoolTerm (Mac) or HyperTerminal (Windows).
*/
//#define XONXOFF

/** \def USB_SERIAL
  Define this for using USB instead of the serial RS232 protocol. Works on
  USB-equipped ATmegas, like the ATmega32U4, only.
*/
//#define USB_SERIAL


Attachments:
open | download - board.CNC_Shield_V3_UNO.h (8.3 KB)
Re: Project: Teacup Firmware
June 19, 2015 01:52PM
Quote
Traumflug
Quote
thetazzbot
How about the ultralcd support?

I see no reason why this should happen. Plenty of [censored] yelling wishlists, zero people actually writing such code. For me, there are more interesting things to hack, e.g. jerk-less look-ahead, which is something I'd have actual use for.

For the record, I'm not an [censored], actually I'm quite a nice guy smiling smiley And a developer, so if you don't have any objections I wouldn't mind forking Teacup to see if I can add in the lcd support. I would love to see Teacup with LCD and SD card and that's just about all I'd add to it smiling smiley Because then it will be perfect (for my selfish needs) smiling smiley.
Re: Project: Teacup Firmware
June 19, 2015 03:25PM
Quote
thetazzbot
I'm quite a nice guy smiling smiley And a developer

That's an excellent combination :-)

Quote
thetazzbot
if you don't have any objections I wouldn't mind forking Teacup to see if I can add in the lcd support. I would love to see Teacup with LCD and SD card and that's just about all I'd add to it smiling smiley Because then it will be perfect (for my selfish needs) smiling smiley.

Doing a fork will just increase the likelyness this stuff gets lost sooner or later. I'll happily give you write access to the main repo, just drop me a line in this issue: [github.com] You can create as many branches as you see use for, as long as the others are kept intact. Having branches (known as "topic branches" in Git documentation) is a very powerful method to keep track of developments on other branches, you simply rebase on them from time to time. As commits are taken cherry-picked over to experimental (development branch), these topic branches become shorter and shorter, until they're eventually empty and get removed.

Edited 1 time(s). Last edit at 06/19/2015 03:49PM by Traumflug.


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Project: Teacup Firmware
June 19, 2015 03:44PM
Quote
madmike8
I'm using AIO2 (UNO) / Resume (CNC Shield) for the Hotend Seven Switch Connection

You likely want a pin capable of doing PWM, which are DIO3, DIO5, DIO6 and DIO11. All others can run a heater, too, but only full on / full off.

For the thermistor, any analog pin is equally fine. Step/Dir and such stuff care even less and can take any analog or any digital pin.

Quote
madmike8
It would be nice is all the CPU's were listed.

You add them by defining multiple CPU_TYPE lines, all commented out. Like:
//#define CPU_TYPE atmega168
//#define CPU_TYPE atmega168p
//#define CPU_TYPE atmega328
//#define CPU_TYPE atmega328p

Quote
madmike8
Does the CPU part look right?

328 and 328P are different types. The Arduinos I'm aware of all use -P types. Other than that, just try. If uploading results in something about "unexpected signature", it was not the right one. After changing this choice, a new build is neccessary.


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Project: Teacup Firmware
June 19, 2015 03:55PM
Thanks!

I'm going to give it a try tonight.
Re: Project: Teacup Firmware
June 21, 2015 11:38AM
Quote
madmike8
Thanks!

I'm going to give it a try tonight.

Excellent new. I have feceived this shield last week. I was thinking in porting it to teacup. Keep on with your test and development.
Re: Project: Teacup Firmware
June 22, 2015 10:09AM
Based on this post, I changed the name from hotend to extruder.

Quote
Traumflug
Thanks. I think it's about time to add one or two of these Nano/Uno based setups to the distribution, so I looked into it. One thing I found is, you name the extruder "hotend", which requires adding a P0 to each M104 and gives a slightly different answer text on M105. Renaming this to "extruder" would fix this. "extruder", "bed" and "fan" are names with a special meaning, see the tooltip when hovering over the "add sensor" "Add" button on the heater tab.

I still haven't gotten a chance to test it this weekend due to Father's Day obligations...

board.CNC_Shield_V3_UNO.h
Re: Project: Teacup Firmware
July 01, 2015 11:17AM
Earlier today I committed a config template for a similar board, the NanoHeart. You might want to use this to derivate other Nano based boards from.


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Project: Teacup Firmware
July 01, 2015 11:22AM
Another one: there's now a "Report problem" entry in the help menu. It'll fetch the important files, strip their comments and stuff them into an Email, along with a few simple questions. When choosing this entry, your emailer should open with an almost ready-to-send email, just the answers to the questions missing

Please answer these questions before hitting "send":

What did you try to do?


What did you expect to happen?


What happened instead?

Good idea, isn't it? Should make reporting issues much easier.


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Project: Teacup Firmware
July 06, 2015 02:18PM
Just "printed" the first file from SD card on the test bench. All on yet another branch, sdcard4.

M20 to M25 implemented. Depending on the card it still might require enabling FAT32. Will turn back to this later.

- Processing happens on a per-line basis. While printing from SD, typing something on the serial line will stop reading from SD until this line is done. Simple way to not mix up G-code coming from both sources.

- M23, then M24 also restarts a file.

- M26 will likely be added, easy to implement.

- Not sure what M27 should read. RepRap wiki says "report status". Whatever "status" means.

- M20 currently lists the top level directory, only. Also, printing only works from there. Can't afford to reserve 1024 bytes RAM just to receive a full path :-)

Enjoy!


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Project: Teacup Firmware
July 10, 2015 07:05AM
Quote
thetazzbot
Quote
Traumflug
Quote
thetazzbot
How about the ultralcd support?

I see no reason why this should happen. Plenty of [censored] yelling wishlists, zero people actually writing such code. For me, there are more interesting things to hack, e.g. jerk-less look-ahead, which is something I'd have actual use for.

For the record, I'm not an [censored], actually I'm quite a nice guy smiling smiley And a developer, so if you don't have any objections I wouldn't mind forking Teacup to see if I can add in the lcd support. I would love to see Teacup with LCD and SD card and that's just about all I'd add to it smiling smiley Because then it will be perfect (for my selfish needs) smiling smiley.


have you done anything with this? i'm curious as i'm also looking at the possibility of lcd support now that the sdcard stuff is working




-=( blog )=- -=( thingiverse )=- -=( 3Dindustries )=- -=( Aluhotend - mostly metal hotend)=--=( Facebook )=-



Re: Project: Teacup Firmware
July 11, 2015 05:23AM
Quote
thejollygrimreaper
have you done anything with this?

Maybe he did, but certainly nothing publicly visible. That much to "I'm a nice guy" and "I'm not an [censored]".


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Project: Teacup Firmware
July 14, 2015 05:24PM
Quote
Traumflug
Quote
thejollygrimreaper
Quote
thetazzbot
Quote
Traumflug
Quote
thetazzbot
How about the ultralcd support?

I see no reason why this should happen. Plenty of [censored] yelling wishlists, zero people actually writing such code. For me, there are more interesting things to hack, e.g. jerk-less look-ahead, which is something I'd have actual use for.

For the record, I'm not an [censored], actually I'm quite a nice guy smiling smiley And a developer, so if you don't have any objections I wouldn't mind forking Teacup to see if I can add in the lcd support. I would love to see Teacup with LCD and SD card and that's just about all I'd add to it smiling smiley Because then it will be perfect (for my selfish needs) smiling smiley.

have you done anything with this? i'm curious as i'm also looking at the possibility of lcd support now that the sdcard stuff is working

Maybe he did, but certainly nothing publicly visible. That much to "I'm a nice guy" and "I'm not an [censored]".

Would you guys consider trying out bounties? It seems like bounties could make this a win-win situation for everyone. People yelling wishlists could put up a little cash if they were really serious, and the developer(s) could get incentives for things they are not immediately interested in working on. In addition, developer(s) might be able to drum up a little funding to work on things they are immediately interested in.

(Tangent: I am trying to revitalize interest in the bounty system so I am going around finding places where it might be useful.)
Sorry, only registered users may post in this forum.

Click here to login