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!
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.
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.
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!
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:
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.
I trust your work
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.
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.
Also
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.
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 :
