Poppy 1.1 : Hipi

Tags: #<Tag:0x00007fae8cffa590> #<Tag:0x00007fae8cffa310>


Yes, they set a mini-uart on TXD RXD, but this mini-uart don’t have separate clock source, so when the CPU frequency move (for energy saving and heat) the mini-uart frequency move too.

@sonel, you make my day, your suggestion are all really good and probably save me a lot of time.

I was going to the wrong direction, so you make me comming back to the right way!

Yes we plan to manage 7.5v and 12v.

Yes as @sonel said about Pixel, manage 3 point TTL for mx and XL320 series, And I also plan to add RS connector for pro series and for futurs motors from robotis (a 4P xl320 connector).

I plan to manage battery too but we want to do it optionally with a deported board. The extention connector should able to manage an arduino for makers and a batterie and button to start/stop and manage some basic things on the robot.
I don’t start anything about that, so we could work together (@juju, @sonel) on it!

Indeed it could be a really interesting feature, and I think about something like @sonel said :

But the USB port are out of the head, so it will be impossible to use this solution. We should add an I2S component who can manage mic… If opne of you guys have any experiments on this kind of component, it could be really interesting!

@sonel : If we do the same thing we could merge our work on it! If you are ok I can give you some access!


@sonel, @juju I have just update the Hipi project, please look at it and give me some feedback!



I had a quick look and it looks much better now… Nice work.

Some things I would suggest changing:

  • for the RX485 chain we might not need the ESD protection because it is usually built in the RS485 chip; check in the data sheet for that chip and it will say if the output are ESD protected or not

  • I think removing the Audio amplifier from the board might be better; here is the logic: the audio amplifier needs nothing from this board except the power supply (5V). If we keep the amplifier on the board it means the board will have to be in the head (that’s the place where the speakers are - and it is very unlikely we would move them somewhere else). Then all the cables to the servos will have to go through the neck (ex. 4 of them) and that would be nasty. I am still of the opinion that the controller for the movement should be in the chest - hence no need for the audio. The audio/video part could be in the head with a second Pi (attached to the display for the “eyes”) simply using one of the many ready made amplifier boards that are on the market.

  • also judge if the “Extension” connector is really necessary; if we want to put all in a board that is respecting the HAT format any little bit of space will be at premium

  • instead of the amplifier you could add a voltage/current measurement using INA219 chip. Check this one from Adafruit - they also have the schematics. You can change the 0.1ohm resistor with a 0.05 one to allow for measurements up to 6.4A - the code will need to be adjusted but that is easy. This way we can monitor the voltage (for batteries) and current independent on accessing the Dynamixel bus (from where we could have read the voltage from one servo). But this way it’s better as we have additional information (current) and we keep the things separate.

I’ll look in detail to make sure that all the connections are fine and maybe this week-end I can put a prototype on the wire board - got this morning the crystals so I think I have everything to put together.


One more thing: in some other boards they use for ESD protection this chip: IP4256CZ5 (made by NXP). It might be better suited. When I test this week I will use the KBMF chip because I already have that around, and I will let you know if there is any issue.


Mine seems to be not ESD protected…

For the simplicity of the system we want to keep only one raspberry pi. Poppy have an articulated spin so the only free space is on the head. That’s why we need to keep the audio amplifier.

That sound good for now :

We plan to create a dedicated board for batteries, button and power things… The main voltage/current measurement should be in this board.

I wait your feedback about it, I think the KBMF should be ok!


Do you mean you won’t power servos on this board, unlike USB2AX?


According to the schematic, the TTL connectors seems to be powered by power in.

@Nicolas , your work is really good ! I’d like to give you more feedback but I’m not good enough and read the datasheet is something… quite long !
New poppy logo ?


Yes indeed, you can power up your motors with the Power Jack input. This board can manage 7.2v for XL320 or 12V for other motors. So you can also mount the corrseponding connector on it.

Yes, We are curently working on new graphic things, you should discover it soon!


The first version of the prototype of the Hipi is ready to produce : http://workspace.circuitmaker.com/Projects/613AA802-319D-402E-B81F-3CB3E253DA1E
We have to test ISP to UART convertion before, but if this test pass we start the prototype production this week.

@sonel : do you have any feedback about SC16IS762, we are testing it now!


Sorry for being so quiet these days…
I have setup the prototype on the breadboard and tried first to see if the chip is visible during boot and the two serial ports are created in /dev.

As expected nothing happened and I need to dig into the setup of the overlay for this chip to work. We need to produce a dts file that needs to be complied to dtb and then place it in in the /boots/overlays. We also need to update /boot/config.txt to activate the usage. There are some posts on the web here:

Article 1
Article 2
Article 3
Article 4

I’ll be working on this today.

