As I now have received my BrickPi i would ofc. need motors and sensors and stuff to extend my lego projects and BrickPiify them.
As I want to buy something thats not too outdated, I am of course looking at the brand new Mindstorms EV3 package.
I see however that it isn’t initially supported.
I am wondering what the limitation is, if it is hardware or firmware?
If it is purely firmware I guess I should buy the EV3 set and start poking the firmware to help with the effort, as I am not too foreign to hacking.
The limitation seems to be hardware. Each EV3 sensor, the advanced sensors at least, use a serial line rather than I2C. Putting a serial line on each port of the BrickPi would require some serious bit-banging of serial lines.
However, there’s hope: we’ve tested the EV3 motors and they seem to work just fine. Also, a few of the EV3 sensors are analog (such as the touch sensor). Those sensors will work already without problem.
FYI, even though the EV3 touch sensor is analog, it uses pin 6 (instead of pin 1). The motors do work fine, but the sensors are not supported.
So is it hardware or software? You say hardware but mention bitbanging which is software. “Serious serial bitbanging” isn’t so serious. In fact the Arduino already has a high performance bitbanging serial library. (Isn’t opensource development great?) It used to be called NewSoftSerial when it was external. It was merged into the standard Arduino distribution and is now called SoftwareSerial. It is interrupt driven which takes the load off the main program so other things can happen. Supports most Arduino pins. The only question is whether it can handle the required baud rate. Doc says “speeds up to 115200 bps” but that depends on processor speed.
Does anyone know the serial characteristics of the EV3 sensors, baud rate, start/stop bits, parity etc? Are they hard coded? Is there online documentation someone could point us to. espenjfo and I make two hackers willing to take a whack at it if we had more data. There are probably others.
Of course being a lowly pre-order customer my help will depend on when pre-order customers get their kits. Rumors say pre-order shipments start this week so I am getting excited.
Lego has not released information about the EV3 system communication or hardware (other than general hardware specs), so all available information is based on the community’s reverse engineering.
The EV3 touch sensor can’t be used with the BrickPi (or the NXT) due to hardware design.
According to my tests, the EV3 uses 115.2k and 57.6k baud for UART communication. As far as I can remember it’s 8N1.
Although it is theoretically possible to support SW UARTS with Arduino, each microcontroller is already using several interrupts. Each microcontroller uses interrupts for HW UART (significantly less than is necessary for SW UART), and for motor encoder support (4,320 interrupts per second, assuming both motors are running at exactly 180 RPM). To support two 57.6k or 115.2k baud full duplex SW UARTS would probably be quite a challenge, and likely impossible with the other interrupts.
Hey Zencuke, why do you say “Lowly”?
That makes it more challenging but probably not impossible. Much of my career has been trying to force unbelievable functionality out of pathetic (cheap) CPU horsepower. The Arduino Atmels are super computers compared to some of the processors I have been forced to use to keep manufacturing costs down.
When I have done things like this before I merged all of the interrupt handlers into one routine then call it at a fixed high frequency. If I can stand the interrupt overhead I make it an interrupt routine on a high frequency timer interrupt. Otherwise the entire software becomes a loop that first waits for a clock edge then uses a table/counter based scheme to decide what to do on this pass. The ISR basically becomes a mini task scheduler where the tasks are functions that must return in a specific minimum time so they don’t overflow the next time slice. Extended functionality needs to be implemented as a state machine with repeated calls to a state handler.
The interrupt version is simpler because much of the functionality can be done in the main loop with traditional procedural code. Only the time based events need to be handled by interrupts. Even some of that can be deferred by having the ISR merely record the time of events in buffers which the main loop processes. Usually serial data doesn’t require rapid response, at least on the order of magnitude as the bit rate. As long as no edges are missed if is usually OK to delay responding by a couple of milliseconds. Serial data (data bytes) usually don’t need to be extracted and processed in real time. Similarly since grey coded quad counters don’t need debouncing handling encoder input data is even simpler because time isn’t important. All the meaning is in the edges. The state is the counter and previous sensor bits and the event is the new value. You just need to apply every event to the counter. Do the motor sensors report speed? That would require time? This could still happen in the main line,
Do you have pointers to where the EV3 reverse engineering is discussed? My google searches get swamped by the shear volume of EV3 pages.
LEGO released EV3 source code in August. In the the driver file d_uart_mod.c is a lot of documentation about the serial sensor protocol. Preliminary vier on quick read: A lot of the code is uart specific but this module seems to bring up, sync and identify the connected devices. It looks looks devices come up at 2400 baud and change baud rate on command. Command protocols are discussed. In other words this module seems to sit on top of the uart and implement the serial sensor protocal. It isn’t a simple serial driver. Application code reads and writes high level command/response data using this module as a device driver.
Not included here are the device specifics. You can query a bunch of stuff though like baudrate (after init sequence)data type and range of data values.
Because until recently preorder customers were treated quite shabily as if Dexter Industries staff thought we were unimportant. It has been fixed but it left a bad taste. All will probably be forgiven when my toy arrives but until then you’ll have to cope with the occasional grumble.
With d_uart_mod.c as documentation it should possible to drive a serial sensor directly from RPi. Need a special cable to route serial pins to RPi serial and the other pins to RPi GPIO pins. Use BrickPi for basic sensors and motors and talk directly to advanced sensors. Advanced sensors seem to have their own processors and not need precise tioming control BrickPi provides. Maybe Dexter should provide PI add on which includes cable for advanced sensors.
zencuke, I want to sincerely and whole-heartedly apologize if myself (John) or any of my employees treated you or any other pre-orders “shabily”. If you have a specific example you’d like to discuss or bring to my attention where we treated our customers poorly or did not deliver, please let me know.
Oops. That won’t work. All the rPI serial ports are in use. I guess it is either software serial on BrickPi or a daughter card somewhere with a uart. Hmm. The rPI can host a usb serial device.
On the other hand there is already a i2c interface per BrickPi sensor port. Maybe what is needed is a I2C/uart converter chip like the 16C450 or one of its successors. (They also do SPI.) At least one member of the family has a 64 byte fifo which might be big enough to hold an EV3 packet. I’ve got to look at the protocol source code again. This could be built as a small daughter card built into a BrickPi EV3 adapter cable sold as a BrickPi add-on. The “daughter card” would interface all the sensor pins including power. It would be easy to enhance the existing software to use the I2C different ways depending on the sensor type it detected. These chips have GPIO pins. A mux might be needed to switch pin functions so the same cable can do EV3 or NXT style interfacing. Sparkfun has a breakout board for the SC16IS750. I think I’ll buy a couple to experiment.
The best part of this strategy is that the BrickPi itself wouldn’t require any mods (well a software upgrade) although a future version might want this built in.
My BrickPi came today. I spent so much time admiring it that I haven’t plugged it in yet.
I wonder if a broader product could be developed that would mediate both ways. That is, if you have an I2C sensor and it needs to talk to EV3, it could do so over serial. And vice versa: if you have an EV3 sensor you want to connect to the BrickPi, NXT, or other device, it would also do that.
I wonder if this couldn’t be done with a cheap microcontroller like an Attiny or something?
Mindsensors is advertising such a device is currently in development (an EV3 sensor interface to be used with NXT and Arduino).
I’ve used HW I2C with the AtTiny85 (through the USI), but ideally the uC would have both HW I2C and HW UART (Edit: which I don’t think any of the small AVRs have).
Yes, exactly. But the MS device only goes one way: converts serial to I2C, no? I’m envisioning somethign that goes both way, making NXT I2C sensors accessible to the EV3.
I don’t think that’s necessary. The EV3 already supports I2C (through bit-banging, like the NXT).
So…I want to dip a toe into the Pi world…and have a young son who loves lego…so BrickPi it is…ordered today…and the plan was to by NXT to go with it of course…now I see that NXT is sold out and superseded by EV3 it seems…but the sensors in the EV3 kit won’t work with BrickPi…so any thoughts on the best way ahead for me please? Thanks for any advice
A few options are available I think, and we’ve tried to outline them in this thread: