Jump to content

jreveane

Members
  • Gesamte Inhalte

    13
  • Benutzer seit

  • Letzter Besuch

jreveane's Achievements

Newbie

Newbie (1/14)

0

Reputation in der Community

  1. Hi, Thanks for your reply. I get bunch of "Bable Interrupts" with this BBB platform. As soon as this happens, the only way to recover seems to power cycle the BBB. I get better results with the Raspberry Pi for the moment and I will probably give up on the BeagleBone Black then. Things will get simpler (I hope), when the RED brick will be available. Thanks for your help.
  2. So, I did a quick test and it sounds that brickd does not get notified of the USB unplug event. Running dmesg, I got this line only: [time stamp] musb_stage0_irq 790: unhandled DISCONNECT transition (a_idle) BTW, I'm using a BeagleBone Black running Debian. Thanks.
  3. Thanks a lot for your detailed reply. I understand your design decisions, but this behavior is really unusual to me. If brickd can not filter the callbacks, then the TKF client library should take care of it IMHO, not the client code. Thanks.
  4. Thanks. You might be right, this could be an issue with the host USB stack. I will dig into brickd logs. Thanks.
  5. Hi, I'm accessing Linux brickd running over TCP/IP. I using both the Brickviewer and a small C client. Trying to stop the Linux brickd service, I can observe that the Brickviewer and my C clients get notified properly. However, if I unplug the TKF stack from the USB host port, this is not reflected either on Brickviewer or my small client. Please not that I'm not trying to disconnect the bricklets themselves, which is not supported and I guest could damage the whole stack, and which is already the subject of an other thread, but simply perform a valid USB device unplug. So, should I use a specific API call to get notified by brickd that the USB stack is gone ? Thanks.
  6. Thanks a lot for your reply. However, I must probably miss the point but I don't understand where is the bandwidth gain if all the clients get these notification, in particular in the case of clients connected to brickd (running on a Linux system for example) over a TCP/IP connection ? Unless you use UDP multicast ? Please forgive my ignorance about the internal design and constraints, but I would have expected brickd to main a context per client connection. This would avoid the need on the client side to filter out unexpected events, which is likely error prone... Thanks.
  7. Hi, I've noticed that when a client registers a IPCON_CALLBACK_ENUMERATE callback, this callback gets fired each time any client connected to the same Brickd requires an enumeration. I would have expected this to happen only for the context of the client which has performed an enumeration itself. Looking at the API, I didn't notice any parameter or call to filter out unexpected enumeration events. So, is this the expected behavior ? Thanks.
  8. Thanks for your reply. Yes, I was hoping that I could avoid to power the stack from the USB connector or a Step-Down since the servo brick can be powered from the stack connector. That's obviously not possible Thanks.
  9. Hi, Is it possible to use a servo brick, powered by a 5V PS, to provide power to a small stack (one Servo Brick, one master brick and 6 bricklets) ? Note that there will be no motors connected to the Servo Brick. Thanks.
  10. Hi, Thanks for your detailed answer, it is very helpful. The Servo Brick can generate PWM frequencies up to 1MHz. Why do you think it's 500Hz, were did you get that information? Well, I have probably miss interpreted the C API then: int servo_set_period(Servo *servo, uint8_t servo_num, uint16_t period) Sets the period of the specified servo in µs. ..... The minimum possible period is 2000µs and the maximum is 65535µs. The minimum period seems to be of 2 ms if I'm correct and not 1us ? I don't think that going the USB is an option for me so it sounds that I will have to use a Servo Brick. At least this will provide two more bricklets ports. I have one additional question for you if you don't mind: - wouldn't it be possible to modify a master brick firmware to run exactly the same sequence of code for turning on/off the port of an I/O bricklet ? Thanks.
  11. Thanks for your reply, I do appreciate. The main issue is the prince then since using a servo brick is at least 5 times more expensive than a simple bricklet to provide this kind of feature. I had a look at the servo brick C/C++ API and unless I'm wrong I should use: - int servo_set_period(Servo *servo, uint8_t servo_num, uint16_t period) to setup the PWM frequency - int servo_set_pulse_width(Servo *servo, uint8_t servo_num, uint16_t min, uint16_t max) to setup the PWM duty cycle I my case, how should I set the min and max values, I mean can they have the same value ? Regarding the PWM frequency, it sounds that the max is 500 Hz ? Last, can I use the servo brick without external power if I simply need to generate a PWM command signal ? Thanks.
  12. Thanks a lot for your reply. Regarding the pump itself, the power is provided by main AC 230V but its speed is controlled by a PWM signal (1Kz) with a usable and variable speed range from 10 to 80%. So, basically, I would need to be able to emulate and get the same behavior than the Arduino AnalogWrite() for example. BTW, I've noticed that the Breakout Bricklet does expose a PWM signal. I guess it is used for the SPI interface could it be used for this purpose if there is no attached SPI device on this slot ? Thanks.
  13. Hi, I'm a brand new user of TinkerForge devices which I've only discovered recently. I'd like to be able to generate a PWM signal to control the speed of a pump. I thought that I could do that either with the 4 Digital I/O or the AnalogOut Bricklets but reading the API documentation did not confirm this. I don't think that the DC motors bricklets would be appropriate either. Does anyone know how I could generate this kind of signal easily then ? Thanks in advance for your help.
×
×
  • Neu erstellen...