I don’t think it would be good to ask them to issue prototypes yet because one of the things I’ve seen on all overlays is that they use one of the Raspberry Pi GPIO pins for IRQ and the circuit that we have now has the IRQ of the SC16IS pulled up. I think it might need to be connected to one GPIO pins.


Can you allow me to buy one or two proto with you to test it on my robots (heol and horse) ?


We probably buy it with Inria budget so it will be difficult to split it! It will be available on CircuitHub so I keep you in touch.

The First Hipi prototype could be simply burn… It’s risky for your money…


I trust your work :slight_smile:
and if it is not too expensive because I tought that making one or two more with circuithub don’t really change the total price.
Nevermind if it is not possible.


Guys, not too much joy yet.

I managed to write the dts file and compile it . Placed it in the /boot/overlays and then update /boot/config.txt by adding:


When I reboot the Raspberry Pi i cannot see anything in dmesg about this overlay being loaded.

If anyone has any experience with writing device tree overlays please chip in.
I’ll keep digging in the meantime.



I’m actualy working with @Nicolas on the SC16IS750 breakout board from Sparkfun.
For testing it we try to communicate with the chip with a simple python program sending some SPI command. But the chip doesn’t respond. In fact we are not able to read or write register to configure the module.

We checked all command send on the SPI bus with an oscilloscope and they’re not involved. We wil try directly with the linux module but without a proper SPI communication, there isn’t a lot of chances.


I have made some kind of progress but I am nowhere near the end.

I have solved some typos in the dts file and managed in the end to get some messages in the dmesg at boot time. They were solved (some missing parameters), then I started to get some conflicts with spidev (using the same CS). In the end I have included in the dts a section that deactivates the spidev driver. Now there are no more messages of any kind and if I run

dtc -I fs /proc/device-tree

I can see the device declared and also the clock and the gpio parameters being inserted in the corresponding part of the device tree.


sudo vcdbg log msg

reports all things in place.

The problem is that running lsmod does not show any module sc16is7xx and like before there are no /dev/ttySCx ports created.

My suspicion is that the standard sc16is driver is actually not included in the compilation that is delivered on Raspberry Pi and needs to be manually compiled and added to the kernel. I’ve seen on other forums that most of the people that managed to get the chip going have recompiled the kernel.

Again, if someone has any knowledge of these things please feel free to chip in.


Yes you right, so today I spend some time on the driver compilation. I create a repo who contains my notes (just the commands I have done one by one) :

There is 2 different way to include a driver into the kernel are :

The integrated method : this method put the driver statically on the linux kernel
The module method : this method create a dynamicaly loadable driver (.ko)

#The integrated method
I use this method to cross-compile a RPI2/3 kernel on my X86 linux.
You can find command sequences on the “integrated” folder.

install.sh : just install the RPI toolchain on your computer.
crosscompile.sh :

  • Download the raspberry linux sources
  • Download the driver c sources
  • Insert the driver sources on the linux sources
  • Configure the kernel build for RPI 2/3
  • Build the kernel with the driver.

I success to build the kernel but I don’t mount it on the SD for now…

#The module method
I use this methode directly on an RPI2/3.
You can find command sequences on the “module” folder.

install.sh :

  • Download the linux sources
  • Download the driver c sources and create a Makefile
  • Configure the kernel for RPI2/3
  • Compile the kernel
  • Create the module tree
  • Replace the actual kernel to the new one
  • Reboot

module_setup.sh :

  • Build the driver for your new kernel
  • Create a device tree configuration file (I use the @sonel one but for sc16is750, so I do a crappy paste…) and install it
  • Configure the RPI to run the new compiled module at boot
  • Reboot

everything seems ok but when I run sudo vcdbg log msg I got Failed to load overlay 'sc16is750-spi'

@sonel can you try the module way? It seems I have the compilation ok and you have the configuration…


@Nicolas Sorry just seen your post. I will check this in the evening.


Thank’s @sonel,

I need to speed up the developpement of the Hipi, I will lauch the prototype production tomorrow unless the sc16is762 dosen’t work!
Today I will create a backup solution with a µcontroler even if that does not please me…

I plan to use the smallest µcontroler as possible so I choose the ATtiny841@16Mhz who have 14 pins, 2 uart, 1 SPI and 2 available GPIO for direction selection…
The only default of this one is the alimentation nedded at 16Mhz :

  • 0 – 2 MHz @ 1.7 – 1.8V
  • 0 – 4 MHz @ 1.8 – 5.5V
  • 0 – 10 MHz @ 2.7 – 5.5V
  • 0 – 16 MHz @ 4.5 – 5.5V


@Nicolas can you try in the meantime to enter this in configure.txt:


That should provide you more details in the vcdbg and dmesg. Maybe it will be visible why the overlay cannot be loaded.