| Products > Embedded Computing |
| implementing ICSP (program Microchip MCU) on a linux SBC |
| << < (3/3) |
| JPortici:
--- Quote from: westfw on September 27, 2024, 07:07:37 am ---Why do you think this would be difficult? --- End quote --- difficult part would be doing it in linux, i guess. I currently shelved the project after a couple of nights of frustating attempt to get things going with a beaglebone black i had laying around, which for the life of me could not get to work (trying to reproduce any example i found on the internet, using old distros or current one, all failed. It's posponed until i get another SBC, one with better community support.) |
| Nominal Animal:
BeagleBone Black has an eMMC issue (Kingston MK2704 4GB eMMC) with 6.x kernels that is apparently being investigated. The eMMC dies a very early death, making the board unusable. I recommend starting with a Debian image with a 5.10.168-ti-r71 kernel and v2022.04 UBoot for your exact BBB variant, here. Other than using Discourse, forum.beagleboard.org is quite active. BBB (TI AM335x "Sitara" SoC) is a valid choice, because of the two PRUs, programmable realtime units, that can handle the actual low-level I/O details, with an userspace program managing the bulk data and control. The AM335x PRU-ICSS Reference Guide (rev. A, PDF) should be very useful. For examples, I do recommend you start with the BeagleBoard ones at github.com/beagleboard/am335x_pru_package and Derek Molloy examples from his book Exploring Beaglebone at github. First, however, do look at the diagrams in the AM335x PRU Linux Application Loader (PDF) to remind you of the structure of the system at hand. Instead of PRU, you can also use the "raw" SPI on BBB, follow the Element14 SPI example, using Derek Molloy's spidev_test code. I have never gotten a BeagleBone Black (or any other BB), because they're relatively expensive for what they are, being over a decade old design. The cheapest I've found is from Mouser, which comes to about 60€ including Finnish VAT 25.5%. (Right now, I'm ogling at Odroid M2, with a PCIe M.2 2280 SSD.) In the same price range as BBB would be Odroid M1S, or a Radxa Rock 5C (2GB) plus a 16 GB eMMC module. For a tiny ICSP SBC, I would consider Radxa Rock Pi S 512MB+8GB+WiFi (Wiki; get the PoE module too if you intend to use it over Ethernet and have PoE capability), or Odroid M1S (Wiki). Note, however, that my suggestions have a HUGE bias: I focus on hardware capabilities and kernel support versus price. I have time and the skills needed to put together my own distro if I want or need, but not much money to spend. I do prefer Debian basis, for a number of reasons; and avoid fork-based "SDK" vendors like a plague (because they get stale faster than wheat rolls). I need examples to understand how the integrators/designers intended various features to be used/configured, but I can extrapolate from there. To me, the way e.g. Fuzhou Rockchip Electronics Co., Ltd. has long-term developers actively contributing support into upstream Linux kernels, as opposed to say a certain United Kingdom foundation with millions of users, is much more significant (due to its long-term implications) than the community or community support. |
| DiTBho:
--- Quote from: westfw on September 27, 2024, 07:07:37 am ---I'm not sure whether it uses the standard COM driver, or FTDI's driver. --- End quote --- FTDI's driver :D The serial part of the kernel has a lot of problems, like the fact that - by default (Vanilla code) - as soon as you open the "/dev/ttyS0" port with e.g. { picocome, minicom, kermit, ... }, there is a driver part of the kernel, related to "ttyS0.open()", that moves the CTS pin, which personally bothers me a lot because it resets my devices. It can be solved in a couple of minutes by hacking the driver, but it's very annoying as the driver is a mess of lines that are supposed to support EOL modem stuff. It was my 50 cents just to say that - for me - the extra serial pins are a formidable mess and it is much better not to touch them because otherwise you have to dedicate extra time to them. On the contrary FTDI USB-serial drivers have the idea of GPIO as "extra pins", which can be used to implement things like jtag and it's not even too bad to work with them. |
| NorthGuy:
Linux driver is just the other end of the file. You write to a file, the driver gets called and does whatever you want it to do. Driver can write to hardware registers or serve interrupts. These registers and interrupts must be provided by some sort of device. Usually, such devices use one of the system buses, such as PCIe or USB, but there could be other ways of interfacing CPU. But at any rate you need some sort of hardware to toggle pins for you. RPi has bunch of pins, which can do UART, SPI etc. They should already have drivers. I've never used them, but it must be very easy as there are hoards of housewives using RPi. I don't know how good these drivers are. Can they produce metered delays, for example? How fast is the feedback loop - i.e. what is the delay between writing an SPI byte and receiving the response? Are the RPi pins suitable for programming? I don't know. But there are many people who use RPi for these purposes, they must know. There must be RPi groups somewhere. |
| Navigation |
| Message Index |
| Previous page |