I am working on new costume board based on (i. MX 6Solo6DualLite).and I use (TJA1100 100BASE-T1 PHY) for Automotive Ethernet..
please correct me if my questions don't make sense, or I am in the wrong way.
I want to write driver for this device.. and make sure that it works correctly.
1- I can make sure that the driver works properly in the U-boot step, Right? I mean no need to load Linux kernel, so I have just to add source code C driver in U-boot source code and compile it. I want to do this in U-boot step, so I can limit the numbers of files that initialise all peripheriques, and make it simple as possible since that U-boot can behave like (mini-Os)
2-I don't know how to write this driver (exactly..), so I am looking for the driver (source code) that initialise the Ethernet Controller in any other processor , and initialise another typeof ethernet phy, in order to get an idea and write a similar driver source code for I.MX6 and TJA1100,?
after this i think that i could maybe add some very basic file c For simple Protocol like ARP, for test purpose..
3- is this good idea writing driver code by inspiring from another driver code source?
4 - maybe, if you already have a driver for (i. MX 6Solo6DualLite and TJA1100 100BASE-T1 PHY) can you provide to me please... ?
for my second question i tried to extract from U-boot source code the C file that initialise Ethernet Controller in AM335x, and initialise LAN8710A phy,(in beaglebone black) in order to get an idea and write a similar driver source code but i couldn't found it .. i found network C file for protocol .... but that's disturp me i couldn't seperate them from the real C file that initialise ethernet controller and ethernent Phy .
http://www.denx.de/wiki/U-Boot/SourceCode
There is a driver published on the NXP forum:
https://community.nxp.com/thread/460767
It includes both some bare metal code that should be usable with U-Boot and a Linux driver.
Related
I have an issue working with DiagramBuilder and ManipulationStation classes.
It appears to me, that c++ API and the python bindings work differently in my case.
C++ API behaves as expected, while the python bindings result in the runtime error:
DiagramBuilder: Cannot operate on ports of System plant until it has been registered using AddSystem
How I use C++ API
In one of the ManipulationStation::Setup...() methods I inject a block of code, that adds an extra manipuland
const std::string sdf_path = FindResourceOrThrow("drake/examples/manipulation_station/models/bolt_n_nut.sdf");
RigidTransform<double> X_WC(RotationMatrix<double>::Identity(), Vector3d(0.0, -0.3, 0.1));
bolt_n_nut_ = internal::AddAndWeldModelFrom(sdf_path, "nut_and_bolt", lant_->world_frame(), "bolt", X_WC, plant_);
I inject another block of code into the method ManipulationStation::Finalize:
auto zero_torque = builder.template AddSystem<systems::ConstantVectorSource<double>>(Eigen::VectorXd::Zero(plant_->num_velocities(bolt_n_nut_)));
builder.Connect(zero_torque->get_output_port(), plant_->get_actuation_input_port(bolt_n_nut_));
With these changes, the simulation runs as expected.
How I use python bindings
plant = station.get_multibody_plant()
manipuland_path = get_manipuland_resource_path()
bolt_with_nut = Parser(plant=plant).AddModelFromFile(manipuland_path)
X_WC = RigidTransform(RotationMatrix.Identity(), [0.0, -0.3, 0.1])
plant.WeldFrames(plant.world_frame(), plant.GetFrameByName('bolt', bolt_with_nut), X_WC)
...
station.Finalize()
zero_torque = builder.AddSystem(ConstantValueSource(AbstractValue.Make([0.])))
builder.Connect(zero_torque.get_output_port(), plant.get_actuation_input_port(bolt_with_nut_model))
This triggers a RuntimeError with a message as above; The port, which causes this error is nut_and_bolt_actuation.
My vague understanding of the problem is the (in) visibility of nut_and_bolt System, due to having two distinct DiagramBuilders in a process: 1) a one is inside ManipulationStation 2) another is in the python code, that instantiates this ManipulationStation object.
Using ManipulationStation via python bindings is a preference for me, because that way I would've avoided depending on a custom build of drake library.
Thanks for your insight!
I agree with your assessment: you have two different DiagramBuilder objects here. This does not have anything to due with C++ or Python; the ManipulationStation is itself a Diagram (created using its own DiagramBuilder), and you have a second DiagramBuilder (in either c++ or python) that is connecting the ManipulationStation together with other elements. You are trying to connect a system that is in the external diagram to a port that is in the internal diagram, but is not exposed.
The solution would be to have the ManipulationStation diagram expose the extra nut and bolt actuation port so that you can connect to it from the second builder.
If you prefer Python, I've switched my course to using a completely python version of the manipulation station. I find this version is much easier to adapt to different student projects. (To be clear, the setup is in python, but at simulation time all of the elements are c++ and it doesn't call back to python; so the performance is almost identical.)
I would like to visualize pointcloud in drake-visualizer using python binding.
I imitated how to publish images through lcm from here, and checked out these two issues (14985, 14991). The snippet is as follows :
point_cloud_to_lcm_point_cloud = builder.AddSystem(PointCloudToLcm())
point_cloud_to_lcm_point_cloud.set_name('pointcloud_converter')
builder.Connect(
station.GetOutputPort('camera0_point_cloud'),
point_cloud_to_lcm_point_cloud.get_input_port()
)
point_cloud_lcm_publisher = builder.AddSystem(
LcmPublisherSystem.Make(
channel="DRAKE_POINT_CLOUD_camera0",
lcm_type=lcmt_point_cloud,
lcm=None,
publish_period=0.2,
# use_cpp_serializer=True
)
)
point_cloud_lcm_publisher.set_name('point_cloud_publisher')
builder.Connect(
point_cloud_to_lcm_point_cloud.get_output_port(),
point_cloud_lcm_publisher.get_input_port()
)
However, I got the following runtime error:
RuntimeError: DiagramBuilder::Connect: Mismatched value types while connecting output port lcmt_point_cloud of System pointcloud_converter (type drake::lcmt_point_cloud) to input port lcm_message of System point_cloud_publisher (type drake::pydrake::Object)
When I set 'use_cpp_serializer=True', the error becomes
LcmPublisherSystem.Make(
File "/opt/drake/lib/python3.8/site-packages/pydrake/systems/_lcm_extra.py", line 71, in _make_lcm_publisher
serializer = _Serializer_[lcm_type]()
File "/opt/drake/lib/python3.8/site-packages/pydrake/common/cpp_template.py", line 90, in __getitem__
return self.get_instantiation(param)[0]
File "/opt/drake/lib/python3.8/site-packages/pydrake/common/cpp_template.py", line 159, in get_instantiation
raise RuntimeError("Invalid instantiation: {}".format(
RuntimeError: Invalid instantiation: _Serializer_[lcmt_point_cloud]
I saw the cpp example here, so maybe this issue is specific to python binding.
I also saw this python example, but thought using 'PointCloudToLcm' might be more convenient.
P.S.
I am aware of the development in recent commits on MeshcatVisualizerCpp and MeshcatPointCloudVisualizerCpp, but I am still on the drake-dev stable build 0.35.0-1 and want to stay on drake visualizer until the meshcat c++ is more mature.
The old version in pydrake.systems.meshcat_visualizer.MeshcatVisualizer is a bit too slow on my current use-case (multiple objects drop). I can visualize the pointcloud with this visualization setting, but it took too much machine resources.
Only the message types that are specifically bound in lcm_py_bind_cpp_serializers.cc can be used on an LCM message input/output port connection between C++ and Python. For all other LCM message types, the input/output port connection must be from a Python system to a Python system or a C++ System to a C++ System.
The lcmt_image_array is listed there, but not the lcmt_point_cloud.
If you're stuck using Drake's v0.35.0 capabilities, then I don't see any great solutions. Some options:
(1) Write your own PointCloudToLcm system in Python (by re-working the C++ code into Python, possibly with a narrower set of supported features / channels for simplicity).
(2) Write your own small C++ helper function MakePointCloudPublisherSystem(...) that calls LcmPublisherSystem::Make<lcmt_point_cloud> function in C++, and bind it into Python. Then your Python code can call MakePointCloudPublisherSystem() and successfully connect that to the existing C++ PointCloudToLcm.
I have 2 types of ARDUINO-cards. ATMEGA 2560 and ATMEGA 328P.
In my Delphi7 (XP64 sp2) I have modified the JvHidDeviceController Unit to show the PID/VID's of the abovementioned Cards. That works perfectly. And with the use of the TComPort unit I can communicate with the selected card. No problems here.
And here is the problem:
I connect my AVR MARK II (usb-tiny). System "says" OK.
(When I run the ARUINO program I have no problems communicating with the connected card.)
I run the Delphi program (JVHidDeviceController Unit), the 2560 and 328p PID/VID appear in a LIST-box but NOT the AVR-MARK II.
I Wonder why ? Please help.
After a search on the WWW I discovered, that the UNO (328P) could be turned into a ISP programmer. And by doing so I solve 2 (sub-)problems. I got the code ("bootloader") and the UNO Stills responds to the JVHidDeviceController requests. (Final solution in reach.. ) Kris
I´m newbie with Thingsquare
I'm traying to create a IP64 Gateway with MB851 Board (STM32W108CC microprocessor)
I send and receive data (IPv6 Radio) using 2 MB851 Boards with Thingsquare udp-multicast example.
I modified mist-mb851 platform to include an enc28j60-arch.c file to implement the platform code of SPI functions that are called by the enc28j60 driver
I modified ip64-conf.h to include enc28j60 driver and fallback interface
include "ip64-eth-interface.h"
include "enc28j60-ip64-driver.h"
define IP64_CONF_UIP_FALLBACK_INTERFACE ip64_eth_interface
define IP64_CONF_INPUT ip64_eth_interface_input
define IP64_CONF_DHCP 1
define IP64_CONF_ETH_DRIVER enc28j60_ip64_driver
I modified Contiki/platform/mb851 to include STM32 PeripheralLibs to create the SPI driver
The enj28j60 driver is tested
I compile the Thingsquare Router-Node example but when initialize the DHCP process
ip64_init();--->ip64_ipv4_dhcp_init();--->ip64_dhcpc_request();--->handle_dhcp();--->send_discover();
Nothing happens
Debugging the code when tcpip_ipv6_output(); function is call to send the packet the function ip64_6to4(...); fails and i don´t know why
Best Regards
I'm stumped trying to get etherOutputHookAdd() to work. Its counterpart, etherInputHookAdd(), seems to work fine. The OS version in question is VxWorks 5.4 .
The hook code looks like so (the code I intend to actually run is more complicated, but this serves for an example.)
int anCounter;
STATUS etherHook(struct ifnet *pif, char *buf, int size)
{
anCounter += 1;
return FALSE;
}
I can hook up etherInputHookAdd from the vxworks shell like so
etherInputHookAdd etherHook,"fei",0
This returns 0 (STATUS OK), after which examination of the 'anCounter' variable will indicate activity as expected. However, no such luck with the output direction. I've tried both of these command lines
etherOutputHookAdd etherHook,"fei",0
etherOutputHookAdd etherHook
Both of these return OK, but the hook routine doesn't seem to be getting called at all. My best hypotheses are (1) I'm missing an initialization step, or calling it wrong, (2) the etherOutputHookAdd implementation is just a stub, (3) you just can't call it from the shell, or (4) maybe my nic driver implementation is buggy.
Any ideas that solve the central problem - how do I see what's being sent off my board - are welcome.
The following VxWorks network drivers support both the input-hook and output-hook routines:
if_cpm - Motorola MC68EN360 QUICC network interface driver
if_eex - Intel EtherExpress 16
if_ei - Intel 82596 ethernet driver
if_elc - SMC 8013WC Ethernet driver
if_elt - 3Com 3C509 Ethernet driver
if_ene - Novell/Eagle NE2000 network driver
if_fn - Fujitsu MB86960 NICE Ethernet driver
if_ln - Advanced Micro Devices Am7990 LANCE Ethernet driver
if_sm - shared memory backplane network interface driver
if_sn - National Semiconductor DP83932B SONIC Ethernet driver
if_ultra - SMC Elite Ultra Ethernet network interface driver
if_gn - generic MUX interface layer
The following drivers support only the input-hook routines:
if_nic - National Semiconductor SNIC Chip (for HKV30)
if_sl - Serial Line IP (SLIP) network interface driver
The following drivers support only the output-hook routines:
if_ulip - network interface driver for User Level IP (VxSim)
The following drivers do not support either the input-hook or output-hook routines:
if_loop - software loopback network interface driver
To those few who might stumble this way .. It was the horrible 'hypothesis 4'!
It turns out that in order for etherOutputHookAdd() to work correctly, it is incumbent on the NIC device driver writer to include a call to the function pointed to by etherOutputHookRtn. All etherOutputHookAdd() does is add your proffered packet handler to a list, so that when a NIC driver calls etherOutputHookRtn, you get a copy of what's being transmitted. Sadly, there are many drivers where for whatever reason, this was simply not done.
So in cases such as this one, there are only two courses of action.
find a patch for your driver, or patch it yourself
change tactics entirely, e.g., try using etherInputHookAdd() on the other side.
In case you migrate to a newer version (>6.x) of VxWorks , etherLib is no longer supported. Instead, one can use muxLib for a similar purpose.
Hook inbound traffic: Use muxBind with MUX_PROTO_PROMISC or MUX_PROTO_OUTPUT.
Hook outbound traffic: Use muxBind with MUX_PROTO_OUTPUT.
You should provide a callback routine in both cases.